Kira-kira 15 tahun yang lalu, saya bekerja di sebuah syarikat tempat kami membina apl untuk ejen pelancongan, pekerja lapangan terbang dan syarikat penerbangan. Kami juga membina rangka kerja dalaman kami sendiri untuk komponen UI dan keupayaan aplikasi satu halaman. Kami mempunyai komponen untuk segala-galanya: medan, butang, tab, julat, jadual data, menu, pemilih tarikh, pilihan dan pilihan berbilang. Kami juga mempunyai komponen div. Komponen div kami sangat bagus, ia membenarkan kami melakukan sudut bulat pada semua penyemak imbas, yang, percaya atau tidak, bukanlah perkara yang mudah untuk dilakukan pada masa itu.
Kerja kami berlaku pada satu titik dalam sejarah kami apabila JS, Ajax, dan HTML dinamik dilihat sebagai revolusi yang membawa kami ke masa hadapan. Tiba-tiba, kami boleh mengemas kini halaman secara dinamik, mendapatkan data daripada pelayan dan mengelak daripada menavigasi ke halaman lain, yang dilihat sebagai perlahan dan memancarkan segi empat tepat putih besar pada skrin antara dua halaman. Terdapat frasa, yang dipopularkan oleh Jeff Atwood (pengasas StackOverflow), yang berbunyi: "Sebarang aplikasi yang boleh ditulis dalam JavaScript akhirnya akan ditulis dalam JavaScript." - Jeff Atwood
Bagi kami pada masa itu, ini terasa seperti berani untuk pergi dan mencipta aplikasi tersebut. Rasanya seperti kelulusan menyeluruh untuk melakukan segala-galanya dengan JS. Jadi kami melakukan segala-galanya dengan JS, dan kami tidak benar-benar meluangkan masa untuk menyelidik cara lain untuk melakukan sesuatu. Kami tidak benar-benar merasakan insentif untuk mempelajari dengan betul perkara yang boleh dilakukan oleh HTML dan CSS. Kami tidak benar-benar menganggap web sebagai platform aplikasi yang berkembang secara keseluruhannya. Kami kebanyakannya melihatnya sebagai sesuatu yang perlu kami selesaikan, terutamanya apabila ia berkaitan dengan sokongan penyemak imbas. Kami hanya boleh membuang lebih banyak JS padanya untuk menyelesaikan sesuatu. Adakah meluangkan masa untuk mengetahui lebih lanjut tentang cara web berfungsi dan perkara yang tersedia pada platform telah membantu saya? Sudah tentu, saya mungkin telah mencukur sekumpulan kod yang tidak benar-benar diperlukan. Tetapi, pada masa itu, mungkin tidak begitu banyak. Anda lihat, perbezaan penyemak imbas agak ketara ketika itu. Ini adalah masa apabila Internet Explorer masih menjadi penyemak imbas yang dominan, dengan Firefox menjadi yang kedua, tetapi mula kehilangan bahagian pasaran kerana Chrome semakin popular. Walaupun Chrome dan Firefox agak mahir dalam menyetujui piawaian web, persekitaran di mana apl kami dijalankan bermakna kami terpaksa menyokong IE6 untuk masa yang lama. Walaupun apabila kami dibenarkan menyokong IE8, kami masih perlu berurusan dengan banyak perbezaan antara penyemak imbas. Bukan itu sahaja, tetapi web pada masa itu tidak mempunyai banyak keupayaan yang dibina terus ke dalam platform.
Cepat ke hari ini. Perkara telah berubah dengan ketara. Kami bukan sahaja mempunyai lebih banyak keupayaan ini berbanding sebelum ini, tetapi kadar ia tersedia telah meningkat juga. Izinkan saya bertanya soalan itu sekali lagi, kemudian: Adakah meluangkan masa untuk mengetahui lebih lanjut tentang cara web berfungsi dan perkara yang tersedia pada platform membantu anda hari ini? betul-betul ya. Belajar untuk memahami dan menggunakan platform web hari ini memberikan anda kelebihan besar berbanding pembangun lain. Sama ada anda mengusahakan prestasi, kebolehaksesan, responsif, kesemuanya bersama-sama atau hanya menghantar ciri UI, jika anda mahu melakukannya sebagai jurutera yang bertanggungjawab, mengetahui alatan yang tersedia untuk anda membantu anda mencapai matlamat anda dengan lebih pantas dan lebih baik. Beberapa Perkara Yang Anda Mungkin Tidak Memerlukan Perpustakaan Lagi Mengetahui apa yang pelayar menyokong hari ini, persoalannya, kemudian, ialah: Apa yang boleh kita parit? Adakah kita memerlukan komponen div untuk melakukan sudut bulat pada tahun 2025? Sudah tentu, kami tidak. Sifat jejari sempadan telah disokong oleh semua penyemak imbas yang sedang digunakan selama lebih daripada 15 tahun pada ketika ini. Dan bentuk sudut juga akan datang tidak lama lagi, untuk sudut yang lebih menarik. Mari kita lihat ciri yang agak terkini yang kini tersedia dalam semua penyemak imbas utama, dan yang boleh anda gunakan untuk menggantikan kebergantungan sedia ada dalam pangkalan kod anda. Maksudnya bukan untuk segera membuang semua perpustakaan yang anda sayangi dan menulis semula pangkalan kod anda. Bagi yang lain, anda perlu mengambil kira sokongan penyemak imbas terlebih dahulu dan membuat keputusan berdasarkan faktor lain yang khusus untuk projek anda. Ciri berikut dilaksanakan dalam tiga enjin penyemak imbas utama (Chromium, WebKit dan Gecko), tetapi anda mungkin mempunyai keperluan sokongan penyemak imbas yang berbeza yang menghalang anda daripada menggunakannya serta-merta. Sekarang masih masa yang baik untuk belajar tentang ciri ini, walaupun, dan mungkin merancang untuk menggunakannya pada satu ketika. Popovers Dan Dialog API Popover, elemen HTML
Sudah tentu, kelajuan sambungan internet anda mungkin telah meningkat juga, tetapi itu tidak berlaku untuk semua orang. Dan tidak semua orang mempunyai keupayaan peranti yang sama sama ada. Menarik kod pihak ketiga untuk perkara yang boleh anda lakukan dengan platform, sebaliknya, kemungkinan besar bermakna anda menghantar lebih banyak kod dan oleh itu menjangkau lebih sedikit pelanggan daripada yang biasa anda lakukan. Di web, prestasi pemuatan yang buruk membawa kepada kadar pengabaian yang besar dan menjejaskan reputasi jenama. Menjalankan Kurang Kod Pada Peranti Tambahan pula, kod yang anda hantar pada peranti pelanggan anda berkemungkinan berjalan lebih pantas jika menggunakan lebih sedikit abstraksi JavaScript di atas platform. Ia juga mungkin lebih responsif dan lebih mudah diakses secara lalai. Semua ini membawa kepada lebih ramai pelanggan dan lebih gembira. Semak blog jurang ketidaksamaan prestasi tahunan rakan sekerja saya Alex Russell, yang menunjukkan bahawa peranti premium sebahagian besarnya tidak hadir dalam pasaran dengan berbilion pengguna disebabkan ketidaksamaan kekayaan. Dan jurang ini hanya berkembang dari semasa ke semasa.
Reka Letak Batu Terbina dalam Satu ciri platform web yang akan datang tidak lama lagi dan yang saya sangat teruja ialah CSS Masonry.
Biar saya mulakan dengan menerangkan apa itu Masonry. Apa Itu Masonry Masonry ialah sejenis susun atur yang dipopularkan oleh Pinterest tahun lalu. Ia mencipta trek bebas kandungan di mana item membungkus diri mereka sehampir mungkin dengan permulaan trek.
Ramai orang melihat Masonry sebagai pilihan hebat untuk portfolio dan galeri foto, yang pastinya boleh dilakukan. Tetapi Masonry lebih fleksibel daripada apa yang anda lihat di Pinterest, dan ia tidak terhad kepada reka letak seperti air terjun sahaja. Dalam susun atur Masonry:
Lagu boleh menjadi lajur atau baris:
Runut kandungan tidak semestinya saiz yang sama:
Item boleh merangkumi berbilang trek:
Item boleh diletakkan pada trek tertentu; mereka tidak perlu sentiasa mengikut algoritma peletakan automatik:
tunjuk cara Berikut ialah beberapa tunjuk cara mudah yang saya buat dengan menggunakan pelaksanaan CSS Masonry yang akan datang dalam Chromium. Demo galeri foto, menunjukkan cara item (tajuk dalam kes ini) boleh merangkumi berbilang trek:
Galeri foto lain menunjukkan trek dengan saiz yang berbeza:
Reka letak tapak berita dengan beberapa trek lebih luas daripada yang lain dan beberapa item yang merangkumi keseluruhan lebar reka letak:
Papan kanban yang menunjukkan bahawa item boleh diletakkan pada trek tertentu:
Nota: Thetunjuk cara sebelumnya telah dibuat dengan versi Chromium yang belum lagi tersedia kepada kebanyakan pengguna web, kerana CSS Masonry baru mula dilaksanakan dalam penyemak imbas. Walau bagaimanapun, pembangun web dengan senang hati menggunakan perpustakaan untuk mencipta susun atur Masonry selama bertahun-tahun. Tapak Menggunakan Masonry Hari Ini Sesungguhnya, Masonry adalah perkara biasa di web hari ini. Berikut adalah beberapa contoh yang saya temui selain Pinterest:
Dan beberapa lagi, kurang jelas, contoh:
Jadi, bagaimana reka letak ini dicipta? Penyelesaian Satu helah yang saya lihat digunakan ialah menggunakan reka letak Flexbox sebaliknya, menukar arahnya kepada lajur dan menetapkannya untuk membalut. Dengan cara ini, anda boleh meletakkan item ketinggian yang berbeza dalam berbilang lajur bebas, memberikan gambaran reka letak Masonry:
Walau bagaimanapun, terdapat dua batasan dengan penyelesaian ini:
Susunan item adalah berbeza daripada susun atur Masonry sebenar. Dengan Flexbox, item mengisi lajur pertama dahulu dan, apabila ia penuh, kemudian pergi ke lajur seterusnya. Dengan Masonry, item akan disusun dalam mana-mana trek (atau lajur dalam kes ini) yang mempunyai lebih banyak ruang. Tetapi juga, dan mungkin yang lebih penting, penyelesaian ini memerlukan anda menetapkan ketinggian tetap pada bekas Flexbox; jika tidak, tiada pembalut akan berlaku.
Perpustakaan Masonry pihak ketiga Untuk kes yang lebih maju, pembangun telah menggunakan perpustakaan. Perpustakaan yang paling terkenal dan popular untuk ini hanya dipanggil Masonry, dan ia dimuat turun kira-kira 200,000 kali seminggu mengikut NPM. Squarespace juga menyediakan komponen reka letak yang menghasilkan susun atur Masonry, untuk alternatif tanpa kod, dan banyak tapak menggunakannya. Kedua-dua pilihan ini menggunakan kod JavaScript untuk meletakkan item dalam reka letak. Batu Terbina dalam Saya sangat teruja kerana Masonry kini mula muncul dalam pelayar sebagai ciri CSS terbina dalam. Lama kelamaan, anda akan dapat menggunakan Masonry seperti yang anda lakukan Grid atau Flexbox, iaitu, tanpa memerlukan sebarang penyelesaian atau kod pihak ketiga. Pasukan saya di Microsoft telah melaksanakan sokongan Masonry terbina dalam dalam projek sumber terbuka Chromium, yang digunakan oleh Edge, Chrome dan banyak penyemak imbas lain. Mozilla sebenarnya adalah vendor penyemak imbas pertama yang mencadangkan pelaksanaan eksperimen Masonry pada tahun 2020. Dan Apple juga sangat berminat untuk menjadikan reka letak web baharu ini primitif berlaku. Kerja untuk menyeragamkan ciri juga sedang berjalan, dengan persetujuan dalam kumpulan kerja CSS tentang arah umum dan juga paparan jenis paparan baharu: lorong grid. Jika anda ingin mengetahui lebih lanjut tentang Masonry dan menjejaki kemajuan, lihat halaman sumber CSS Masonry saya. Pada masanya, apabila Masonry menjadi ciri Baseline, sama seperti Grid atau Flexbox, kami akan dapat menggunakannya dengan mudah dan mendapat manfaat daripada:
Prestasi yang lebih baik, Responsif yang lebih baik, Kemudahan penggunaan dan kod yang lebih ringkas.
Mari kita lihat ini dengan lebih dekat. Prestasi Lebih Baik Membuat sistem susun atur seperti Masonry anda sendiri, atau menggunakan pustaka pihak ketiga sebaliknya, bermakna anda perlu menjalankan kod JavaScript untuk meletakkan item pada skrin. Ini juga bermakna bahawa kod ini akan menyebabkan penyekatan. Sesungguhnya, sama ada tiada apa yang akan muncul, atau perkara tidak akan berada di tempat yang betul atau saiz yang betul, sehingga kod JavaScript itu telah dijalankan. Reka letak batu sering digunakan untuk bahagian utama halaman web, yang bermaksud kod tersebut akan menjadikan kandungan utama anda dipaparkan lebih lewat daripada yang sepatutnya, merendahkan LCP anda atau metrik Cat Kandungan Terbesar, yang memainkan peranan besar dalam persepsi prestasi dan pengoptimuman enjin carian. Saya menguji perpustakaan Masonry JS dengan susun atur yang mudah dan dengan mensimulasikan sambungan 4G yang perlahan dalam DevTools. Pustaka ini tidak begitu besar (24KB, 7.8KB gzip), tetapi ia mengambil masa 600ms untuk dimuatkan di bawah keadaan ujian saya. Berikut ialah rakaman prestasi yang menunjukkan masa muat 600ms yang panjang untuk perpustakaan Masonry dan tiada aktiviti pemaparan lain berlaku semasa perkara itu berlaku:
Selain itu, selepas masa muat awal, skrip yang dimuat turun kemudiannya perlu dihuraikan, disusun dan kemudian dijalankan. Kesemuanya, seperti yang dinyatakan sebelum ini, menyekat pemaparan halaman. Dengan pelaksanaan Masonry terbina dalam dalam penyemak imbas, kami tidak akan mempunyai skrip untuk dimuatkan dan dijalankan. Enjin penyemak imbas hanya akan melakukan perkara itu semasa langkah pemaparan halaman awal. Responsif yang Lebih Baik Sama seperti apabila halaman mula-mula dimuatkan, mengubah saiz tetingkap penyemak imbas membawa kepada memaparkan reka letak dalam halaman itu semula. Pada ketika ini, walaupun, jika halaman menggunakan perpustakaan Masonry JS, tidak perlu memuatkan skrip sekali lagi, kerana ia sudah pundi sini. Walau bagaimanapun, kod yang mengalihkan item di tempat yang betul perlu dijalankan. Kini perpustakaan khusus ini nampaknya cukup pantas untuk melakukan ini apabila halaman dimuatkan. Walau bagaimanapun, ia menghidupkan item apabila mereka perlu berpindah ke tempat lain pada saiz semula tetingkap, dan ini membuat perbezaan yang besar. Sudah tentu, pengguna tidak menghabiskan masa mengubah saiz tetingkap penyemak imbas mereka seperti yang kami lakukan oleh pembangun. Tetapi pengalaman mengubah saiz animasi ini boleh menjadi agak membingungkan dan menambah kepada jangkaan masa yang diperlukan untuk halaman menyesuaikan diri dengan saiz baharunya. Kemudahan Penggunaan Dan Kod Lebih Ringkas Betapa mudahnya untuk menggunakan ciri web dan betapa ringkasnya kod itu adalah faktor penting yang boleh membuat perubahan besar untuk pasukan anda. Sudah tentu, mereka tidak boleh menjadi sepenting pengalaman pengguna akhir, tetapi pengalaman pembangun memberi kesan kepada kebolehselenggaraan. Menggunakan ciri web terbina dalam datang dengan faedah penting di bahagian hadapan itu:
Pembangun yang sudah mengetahui HTML, CSS dan JS berkemungkinan besar akan dapat menggunakan ciri tersebut dengan mudah kerana ia telah direka bentuk untuk disepadukan dengan baik dan konsisten dengan seluruh platform web. Tiada risiko melanggar perubahan yang diperkenalkan dalam cara ciri itu digunakan. Terdapat hampir sifar risiko ciri itu menjadi tidak digunakan atau tidak diselenggara.
Dalam kes Masonry terbina dalam, kerana ia adalah reka letak primitif, anda menggunakannya daripada CSS, sama seperti Grid atau Flexbox, tiada JS yang terlibat. Selain itu, sifat CSS berkaitan reka letak lain, seperti gap, berfungsi seperti yang anda harapkan. Tiada helah atau penyelesaian yang perlu diketahui, dan perkara yang anda pelajari didokumenkan di MDN. Untuk lib Masonry JS, pemulaan agak rumit: ia memerlukan atribut data dengan sintaks tertentu, bersama-sama dengan elemen HTML tersembunyi untuk menetapkan saiz lajur dan jurang. Selain itu, jika anda ingin menjangkau lajur, anda perlu memasukkan sendiri saiz jurang untuk mengelakkan masalah:
Mari bandingkan ini dengan rupa pelaksanaan Masonry terbina dalam:
Kod yang lebih ringkas dan lebih padat yang hanya boleh menggunakan perkara seperti jurang dan tempat trek rentang dilakukan dengan rentang 2, sama seperti dalam grid dan tidak memerlukan anda mengira lebar yang betul yang merangkumi saiz jurang. Bagaimana Untuk Mengetahui Apa Yang Tersedia Dan Bila Ia Tersedia? Secara keseluruhannya, persoalannya bukanlah sama ada anda perlu menggunakan Masonry terbina dalam ke atas perpustakaan JS, tetapi apabila. Perpustakaan Masonry JS sangat mengagumkan dan telah mengisi jurang dalam platform web selama bertahun-tahun, dan untuk ramai pembangun dan pengguna yang gembira. Ia mempunyai beberapa kelemahan jika anda membandingkannya dengan pelaksanaan Masonry terbina dalam, sudah tentu, tetapi itu tidak penting jika pelaksanaan itu belum siap. Mudah bagi saya untuk menyenaraikan ciri platform web baharu yang hebat ini kerana saya bekerja di vendor penyemak imbas, dan oleh itu saya cenderung untuk mengetahui perkara yang akan datang. Tetapi pembangun sering berkongsi, tinjauan demi tinjauan, bahawa menjejaki perkara baharu adalah sukar. Mengekalkan maklumat adalah sukar, dan syarikat tidak selalu mengutamakan pembelajaran. Untuk membantu dengan perkara ini, berikut ialah beberapa sumber yang menyediakan kemas kini dengan cara yang ringkas dan padat supaya anda boleh mendapatkan maklumat yang anda perlukan dengan cepat:
Platform Web menampilkan tapak peneroka: Anda mungkin berminat dengan halaman nota keluarannya. Dan, jika anda menyukai RSS, lihat suapan nota keluaran, serta suapan Baseline Newly Available dan Widely Available.
WebPapan pemuka Status Platform: Anda mungkin menyukai pelbagai halaman tahun Baselinenya.
Halaman peta jalan Status Platform Chrome.
Jika anda mempunyai sedikit masa lagi, anda mungkin juga berminat dengan nota keluaran vendor penyemak imbas:
Chrome Tepi Firefox Safari
Untuk mendapatkan lebih banyak sumber, lihat Lembaran Cheat Navigasi Platform Web saya. Perkara Saya Masih Tidak Dilaksanakan Itulah sisi lain masalahnya. Walaupun anda mencari masa, tenaga dan cara untuk menjejaki, masih ada kekecewaan untuk mendengar suara anda dan ciri kegemaran anda dilaksanakan. Mungkin anda telah menunggu selama bertahun-tahun untuk pepijat tertentu diselesaikan, atau ciri khusus untuk dihantar dalam penyemak imbas yang masih tiada. Apa yang saya akan katakan ialah vendor penyemak imbas memang mendengar. Saya sebahagian daripada beberapa pasukan merentas organisasi tempat kami membincangkan isyarat pembangun dan maklum balas sepanjang masa. Kami melihat banyak sumber maklum balas yang berbeza, dalaman pada setiap vendor penyemak imbas dan luaran/awam di forum, projek sumber terbuka, blog dan tinjauan. Dan, kami sentiasa cuba mencipta cara yang lebih baik untuk pembangun berkongsi keperluan khusus dan kes penggunaan mereka. Jadi, jika anda boleh, sila minta lebih banyak daripada vendor penyemak imbas dan tekan kami untuk melaksanakan ciri yang anda perlukan. Saya faham bahawa ia memerlukan masa, dan juga boleh menakutkan (apatah lagi halangan yang tinggi untuk masuk), tetapi ia juga berfungsi. Berikut ialah beberapa cara anda boleh mendengar suara anda (atau syarikat anda): Ambil tinjauan tahunan State of JS, State of CSS dan State of HTML. Mereka memainkan peranan besar dalam cara vendor penyemak imbas mengutamakan kerja mereka. Jika anda memerlukan API berasaskan standard khusus untuk dilaksanakan secara konsisten merentas penyemak imbas, pertimbangkan untuk menyerahkan cadangan pada lelaran projek Interop seterusnya. Ia memerlukan lebih banyak masa, tetapi pertimbangkan cara Shopify dan RUMvision berkongsi senarai keinginan mereka untuk Interop 2026. Maklumat terperinci seperti ini boleh menjadi sangat berguna untuk vendor penyemak imbas untuk diutamakan. Untuk pautan yang lebih berguna untuk mempengaruhi vendor penyemak imbas, lihat Lembaran Cheat Navigasi Platform Web saya. Kesimpulan Untuk menutup, saya harap artikel ini memberi anda beberapa perkara untuk difikirkan:
Keterujaan untuk Masonry dan ciri web lain yang akan datang. Beberapa ciri web yang anda mungkin mahu mula gunakan. Beberapa keping kod tersuai atau pihak ketiga yang mungkin anda boleh alih keluar untuk memihak kepada ciri terbina dalam. Beberapa cara untuk menjejaki perkara yang akan datang dan mempengaruhi vendor penyemak imbas.
Lebih penting lagi, saya harap saya telah meyakinkan anda tentang faedah menggunakan platform web sepenuhnya.
