Mga 15 taon na ang nakalipas, nagtatrabaho ako sa isang kumpanya kung saan nagtayo kami ng mga app para sa mga ahente sa paglalakbay, manggagawa sa paliparan, at mga kumpanya ng airline. Bumuo din kami ng sarili naming in-house na framework para sa mga bahagi ng UI at mga kakayahan ng app sa isang pahina. Mayroon kaming mga bahagi para sa lahat: mga field, button, tab, range, datatable, menu, datepicker, select, at multiselect. Nagkaroon pa kami ng div component. Mahusay ang aming bahagi ng div, pinahintulutan kaming gumawa ng mga pabilog na sulok sa lahat ng mga browser, na, maniwala ka man o hindi, ay hindi isang madaling bagay na gawin noong panahong iyon.
Ang aming gawain ay naganap sa isang punto sa aming kasaysayan nang ang JS, Ajax, at dynamic na HTML ay nakita bilang isang rebolusyon na nagdala sa amin sa hinaharap. Bigla, maaari naming i-update ang isang pahina nang dynamic, kumuha ng data mula sa isang server, at maiwasan ang pag-navigate sa iba pang mga pahina, na nakitang mabagal at nag-flash ng malaking puting parihaba sa screen sa pagitan ng dalawang pahina. Mayroong isang parirala, na ginawang tanyag ni Jeff Atwood (ang tagapagtatag ng StackOverflow), na nagbabasa: "Anumang application na maaaring isulat sa JavaScript ay sa kalaunan ay isusulat sa JavaScript." - Jeff Atwood
Para sa amin noong panahong iyon, parang isang lakas ng loob na talagang pumunta at gumawa ng mga app na iyon. Parang isang blanket na pag-apruba na gawin ang lahat sa JS. Kaya ginawa namin ang lahat sa JS, at hindi talaga kami naglaan ng oras para magsaliksik ng iba pang paraan ng paggawa ng mga bagay. Hindi talaga namin naramdaman ang insentibo upang matutunan nang maayos kung ano ang magagawa ng HTML at CSS. Hindi namin talaga naisip ang web bilang isang umuusbong na platform ng app sa kabuuan nito. Karamihan ay nakita namin ito bilang isang bagay na kailangan naming ayusin, lalo na pagdating sa suporta sa browser. Maaari lang namin itong ihagis ng higit pang JS para magawa ang mga bagay-bagay. Nakatulong ba sa akin ang paglalaan ng oras upang matuto nang higit pa tungkol sa kung paano gumagana ang web at kung ano ang available sa platform? Oo naman, malamang na nag-ahit ako ng isang grupo ng code na hindi talaga kailangan. Ngunit, sa oras na iyon, marahil ay hindi gaanong. Kita mo, ang mga pagkakaiba sa browser ay medyo makabuluhan noon. Ito ang panahon kung saan ang Internet Explorer pa rin ang nangingibabaw na browser, kung saan ang Firefox ang naging malapit na pangalawa, ngunit nagsisimula nang mawalan ng bahagi sa merkado dahil sa mabilis na pagkakaroon ng katanyagan ng Chrome. Bagama't medyo mahusay ang Chrome at Firefox sa pagsang-ayon sa mga pamantayan sa web, ang mga kapaligiran kung saan tumatakbo ang aming mga app ay nangangahulugan na kailangan naming suportahan ang IE6 sa mahabang panahon. Kahit na pinahintulutan kaming suportahan ang IE8, kailangan pa rin naming harapin ang maraming pagkakaiba sa pagitan ng mga browser. Hindi lang iyon, ngunit ang web ng panahon ay walang ganoong karaming kakayahan na binuo mismo sa platform.
Fast forward hanggang ngayon. Ang mga bagay ay nagbago nang husto. Hindi lamang mayroon tayong higit sa mga kakayahan na ito kaysa dati, ngunit ang bilis ng pagiging available ng mga ito ay tumaas din. Hayaan akong magtanong muli, kung gayon: Makakatulong ba sa iyo ngayon ang paglalaan ng oras upang matuto nang higit pa tungkol sa kung paano gumagana ang web at kung ano ang available sa platform? Oo naman. Ang pag-aaral na maunawaan at gamitin ang web platform ngayon ay nagbibigay sa iyo ng malaking kalamangan sa iba pang mga developer. Magtrabaho ka man sa performance, accessibility, responsiveness, lahat ng ito nang magkasama, o nagpapadala lang ng mga feature ng UI, kung gusto mong gawin ito bilang isang responsableng engineer, ang pag-alam sa mga tool na available sa iyo ay makakatulong sa iyong maabot ang iyong mga layunin nang mas mabilis at mas mahusay. Ilang Bagay na Maaaring Hindi Mo Na Kailangan Ng Aklatan Ang pag-alam kung ano ang sinusuportahan ng mga browser ngayon, ang tanong, kung gayon, ay: Ano ang maaari nating itapon? Kailangan ba natin ng div component para makagawa ng mga rounded corner sa 2025? Siyempre, hindi namin ginagawa. Ang pag-aari ng border-radius ay suportado ng lahat ng kasalukuyang ginagamit na browser nang higit sa 15 taon sa puntong ito. At malapit na rin ang hugis ng sulok, para sa mas magarbong sulok. Tingnan natin ang mga relatibong kamakailang feature na available na ngayon sa lahat ng pangunahing browser, at magagamit mo para palitan ang mga kasalukuyang dependency sa iyong codebase. Ang punto ay hindi agad itapon ang lahat ng iyong minamahal na aklatan at muling isulat ang iyong codebase. Tulad ng para sa lahat ng iba pa, kakailanganin mong isaalang-alang muna ang suporta sa browser at magpasya batay sa iba pang mga salik na partikular sa iyong proyekto. Ang mga sumusunod na feature ay ipinatupad sa tatlong pangunahing browser engine (Chromium, WebKit, at Gecko), ngunit maaari kang magkaroon ng iba't ibang mga kinakailangan sa suporta sa browser na pumipigil sa iyong gamitin kaagad ang mga ito. Ngayon ay isang magandang panahon pa rin upang malaman ang tungkol sa mga tampok na ito, bagaman, at marahil ay planong gamitin ang mga ito sa isang punto. Mga Popover At Dialog Ang Popover API, ang
Oo naman, malamang na tumaas din ang bilis ng iyong koneksyon sa internet, ngunit hindi iyon ang kaso para sa lahat. At hindi lahat ay may parehong kakayahan sa device. Ang pagkuha ng code ng third-party para sa mga bagay na maaari mong gawin sa platform, sa halip, malamang ay nangangahulugan na nagpapadala ka ng mas maraming code, at samakatuwid ay naaabot ang mas kaunting mga customer kaysa sa karaniwan mong ginagawa. Sa web, ang hindi magandang performance sa pag-load ay humahantong sa malalaking rate ng pag-abandona at nakakasama sa reputasyon ng brand. Pagpapatakbo ng Mas Kaunting Code Sa Mga Device Higit pa rito, ang code na iyong ipinapadala sa mga device ng iyong mga customer ay malamang na tumakbo nang mas mabilis kung gumagamit ito ng mas kaunting mga abstraction ng JavaScript sa itaas ng platform. Ito rin ay malamang na mas tumutugon at mas naa-access bilang default. Ang lahat ng ito ay humahantong sa mas marami at mas masaya na mga customer. Tingnan ang taunang blog ng hindi pagkakapantay-pantay ng pagganap ng aking kasamahan na si Alex Russell, na nagpapakita na ang mga premium na device ay halos wala sa mga merkado na may bilyun-bilyong user dahil sa hindi pagkakapantay-pantay ng yaman. At ang puwang na ito ay lumalaki lamang sa paglipas ng panahon.
Built-in na Layout ng Masonry Isang tampok sa web platform na paparating na at labis kong ikinatuwa ay ang CSS Masonry.
Hayaan akong magsimula sa pamamagitan ng pagpapaliwanag kung ano ang Masonry. Ano ang Pagmamason Ang pagmamason ay isang uri ng layout na ginawang tanyag ng Pinterest taon na ang nakalipas. Lumilikha ito ng mga independiyenteng track ng nilalaman kung saan ang mga item ay naka-pack sa kanilang mga sarili nang malapit sa simula ng track hangga't maaari.
Nakikita ng maraming tao ang Masonry bilang isang magandang opsyon para sa mga portfolio at photo gallery, na tiyak na magagawa nito. Ngunit mas flexible ang Masonry kaysa sa nakikita mo sa Pinterest, at hindi ito limitado sa mga layout na parang waterfall lang. Sa isang layout ng Masonry:
Ang mga track ay maaaring mga column o row:
Hindi kailangang magkapareho ang laki ng mga track ng content:
Maaaring sumasaklaw ang mga item sa maraming track:
Maaaring ilagay ang mga item sa mga partikular na track; hindi nila kailangang palaging sundin ang algorithm ng awtomatikong placement:
Mga demo Narito ang ilang simpleng demo na ginawa ko sa pamamagitan ng paggamit sa paparating na pagpapatupad ng CSS Masonry sa Chromium. Isang demo ng photo gallery, na nagpapakita kung paano maaaring sumasaklaw ang mga item (ang pamagat sa kasong ito) sa maraming track:
Isa pang photo gallery na nagpapakita ng mga track ng iba't ibang laki:
Isang layout ng site ng balita na may ilang mga track na mas malawak kaysa sa iba, at ilang mga item na sumasaklaw sa buong lapad ng layout:
Isang kanban board na nagpapakita na ang mga item ay maaaring ilagay sa mga partikular na track:
Tandaan: Angang mga nakaraang demo ay ginawa gamit ang isang bersyon ng Chromium na hindi pa available sa karamihan ng mga user ng web, dahil nagsisimula pa lang ipatupad ang CSS Masonry sa mga browser. Gayunpaman, ang mga web developer ay masayang gumagamit ng mga aklatan upang lumikha ng mga layout ng Masonry sa loob ng maraming taon. Mga Site na Gumagamit ng Masonry Ngayon Sa katunayan, ang Masonry ay medyo karaniwan sa web ngayon. Narito ang ilang mga halimbawa na nakita ko bukod sa Pinterest:
At ilan pa, hindi gaanong halata, mga halimbawa:
Kaya, paano nilikha ang mga layout na ito? Mga solusyon Ang isang trick na nakita kong ginamit ay ang paggamit ng layout ng Flexbox sa halip, binabago ang direksyon nito sa column, at itinatakda ito upang i-wrap. Sa ganitong paraan, maaari kang maglagay ng mga item na may iba't ibang taas sa maramihang, independiyenteng mga column, na nagbibigay ng impresyon ng layout ng Masonry:
Gayunpaman, mayroong dalawang limitasyon sa workaround na ito:
Ang pagkakasunud-sunod ng mga item ay iba sa kung ano ito sa isang tunay na layout ng Masonry. Sa Flexbox, punan muna ng mga item ang unang column at, kapag puno na ito, pagkatapos ay pumunta sa susunod na column. Sa Masonry, ang mga item ay sasalansan sa alinmang track (o column sa kasong ito) ay may mas maraming espasyong magagamit. Ngunit gayundin, at marahil mas mahalaga, ang workaround na ito ay nangangailangan na magtakda ka ng isang nakapirming taas sa lalagyan ng Flexbox; kung hindi, walang pambalot na magaganap.
Third-party na Masonry Libraries Para sa mas advanced na mga kaso, ang mga developer ay gumagamit ng mga aklatan. Ang pinakakilala at tanyag na aklatan para dito ay tinatawag na Masonry, at nada-download ito nang humigit-kumulang 200,000 beses bawat linggo ayon sa NPM. Nagbibigay din ang Squarespace ng bahagi ng layout na nag-render ng layout ng Masonry, para sa alternatibong walang code, at ginagamit ito ng maraming site. Pareho sa mga opsyong ito ay gumagamit ng JavaScript code upang ilagay ang mga item sa layout. Built-in na Pagmamason Talagang nasasabik ako na ang Masonry ay nagsisimula na ngayong lumitaw sa mga browser bilang isang built-in na tampok na CSS. Sa paglipas ng panahon, magagamit mo ang Masonry tulad ng ginagawa mo sa Grid o Flexbox, iyon ay, nang hindi nangangailangan ng anumang mga workaround o third-party na code. Ang aking koponan sa Microsoft ay nagpapatupad ng built-in na suporta sa Masonry sa Chromium open source na proyekto, kung saan nakabatay ang Edge, Chrome, at marami pang ibang browser. Ang Mozilla talaga ang unang vendor ng browser na nagmungkahi ng eksperimental na pagpapatupad ng Masonry noong 2020. At naging interesado rin ang Apple na gawing primitive ang bagong web layout na ito. Nagpapatuloy din ang gawaing i-standardize ang feature, na may kasunduan sa loob ng CSS working group tungkol sa pangkalahatang direksyon at kahit isang bagong display type na display: grid-lanes. Kung gusto mong matuto nang higit pa tungkol sa Masonry at subaybayan ang pag-unlad, tingnan ang aking CSS Masonry resources page. Sa kalaunan, kapag ang Masonry ay naging isang tampok na Baseline, tulad ng Grid o Flexbox, magagamit lang natin ito at makikinabang sa:
Mas mahusay na pagganap, Mas mahusay na pagtugon, Dali ng paggamit at mas simpleng code.
Tingnan natin ang mga ito nang mas malapitan. Mas mahusay na Pagganap Ang paggawa ng sarili mong sistema ng layout na mala-Masonry, o gumamit na lang ng third-party na library, ay nangangahulugang kailangan mong patakbuhin ang JavaScript code para maglagay ng mga item sa screen. Nangangahulugan din ito na ang code na ito ay magiging render blocking. Sa katunayan, alinman sa walang lalabas, o ang mga bagay ay wala sa mga tamang lugar o sa tamang laki, hanggang sa tumakbo ang JavaScript code na iyon. Ang masonry layout ay kadalasang ginagamit para sa pangunahing bahagi ng isang web page, na nangangahulugan na ang code ay magpapalabas ng iyong pangunahing nilalaman sa ibang pagkakataon kaysa sa maaaring mangyari, na nagpapasama sa iyong LCP, o Pinakamalaking Contentful Paint na sukatan, na gumaganap ng malaking papel sa nakikitang pagganap at pag-optimize ng search engine. Sinubukan ko ang library ng Masonry JS gamit ang isang simpleng layout at sa pamamagitan ng pagtulad sa isang mabagal na koneksyon sa 4G sa DevTools. Ang library ay hindi masyadong malaki (24KB, 7.8KB na naka-gzip), ngunit tumagal ng 600ms bago mag-load sa ilalim ng aking mga kondisyon sa pagsubok. Narito ang isang performance recording na nagpapakita ng mahabang 600ms load time para sa Masonry library, at walang ibang aktibidad sa pag-render na nangyari habang nangyayari iyon:
Bilang karagdagan, pagkatapos ng unang oras ng pag-load, ang na-download na script noon ay kailangang i-parse, i-compile, at pagkatapos ay patakbuhin. Lahat ng ito, tulad ng nabanggit kanina, ay humaharang sa pag-render ng pahina. Sa pamamagitan ng built-in na pagpapatupad ng Masonry sa browser, wala kaming script na ilo-load at tatakbo. Gagawin lang ng browser engine ang bagay nito sa paunang hakbang sa pag-render ng page. Mas mahusay na Pagtugon Katulad noong unang nag-load ang isang page, ang pagbabago ng laki ng browser window ay humahantong sa pag-render muli ng layout sa page na iyon. Gayunpaman, sa puntong ito, kung ang page ay gumagamit ng Masonry JS library, hindi na kailangang i-load muli ang script, dahil ito aydito. Gayunpaman, kailangang tumakbo ang code na naglilipat ng mga item sa mga tamang lugar. Ngayon ang partikular na library na ito ay tila medyo mabilis sa paggawa nito kapag nag-load ang pahina. Gayunpaman, binibigyang-buhay nito ang mga item kapag kailangan nilang lumipat sa ibang lugar sa pagbabago ng laki ng window, at ito ay gumagawa ng malaking pagkakaiba. Siyempre, hindi gumugugol ng oras ang mga user sa pagbabago ng laki ng kanilang mga browser window gaya ng ginagawa naming mga developer. Ngunit ang animated na karanasan sa pagbabago ng laki na ito ay maaaring medyo nakakagulo at nagdaragdag sa nakikitang oras na kinakailangan para sa page na umangkop sa bagong laki nito. Dali ng Paggamit At Mas Simpleng Code Gaano kadaling gumamit ng web feature at kung gaano kasimple ang hitsura ng code ay mahalagang mga salik na maaaring gumawa ng malaking pagkakaiba para sa iyong koponan. Siyempre, hindi sila maaaring maging kasinghalaga ng panghuling karanasan ng user, ngunit ang karanasan ng developer ay nakakaapekto sa pagpapanatili. Ang paggamit ng built-in na web feature ay may kasamang mahahalagang benepisyo sa harap na iyon:
Ang mga developer na alam na ang HTML, CSS, at JS ay malamang na madaling magamit ang feature na iyon dahil ito ay idinisenyo upang maisama nang maayos at maging pare-pareho sa natitirang bahagi ng web platform. Walang panganib na masira ang mga pagbabago na ipinakilala sa kung paano ginagamit ang feature. Halos walang panganib na ang feature na iyon ay hindi na ginagamit o hindi pinapanatili.
Sa kaso ng built-in na Masonry, dahil isa itong primitive na layout, ginagamit mo ito mula sa CSS, tulad ng Grid o Flexbox, walang kasamang JS. Gayundin, gumagana ang iba pang mga katangian ng CSS na nauugnay sa layout, gaya ng gap, gaya ng inaasahan mo sa kanila. Walang mga trick o workaround na dapat malaman, at ang mga bagay na natutunan mo ay nakadokumento sa MDN. Para sa Masonry JS lib, medyo kumplikado ang pagsisimula: nangangailangan ito ng attribute ng data na may partikular na syntax, kasama ang mga nakatagong elemento ng HTML upang itakda ang mga laki ng column at gap. Dagdag pa, kung gusto mong mag-span ng mga column, kailangan mong isama ang laki ng gap sa iyong sarili upang maiwasan ang mga problema:
Ihambing natin ito sa kung ano ang magiging hitsura ng isang built-in na pagpapatupad ng Masonry:
Mas simple, mas compact na code na maaari lang gumamit ng mga bagay tulad ng gap at kung saan ang mga spanning track ay ginagawa gamit ang span 2, tulad ng sa grid, at hindi nangangailangan sa iyong kalkulahin ang tamang lapad na kasama ang laki ng gap. Paano Malalaman Kung Ano ang Available At Kailan Ito Available? Sa pangkalahatan, ang tanong ay hindi talaga kung dapat mong gamitin ang built-in na Masonry sa isang JS library, ngunit sa halip kung kailan. Ang library ng Masonry JS ay kamangha-mangha at pinupunan ang isang puwang sa web platform sa loob ng maraming taon, at para sa maraming masasayang developer at user. Mayroon itong ilang mga disbentaha kung ihahambing mo ito sa isang built-in na pagpapatupad ng Masonry, siyempre, ngunit ang mga iyon ay hindi mahalaga kung ang pagpapatupad na iyon ay hindi handa. Madali para sa akin na ilista ang mga cool na bagong tampok sa web platform dahil nagtatrabaho ako sa isang vendor ng browser, at samakatuwid ay malamang na alam ko kung ano ang darating. Ngunit madalas ibinabahagi ng mga developer, survey pagkatapos survey, na ang pagsubaybay sa mga bagong bagay ay mahirap. Mahirap manatiling may kaalaman, at hindi palaging inuuna ng mga kumpanya ang pag-aaral. Upang makatulong dito, narito ang ilang mapagkukunan na nagbibigay ng mga update sa simple at compact na paraan upang mabilis mong makuha ang impormasyong kailangan mo:
Nagtatampok ang Web platform ng explorer site: Maaaring interesado ka sa pahina ng mga tala ng paglabas nito. At, kung gusto mo ang RSS, tingnan ang feed ng mga tala sa paglabas, pati na rin ang Baseline na Newly Available at Widely Available na mga feed.
Ang WebDashboard ng Status ng Platform: Maaaring gusto mo ang iba't ibang pahina ng taon ng Baseline.
Page ng roadmap ng Status ng Chrome Platform.
Kung mayroon kang kaunting oras, maaari ka ring maging interesado sa mga tala sa paglabas ng mga vendor ng browser:
Chrome gilid Firefox Safari
Para sa higit pang mga mapagkukunan, tingnan ang aking Pag-navigate sa Web Platform Cheatsheet. Ang Aking Bagay ay Hindi Pa Natutupad Iyan ang kabilang panig ng problema. Kahit na nakahanap ka ng oras, lakas, at mga paraan para subaybayan, nariyan pa rin ang pagkabigo sa pagpaparinig sa iyong boses at sa pagpapatupad ng iyong mga paboritong feature. Marahil ay naghihintay ka ng maraming taon para sa isang partikular na bug na malutas, o isang partikular na feature na maipadala sa isang browser kung saan wala pa rin ito. Ang sasabihin ko ay nakikinig ang mga vendor ng browser. Bahagi ako ng ilang cross-organization team kung saan tinatalakay namin ang mga signal ng developer at feedback sa lahat ng oras. Tinitingnan namin ang maraming iba't ibang mapagkukunan ng feedback, parehong panloob sa bawat vendor ng browser at panlabas/publiko sa mga forum, open source na proyekto, blog, at survey. At, palagi kaming nagsisikap na lumikha ng mas mahuhusay na paraan para maibahagi ng mga developer ang kanilang mga partikular na pangangailangan at mga kaso ng paggamit. Kaya, kung magagawa mo, mangyaring humingi ng higit pa mula sa mga vendor ng browser at pilitin kaming ipatupad ang mga tampok na kailangan mo. Naiintindihan ko na ito ay tumatagal ng oras, at maaari ring maging intimidating (hindi banggitin ang isang mataas na hadlang sa pagpasok), ngunit ito rin ay gumagana. Narito ang ilang paraan para marinig mo ang boses mo (o ng iyong kumpanya): Kunin ang taunang State of JS, State of CSS, at State of HTML survey. Malaki ang papel nila sa kung paano binibigyang-priyoridad ng mga vendor ng browser ang kanilang trabaho. Kung kailangan mo ng isang partikular na standard-based na API na ipatupad nang tuluy-tuloy sa mga browser, isaalang-alang ang pagsusumite ng panukala sa susunod na pag-ulit ng proyekto ng Interop. Nangangailangan ito ng mas maraming oras, ngunit isaalang-alang kung paano ibinahagi ng Shopify at RUMvision ang kanilang mga listahan ng nais para sa Interop 2026. Ang detalyadong impormasyong tulad nito ay maaaring maging lubhang kapaki-pakinabang para sa mga vendor ng browser na unahin. Para sa higit pang kapaki-pakinabang na mga link upang maimpluwensyahan ang mga vendor ng browser, tingnan ang aking Pag-navigate sa Web Platform Cheatsheet. Konklusyon Upang isara, umaasa akong ang artikulong ito ay nag-iwan sa iyo ng ilang bagay na pag-isipan:
Kaguluhan para sa Masonry at iba pang paparating na mga web feature. Ilang web feature na maaaring gusto mong simulang gamitin. Ilang piraso ng custom o 3rd-party na code na maaari mong alisin bilang pabor sa mga built-in na feature. Ilang paraan para subaybayan kung ano ang darating at maimpluwensyahan ang mga vendor ng browser.
Higit sa lahat, inaasahan kong nakumbinsi kita sa mga benepisyo ng paggamit ng web platform sa buong potensyal nito.
