Sekitar 15 tahun yang lalu, saya bekerja di sebuah perusahaan tempat kami membuat aplikasi untuk agen perjalanan, pekerja bandara, dan perusahaan penerbangan. Kami juga membangun kerangka kerja internal kami sendiri untuk komponen UI dan kemampuan aplikasi satu halaman. Kami memiliki komponen untuk semuanya: bidang, tombol, tab, rentang, tabel data, menu, pemilih tanggal, pilihan, dan pilihan ganda. Kami bahkan memiliki komponen div. Komponen div kami sangat bagus, memungkinkan kami membuat sudut membulat di semua browser, yang, percaya atau tidak, bukanlah hal yang mudah untuk dilakukan pada saat itu.
Pekerjaan kami terjadi pada suatu titik dalam sejarah kami ketika JS, Ajax, dan HTML dinamis dipandang sebagai sebuah revolusi yang membawa kami ke masa depan. Tiba-tiba, kami dapat memperbarui halaman secara dinamis, mendapatkan data dari server, dan menghindari keharusan bernavigasi ke halaman lain, yang dianggap lambat dan menampilkan kotak putih besar di layar di antara dua halaman. Ada ungkapan yang dipopulerkan oleh Jeff Atwood (pendiri StackOverflow), yang berbunyi: “Aplikasi apa pun yang dapat ditulis dalam JavaScript pada akhirnya akan ditulis dalam JavaScript.”— Jeff Atwood
Bagi kami pada saat itu, ini terasa seperti sebuah tantangan untuk benar-benar menciptakan aplikasi tersebut. Rasanya seperti persetujuan menyeluruh untuk melakukan segalanya dengan JS. Jadi kami melakukan segalanya dengan JS, dan kami tidak meluangkan waktu untuk meneliti cara lain dalam melakukan sesuatu. Kami tidak benar-benar merasakan dorongan untuk mempelajari dengan baik apa yang dapat dilakukan HTML dan CSS. Kami tidak benar-benar menganggap web sebagai platform aplikasi yang berkembang secara keseluruhan. Kami sebagian besar melihatnya sebagai sesuatu yang perlu kami atasi, terutama ketika menyangkut dukungan browser. Kita bisa menggunakan lebih banyak JS untuk menyelesaikan sesuatu. Apakah meluangkan waktu untuk mempelajari lebih lanjut tentang cara kerja web dan apa yang tersedia di platform dapat membantu saya? Tentu, saya mungkin bisa menghilangkan banyak kode yang sebenarnya tidak diperlukan. Tapi, pada saat itu, mungkin tidak sebanyak itu. Soalnya, perbedaan browser saat itu cukup signifikan. Ini adalah masa ketika Internet Explorer masih menjadi browser dominan, diikuti Firefox di urutan kedua, namun mulai kehilangan pangsa pasar karena Chrome dengan cepat mendapatkan popularitas. Meskipun Chrome dan Firefox cukup baik dalam menyetujui standar web, lingkungan tempat aplikasi kami berjalan berarti kami harus mendukung IE6 untuk waktu yang lama. Meskipun kami diizinkan untuk mendukung IE8, kami masih harus menghadapi banyak perbedaan antar browser. Tidak hanya itu, web pada saat itu belum memiliki banyak kemampuan yang dibangun langsung ke dalam platformnya.
Maju cepat ke hari ini. Banyak hal telah berubah secara drastis. Kita tidak hanya memiliki lebih banyak kemampuan ini dibandingkan sebelumnya, namun tingkat ketersediaannya juga meningkat. Izinkan saya mengajukan pertanyaan lagi: Apakah meluangkan waktu untuk mempelajari lebih lanjut tentang cara kerja web dan apa yang tersedia di platform dapat membantu Anda saat ini? Tentu saja ya. Belajar memahami dan menggunakan platform web saat ini memberi Anda keuntungan besar dibandingkan pengembang lain. Baik Anda mengerjakan kinerja, aksesibilitas, daya tanggap, semuanya secara bersamaan, atau sekadar mengirimkan fitur UI, jika Anda ingin melakukannya sebagai teknisi yang bertanggung jawab, mengetahui alat yang tersedia untuk Anda akan membantu Anda mencapai sasaran dengan lebih cepat dan lebih baik. Beberapa Hal yang Mungkin Tidak Anda Butuhkan Perpustakaan Lagi Mengetahui browser apa yang didukung saat ini, pertanyaannya adalah: Apa yang bisa kita tinggalkan? Apakah kita memerlukan komponen div untuk melakukan sudut membulat pada tahun 2025? Tentu saja tidak. Properti border-radius telah didukung oleh semua browser yang digunakan saat ini selama lebih dari 15 tahun pada saat ini. Dan bentuk sudut juga akan segera hadir, bahkan untuk sudut yang lebih mewah. Mari kita lihat fitur-fitur yang relatif baru yang kini tersedia di semua browser utama, dan yang dapat Anda gunakan untuk menggantikan dependensi yang ada di basis kode Anda. Intinya bukanlah segera membuang semua perpustakaan kesayangan Anda dan menulis ulang basis kode Anda. Mengenai hal lainnya, Anda harus mempertimbangkan dukungan browser terlebih dahulu dan memutuskan berdasarkan faktor lain yang spesifik untuk proyek Anda. Fitur berikut diterapkan di tiga mesin browser utama (Chromium, WebKit, dan Gecko), namun Anda mungkin memiliki persyaratan dukungan browser berbeda yang menghalangi Anda untuk langsung menggunakannya. Namun, sekarang adalah saat yang tepat untuk mempelajari fitur-fitur ini, dan mungkin berencana untuk menggunakannya suatu saat nanti. Popover dan Dialog API Popover, elemen HTML
Tentu saja, kecepatan koneksi internet Anda mungkin juga meningkat, tetapi hal tersebut tidak terjadi pada semua orang. Dan tidak semua orang juga memiliki kemampuan perangkat yang sama. Sebaliknya, menggunakan kode pihak ketiga untuk hal-hal yang dapat Anda lakukan dengan platform, kemungkinan besar berarti Anda mengirimkan lebih banyak kode, sehingga menjangkau lebih sedikit pelanggan daripada biasanya. Di web, kinerja pemuatan yang buruk menyebabkan tingkat pengabaian yang besar dan merusak reputasi merek. Menjalankan Lebih Sedikit Kode Pada Perangkat Selain itu, kode yang Anda kirimkan ke perangkat pelanggan Anda kemungkinan besar berjalan lebih cepat jika menggunakan lebih sedikit abstraksi JavaScript di atas platform. Ini juga mungkin lebih responsif dan lebih mudah diakses secara default. Semua ini menghasilkan lebih banyak pelanggan dan lebih bahagia. Periksa blog kesenjangan kesenjangan kinerja tahunan rekan saya Alex Russell, yang menunjukkan bahwa sebagian besar perangkat premium absen dari pasar dengan miliaran pengguna karena kesenjangan kekayaan. Dan kesenjangan ini semakin besar seiring berjalannya waktu.
Tata Letak Batu Bawaan Salah satu fitur platform web yang akan segera hadir dan membuat saya sangat bersemangat adalah CSS Masonry.
Mari saya mulai dengan menjelaskan apa itu Masonry. Apa Itu Masonry Masonry adalah jenis tata letak yang dipopulerkan oleh Pinterest beberapa tahun lalu. Ini menciptakan jalur konten independen di mana item dikemas sedekat mungkin dengan awal jalur.
Banyak orang melihat Masonry sebagai pilihan bagus untuk portofolio dan galeri foto, dan hal ini tentu bisa dilakukan. Namun Masonry lebih fleksibel daripada yang Anda lihat di Pinterest, dan tidak terbatas pada tata letak seperti air terjun saja. Dalam tata letak Masonry:
Trek dapat berupa kolom atau baris:
Trek konten tidak semuanya harus berukuran sama:
Item dapat menjangkau beberapa track:
Item dapat ditempatkan di jalur tertentu; mereka tidak harus selalu mengikuti algoritma penempatan otomatis:
Demo Berikut adalah beberapa demo sederhana yang saya buat dengan menggunakan implementasi CSS Masonry yang akan datang di Chromium. Demo galeri foto, menunjukkan bagaimana item (dalam hal ini judulnya) dapat menjangkau beberapa track:
Galeri foto lain yang menampilkan trek dengan ukuran berbeda:
Tata letak situs berita dengan beberapa trek lebih lebar dari yang lain, dan beberapa item mencakup seluruh lebar tata letak:
Papan kanban yang menunjukkan bahwa item dapat ditempatkan pada jalur tertentu:
Catatan: Itudemo sebelumnya dibuat dengan versi Chromium yang belum tersedia untuk sebagian besar pengguna web, karena CSS Masonry baru saja mulai diterapkan di browser. Namun, pengembang web dengan senang hati menggunakan perpustakaan untuk membuat tata letak Masonry selama bertahun-tahun. Situs yang Menggunakan Masonry Saat Ini Memang benar, Masonry cukup umum di web saat ini. Berikut beberapa contoh yang saya temukan selain Pinterest:
Dan beberapa contoh lagi yang kurang jelas:
Jadi, bagaimana tata letak ini dibuat? Solusi Salah satu trik yang pernah saya lihat digunakan adalah menggunakan tata letak Flexbox, mengubah arahnya ke kolom, dan mengaturnya menjadi bungkus. Dengan cara ini, Anda dapat menempatkan item dengan ketinggian berbeda di beberapa kolom independen, sehingga memberikan kesan tata letak Masonry:
Namun, ada dua batasan dalam solusi ini:
Urutan item berbeda dari tata letak Masonry yang sebenarnya. Dengan Flexbox, item mengisi kolom pertama terlebih dahulu dan, jika sudah penuh, baru berpindah ke kolom berikutnya. Dengan Masonry, item akan ditumpuk di trek mana pun (atau kolom dalam hal ini) yang memiliki lebih banyak ruang tersedia. Namun juga, dan mungkin yang lebih penting, solusi ini mengharuskan Anda menyetel ketinggian tetap pada wadah Flexbox; jika tidak, pembungkusan tidak akan terjadi.
Perpustakaan Masonry pihak ketiga Untuk kasus lebih lanjut, pengembang telah menggunakan perpustakaan. Perpustakaan paling terkenal dan populer untuk ini disebut Masonry, dan diunduh sekitar 200.000 kali per minggu menurut NPM. Squarespace juga menyediakan komponen tata letak yang menampilkan tata letak Masonry, untuk alternatif tanpa kode, dan banyak situs yang menggunakannya. Kedua opsi ini menggunakan kode JavaScript untuk menempatkan item dalam tata letak. Batu bawaan Saya sangat gembira karena Masonry kini mulai muncul di browser sebagai fitur CSS bawaan. Seiring waktu, Anda akan dapat menggunakan Masonry seperti yang Anda lakukan pada Grid atau Flexbox, tanpa memerlukan solusi atau kode pihak ketiga apa pun. Tim saya di Microsoft telah mengimplementasikan dukungan Masonry bawaan dalam proyek sumber terbuka Chromium, yang menjadi dasar Edge, Chrome, dan banyak browser lainnya. Mozilla sebenarnya adalah vendor browser pertama yang mengusulkan implementasi eksperimental Masonry pada tahun 2020. Dan Apple juga sangat tertarik untuk mewujudkan tata letak web primitif baru ini. Pekerjaan untuk menstandardisasi fitur ini juga sedang berjalan, dengan kesepakatan dalam kelompok kerja CSS tentang arah umum dan bahkan jenis tampilan baru display: grid-lanes. Jika Anda ingin mempelajari lebih lanjut tentang Masonry dan melacak kemajuannya, lihat halaman sumber daya CSS Masonry saya. Pada waktunya, ketika Masonry menjadi fitur Dasar, seperti Grid atau Flexbox, kita akan dapat menggunakannya dan mendapatkan manfaat dari:
Performa lebih baik, Responsif yang lebih baik, Kemudahan penggunaan dan kode yang lebih sederhana.
Mari kita lihat lebih dekat hal ini. Performa Lebih Baik Membuat sistem tata letak mirip Masonry Anda sendiri, atau menggunakan perpustakaan pihak ketiga, berarti Anda harus menjalankan kode JavaScript untuk menempatkan item di layar. Ini juga berarti bahwa kode ini akan memblokir render. Memang benar, tidak ada yang akan muncul, atau segala sesuatunya tidak akan berada di tempat atau ukuran yang tepat, sampai kode JavaScript tersebut dijalankan. Tata letak pasangan bata sering digunakan untuk bagian utama halaman web, yang berarti kode tersebut akan membuat konten utama Anda muncul lebih lambat dari yang seharusnya, menurunkan LCP, atau metrik Cat Konten Terbesar, yang memainkan peran besar dalam persepsi kinerja dan optimasi mesin pencari. Saya menguji perpustakaan Masonry JS dengan tata letak sederhana dan dengan mensimulasikan koneksi 4G yang lambat di DevTools. Pustakanya tidak terlalu besar (24KB, 7,8KB gzip), tetapi butuh waktu 600 ms untuk memuat dalam kondisi pengujian saya. Berikut adalah rekaman kinerja yang menunjukkan waktu muat 600 ms yang panjang untuk perpustakaan Masonry, dan tidak ada aktivitas rendering lain yang terjadi saat hal itu terjadi:
Selain itu, setelah waktu pemuatan awal, skrip yang diunduh perlu diurai, dikompilasi, dan kemudian dijalankan. Semuanya, seperti disebutkan sebelumnya, memblokir rendering halaman. Dengan implementasi Masonry bawaan di browser, kita tidak akan memiliki skrip untuk dimuat dan dijalankan. Mesin browser hanya akan melakukan tugasnya selama langkah rendering halaman awal. Responsif yang Lebih Baik Mirip dengan saat halaman pertama kali dimuat, mengubah ukuran jendela browser akan menyebabkan rendering tata letak halaman tersebut lagi. Namun pada titik ini, jika halaman menggunakan perpustakaan Masonry JS, tidak perlu memuat skrip lagi, karena sudahDi Sini. Namun, kode yang memindahkan item di tempat yang tepat harus dijalankan. Sekarang perpustakaan khusus ini tampaknya cukup cepat dalam melakukan hal ini ketika halaman dimuat. Namun, ini menganimasikan item ketika mereka perlu dipindahkan ke tempat lain saat mengubah ukuran jendela, dan ini membuat perbedaan besar. Tentu saja, pengguna tidak menghabiskan waktu untuk mengubah ukuran jendela browser mereka seperti yang kami lakukan sebagai pengembang. Namun pengalaman pengubahan ukuran animasi ini bisa sangat mengejutkan dan menambah waktu yang dibutuhkan halaman untuk beradaptasi dengan ukuran barunya. Kemudahan Penggunaan Dan Kode Lebih Sederhana Betapa mudahnya menggunakan fitur web dan betapa sederhananya tampilan kode merupakan faktor penting yang dapat membuat perbedaan besar bagi tim Anda. Tentu saja, hal tersebut tidak akan pernah sepenting pengalaman pengguna akhir, namun pengalaman pengembang memengaruhi kemudahan pemeliharaan. Menggunakan fitur web bawaan memberikan manfaat penting:
Pengembang yang sudah mengetahui HTML, CSS, dan JS kemungkinan besar akan dapat menggunakan fitur tersebut dengan mudah karena fitur tersebut dirancang untuk berintegrasi dengan baik dan konsisten dengan platform web lainnya. Tidak ada risiko gangguan terhadap perubahan yang diterapkan pada cara fitur digunakan. Hampir tidak ada risiko fitur tersebut menjadi tidak digunakan lagi atau tidak dikelola.
Dalam kasus Masonry bawaan, karena tata letaknya primitif, Anda menggunakannya dari CSS, seperti Grid atau Flexbox, tidak melibatkan JS. Selain itu, properti CSS terkait tata letak lainnya, seperti gap, berfungsi sesuai harapan Anda. Tidak ada trik atau solusi yang perlu diketahui, dan hal-hal yang Anda pelajari didokumentasikan di MDN. Untuk lib Masonry JS, inisialisasi agak rumit: memerlukan atribut data dengan sintaksis tertentu, bersama dengan elemen HTML tersembunyi untuk mengatur ukuran kolom dan celah. Selain itu, jika Anda ingin merentangkan kolom, Anda perlu memasukkan sendiri ukuran celahnya untuk menghindari masalah:
Mari kita bandingkan ini dengan penerapan Masonry bawaan:
Kode yang lebih sederhana dan ringkas yang hanya dapat menggunakan hal-hal seperti gap dan di mana spanning track dilakukan dengan span 2, seperti pada grid, dan tidak mengharuskan Anda menghitung lebar yang tepat termasuk ukuran gap. Bagaimana Mengetahui Apa yang Tersedia dan Kapan Tersedia? Secara keseluruhan, pertanyaannya bukan apakah Anda harus menggunakan Masonry bawaan melalui perpustakaan JS, melainkan kapan. Perpustakaan Masonry JS luar biasa dan telah mengisi kesenjangan dalam platform web selama bertahun-tahun, dan bagi banyak pengembang dan pengguna yang bahagia. Tentu saja, ini memiliki beberapa kelemahan jika Anda membandingkannya dengan implementasi Masonry bawaan, namun hal tersebut tidak penting jika implementasi tersebut belum siap. Sangat mudah bagi saya untuk membuat daftar fitur platform web baru yang keren ini karena saya bekerja di vendor browser, dan oleh karena itu saya cenderung mengetahui apa yang akan terjadi. Namun pengembang sering kali menyampaikan, survei demi survei, bahwa melacak hal-hal baru itu sulit. Mendapatkan informasi itu sulit, dan perusahaan tidak selalu memprioritaskan pembelajaran. Untuk membantu hal ini, berikut beberapa sumber daya yang menyediakan pembaruan dengan cara yang sederhana dan ringkas sehingga Anda bisa mendapatkan informasi yang Anda perlukan dengan cepat:
Platform Web menampilkan situs penjelajah: Anda mungkin tertarik dengan halaman catatan rilisnya. Dan, jika Anda menyukai RSS, periksa feed catatan rilis, serta feed Baseline yang Baru Tersedia dan Tersedia Secara Luas.
WebDasbor Status Platform: Anda mungkin menyukai berbagai halaman tahun Dasarnya.
Halaman peta jalan Status Platform Chrome.
Jika Anda memiliki lebih banyak waktu, Anda mungkin juga tertarik dengan catatan rilis vendor browser:
krom Tepi Firefox Safari
Untuk lebih banyak sumber daya, lihat Cheatsheet Menavigasi Platform Web saya. Hal Saya Masih Belum Diimplementasikan Itulah sisi lain dari permasalahannya. Sekalipun Anda punya waktu, energi, dan cara untuk memantau perkembangannya, masih ada rasa frustrasi saat suara Anda didengar dan fitur favorit Anda diterapkan. Mungkin Anda telah menunggu bertahun-tahun untuk memperbaiki bug tertentu, atau fitur tertentu dikirimkan ke browser yang masih belum ada. Yang ingin saya katakan adalah vendor browser mendengarkan. Saya adalah bagian dari beberapa tim lintas organisasi tempat kami mendiskusikan sinyal dan masukan pengembang sepanjang waktu. Kami melihat berbagai sumber umpan balik, baik internal di setiap vendor browser maupun eksternal/publik di forum, proyek sumber terbuka, blog, dan survei. Dan, kami selalu berusaha menciptakan cara yang lebih baik bagi pengembang untuk berbagi kebutuhan spesifik dan kasus penggunaan mereka. Jadi, jika Anda bisa, mohon minta lebih banyak dari vendor browser dan tekan kami untuk mengimplementasikan fitur yang Anda perlukan. Saya mengerti bahwa ini membutuhkan waktu, dan juga bisa mengintimidasi (belum lagi hambatan masuk yang tinggi), tetapi ini juga berhasil. Berikut adalah beberapa cara agar pendapat Anda (atau perusahaan Anda) didengar: Ikuti survei tahunan Status JS, Status CSS, dan Status HTML. Mereka memainkan peran besar dalam cara vendor browser memprioritaskan pekerjaan mereka. Jika Anda memerlukan API berbasis standar tertentu untuk diterapkan secara konsisten di seluruh browser, pertimbangkan untuk mengirimkan proposal pada iterasi proyek Interop berikutnya. Ini membutuhkan lebih banyak waktu, tetapi pertimbangkan bagaimana Shopify dan RUMvision membagikan daftar keinginan mereka untuk Interop 2026. Informasi mendetail seperti ini bisa sangat berguna untuk diprioritaskan oleh vendor browser. Untuk link yang lebih berguna untuk mempengaruhi vendor browser, lihat Cheatsheet Menavigasi Platform Web saya. Kesimpulan Sebagai penutup, saya harap artikel ini memberi Anda beberapa hal untuk dipikirkan:
Kegembiraan untuk Masonry dan fitur web lain yang akan datang. Beberapa fitur web yang mungkin ingin Anda mulai gunakan. Beberapa bagian kode khusus atau pihak ketiga yang mungkin dapat Anda hapus demi fitur bawaan. Beberapa cara untuk melacak apa yang akan datang dan memengaruhi vendor browser.
Yang lebih penting lagi, saya harap saya dapat meyakinkan Anda tentang manfaat menggunakan platform web secara maksimal.
