Umbes 15 aastat tagasi töötasin ettevõttes, kus ehitasime rakendusi reisibüroodele, lennujaama töötajatele ja lennufirmadele. Samuti lõime oma majasisese raamistiku kasutajaliidese komponentide ja üheleheliste rakenduste võimaluste jaoks. Meil olid komponendid kõige jaoks: väljad, nupud, vahelehed, vahemikud, andmetabelid, menüüd, kuupäevavalijad, valikud ja mitmikvalimised. Meil oli isegi div komponent. Meie div-komponent oli muide suurepärane, võimaldas meil teha ümaraid nurki kõigis brauserites, mida, uskuge või mitte, polnud sel ajal lihtne teha.
Meie töö leidis aset meie ajaloo hetkel, mil JS-i, Ajaxi ja dünaamilist HTML-i peeti revolutsiooniks, mis tõi meid tulevikku. Järsku saime lehte dünaamiliselt värskendada, serverist andmeid hankida ja vältida teistele lehtedele navigeerimist, mida peeti aeglaseks ja kahe lehe vahel vilkus ekraanil suur valge ristkülik. Seal oli fraas, mille tegi populaarseks Jeff Atwood (StackOverflow asutaja), mis kõlas: "Iga rakendus, mida saab JavaScriptis kirjutada, kirjutatakse lõpuks JavaScriptis." - Jeff Atwood
Meie jaoks tundus see tol ajal kui julgus neid rakendusi luua. Tundus nagu üldine heakskiit teha kõike JS-iga. Seega tegime kõik koos JS-iga ja me ei võtnud tegelikult aega, et uurida muid toimimisviise. Me ei tundnud tegelikult stiimulit õppida, mida HTML ja CSS teha võiksid. Me ei tajunud veebi tervikuna areneva rakendusplatvormina. Peamiselt nägime seda kui midagi, mille ümber tuleks töötada, eriti kui tegemist oli brauseri toega. Võiksime lihtsalt rohkem JS-i visata, et asjad tehtud saaks. Kas oleksin aidanud aja võtmine veebi toimimise ja platvormil saadaoleva kohta lisateabe saamiseks? Muidugi, ma oleksin ilmselt võinud maha ajada hulga koodi, mida tegelikult vaja poleks olnud. Kuid tol ajal võib-olla mitte nii palju. Näete, brauseri erinevused olid siis üsna märkimisväärsed. See oli aeg, mil Internet Explorer oli endiselt domineeriv brauser, kus Firefox oli lähedal teisel kohal, kuid hakkas Chrome'i kiire populaarsuse tõttu turuosa kaotama. Kuigi Chrome ja Firefox olid veebistandardite osas üsna head kokku leppima, tingis keskkonnad, milles meie rakendused töötasid, seda, et pidime IE6-d pikka aega toetama. Isegi siis, kui meil lubati IE8-d toetada, pidime siiski leppima paljude brauseritevaheliste erinevustega. Vähe sellest, tolleaegsel veebil polnud lihtsalt platvormi sisse ehitatud nii palju võimalusi.
Kiirelt edasi tänasesse. Asjad on tohutult muutunud. Meil pole neid võimalusi mitte ainult rohkem kui kunagi varem, vaid ka nende kättesaadavaks saamise kiirus on kasvanud. Lubage mul siis uuesti esitada küsimus: kas veebi toimimise ja platvormil saadaoleva kohta lisateabe võtmine aitaks teid täna? Absoluutselt jah. Tänapäeval veebiplatvormi mõistma ja kasutama õppimine annab teile teiste arendajate ees tohutu eelise. Olenemata sellest, kas töötate jõudluse, juurdepääsetavuse, reageerimisvõime (kõik need koos) või lihtsalt kasutajaliidese funktsioonide tarnimisega, kui soovite seda teha vastutustundliku insenerina, aitab teile saadaolevate tööriistade tundmine teil oma eesmärke kiiremini ja paremini saavutada. Mõned asjad, mille jaoks te ei pruugi enam raamatukogu vajada Teades, mida brauserid tänapäeval toetavad, on küsimus järgmine: millest me saame loobuda? Kas vajame 2025. aastal ümarate nurkade tegemiseks div-komponenti? Muidugi, me ei tee seda. Piiriraadiuse atribuuti on toetanud kõik praegu kasutatavad brauserid praegusel hetkel enam kui 15 aastat. Ja peagi on tulemas ka nurgakuju, mis sobib veelgi uhkemate nurkade jaoks. Vaatame suhteliselt hiljutisi funktsioone, mis on nüüd saadaval kõigis suuremates brauserites ja mida saate kasutada koodibaasi olemasolevate sõltuvuste asendamiseks. Asi ei ole selles, et kõik oma armastatud raamatukogud kohe ära visata ja oma koodibaasi ümber kirjutada. Mis puutub kõigesse muusse, siis peate esmalt võtma arvesse brauseri tuge ja otsustama muude teie projektile iseloomulike tegurite põhjal. Järgmised funktsioonid on rakendatud kolmes peamises brauserimootoris (Chromium, WebKit ja Gecko), kuid teil võivad olla erinevad brauseri tuginõuded, mis takistavad teil neid koheselt kasutamast. Praegu on siiski hea aeg nende funktsioonidega tutvumiseks ja võib-olla plaanite neid mingil hetkel kasutada. Hüpikaknad ja dialoogid Popover API, HTML-element
Muidugi on tõenäoliselt ka teie Interneti-ühenduse kiirus suurenenud, kuid see ei kehti kõigi kohta. Ja kõigil pole ka ühesuguseid seadme võimalusi. Selle asemel, et platvormiga tehtavate asjade jaoks kasutada kolmanda osapoole koodi, tähendab see tõenäoliselt, et saadate rohkem koodi ja jõuate seega vähemate klientideni kui tavaliselt. Veebis põhjustab halb laadimisjõudlus suuri loobumismäärasid ja kahjustab kaubamärgi mainet. Töötab seadmetes vähem koodi Lisaks töötab kood, mille oma klientide seadmetesse saadate, tõenäoliselt kiiremini, kui see kasutab platvormi peal vähem JavaScripti abstraktsioone. See on tõenäoliselt ka vaikimisi tundlikum ja juurdepääsetavam. Kõik see toob kaasa rohkemate ja õnnelikumate klientideni. Vaadake minu kolleegi Alex Russelli iga-aastast tulemuslikkuse ebavõrdsuse lõhe ajaveebi, mis näitab, et esmaklassilised seadmed on miljardite kasutajatega turgudel varandusliku ebavõrdsuse tõttu suuresti puudu. Ja see lõhe aja jooksul ainult kasvab.
Sisseehitatud müüritise paigutus Üks peagi ilmuv veebiplatvormi funktsioon, mille üle ma olen väga põnevil, on CSS Masonry.
Lubage mul alustuseks selgitada, mis on müüritis. Mis on müüritis Müüritis on paigutustüüp, mille Pinterest tegi aastaid tagasi populaarseks. See loob sõltumatud sisurajad, millesse üksused pakivad end raja algusele võimalikult lähedale.
Paljud inimesed näevad müüritist suurepärase võimalusena portfellide ja fotogaleriide jaoks, mida see kindlasti teha saab. Kuid Masonry on paindlikum kui see, mida näete Pinterestis, ja see ei piirdu ainult koselaadsete paigutustega. Müüritise paigutuses:
Rajad võivad olla veerud või read:
Kõik sisurajad ei pea olema ühesuurused:
Üksused võivad hõlmata mitut rada:
Üksusi saab paigutada kindlatele radadele; nad ei pea alati järgima automaatset paigutusalgoritmi:
Demod Siin on mõned lihtsad demod, mille tegin Chromiumi CSS Masonry eelseisva juurutamise abil. Fotogalerii demo, mis näitab, kuidas üksused (antud juhul pealkiri) võivad hõlmata mitut rada:
Veel üks pildigalerii, kus on näha erineva suurusega radu:
Uudistesaidi paigutus, mille mõned rajad on teistest laiemad ja mõned üksused hõlmavad kogu paigutuse laiust:
Kanban-tahvel, mis näitab, et üksusi saab paigutada kindlatele radadele:
Märkus:Eelmised demod tehti Chromiumi versiooniga, mis pole enamikule veebikasutajatele veel saadaval, kuna CSS Masonry'i brauserites juurutamine alles algab. Veebiarendajad on aga juba aastaid hea meelega kasutanud teeke müüripaigutuste loomiseks. Tänapäeval müüritist kasutavad saidid Tõepoolest, müüritise on tänapäeval veebis üsna levinud. Siin on mõned näited, mille leidsin peale Pinteresti:
Ja veel mõned, vähem ilmsed näited:
Niisiis, kuidas need paigutused loodi? Lahendused Üks nipp, mida olen näinud kasutavat, on selle asemel Flexboxi paigutuse kasutamine, selle suuna muutmine veeruks ja mähise seadmine. Nii saate paigutada erineva kõrgusega esemeid mitmesse sõltumatusse veergu, jättes mulje müüritise paigutusest:
Sellel lahendusel on aga kaks piirangut.
Üksuste järjekord erineb sellest, mis see oleks tõelise müüritise paigutuse korral. Flexboxi puhul täidavad üksused kõigepealt esimese veeru ja kui see on täis, siis liiguvad järgmisse veergu. Müüritise puhul virnatakse esemed sellele rajale (või antud juhul veergu), kus on rohkem ruumi. Kuid ka, mis võib-olla veelgi olulisem, nõuab see lahendus Flexboxi konteineri fikseeritud kõrguse määramist; vastasel juhul ei toimuks mähkimist.
Kolmandate osapoolte müüritise raamatukogud Täiustatud juhtudel on arendajad kasutanud teeke. Selle kõige tuntumat ja populaarsemat raamatukogu nimetatakse lihtsalt Masonryks ja NPM-i andmetel laaditakse seda alla umbes 200 000 korda nädalas. Squarespace pakub koodita alternatiivina ka paigutuskomponenti, mis renderdab Masonry-paigutuse, ja paljud saidid kasutavad seda. Mõlemad valikud kasutavad üksuste paigutusse paigutamiseks JavaScripti koodi. Sisseehitatud müüritis Olen väga põnevil, et Masonry hakkab nüüd brauserites ilmuma sisseehitatud CSS-i funktsioonina. Aja jooksul saate Masonryt kasutada täpselt nagu Gridi või Flexboxi, st ilma lahendusi või kolmanda osapoole koodi vajamata. Minu Microsofti meeskond on Chromiumi avatud lähtekoodiga projektis rakendanud sisseehitatud müüritise tuge, millel Edge, Chrome ja paljud teised brauserid põhinevad. Mozilla oli tegelikult esimene brauserimüüja, kes pakkus 2020. aastal välja Masonry eksperimentaalse juurutamise. Samuti on Apple olnud väga huvitatud selle uue veebipaigutuse primitiivseks muutmisest. Töö funktsiooni standardiseerimiseks edeneb ka CSS-i töörühmas kokkuleppel üldise suuna ja isegi uue kuvatüüpi kuva: grid-lanes. Kui soovite müüritise kohta rohkem teada saada ja edenemist jälgida, vaadake minu CSS-i müüritise ressursside lehte. Aja jooksul, kui müüritisest saab põhifunktsioon, nagu Grid või Flexbox, saame seda lihtsalt kasutada ja saada kasu järgmistest eelistest:
Parem jõudlus, Parem reageerimisvõime, Kasutuslihtsus ja lihtsam kood.
Vaatame neid lähemalt. Parem jõudlus Oma müüritiselaadse paigutussüsteemi loomine või selle asemel kolmanda osapoole teegi kasutamine tähendab, et peate üksuste ekraanile paigutamiseks käivitama JavaScripti koodi. See tähendab ka seda, et see kood blokeerib renderdamise. Tõepoolest, enne JavaScripti koodi käivitamist ei kuvata midagi või pole asjad õiges kohas või õige suurusega. Müüripaigutust kasutatakse sageli veebilehe põhiosa jaoks, mis tähendab, et kood paneb teie põhisisu ilmuma hiljem, kui see muidu oleks, halvendades teie LCP-d ehk suurima sisuga värvide mõõdikut, mis mängib suurt rolli tajutavas toimivuses ja otsingumootori optimeerimises. Testisin Masonry JS teeki lihtsa paigutusega ja simuleerides DevToolsis aeglast 4G-ühendust. Teek pole kuigi suur (24KB, 7,8KB gzipped), kuid minu katsetingimustes kulus selle laadimiseks 600 ms. Siin on jõudluse salvestis, mis näitab, et Masonry teegi pikk laadimisaeg on 600 ms ja et selle toimumise ajal ei toimunud ühtegi muud renderdamistegevust:
Lisaks tuli pärast esialgset laadimisaega allalaaditud skript sõeluda, kompileerida ja seejärel käivitada. Kõik see, nagu varem mainitud, blokeeris lehe renderdamise. Kui brauseris on sisseehitatud Masonry-rakendus, ei ole meil laadimiseks ja käivitamiseks skripti. Brauseri mootor teeb lehe algse renderdamise etapis lihtsalt oma asja. Parem reageerimisvõime Sarnaselt lehe esmakordsele laadimisele viib brauseriakna suuruse muutmine selle lehe paigutuse uuesti renderdamiseni. Kui aga leht kasutab Masonry JS-i teeki, ei ole vaja skripti uuesti laadida, kuna see on jubasiin. Siiski tuleb käivitada kood, mis liigutab üksusi õigetesse kohtadesse. Nüüd tundub, et see konkreetne teek teeb seda lehe laadimisel üsna kiiresti. See aga animeerib üksusi, kui need peavad akna suuruse muutmisel teise kohta teisaldama, ja see muudab palju. Muidugi ei kuluta kasutajad oma brauseriakende suuruse muutmisele nii palju aega kui meie, arendajad. Kuid see animeeritud suuruse muutmise kogemus võib olla üsna häiriv ja pikendab lehe uue suurusega kohanemiseks kuluvat aega. Kasutuslihtsus ja lihtsam kood Kui lihtne on veebifunktsiooni kasutada ja kui lihtne kood välja näeb, on olulised tegurid, mis võivad teie meeskonda oluliselt mõjutada. Loomulikult ei saa need kunagi olla nii olulised kui lõppkasutaja kogemus, kuid arendaja kogemus mõjutab hooldatavust. Sisseehitatud veebifunktsiooni kasutamine toob kaasa olulisi eeliseid:
Arendajad, kes juba tunnevad HTML-i, CSS-i ja JS-i, saavad seda funktsiooni tõenäoliselt hõlpsasti kasutada, kuna see on loodud hästi integreeruma ja olema kooskõlas ülejäänud veebiplatvormiga. Puudub oht, et funktsiooni kasutamises tehakse muudatusi. Oht, et see funktsioon aegub või seda ei hooldata, on peaaegu null.
Sisseehitatud müüritise puhul, kuna see on primitiivne paigutus, kasutate seda CSS-ist, nagu Grid või Flexbox, JS-i ei kasutata. Ka muud paigutusega seotud CSS-i atribuudid, nagu lünk, töötavad ootuspäraselt. Pole vaja teada nippe ega lahendusi ning asjad, mida õpite, on dokumenteeritud MDN-is. Masonry JS lib-i jaoks on lähtestamine pisut keeruline: see nõuab kindla süntaksiga andmeatribuuti koos peidetud HTML-elementidega, et määrata veergude ja tühikute suurus. Kui soovite veerge katta, peate probleemide vältimiseks ise lisama vahe suuruse:
Võrdleme seda sellega, kuidas näeks välja sisseehitatud müüritise teostus:
Lihtsam ja kompaktsem kood, mis võib lihtsalt kasutada selliseid asju nagu vahe ja kus radade ületamine toimub vahemikuga 2, nagu ruudustikus, ja ei nõua õige laiuse arvutamist, mis sisaldab vahe suurust. Kuidas teada saada, mis on saadaval ja millal see saadaval on? Üldiselt pole küsimus selles, kas peaksite JS-i teegi kohal kasutama sisseehitatud müüritist, vaid pigem selles, millal. Masonry JS teek on hämmastav ja on täitnud veebiplatvormis lünka juba aastaid ning paljude õnnelike arendajate ja kasutajate jaoks. Sellel on muidugi mõned puudused, kui võrrelda seda sisseehitatud müüritise teostusega, kuid need pole olulised, kui see teostus pole valmis. Mul on lihtne neid lahedaid uusi veebiplatvormi funktsioone loetleda, kuna töötan brauseri müüja juures ja seetõttu tean, mis tulemas on. Kuid arendajad jagavad sageli küsitluse järel, et uute asjade jälgimine on raske. Informatsiooni hoidmine on keeruline ja ettevõtted ei pea alati õppimist prioriteediks. Selle abistamiseks on siin mõned ressursid, mis pakuvad värskendusi lihtsal ja kompaktsel viisil, et saaksite kiiresti vajaliku teabe.
Veebiplatvormil on Exploreri sait: Teid võib huvitada selle väljalaskemärkmete leht. Ja kui teile meeldib RSS, vaadake väljalaskemärkmete voogu, samuti vooge Baseline Newly Available ja Widely Available.
VeebPlatvormi oleku armatuurlaud: Sulle võivad meeldida selle erinevad algtaseme aastalehed.
Chrome'i platvormi oleku teekaardi leht.
Kui teil on veidi rohkem aega, võivad teid huvitada ka brauseritootjate väljalaskemärkused:
Chrome Edge Firefox Safari
Veelgi rohkemate ressursside saamiseks vaadake minu veebiplatvormil navigeerimise lehtlehte. Minu asja pole ikka veel rakendatud See on probleemi teine pool. Isegi kui leiate aega, energiat ja viise, et jälgida, on teie hääle kuulmine ja lemmikfunktsioonide rakendamine endiselt pettunud. Võib-olla olete aastaid oodanud konkreetse vea lahendamist või konkreetse funktsiooni tarnimist brauseris, kus see ikka veel puudub. Ma ütlen, et brauserimüüjad kuulavad. Olen osa mitmest organisatsiooniülesest meeskonnast, kus arutame pidevalt arendajate signaale ja tagasisidet. Vaatame paljusid erinevaid tagasiside allikaid, nii iga brauseri müüja sisemisi kui ka väliseid/avalikke foorumeid, avatud lähtekoodiga projekte, ajaveebe ja küsitlusi. Ja me püüame alati luua paremaid viise, kuidas arendajad saaksid jagada oma konkreetseid vajadusi ja kasutusjuhtumeid. Seega, kui saate, nõudke brauserimüüjatelt rohkem ja avaldage meile survet, et rakendaksime teile vajalikke funktsioone. Ma saan aru, et see võtab aega ja võib olla ka hirmutav (rääkimata kõrgest sisenemisbarjäärist), kuid see toimib ka. Siin on mõned viisid, kuidas oma (või oma ettevõtte) häält kuulda võtta. Vaadake iga-aastaseid uuringuid JS-i, CSS-i seisu ja HTML-i seisu kohta. Nad mängivad suurt rolli selles, kuidas brauserimüüjad oma tööd tähtsuse järjekorda panevad. Kui teil on vaja kindlat standardipõhist API-t, mida järjepidevalt kõigis brauserites juurutada, kaaluge ettepaneku esitamist järgmisel Interopi projekti iteratsioonil. See nõuab rohkem aega, kuid mõelge, kuidas Shopify ja RUMvision jagasid oma Interop 2026 soovide loendeid. Selline üksikasjalik teave võib olla brauseritootjate jaoks eelisjärjekorras väga kasulik. Rohkem kasulikke linke brauserimüüjate mõjutamiseks vaadake minu veebiplatvormil navigeerimise lehe lehelt. Järeldus Lõpetuseks loodan, et see artikkel on jätnud teile mõned mõtted:
Põnevus müüritise ja muude tulevaste veebifunktsioonide pärast. Mõned veebifunktsioonid, mida võiksite hakata kasutama. Mõned kohandatud või kolmanda osapoole kooditükid, mille saate sisseehitatud funktsioonide kasuks eemaldada. Mõned viisid tulevaste sündmuste jälgimiseks ja brauserimüüjate mõjutamiseks.
Veelgi olulisem on see, et ma loodan, et olen teid veennud veebiplatvormi täieliku kasutamise eelistes.
