Asi pred 15 rokmi som pracoval v spoločnosti, kde sme vytvárali aplikácie pre cestovné kancelárie, pracovníkov na letiskách a letecké spoločnosti. Vytvorili sme tiež vlastný interný rámec pre komponenty používateľského rozhrania a možnosti jednostránkových aplikácií. Mali sme komponenty pre všetko: polia, tlačidlá, karty, rozsahy, dátové tabuľky, ponuky, nástroje na výber dátumu, výbery a viacnásobné výbery. Dokonca sme mali aj komponent div. Náš komponent div bol mimochodom skvelý, umožnil nám robiť zaoblené rohy vo všetkých prehliadačoch, čo, verte alebo nie, v tom čase nebolo ľahké.
Naša práca sa odohrala v bode našej histórie, keď sa JS, Ajax a dynamické HTML považovali za revolúciu, ktorá nás priviedla do budúcnosti. Zrazu sme mohli dynamicky aktualizovať stránku, získavať údaje zo servera a vyhnúť sa nutnosti prechádzať na iné stránky, čo sa javilo ako pomalé a na obrazovke medzi dvoma stránkami blikal veľký biely obdĺžnik. Bola tam fráza, ktorú spopularizoval Jeff Atwood (zakladateľ StackOverflow), ktorá znela: „Akákoľvek aplikácia, ktorá môže byť napísaná v JavaScripte, bude nakoniec napísaná v JavaScripte.“ — Jeff Atwood
V tom čase nám to pripadalo ako odvaha skutočne ísť a vytvoriť tieto aplikácie. Bolo to ako všeobecný súhlas robiť všetko s JS. Takže sme urobili všetko s JS a naozaj sme si nenašli čas na skúmanie iných spôsobov, ako robiť veci. V skutočnosti sme necítili motiváciu správne sa naučiť, čo HTML a CSS dokážu. V skutočnosti sme web nevnímali ako vyvíjajúcu sa platformu aplikácií ako celok. Väčšinou sme to vnímali ako niečo, čo musíme vyriešiť, najmä pokiaľ ide o podporu prehliadačov. Mohli by sme na to hodiť viac JS, aby sme veci urobili. Pomohlo by mi nájsť si čas a dozvedieť sa viac o tom, ako web fungoval a čo bolo dostupné na platforme? Iste, pravdepodobne som mohol oholiť veľa kódu, ktorý nebol skutočne potrebný. Ale v tom čase možno nie až tak veľa. Vidíte, rozdiely v prehliadačoch boli vtedy dosť významné. Bolo to obdobie, keď bol Internet Explorer stále dominantným prehliadačom, pričom Firefox bol tesne druhý, ale začal strácať podiel na trhu, pretože Chrome rýchlo získaval na popularite. Hoci Chrome a Firefox boli celkom dobré v zhode na webových štandardoch, prostredia, v ktorých naše aplikácie bežali, znamenali, že sme museli IE6 podporovať na dlhú dobu. Aj keď sme mohli podporovať IE8, stále sme sa museli vysporiadať s mnohými rozdielmi medzi prehliadačmi. Nielen to, ale web tej doby jednoducho nemal toľko možností zabudovaných priamo do platformy.
Rýchlo vpred k dnešku. Veci sa ohromne zmenili. Nielenže máme viac týchto schopností ako kedykoľvek predtým, ale zvýšila sa aj miera ich dostupnosti. Dovoľte mi položiť otázku ešte raz: Pomohlo by vám, keby ste si našli čas a dozvedeli sa viac o tom, ako web funguje a čo je na platforme dostupné? Absolútne áno. Naučiť sa porozumieť a používať webovú platformu dnes vám dáva obrovskú výhodu oproti ostatným vývojárom. Či už pracujete na výkone, prístupnosti, odozve, všetko dohromady, alebo len dodávate funkcie používateľského rozhrania, ak to chcete robiť ako zodpovedný inžinier, znalosť nástrojov, ktoré máte k dispozícii, vám pomôže rýchlejšie a lepšie dosiahnuť vaše ciele. Niektoré veci, na ktoré už možno nebudete potrebovať knižnicu Keď vieme, aké prehliadače dnes podporujú, otázka teda znie: Čo môžeme zavrhnúť? Potrebujeme komponent div na vytvorenie zaoblených rohov v roku 2025? Samozrejme, že nie. Vlastnosť border-radius je v súčasnosti podporovaná všetkými aktuálne používanými prehliadačmi už viac ako 15 rokov. A čoskoro príde aj tvar rohov, pre ešte elegantnejšie rohy. Pozrime sa na relatívne najnovšie funkcie, ktoré sú teraz dostupné vo všetkých hlavných prehliadačoch a ktoré môžete použiť na nahradenie existujúcich závislostí vo vašej kódovej základni. Nejde o to okamžite zahodiť všetky svoje milované knižnice a prepísať svoju kódovú základňu. Pokiaľ ide o všetko ostatné, musíte najprv vziať do úvahy podporu prehliadača a rozhodnúť sa na základe iných faktorov špecifických pre váš projekt. Nasledujúce funkcie sú implementované v troch hlavných nástrojoch prehliadača (Chromium, WebKit a Gecko), ale môžete mať odlišné požiadavky na podporu prehliadača, ktoré vám bránia v ich okamžitom použití. Teraz je však stále ten správny čas dozvedieť sa o týchto funkciách a možno ich niekedy plánujete použiť. Popovers A Dialógy Rozhranie Popover API, prvok HTML
Iste, rýchlosť vášho internetového pripojenia sa pravdepodobne tiež zvýšila, ale to nie je prípad každého. A nie každý má rovnaké možnosti zariadenia. Stiahnutie kódu tretej strany pre veci, ktoré môžete robiť s platformou, namiesto toho s najväčšou pravdepodobnosťou znamená, že odosielate viac kódu, a preto oslovíte menej zákazníkov, ako by ste bežne dostávali. Na webe vedie zlý výkon načítania k vysokej miere opustenia a poškodzuje reputáciu značky. Spustenie menšieho množstva kódu na zariadeniach Okrem toho kód, ktorý odosielate na zariadenia vašich zákazníkov, pravdepodobne beží rýchlejšie, ak na platforme používa menej abstrakcií JavaScriptu. Je tiež pravdepodobne pohotovejšie a v predvolenom nastavení prístupnejšie. To všetko vedie k viacerým a šťastnejším zákazníkom. Pozrite si blog môjho kolegu Alexa Russella o ročnej výkonnostnej nerovnosti, ktorý ukazuje, že prémiové zariadenia do značnej miery chýbajú na trhoch s miliardami používateľov kvôli nerovnosti bohatstva. A tento rozdiel sa časom len zväčšuje.
Vstavané usporiadanie muriva Jednou z funkcií webovej platformy, ktorá bude čoskoro k dispozícii a z ktorej som veľmi nadšený, je CSS Masonry.
Dovoľte mi začať vysvetlením, čo je murivo. Čo je murivo Murivo je typ rozloženia, ktorý pred rokmi spopularizoval Pinterest. Vytvára nezávislé stopy obsahu, v rámci ktorých sa položky nabaľujú čo najbližšie k začiatku stopy.
Mnoho ľudí vidí Murárstvo ako skvelú možnosť pre portfóliá a fotogalérie, čo určite dokáže. Masonry je však flexibilnejší ako to, čo vidíte na Pintereste, a neobmedzuje sa len na rozloženia podobné vodopádom. V murovanom usporiadaní:
Stopy môžu byť stĺpce alebo riadky:
Všetky stopy obsahu nemusia mať rovnakú veľkosť:
Položky môžu zahŕňať viacero stôp:
Položky môžu byť umiestnené na konkrétnych skladbách; nemusia vždy dodržiavať algoritmus automatického umiestnenia:
Ukážky Tu je niekoľko jednoduchých ukážok, ktoré som vytvoril pomocou pripravovanej implementácie CSS Masonry v prehliadači Chromium. Ukážka fotogalérie, ktorá ukazuje, ako môžu položky (v tomto prípade názov) zahŕňať viacero skladieb:
Ďalšia fotogaléria zobrazujúca trate rôznych veľkostí:
Rozloženie spravodajského webu s niektorými stopami širšími než inými a niektorými položkami po celej šírke rozloženia:
Kanbanová tabuľa, ktorá ukazuje, že položky možno umiestniť na konkrétne dráhy:
Poznámka: Thepredchádzajúce ukážky boli vytvorené s verziou prehliadača Chromium, ktorá ešte nie je dostupná pre väčšinu používateľov webu, pretože CSS Masonry sa v prehliadačoch ešte len začína implementovať. Weboví vývojári však už roky s radosťou používajú knižnice na vytváranie murovaných rozložení. Stránky využívajúce murivo ešte dnes V skutočnosti je dnes murárstvo na webe celkom bežné. Tu je niekoľko príkladov, ktoré som našiel okrem Pinterestu:
A niekoľko ďalších, menej zrejmých príkladov:
Ako teda vznikli tieto rozloženia? Alternatívne riešenia Jeden trik, ktorý som videl, je použiť namiesto toho rozloženie Flexbox, zmeniť jeho smer na stĺpec a nastaviť ho na zalomenie. Týmto spôsobom môžete umiestniť položky rôznych výšok do viacerých nezávislých stĺpcov, čím vytvoríte dojem rozloženia muriva:
Toto riešenie má však dve obmedzenia:
Poradie položiek je odlišné od toho, aké by bolo pri skutočnom usporiadaní muriva. S Flexboxom položky vyplnia najskôr prvý stĺpec, a keď je plný, potom prejdú na ďalší stĺpec. V prípade muriva sa položky uložia do ktorejkoľvek stopy (alebo v tomto prípade stĺpca), ktorá má k dispozícii viac miesta. Ale čo je možno ešte dôležitejšie, toto riešenie vyžaduje, aby ste nastavili pevnú výšku kontajnera Flexbox; inak by nedošlo k žiadnemu omotaniu.
Murárske knižnice tretích strán V pokročilejších prípadoch vývojári používali knižnice. Najznámejšia a najobľúbenejšia knižnica na tento účel sa jednoducho nazýva Masonry a podľa NPM sa stiahne približne 200 000-krát týždenne. Squarespace tiež poskytuje komponent rozloženia, ktorý vykresľuje rozloženie muriva ako alternatívu bez kódu a používa ho mnoho stránok. Obe tieto možnosti používajú kód JavaScript na umiestnenie položiek do rozloženia. Vstavané murivo Som naozaj nadšený, že Masonry sa teraz začína objavovať v prehliadačoch ako vstavaná funkcia CSS. Postupom času budete môcť používať Masonry rovnako ako Grid alebo Flexbox, teda bez potreby akýchkoľvek riešení alebo kódu tretích strán. Môj tím v Microsofte implementuje vstavanú podporu Masonry v projekte s otvoreným zdrojovým kódom Chromium, na ktorom sú založené prehliadače Edge, Chrome a mnoho ďalších. Mozilla bola v skutočnosti prvým predajcom prehliadača, ktorý v roku 2020 navrhol experimentálnu implementáciu Masonry. A Apple mal tiež veľký záujem na tom, aby sa toto nové rozloženie webu stalo primitívnym. Práca na štandardizácii funkcie tiež napreduje, pričom sa v rámci pracovnej skupiny CSS dohodlo na všeobecnom smerovaní a dokonca aj na novom zobrazení typu zobrazenia: mriežkové pruhy. Ak sa chcete dozvedieť viac o murárstve a sledovať pokrok, pozrite si moju stránku so zdrojmi CSS muriva. Časom, keď sa Masonry stane základnou funkciou, rovnako ako Grid alebo Flexbox, budeme ju môcť jednoducho používať a profitovať z:
Lepší výkon, Lepšia odozva, Jednoduché použitie a jednoduchší kód.
Pozrime sa na ne bližšie. Lepší výkon Vytvorenie vlastného systému rozloženia podobného murive alebo použitie knižnice tretej strany znamená, že na umiestnenie položiek na obrazovku budete musieť spustiť kód JavaScript. To tiež znamená, že tento kód bude blokovať vykreslenie. V skutočnosti sa buď nič nezobrazí, alebo veci nebudú na správnych miestach alebo v správnej veľkosti, kým sa nespustí kód JavaScript. Masony layout sa často používa pre hlavnú časť webovej stránky, čo znamená, že kód by spôsobil, že by sa váš hlavný obsah objavil neskôr, ako by sa inak mohol zobraziť, čím by sa zhoršila vaša metrika LCP alebo metrika Najväčší obsah, ktorá hrá veľkú úlohu pri vnímanej výkonnosti a optimalizácii pre vyhľadávače. Testoval som knižnicu Masonry JS s jednoduchým rozložením a simuláciou pomalého 4G pripojenia v DevTools. Knižnica nie je príliš veľká (24 KB, 7,8 KB komprimovaná pomocou gzip), ale v mojich testovacích podmienkach trvalo načítanie 600 ms. Tu je záznam výkonu, ktorý ukazuje, že dlhý čas načítania 600 ms pre knižnicu Masonry a že počas toho nedošlo k žiadnej inej aktivite vykresľovania:
Navyše, po počiatočnom čase načítania bolo potrebné stiahnutý skript analyzovať, skompilovať a následne spustiť. To všetko, ako už bolo spomenuté, blokovalo vykresľovanie stránky. So vstavanou implementáciou Masonry v prehliadači nebudeme mať skript na načítanie a spustenie. Motor prehliadača jednoducho urobí svoju vec počas počiatočného kroku vykresľovania stránky. Lepšia odozva Podobne ako pri prvom načítaní stránky, zmena veľkosti okna prehliadača vedie k opätovnému vykresleniu rozloženia na tejto stránke. Ak však stránka v tomto momente používa knižnicu Masonry JS, nie je potrebné načítať skript znova, pretože užtu. Musí sa však spustiť kód, ktorý presúva položky na správne miesta. Teraz sa zdá, že táto konkrétna knižnica to robí dosť rýchlo, keď sa stránka načíta. Avšak animuje položky, keď sa potrebujú presunúť na iné miesto pri zmene veľkosti okna, a to je veľký rozdiel. Používatelia samozrejme netrávia čas zmenou veľkosti okien prehliadača toľko ako my vývojári. Ale táto animovaná zmena veľkosti môže byť dosť rušivá a zvyšuje vnímaný čas, ktorý trvá, kým sa stránka prispôsobí novej veľkosti. Jednoduché použitie a jednoduchší kód To, aké jednoduché je používať webovú funkciu a ako jednoducho vyzerá kód, sú dôležité faktory, ktoré môžu váš tím výrazne zmeniť. Samozrejme, nikdy nemôžu byť také dôležité ako konečná používateľská skúsenosť, ale skúsenosti vývojárov ovplyvňujú udržiavateľnosť. Používanie vstavanej webovej funkcie prináša dôležité výhody:
Vývojári, ktorí už poznajú HTML, CSS a JS, budú s najväčšou pravdepodobnosťou môcť túto funkciu ľahko používať, pretože bola navrhnutá tak, aby sa dobre integrovala a bola konzistentná so zvyškom webovej platformy. Neexistuje žiadne riziko prerušenia zmien v spôsobe používania funkcie. Existuje takmer nulové riziko, že táto funkcia bude zastaraná alebo nebude udržiavaná.
V prípade vstavaného muriva, pretože ide o primitívne rozloženie, ho používate z CSS, rovnako ako Grid alebo Flexbox, bez použitia JS. Aj ďalšie vlastnosti CSS súvisiace s rozložením, ako napríklad medzera, fungujú tak, ako by ste od nich očakávali. Neexistujú žiadne triky alebo riešenia, o ktorých by ste mali vedieť, a veci, ktoré sa naučíte, sú zdokumentované na MDN. Pre knižnicu Masonry JS je inicializácia trochu zložitá: vyžaduje dátový atribút so špecifickou syntaxou spolu so skrytými prvkami HTML na nastavenie veľkosti stĺpcov a medzier. Navyše, ak chcete preklenúť stĺpce, musíte sami zahrnúť veľkosť medzery, aby ste sa vyhli problémom:
Porovnajme to s tým, ako by vyzerala vstavaná implementácia muriva:
Jednoduchší a kompaktnejší kód, ktorý môže používať len veci, ako je medzera a kde sa preklenutie stôp vykonáva pomocou rozpätia 2, rovnako ako v mriežke, a nevyžaduje, aby ste vypočítali správnu šírku, ktorá zahŕňa veľkosť medzery. Ako zistiť, čo je k dispozícii a kedy je k dispozícii? Celkovo nie je otázkou, či by ste mali použiť vstavané murivo nad knižnicou JS, ale skôr kedy. Knižnica Masonry JS je úžasná a už mnoho rokov vypĺňa medzeru vo webovej platforme a pre mnohých spokojných vývojárov a používateľov. Má to niekoľko nevýhod, ak to porovnáte so vstavanou implementáciou muriva, samozrejme, ale tie nie sú dôležité, ak táto implementácia nie je pripravená. Je pre mňa ľahké vymenovať tieto skvelé nové funkcie webovej platformy, pretože pracujem u dodávateľa prehliadača, a preto mám tendenciu vedieť, čo príde. Vývojári však často zdieľajú prieskum za prieskumom, že sledovať nové veci je ťažké. Zostať informovaný je ťažké a spoločnosti aj tak nie vždy uprednostňujú učenie. Aby ste tomu pomohli, tu je niekoľko zdrojov, ktoré poskytujú aktualizácie jednoduchým a kompaktným spôsobom, aby ste mohli rýchlo získať potrebné informácie:
Webová platforma obsahuje stránku prieskumníka: Mohla by vás zaujímať jeho stránka s poznámkami k vydaniu. A ak máte radi RSS, pozrite si informačný kanál poznámok k vydaniu, ako aj informačné kanály Baseline Newly Available a Widely Available.
WebPanel stavu platformy: Mohli by sa vám páčiť jeho rôzne stránky základného roka.
Stránka plánu Chrome Platform Status.
Ak máte trochu viac času, mohli by vás zaujímať aj poznámky k vydaniu dodávateľov prehliadačov:
Chrome Edge Firefox Safari
Pre ešte viac zdrojov si pozrite môj Cheatsheet Navigácia na webovej platforme. Moja vec stále nie je implementovaná To je druhá strana problému. Aj keď si nájdete čas, energiu a spôsoby, ako sledovať, stále je tu frustrácia z toho, že váš hlas bude počuť a vaše obľúbené funkcie budú implementované. Možno ste roky čakali na vyriešenie konkrétnej chyby alebo na odoslanie konkrétnej funkcie v prehliadači, kde stále chýba. Poviem vám, že predajcovia prehliadačov počúvajú. Som súčasťou niekoľkých medziorganizačných tímov, kde neustále diskutujeme o signáloch vývojárov a spätnej väzbe. Pozeráme sa na mnoho rôznych zdrojov spätnej väzby, interné u každého dodávateľa prehliadača, ako aj externé/verejné na fórach, open source projektoch, blogoch a prieskumoch. A vždy sa snažíme vytvárať lepšie spôsoby, ako môžu vývojári zdieľať svoje špecifické potreby a prípady použitia. Ak teda môžete, vyžiadajte si od dodávateľov prehliadačov viac a tlačte na nás, aby sme implementovali funkcie, ktoré potrebujete. Chápem, že to chce čas a môže to byť aj zastrašujúce (nehovoriac o vysokej prekážke vstupu), ale tiež to funguje. Tu je niekoľko spôsobov, ako môžete vypočuť svoj (alebo svoj firemný) hlas: Zúčastnite sa každoročného prieskumu stavu JS, stavu CSS a stavu HTML. Zohrávajú veľkú úlohu v tom, ako predajcovia prehliadačov uprednostňujú svoju prácu. Ak potrebujete, aby sa špecifické rozhranie API založené na štandardoch implementovalo konzistentne vo všetkých prehliadačoch, zvážte odoslanie návrhu pri ďalšej iterácii projektu Interop. Vyžaduje si to viac času, ale zvážte, ako Shopify a RUMvision zdieľali svoje zoznamy želaní pre Interop 2026. Podobné podrobné informácie môžu byť pre predajcov prehliadačov veľmi užitočné, aby ich uprednostnili. Ďalšie užitočné odkazy na ovplyvnenie dodávateľov prehliadačov nájdete v mojom Cheatsheete navigácie na webovej platforme. Záver Na záver dúfam, že vám tento článok priniesol pár vecí na zamyslenie:
Vzrušenie pre murivo a ďalšie pripravované webové funkcie. Niekoľko webových funkcií, ktoré možno budete chcieť začať používať. Niekoľko kusov vlastného kódu alebo kódu tretej strany, ktoré možno budete môcť odstrániť v prospech vstavaných funkcií. Niekoľko spôsobov, ako sledovať, čo prichádza, a ovplyvniť predajcov prehliadačov.
A čo je dôležitejšie, dúfam, že som vás presvedčil o výhodách využívania webovej platformy v jej plnom rozsahu.
