Kira-kira 15 taun kepungkur, aku kerja ing perusahaan sing nggawe aplikasi kanggo agen perjalanan, buruh bandara, lan perusahaan penerbangan. Kita uga nggawe kerangka internal dhewe kanggo komponen UI lan kemampuan aplikasi siji-halaman. Kita duwe komponen kanggo kabeh: kolom, tombol, tab, kisaran, datatables, menu, datepickers, pilih, lan multiselects. Kita malah duwe komponen div. Komponen div kita apik banget, ngidini kita nindakake sudhut sing dibunderaké ing kabeh browser, sing, pracaya utawa ora, ora gampang ditindakake nalika iku.
Karya kita dumadi ing sawijining titik ing sajarah kita nalika JS, Ajax, lan HTML dinamis katon minangka revolusi sing nggawa kita menyang mangsa ngarep. Semalat, kita bisa nganyari kaca kanthi dinamis, entuk data saka server, lan supaya ora kudu navigasi menyang kaca liya, sing katon alon lan sumunar persegi panjang putih gedhe ing layar ing antarane rong kaca kasebut. Ana frasa, digawe populer dening Jeff Atwood (pendiri StackOverflow), sing maca: "Aplikasi apa wae sing bisa ditulis ing JavaScript pungkasane bakal ditulis ing JavaScript." - Jeff Atwood
Kanggo kita ing wektu, iki felt kaya wani kanggo bener pindhah lan nggawe app sing. Iku felt kaya persetujuan kemul kanggo nindakake kabeh karo JS. Dadi kita nindakake kabeh karo JS, lan kita ora njupuk wektu kanggo riset cara liya kanggo nindakake samubarang. Kita ora ngrasakake insentif kanggo sinau kanthi bener apa sing bisa ditindakake HTML lan CSS. Kita ora nganggep web minangka platform aplikasi sing berkembang kanthi lengkap. Umume kita ndeleng minangka perkara sing kudu ditindakake, utamane babagan dhukungan browser. Kita mung bisa mbuwang luwih akeh JS kanggo ngrampungake. Apa njupuk wektu kanggo sinau luwih lengkap babagan cara kerja web lan apa sing kasedhiya ing platform mbantu aku? Mesthi, aku bisa uga wis nyukur akeh kode sing ora dibutuhake. Nanging, ing wektu, bisa uga ora akeh. Sampeyan ndeleng, beda browser cukup signifikan nalika iku. Iki minangka wektu nalika Internet Explorer isih dadi browser sing dominan, kanthi Firefox dadi nomer loro sing cedhak, nanging wiwit ilang pangsa pasar amarga Chrome kanthi cepet entuk popularitas. Sanajan Chrome lan Firefox cukup apik kanggo setuju karo standar web, lingkungan ing ngendi aplikasi kita mlaku tegese kita kudu ndhukung IE6 nganti suwe. Malah nalika diijini ndhukung IE8, kita isih kudu ngatasi akeh beda antarane browser. Ora mung iku, nanging web wektu mung ora duwe sing akeh kapabilitas dibangun langsung menyang platform.
Cepet maju kanggo dina iki. Perkara wis owah banget. Ora mung kita duwe kapabilitas iki luwih akeh tinimbang sadurunge, nanging tingkat sing kasedhiya uga saya tambah. Ayo kula takon maneh, banjur: Apa njupuk wektu kanggo sinau luwih lengkap babagan cara kerja web lan apa sing kasedhiya ing platform mbantu sampeyan saiki? Pancen iya. Sinau mangertos lan nggunakake platform web saiki ndadekake sampeyan entuk keuntungan gedhe tinimbang pangembang liyane. Apa sampeyan nggarap kinerja, aksesibilitas, responsif, kabeh mau bebarengan, utawa mung ngirim fitur UI, yen sampeyan pengin nindakake minangka insinyur sing tanggung jawab, ngerti alat sing kasedhiya kanggo sampeyan mbantu sampeyan nggayuh tujuan kanthi luwih cepet lan luwih apik. Sawetara Prekara Sampeyan Bisa Ora Mbutuhake Pustaka maneh Ngerti apa browser ndhukung saiki, pitakonan, banjur, punika: Apa kita bisa selokan? Apa kita butuh komponen div kanggo nindakake sudhut bunder ing 2025? Mesthi, kita ora. Properti radius wates wis didhukung dening kabeh browser sing saiki digunakake luwih saka 15 taun ing wektu iki. Lan sudhut-wangun uga teka rauh, kanggo sudhut malah fancier. Ayo goleki fitur sing relatif anyar sing saiki kasedhiya ing kabeh browser utama, lan sing bisa digunakake kanggo ngganti dependensi sing ana ing basis kode sampeyan. Intine ora langsung ngilangi kabeh perpustakaan sing ditresnani lan nulis maneh basis kode. Kanggo kabeh liyane, sampeyan kudu nganggep dhukungan browser dhisik lan mutusake adhedhasar faktor liyane sing spesifik kanggo proyek sampeyan. Fitur ing ngisor iki dileksanakake ing telung mesin browser utama (Chromium, WebKit, lan Gecko), nanging sampeyan bisa uga duwe syarat dhukungan browser sing beda sing nyegah sampeyan langsung nggunakake. Saiki isih wektu sing apik kanggo sinau babagan fitur-fitur kasebut, lan bisa uga rencana nggunakake ing sawetara titik. Popovers Lan Dialog Popover API,
Mesthi, kacepetan sambungan internet sampeyan uga wis tambah, nanging ora kabeh wong. Lan ora saben wong duwe kemampuan piranti sing padha. Narik kode pihak katelu kanggo perkara sing bisa sampeyan lakoni karo platform kasebut, mesthine tegese sampeyan ngirim kode luwih akeh, mula entuk luwih sithik pelanggan tinimbang biasane. Ing web, kinerja loading ala ndadékaké kanggo tingkat abandonment gedhe lan cilaka reputasi merek. Mlaku Kurang Kode Ing Piranti Salajengipun, kode sing dikirim ing piranti pelanggan sampeyan bisa mlaku luwih cepet yen nggunakake abstraksi JavaScript sing luwih sithik ing ndhuwur platform. Sampeyan uga bisa uga luwih responsif lan luwih gampang diakses kanthi standar. Kabeh iki ndadékaké kanggo pelanggan liyane lan seneng. Priksa blog kesenjangan kinerja tahunan kolega Alex Russell, sing nuduhake manawa piranti premium umume ora ana ing pasar kanthi milyaran pangguna amarga ora seimbang. Lan kesenjangan iki mung saya suwe saya suwe.
Layout Masonry sing dibangun Salah sawijining fitur platform web sing bakal teka lan aku seneng banget yaiku CSS Masonry.
Ayo kula miwiti kanthi nerangake apa Masonry. Apa Masonry Masonry minangka jinis tata letak sing digawe populer dening Pinterest taun kepungkur. Iku nggawe trek independen saka isi ing kang item Pack piyambak munggah minangka cedhak wiwitan trek minangka padha bisa.
Akeh wong sing ndeleng Masonry minangka pilihan sing apik kanggo portofolio lan galeri foto, sing bisa ditindakake. Nanging Masonry luwih fleksibel tinimbang sing sampeyan deleng ing Pinterest, lan ora diwatesi mung tata letak kaya grojogan. Ing tata letak Masonry:
Trek bisa dadi kolom utawa baris:
Trek konten ora kabeh kudu padha ukurane:
Item bisa ngliwati pirang-pirang trek:
Item bisa diselehake ing trek tartamtu; dheweke ora kudu tansah ngetutake algoritma penempatan otomatis:
Demo Ing ngisor iki sawetara demo prasaja sing digawe kanthi nggunakake implementasi CSS Masonry ing Chromium. Tur galeri foto, nuduhake carane item (judhul ing kasus iki) bisa mbentang sawetara trek:
Galeri foto liyane sing nuduhake trek kanthi ukuran sing beda:
Tata letak situs warta kanthi sawetara trek luwih amba tinimbang liyane, lan sawetara item sing nyakup kabeh jembar tata letak:
Papan kanban sing nuduhake yen item bisa diselehake ing trek tartamtu:
Cathetan: Ingdemo sadurunge digawe karo versi Chromium sing durung kasedhiya kanggo umume pangguna web, amarga CSS Masonry mung diwiwiti kanggo dileksanakake ing browser. Nanging, pangembang web kanthi seneng nggunakake perpustakaan kanggo nggawe tata letak Masonry wis pirang-pirang taun. Situs Nggunakake Masonry Dina Pancen, Masonry cukup umum ing web saiki. Ing ngisor iki sawetara conto sing ditemokake saliyane Pinterest:
Lan sawetara conto liyane, kurang jelas:
Dadi, kepiye tata letak kasebut digawe? Workarounds Siji trik sing dakdeleng digunakake yaiku nggunakake tata letak Flexbox, ngganti arah menyang kolom, lan nyetel kanggo mbungkus. Kanthi cara iki, sampeyan bisa nyelehake item kanthi dhuwur sing beda-beda ing pirang-pirang kolom independen, menehi kesan tata letak Masonry:
Nanging, ana rong watesan karo solusi iki:
Urutan barang beda karo tata letak Masonry sing nyata. Kanthi Flexbox, item ngisi kolom pisanan lan, yen wis kebak, banjur pindhah menyang kolom sabanjure. Kanthi Masonry, item bakal ditumpuk ing trek endi wae (utawa kolom ing kasus iki) duwe ruang luwih akeh. Nanging uga, lan mbok menawa liyane Jahwéh, workaround iki mbutuhake sampeyan nyetel dhuwur tetep kanggo wadhah Flexbox; digunakake, ora mbungkus bakal kelakon.
Pustaka Masonry pihak katelu Kanggo kasus sing luwih maju, pangembang wis nggunakake perpustakaan. Perpustakaan sing paling kondhang lan populer kanggo iki mung diarani Masonry, lan diundhuh udakara 200,000 kaping saben minggu miturut NPM. Squarespace uga nyedhiyakake komponen tata letak sing nggawe tata letak Masonry, kanggo alternatif tanpa kode, lan akeh situs sing nggunakake. Kaloro opsi kasebut nggunakake kode JavaScript kanggo nyelehake item ing tata letak. Masonry sing dibangun Aku bungah banget yen Masonry saiki wiwit katon ing browser minangka fitur CSS sing dibangun. Suwe-suwe, sampeyan bakal bisa nggunakake Masonry kaya Grid utawa Flexbox, yaiku, tanpa mbutuhake solusi utawa kode pihak katelu. Timku ing Microsoft wis ngetrapake dhukungan Masonry sing dibangun ing proyek sumber terbuka Chromium, sing adhedhasar Edge, Chrome, lan akeh browser liyane. Mozilla sejatine minangka vendor browser pertama sing ngusulake implementasi eksperimen Masonry ing taun 2020. Lan Apple uga kepengin banget nggawe tata letak web anyar iki dadi primitif. Pakaryan kanggo standarisasi fitur kasebut uga maju, kanthi persetujuan ing klompok kerja CSS babagan arah umum lan uga tampilan jinis tampilan anyar: jalur-jalur. Yen sampeyan pengin sinau luwih lengkap babagan Masonry lan nglacak kemajuan, priksa kaca sumber CSS Masonry. Ing wektu, nalika Masonry dadi fitur Baseline, kaya Grid utawa Flexbox, kita bakal bisa nggunakake lan entuk manfaat saka:
Kinerja sing luwih apik, Respon luwih apik, Ease saka nggunakake lan kode prasaja.
Ayo padha nliti iki. Kinerja sing luwih apik Nggawe sistem tata letak kaya Masonry dhewe, utawa nggunakake perpustakaan pihak katelu, tegese sampeyan kudu mbukak kode JavaScript kanggo nyelehake item ing layar. Iki uga tegese kode iki bakal diblokir. Pancen, ora ana sing bakal katon, utawa samubarang ora ana ing panggonan sing bener utawa ukuran sing bener, nganti kode JavaScript kasebut wis mlaku. Tata letak masonry asring digunakake kanggo bagean utama kaca web, tegese kode kasebut bakal nggawe konten utama sampeyan katon luwih cepet tinimbang sing bisa ditindakake, ngremehake LCP, utawa metrik Cat Isi Paling Terbesar, sing nduwe peran gedhe ing kinerja sing dirasakake lan optimasi mesin telusur. Aku dites perpustakaan Masonry JS karo tata prasaja lan simulating sambungan 4G alon ing DevTools. Perpustakaan ora amba banget (24KB, 7.8KB gzipped), nanging njupuk 600ms kanggo mbukak ing kahanan test sandi. Iki minangka rekaman kinerja sing nuduhake wektu mbukak 600ms dawa kanggo perpustakaan Masonry, lan ora ana kegiatan rendering liyane nalika kedadeyan kasebut:
Kajaba iku, sawise wektu mbukak wiwitan, skrip sing diundhuh banjur kudu diurai, dikompilasi, lan banjur diluncurake. Kabeh mau, kaya sing wis kasebut sadurunge, ngalangi rendering kaca kasebut. Kanthi implementasi Masonry sing dibangun ing browser, kita ora bakal duwe skrip kanggo mbukak lan mbukak. Mesin browser mung bakal nindakake sajrone langkah rendering kaca wiwitan. Responsif sing luwih apik Kaya nalika kaca pisanan dimuat, ngowahi ukuran jendhela browser ndadékaké kanggo nerjemahake tata letak ing kaca kasebut maneh. Nanging, ing wektu iki, yen kaca nggunakake perpustakaan Masonry JS, ora perlu mbukak skrip maneh, amarga wiskene. Nanging, kode sing mindhah item ing panggonan tengen kudu mbukak. Saiki perpustakaan tartamtu iki katon cepet banget nalika nindakake iki nalika kaca dimuat. Nanging, iku animates item nalika padha kudu pindhah menyang panggonan liyane ing ukuran jendhela, lan iki ndadekake prabédan amba. Mesthine, pangguna ora nglampahi wektu ngowahi ukuran jendhela browser kaya sing ditindakake para pangembang. Nanging pengalaman ngowahi ukuran animasi iki bisa dadi jarring lan nambah wektu sing dirasakake supaya kaca bisa adaptasi karo ukuran anyar. Gampang Gunakake Lan Kode Luwih Gampang Carane gampang nggunakake fitur web lan carane prasaja kode katon minangka faktor penting sing bisa nggawe prabédan gedhe kanggo tim sampeyan. Dheweke ora bisa dadi penting kaya pengalaman pangguna pungkasan, mesthine, nanging pengalaman pangembang duwe pengaruh kanggo njaga. Nggunakake fitur web sing dibangun ing ngarep duwe keuntungan sing penting:
Pangembang sing wis ngerti HTML, CSS, lan JS bakal bisa nggunakake fitur kasebut kanthi gampang amarga wis dirancang kanggo nggabungake kanthi apik lan konsisten karo platform web liyane. Ora ana risiko ngrusak owah-owahan babagan cara nggunakake fitur kasebut. Ana meh ora ana risiko fitur kasebut dadi ora bisa digunakake utawa ora dijaga.
Ing kasus Masonry sing dibangun, amarga tata letak primitif, sampeyan nggunakake saka CSS, kaya Grid utawa Flexbox, ora ana JS. Uga, properti CSS sing gegandhengan karo tata letak liyane, kayata gap, bisa digunakake kaya sing dikarepake. Ora ana trik utawa solusi sing kudu dingerteni, lan perkara sing sampeyan sinau didokumentasikake ing MDN. Kanggo lib Masonry JS, initialization rada rumit: mbutuhake atribut data kanthi sintaks tartamtu, bebarengan karo unsur HTML sing didhelikake kanggo nyetel ukuran kolom lan longkangan. Kajaba iku, yen sampeyan pengin mbentang kolom, sampeyan kudu nyakup ukuran longkangan dhewe kanggo ngindhari masalah:
Ayo mbandhingake iki karo implementasi Masonry sing dibangun ing:
Kode sing luwih prasaja lan luwih kompak sing mung bisa digunakake kaya gap lan ing ngendi trek spanning rampung karo span 2, kaya ing kothak, lan ora mbutuhake sampeyan ngetung jembar sing tepat sing kalebu ukuran longkangan. Kepiye Cara Ngerti Apa Sing Kasedhiya lan Nalika Wis kasedhiya? Sakabèhé, pitakonan iki dudu yen sampeyan kudu nggunakake Masonry sing dibangun ing perpustakaan JS, nanging nalika. Perpustakaan Masonry JS pancen apik tenan lan wis ngisi kesenjangan ing platform web sajrone pirang-pirang taun, lan kanggo akeh pangembang lan pangguna sing seneng. Nduwe sawetara kekurangan yen sampeyan mbandhingake karo implementasi Masonry sing dibangun, mesthine, nanging ora penting yen implementasine durung siyap. Iku gampang kanggo kula kanggo dhaptar fitur platform web anyar kelangan iki amarga aku makarya ing vendor browser, lan mulane aku kathah ngerti apa sing bakal teka. Nanging pangembang asring nuduhake, survey sawise survey, yen nglacak perkara anyar iku angel. Tetep informed angel, lan perusahaan ora tansah prioritas sinau. Kanggo mbantu iki, ana sawetara sumber daya sing nyedhiyakake nganyari kanthi cara sing prasaja lan kompak supaya sampeyan bisa entuk informasi sing dibutuhake kanthi cepet:
Platform Web nduweni fitur situs explorer: Sampeyan bisa uga kasengsem ing kaca cathetan rilis. Lan, yen sampeyan seneng RSS, priksa feed cathetan rilis, uga feed Baseline Newly Available lan Widely Available.
WebDasbor Status Platform: Sampeyan bisa uga seneng macem-macem kaca taun Baseline.
Kaca peta dalan Status Platform Chrome.
Yen sampeyan duwe wektu luwih suwe, sampeyan bisa uga kasengsem karo cathetan rilis vendor browser:
Chrome Pinggir Firefox Safari
Kanggo sumber daya liyane, priksa Cheatsheet Navigasi ing Web Platform. Bab Kula Isih Ora Dilaksanakake Sing sisih liyane saka masalah. Sanajan sampeyan nemokake wektu, energi, lan cara kanggo nglacak, isih ana frustasi nalika krungu swara lan fitur favorit sampeyan dileksanakake. Mungkin sampeyan wis ngenteni pirang-pirang taun kanggo ngrampungake bug tartamtu, utawa fitur tartamtu kanggo dikirim ing browser sing isih ilang. Apa sing bakal dakkandhakake yaiku vendor browser ngrungokake. Aku bagean saka sawetara tim lintas-organisasi ngendi kita ngrembug sinyal pangembang lan saran kabeh wektu. Kita ndeleng macem-macem sumber umpan balik, internal ing saben vendor browser lan eksternal / umum ing forum, proyek sumber terbuka, blog, lan survey. Lan, kita tansah nyoba nggawe cara sing luwih apik kanggo pangembang kanggo nuduhake kabutuhan tartamtu lan kasus panggunaan. Dadi, yen sampeyan bisa, njaluk luwih akeh saka vendor browser lan meksa supaya bisa ngetrapake fitur sing sampeyan butuhake. Aku njaluk sing njupuk wektu, lan uga bisa intimidating (ora kanggo sebutno alangi dhuwur kanggo entri), nanging uga dianggo. Ing ngisor iki sawetara cara sampeyan bisa krungu swara (utawa perusahaan sampeyan): Njupuk survey taunan State of JS, State of CSS, lan State of HTML. Dheweke nduwe peran gedhe babagan carane vendor browser prioritize karyane. Yen sampeyan mbutuhake API basis standar tartamtu kanggo dileksanakake terus-terusan ing browser, nimbang ngirim proposal ing pengulangan project Interop sabanjuré. Mbutuhake wektu luwih akeh, nanging nimbang carane Shopify lan RUMvision nuduhake dhaptar pesenan kanggo Interop 2026. Informasi rinci kaya iki bisa migunani banget kanggo vendor browser supaya prioritas. Kanggo pranala sing luwih migunani kanggo pengaruhe vendor browser, priksa Cheatsheet Navigasi ing Web Platform. Kesimpulan Kanggo nutup, muga-muga artikel iki menehi sawetara perkara sing kudu dipikirake:
Kasenengan kanggo Masonry lan fitur web mbesuk liyane. Sawetara fitur web sing sampeyan pengin miwiti nggunakake. Sawetara potongan kode khusus utawa pihak katelu sing bisa dicopot kanggo fitur sing wis dibangun. Sawetara cara kanggo nglacak apa sing bakal teka lan pengaruhe vendor browser.
Sing luwih penting, muga-muga aku bisa ngyakinake sampeyan babagan keuntungan nggunakake platform web kanthi potensial.
