Pred približno 15 leti sem delal v podjetju, kjer smo gradili aplikacije za potovalne agente, letališke delavce in letalske družbe. Zgradili smo tudi svoje lastno ogrodje za komponente uporabniškega vmesnika in zmogljivosti enostranskih aplikacij. Imeli smo komponente za vse: polja, gumbe, zavihke, obsege, podatkovne tabele, menije, izbirnike datumov, izbire in več izbir. Imeli smo celo komponento div. Mimogrede, naša komponenta div je bila odlična, omogočala nam je delati zaobljene vogale v vseh brskalnikih, kar, verjeli ali ne, takrat ni bilo lahko narediti.
Naše delo je potekalo na točki naše zgodovine, ko so JS, Ajax in dinamični HTML veljali za revolucijo, ki nas je popeljala v prihodnost. Nenadoma smo lahko dinamično posodobili stran, dobili podatke iz strežnika in se izognili navigaciji na druge strani, kar je bilo videti kot počasno in je na zaslonu med obema stranema utripal velik bel pravokotnik. Obstajal je stavek, ki ga je Jeff Atwood (ustanovitelj StackOverflow) razglasil: "Vsaka aplikacija, ki jo je mogoče napisati v JavaScriptu, bo sčasoma napisana v JavaScriptu."— Jeff Atwood
Takrat se nam je to zdelo kot upanje, da bi dejansko ustvarili te aplikacije. Zdelo se je kot splošno odobravanje, da počnem vse z JS. Tako smo vse naredili z JS in si nismo vzeli časa za raziskovanje drugih načinov dela. V resnici nismo čutili spodbude, da bi se pravilno naučili, kaj zmoreta HTML in CSS. Spleta v resnici nismo dojemali kot razvijajoče se platforme aplikacij v celoti. Na to smo večinoma gledali kot na nekaj, kar moramo zaobiti, zlasti ko je šlo za podporo brskalnika. Lahko bi samo dodali več JS-ja, da bi opravili stvari. Ali bi mi kaj pomagalo, če bi si vzel čas in izvedel več o tem, kako splet deluje in kaj je na voljo na platformi? Seveda bi verjetno lahko odstranil kup kode, ki ni bila resnično potrebna. Toda takrat morda ne toliko. Vidite, razlike v brskalnikih so bile takrat precejšnje. To je bil čas, ko je bil Internet Explorer še vedno prevladujoči brskalnik, Firefox pa je bil skoraj drugi, vendar je začel izgubljati tržni delež zaradi Chroma, ki je hitro pridobival na priljubljenosti. Čeprav sta se Chrome in Firefox zelo dobro strinjala glede spletnih standardov, so okolja, v katerih so delovale naše aplikacije, pomenila, da smo morali dolgo časa podpirati IE6. Tudi ko nam je bilo dovoljeno podpirati IE8, smo se še vedno morali ukvarjati z veliko razlikami med brskalniki. Ne samo to, takratni splet preprosto ni imel toliko zmogljivosti, vgrajenih neposredno v platformo.
Hitro naprej do danes. Stvari so se izjemno spremenile. Ne samo, da imamo več teh zmogljivosti kot kadar koli prej, ampak se je povečala tudi stopnja, s katero postanejo na voljo. Naj torej še enkrat postavim vprašanje: ali bi vam danes pomagalo, če bi si vzeli čas in izvedeli več o tem, kako splet deluje in kaj je na voljo na platformi? Absolutno da. Če se danes naučite razumeti in uporabljati spletno platformo, ste v veliki prednosti pred drugimi razvijalci. Ne glede na to, ali delate na zmogljivosti, dostopnosti, odzivnosti, vsem skupaj ali samo na pošiljanju funkcij uporabniškega vmesnika, če želite to storiti kot odgovoren inženir, vam poznavanje orodij, ki so vam na voljo, pomaga hitreje in bolje doseči vaše cilje. Nekatere stvari, za katere morda ne potrebujete več knjižnice Če vemo, kaj brskalniki danes podpirajo, se postavlja vprašanje: kaj lahko opustimo? Ali potrebujemo komponento div za ustvarjanje zaobljenih vogalov leta 2025? Seveda ne. Lastnost border-radius trenutno podpirajo vsi trenutno uporabljeni brskalniki že več kot 15 let. Kmalu bo na voljo tudi kotna oblika za še bolj modne kote. Oglejmo si razmeroma nedavne funkcije, ki so zdaj na voljo v vseh večjih brskalnikih in jih lahko uporabite za zamenjavo obstoječih odvisnosti v svoji kodni bazi. Bistvo ni v tem, da takoj opustite vse svoje ljubljene knjižnice in ponovno napišete svojo kodno zbirko. Kar zadeva vse ostalo, boste morali najprej upoštevati podporo brskalnika in se odločiti na podlagi drugih dejavnikov, značilnih za vaš projekt. Naslednje funkcije so implementirane v treh glavnih motorjih brskalnika (Chromium, WebKit in Gecko), vendar imate morda drugačne zahteve glede podpore brskalnika, zaradi katerih jih ne morete uporabiti takoj. Zdaj je še vedno pravi čas, da se poučite o teh funkcijah in jih morda kdaj nameravate uporabiti. Popkovi in pogovorna okna API Popover, element HTML
Seveda se je verjetno povečala tudi vaša hitrost internetne povezave, vendar to ne velja za vse. In tudi nimajo vsi enakih zmogljivosti naprave. Namesto tega vnašanje kode tretjih oseb za stvari, ki jih lahko počnete s platformo, najverjetneje pomeni, da pošljete več kode in tako dosežete manj strank, kot bi jih običajno. V spletu slabo delovanje nalaganja vodi do velikih stopenj opustitve in škoduje ugledu blagovne znamke. Izvajanje manj kode na napravah Poleg tega koda, ki jo pošiljate v naprave svojih strank, verjetno deluje hitreje, če uporablja manj abstrakcij JavaScript na vrhu platforme. Verjetno je tudi bolj odziven in privzeto bolj dostopen. Vse to vodi do več in srečnejših strank. Oglejte si letni blog mojega kolega Alexa Russella o vrzeli v neenakosti v uspešnosti, ki kaže, da vrhunskih naprav večinoma ni na trgih z milijardami uporabnikov zaradi neenakosti v premoženju. In ta vrzel se sčasoma samo še povečuje.
Vgrajeni zidarski načrt Funkcija spletne platforme, ki bo kmalu na voljo in nad katero sem zelo navdušen, je CSS Masonry.
Naj začnem z razlago, kaj je masonstvo. Kaj je zidarstvo Zidarstvo je vrsta postavitve, ki jo je pred leti populariziral Pinterest. Ustvari neodvisne skladbe vsebine, znotraj katerih se predmeti zapakirajo čim bližje začetku skladbe.
Mnogi ljudje vidijo Masonry kot odlično možnost za portfelje in galerije fotografij, kar zagotovo zmore. Toda Masonry je bolj prilagodljiv od tistega, kar vidite na Pinterestu, in ni omejen samo na postavitve, podobne slapu. V zidarski postavitvi:
Skladbe so lahko stolpci ali vrstice:
Ni nujno, da so vse sledi vsebine enake velikosti:
Elementi lahko zajemajo več skladb:
Predmete je mogoče postaviti na določene steze; ni jim treba vedno slediti algoritmu za samodejno umestitev:
Predstavitve Tukaj je nekaj preprostih predstavitev, ki sem jih naredil s prihajajočo implementacijo CSS Masonry v Chromiumu. Predstavitev galerije fotografij, ki prikazuje, kako lahko elementi (v tem primeru naslov) obsegajo več skladb:
Še ena fotogalerija, ki prikazuje proge različnih velikosti:
Postavitev spletnega mesta z novicami z nekaterimi skladbami, ki so širše od drugih, nekateri elementi pa se raztezajo po celotni širini postavitve:
Tabla kanban, ki prikazuje, da je mogoče elemente postaviti na določene steze:
Opomba: Theprejšnje predstavitve so bile narejene z različico Chromiuma, ki še ni na voljo večini spletnih uporabnikov, ker se CSS Masonry šele začenja izvajati v brskalnikih. Vendar pa spletni razvijalci že leta z veseljem uporabljajo knjižnice za ustvarjanje postavitev Masonry. Mesta, ki danes uporabljajo zidarstvo Dejansko je zidarstvo danes precej pogosto na spletu. Tukaj je nekaj primerov, ki sem jih našel poleg Pinteresta:
In še nekaj manj očitnih primerov:
Torej, kako so bile te postavitve ustvarjene? Rešitve En trik, ki sem ga videl uporabljati, je uporaba postavitve Flexbox, spreminjanje njegove smeri v stolpec in nastavitev, da se preliva. Na ta način lahko postavite predmete različnih višin v več neodvisnih stolpcev, kar daje vtis zidane postavitve:
Vendar pa obstajata dve omejitvi te rešitve:
Vrstni red elementov je drugačen od tistega, ki bi bil pri pravi zidarski postavitvi. S Flexboxom elementi najprej zapolnijo prvi stolpec in, ko je poln, preidejo na naslednji stolpec. Z Masonryjem bi se predmeti zložili v tisto stezo (ali stolpec v tem primeru), ki ima na voljo več prostora. Ampak tudi, kar je morda še pomembneje, ta rešitev zahteva, da nastavite fiksno višino vsebnika Flexbox; drugače ne bi prišlo do ovijanja.
Masonry knjižnice tretjih oseb Za naprednejše primere so razvijalci uporabljali knjižnice. Najbolj znana in priljubljena knjižnica za to se preprosto imenuje Masonry in jo glede na NPM prenesejo približno 200.000-krat na teden. Squarespace ponuja tudi komponento postavitve, ki upodablja postavitev Masonry, kot alternativo brez kode, in številna spletna mesta jo uporabljajo. Obe možnosti uporabljata kodo JavaScript za umestitev elementov v postavitev. Vgrajeni zidaki Resnično sem navdušen, da se je Masonry zdaj začel pojavljati v brskalnikih kot vgrajena funkcija CSS. Sčasoma boste lahko uporabljali Masonry tako kot uporabljate Grid ali Flexbox, to je, ne da bi potrebovali kakršne koli rešitve ali kodo tretje osebe. Moja ekipa pri Microsoftu izvaja vgrajeno podporo za Masonry v odprtokodnem projektu Chromium, na katerem temeljijo Edge, Chrome in številni drugi brskalniki. Mozilla je bila dejansko prvi prodajalec brskalnikov, ki je leta 2020 predlagal eksperimentalno izvedbo Masonryja. Apple je bil prav tako zelo zainteresiran, da bi ta nova spletna postavitev postala primitivna. Delo za standardizacijo funkcije prav tako napreduje, z dogovorom znotraj delovne skupine CSS o splošni usmeritvi in celo o novem prikazu tipa zaslona: mrežni pasovi. Če želite izvedeti več o zidarstvu in spremljati napredek, si oglejte mojo stran z viri o zidarstvu CSS. Sčasoma, ko bo Masonry postal osnovna funkcija, tako kot Grid ali Flexbox, jo bomo lahko preprosto uporabljali in imeli koristi od:
Boljša zmogljivost, Boljša odzivnost, Preprosta uporaba in preprostejša koda.
Oglejmo si jih podrobneje. Boljša zmogljivost Izdelava lastnega sistema postavitve, podobnega zidarstvu, ali namesto tega uporaba knjižnice drugega proizvajalca pomeni, da boste morali zagnati kodo JavaScript, da postavite elemente na zaslon. To tudi pomeni, da bo ta koda blokirala upodabljanje. Dejansko se ne bo nič pojavilo ali pa stvari ne bodo na pravih mestih ali pravih velikosti, dokler se koda JavaScript ne zažene. Zidana postavitev se pogosto uporablja za glavni del spletne strani, kar pomeni, da bi koda poskrbela, da bi se vaša glavna vsebina prikazala pozneje, kot bi se sicer lahko, kar bi poslabšalo vaš LCP ali metriko Largest Contentful Paint, ki ima pomembno vlogo pri zaznani uspešnosti in optimizaciji iskalnikov. Knjižnico Masonry JS sem preizkusil s preprosto postavitvijo in s simulacijo počasne povezave 4G v DevTools. Knjižnica ni zelo velika (24 KB, 7,8 KB gzipane), vendar je trajalo 600 ms za nalaganje pod mojimi testnimi pogoji. Tukaj je posnetek zmogljivosti, ki prikazuje ta dolgi 600 ms čas nalaganja za knjižnico Masonry in da se med tem dogajanjem ni zgodila nobena druga dejavnost upodabljanja:
Poleg tega je bilo treba po začetnem času nalaganja preneseni skript nato razčleniti, prevesti in nato zagnati. Vse to je, kot že omenjeno, blokiralo upodabljanje strani. Z vgrajeno izvedbo Masonry v brskalniku ne bomo imeli skripta za nalaganje in izvajanje. Motor brskalnika bo med začetnim korakom upodabljanja strani opravil svoje. Boljša odzivnost Podobno kot pri prvem nalaganju strani, spreminjanje velikosti okna brskalnika vodi do ponovnega upodabljanja postavitve na tej strani. Na tej točki pa, če stran uporablja knjižnico Masonry JS, skripta ni treba znova naložiti, ker je žetukaj Vendar se mora zagnati koda, ki premakne elemente na prava mesta. Zdaj se zdi, da ta posebna knjižnica to počne precej hitro, ko se stran naloži. Vendar pa elemente animira, ko se morajo pri spreminjanju velikosti okna premakniti na drugo mesto, kar je velika razlika. Seveda uporabniki ne porabljajo toliko časa za spreminjanje velikosti svojih oken brskalnika kot razvijalci. Toda ta animirana izkušnja spreminjanja velikosti je lahko precej moteča in poveča zaznan čas, ki ga potrebuje, da se stran prilagodi novi velikosti. Preprosta uporaba in preprostejša koda Kako enostavno je uporabljati spletno funkcijo in kako preprosto je koda videti, sta pomembna dejavnika, ki lahko močno vplivata na vašo ekipo. Seveda ne morejo biti tako pomembne kot končna uporabniška izkušnja, vendar izkušnja razvijalca vpliva na vzdržljivost. Uporaba vgrajene spletne funkcije prinaša pomembne prednosti na tem področju:
Razvijalci, ki že poznajo HTML, CSS in JS, bodo najverjetneje lahko zlahka uporabljali to funkcijo, ker je bila zasnovana tako, da se dobro integrira in je skladna s preostalo spletno platformo. Nobenega tveganja ni, da bi bile uvedene spremembe v načinu uporabe funkcije. Obstaja skoraj ničelno tveganje, da bi ta funkcija postala zastarela ali nevzdrževana.
V primeru vgrajenega Masonryja, ker gre za primitivno postavitev, ga uporabite iz CSS, tako kot Grid ali Flexbox, brez vključenega JS. Tudi druge lastnosti CSS, povezane s postavitvijo, kot je vrzel, delujejo, kot bi pričakovali. Ni trikov ali rešitev, o katerih bi morali vedeti, in stvari, ki se jih naučite, so dokumentirane na MDN. Za Masonry JS lib je inicializacija nekoliko zapletena: zahteva podatkovni atribut s posebno sintakso, skupaj s skritimi elementi HTML za nastavitev velikosti stolpcev in vrzeli. Poleg tega, če želite razširiti stolpce, morate sami vključiti velikost vrzeli, da se izognete težavam:
Primerjajmo to s tem, kako bi izgledala vgrajena izvedba Masonry:
Enostavnejša, kompaktnejša koda, ki lahko samo uporablja stvari, kot je vrzel, in kjer se vpetje sledi izvaja z razponom 2, tako kot v mreži, in ne zahteva, da izračunate pravo širino, ki vključuje velikost vrzeli. Kako vedeti, kaj je na voljo in kdaj je na voljo? Na splošno vprašanje pravzaprav ni, ali bi morali namesto knjižnice JS uporabiti vgrajeno Masonry, ampak kdaj. Knjižnica Masonry JS je neverjetna in že vrsto let zapolnjuje vrzel v spletni platformi ter za številne vesele razvijalce in uporabnike. Če ga primerjate z vgrajeno izvedbo Masonry, ima seveda nekaj pomanjkljivosti, vendar te niso pomembne, če ta izvedba ni pripravljena. Z lahkoto naštejem te odlične nove funkcije spletne platforme, ker delam pri prodajalcu brskalnika in zato ponavadi vem, kaj prihaja. Toda razvijalci pogosto delijo anketo za anketo, da je sledenje novim stvarem težko. Težko je ostati obveščen, podjetja pa tako ali tako ne dajejo vedno prednost učenju. V pomoč pri tem je tukaj nekaj virov, ki zagotavljajo posodobitve na preproste in kompaktne načine, tako da lahko hitro dobite informacije, ki jih potrebujete:
Spletna platforma vsebuje spletno mesto raziskovalca: Morda vas bo zanimala njegova stran z opombami ob izdaji. Če vam je všeč RSS, si oglejte vir opomb ob izdaji ter vire Baseline Newly Available in Widely Available.
SpletNadzorna plošča stanja platforme: Morda vam bodo všeč njene različne strani z osnovnim letom.
Stran načrta stanja platforme Chrome.
Če imate nekaj več časa, vas bodo morda zanimale tudi opombe ob izdaji proizvajalcev brskalnikov:
Chrome Edge Firefox Safari
Za še več virov si oglejte moj list za krmarjenje po spletni platformi. Moja stvar še vedno ni implementirana To je druga plat problema. Tudi če najdete čas, energijo in načine za sledenje, je še vedno frustracija, da se vaš glas sliši in da se izvajajo vaše najljubše funkcije. Morda že leta čakate na odpravo določene napake ali na pošiljanje določene funkcije v brskalniku, kjer še vedno manjka. Rekel bom, da prodajalci brskalnikov poslušajo. Sem del več medorganizacijskih skupin, kjer ves čas razpravljamo o signalih in povratnih informacijah razvijalcev. Upoštevamo veliko različnih virov povratnih informacij, tako notranjih pri vsakem prodajalcu brskalnika kot zunanjih/javnih na forumih, odprtokodnih projektih, blogih in anketah. In vedno poskušamo ustvariti boljše načine za razvijalce, da delijo svoje specifične potrebe in primere uporabe. Torej, če lahko, zahtevajte več od prodajalcev brskalnikov in pritiskajte na nas, da implementiramo funkcije, ki jih potrebujete. Razumem, da zahteva čas in je lahko tudi zastrašujoče (da ne omenjam visoke ovire za vstop), vendar tudi deluje. Tukaj je nekaj načinov, kako lahko dosežete, da se vaš glas (ali glas vašega podjetja) sliši: Izpolnite letne ankete o stanju JS, stanju CSS in stanju HTML. Imajo veliko vlogo pri tem, kako prodajalci brskalnikov dajejo prednost svojemu delu. Če potrebujete poseben API, ki temelji na standardih, ki bo dosledno implementiran v vseh brskalnikih, razmislite o oddaji predloga pri naslednji ponovitvi projekta Interop. Zahteva več časa, vendar upoštevajte, kako sta Shopify in RUMvision delila svoje sezname želja za Interop 2026. Podrobne informacije, kot je ta, so lahko zelo koristne za prodajalce brskalnikov, da jim dajo prednost. Če želite več uporabnih povezav za vplivanje na prodajalce brskalnikov, si oglejte moj Navigating the Web Platform Cheatsheet. Zaključek Za zaključek upam, da vam je ta članek pustil nekaj stvari za razmislek:
Navdušenje za Masonry in druge prihajajoče spletne funkcije. Nekaj spletnih funkcij, ki bi jih morda želeli začeti uporabljati. Nekaj delov kode po meri ali kode tretjih oseb, ki jih boste morda lahko odstranili v korist vgrajenih funkcij. Nekaj načinov, kako spremljati, kaj prihaja, in vplivati na prodajalce brskalnikov.
Kar je še pomembneje, upam, da sem vas prepričal o prednostih uporabe spletne platforme v celoti.
