Sowat 15 jaar gelede het ek by 'n maatskappy gewerk waar ons toepassings vir reisagente, lughawewerkers en lugrederymaatskappye gebou het. Ons het ook ons eie interne raamwerk vir UI-komponente en enkelbladsy-toepassingsvermoëns gebou. Ons het komponente vir alles gehad: velde, knoppies, oortjies, reekse, datatabelle, spyskaarte, datumkiesers, keuses en multiseleksies. Ons het selfs 'n div-komponent gehad. Ons div-komponent was terloops wonderlik, dit het ons toegelaat om afgeronde hoeke op alle blaaiers te doen, wat, glo dit of nie, destyds nie 'n maklike ding was om te doen nie.
Ons werk het plaasgevind op 'n punt in ons geskiedenis toe JS, Ajax en dinamiese HTML gesien is as 'n rewolusie wat ons in die toekoms gebring het. Skielik kon ons 'n bladsy dinamies opdateer, data van 'n bediener af kry en vermy om na ander bladsye te navigeer, wat as stadig beskou is en 'n groot wit reghoek op die skerm tussen die twee bladsye flits. Daar was 'n frase, gewild gemaak deur Jeff Atwood (die stigter van StackOverflow), wat lui: “Enige toepassing wat in JavaScript geskryf kan word, sal uiteindelik in JavaScript geskryf word.”— Jeff Atwood
Vir ons het dit destyds gevoel soos 'n waagstuk om eintlik daardie toepassings te gaan skep. Dit het soos 'n kombers goedkeuring gevoel om alles saam met JS te doen. Ons het dus alles saam met JS gedoen, en ons het nie regtig tyd geneem om ander maniere om dinge te doen na te vors nie. Ons het nie regtig die aansporing gevoel om behoorlik te leer wat HTML en CSS kan doen nie. Ons het die web nie regtig as 'n ontwikkelende app-platform in sy geheel beskou nie. Ons het dit meestal gesien as iets waaraan ons moet werk, veral as dit by blaaierondersteuning kom. Ons kan net meer JS daarop gooi om dinge gedoen te kry. Sou dit my gehelp het om die tyd te neem om meer te wete te kom oor hoe die web werk en wat op die platform beskikbaar was? Sekerlik, ek kon waarskynlik 'n klomp kode geskeer het wat nie regtig nodig was nie. Maar, destyds, miskien nie so baie nie. Jy sien, blaaierverskille was destyds redelik beduidend. Dit was 'n tyd toe Internet Explorer steeds die oorheersende blaaier was, met Firefox die naaste tweede, maar begin markaandeel verloor as gevolg van Chrome wat vinnig gewild geword het. Alhoewel Chrome en Firefox redelik goed was om oor webstandaarde ooreen te kom, het die omgewings waarin ons toepassings geloop het, beteken dat ons IE6 vir 'n lang tyd moes ondersteun. Selfs toe ons toegelaat is om IE8 te ondersteun, moes ons steeds baie verskille tussen blaaiers hanteer. Nie net dit nie, maar die web van destyds het net nie soveel vermoëns in die platform ingebou gehad nie.
Vinnig vorentoe na vandag. Dinge het geweldig verander. Ons het nie net meer van hierdie vermoëns as ooit tevore nie, maar die tempo waarteen dit beskikbaar word, het ook toegeneem.
Laat ek dan weer die vraag vra: Sal dit jou vandag help om die tyd te neem om meer te wete te kom oor hoe die web werk en wat op die platform beskikbaar is? Absoluut ja. As u vandag leer om die webplatform te verstaan en te gebruik, het u 'n groot voordeel bo ander ontwikkelaars.
Of jy nou werk aan werkverrigting, toeganklikheid, responsiwiteit, alles saam, of net die stuur van UI-kenmerke, as jy dit as 'n verantwoordelike ingenieur wil doen, om te weet wat die gereedskap is wat tot jou beskikking is, help jou om jou doelwitte vinniger en beter te bereik.
Sommige dinge waarvoor jy dalk nie meer 'n biblioteek nodig het nie
Om te weet wat blaaiers vandag ondersteun, is die vraag dan: Wat kan ons laat vaar? Het ons 'n div-komponent nodig om in 2025 afgeronde hoeke te doen? Natuurlik, ons doen dit nie. Die grensradius-eienskap word op hierdie stadium vir meer as 15 jaar deur alle blaaiers wat tans gebruik word, ondersteun. En hoek-vorm kom ook binnekort, vir selfs meer spoggerige hoeke.
Kom ons kyk na relatief onlangse kenmerke wat nou in alle groot blaaiers beskikbaar is, en wat jy kan gebruik om bestaande afhanklikhede in jou kodebasis te vervang.
Die punt is nie om dadelik al jou geliefde biblioteke te laat vaar en jou kodebasis te herskryf nie. Wat alles anders betref, moet u eers blaaierondersteuning in ag neem en besluit op grond van ander faktore spesifiek vir u projek. Die volgende kenmerke word in die drie hoofblaaier-enjins (Chromium, WebKit en Gecko) geïmplementeer, maar jy het dalk verskillende blaaierondersteuningsvereistes wat jou verhoed om dit dadelik te gebruik. Dit is egter nou nog 'n goeie tyd om meer oor hierdie kenmerke te leer, en miskien beplan om dit een of ander tyd te gebruik.
Popovers En Dialogs
Die Popover API, die
Sekerlik, jou internetverbindingspoed het waarskynlik ook toegeneem, maar dit is nie die geval vir almal nie. En nie almal het ook dieselfde toestelvermoë nie. As u derdeparty-kode intrek vir dinge wat u met die platform kan doen, beteken dit heel waarskynlik dat u meer kode stuur en dus minder kliënte bereik as wat u normaalweg sou doen. Op die web lei swak laaiprestasie tot groot verlatingsyfers en benadeel handelsmerkreputasie. Hardloop minder kode op toestelle Verder loop die kode wat u wel op u kliënte se toestelle stuur waarskynlik vinniger as dit minder JavaScript-abstraksies bo-op die platform gebruik. Dit is ook waarskynlik meer responsief en by verstek meer toeganklik. Dit alles lei tot meer en gelukkiger kliënte. Kyk na my kollega Alex Russell se jaarlikse prestasie-ongelykheidsgaping-blog, wat toon dat premium-toestelle grootliks afwesig is van markte met miljarde gebruikers as gevolg van rykdomsongelykheid. En hierdie gaping groei net mettertyd.
Ingeboude messelwerk uitleg Een webplatformkenmerk wat binnekort kom en waaroor ek baie opgewonde is, is CSS Masonry.
Laat ek begin deur te verduidelik wat messelwerk is. Wat is messelwerk Messelwerk is 'n tipe uitleg wat jare gelede deur Pinterest gewild gemaak is. Dit skep onafhanklike snitte van inhoud waarbinne items hulself so na as moontlik aan die begin van die snit oppak.
Baie mense sien messelwerk as 'n goeie opsie vir portefeuljes en fotogalerye, wat dit beslis kan doen. Maar Masonry is meer buigsaam as wat jy op Pinterest sien, en dit is nie beperk tot net watervalagtige uitlegte nie. In 'n messelwerk-uitleg:
Snitte kan kolomme of rye wees:
Snitte van inhoud hoef nie almal dieselfde grootte te wees nie:
Items kan oor verskeie snitte strek:
Items kan op spesifieke bane geplaas word; hulle hoef nie altyd die outomatiese plasingsalgoritme te volg nie:
Demo's Hier is 'n paar eenvoudige demonstrasies wat ek gemaak het deur die komende implementering van CSS Masonry in Chromium te gebruik. 'n Fotogalery-demo, wat wys hoe items (die titel in hierdie geval) oor verskeie snitte kan strek:
Nog 'n fotogalery wat snitte van verskillende groottes wys:
'n Nuuswerfuitleg met sommige snitte wyer as ander, en sommige items wat oor die hele breedte van die uitleg strek:
'n Kanban-bord wat wys dat items op spesifieke bane geplaas kan word:
Let wel: Dievorige demonstrasies is gemaak met 'n weergawe van Chromium wat nog nie vir die meeste webgebruikers beskikbaar is nie, want CSS Masonry begin nou eers in blaaiers geïmplementeer word. Webontwikkelaars gebruik egter al jare gelukkig biblioteke om messelwerk-uitlegte te skep. Werwe wat vandag messelwerk gebruik Inderdaad, messelwerk is vandag redelik algemeen op die web. Hier is 'n paar voorbeelde wat ek behalwe Pinterest gevind het:
En 'n paar meer, minder ooglopende, voorbeelde:
So, hoe is hierdie uitlegte geskep? Oplossings Een truuk wat ek al gebruik het, is om eerder 'n Flexbox-uitleg te gebruik, die rigting daarvan na kolom te verander en dit om te vou. Op hierdie manier kan jy items van verskillende hoogtes in veelvuldige, onafhanklike kolomme plaas, wat die indruk van 'n messelwerk-uitleg gee:
Daar is egter twee beperkings met hierdie oplossing:
Die volgorde van items is anders as wat dit sou wees met 'n regte messelwerk-uitleg. Met Flexbox vul items eers die eerste kolom en, wanneer dit vol is, gaan dan na die volgende kolom. Met Masonry, sal items stapel in watter baan (of kolom in hierdie geval) meer spasie beskikbaar het. Maar ook, en dalk nog belangriker, hierdie oplossing vereis dat jy 'n vaste hoogte op die Flexbox-houer stel; anders sou geen wikkeling plaasvind nie.
Derdeparty-messelarybiblioteke Vir meer gevorderde gevalle het ontwikkelaars biblioteke gebruik. Die bekendste en gewildste biblioteek hiervoor word bloot Masonry genoem, en dit word volgens NPM ongeveer 200 000 keer per week afgelaai. Squarespace bied ook 'n uitlegkomponent wat 'n Masonry-uitleg lewer, vir 'n geen-kode-alternatief, en baie werwe gebruik dit. Albei hierdie opsies gebruik JavaScript-kode om items in die uitleg te plaas. Ingeboude messelwerk Ek is baie opgewonde dat Masonry nou in blaaiers begin verskyn as 'n ingeboude CSS-funksie. Met verloop van tyd sal jy Masonry kan gebruik net soos Grid of Flexbox, dit wil sê sonder om enige oplossings of derdeparty-kode te benodig. My span by Microsoft het ingeboude Masonry-ondersteuning geïmplementeer in die Chromium oopbronprojek, waarop Edge, Chrome en baie ander blaaiers gebaseer is. Mozilla was eintlik die eerste blaaierverkoper wat 'n eksperimentele implementering van Masonry in 2020 voorgestel het. En Apple was ook baie geïnteresseerd om hierdie nuwe webuitleg primitief te laat gebeur. Die werk om die kenmerk te standaardiseer vorder ook, met ooreenkoms binne die CSS-werkgroep oor die algemene rigting en selfs 'n nuwe vertoontipe vertoning: roosterbane. As jy meer wil leer oor Masonry en vordering wil volg, kyk na my CSS Masonry-hulpbronbladsy. Mettertyd, wanneer messelwerk 'n basislynkenmerk word, net soos Grid of Flexbox, sal ons dit eenvoudig kan gebruik en voordeel trek uit:
Beter prestasie, Beter reaksie, Gebruiksgemak en eenvoudiger kode.
Kom ons kyk van nader hierna. Beter prestasie Om jou eie messelwerk-agtige uitlegstelsel te maak, of eerder 'n derdeparty-biblioteek te gebruik, beteken dat jy JavaScript-kode moet gebruik om items op die skerm te plaas. Dit beteken ook dat hierdie kode blokkerend sal lewer. Inderdaad, óf niks sal verskyn nie, óf dinge sal nie op die regte plekke of van die regte groottes wees totdat daardie JavaScript-kode geloop het nie. Messelwerk-uitleg word dikwels gebruik vir die hoofgedeelte van 'n webblad, wat beteken dat die kode jou hoofinhoud later sou laat verskyn as wat dit andersins sou kon hê, wat jou LCP, of Largest Contentful Paint-metriek, verneder, wat 'n groot rol speel in waargenome werkverrigting en soekenjinoptimalisering. Ek het die Masonry JS-biblioteek getoets met 'n eenvoudige uitleg en deur 'n stadige 4G-verbinding in DevTools te simuleer. Die biblioteek is nie baie groot nie (24KB, 7.8KB gzipped), maar dit het 600ms geneem om onder my toetstoestande te laai. Hier is 'n prestasie-opname wat die lang laaityd van 600 ms vir die Masonry-biblioteek wys, en dat geen ander weergawe-aktiwiteit plaasgevind het terwyl dit gebeur het nie:
Daarbenewens moes die afgelaaide skrip na die aanvanklike laaityd ontleed, saamgestel en dan uitgevoer word. Al wat, soos voorheen genoem, die weergawe van die bladsy geblokkeer het. Met 'n ingeboude Masonry-implementering in die blaaier, sal ons nie 'n skrip hê om te laai en uit te voer nie. Die blaaier-enjin sal net sy ding doen tydens die aanvanklike bladsyweergawestap. Beter responsiwiteit Soortgelyk aan wanneer 'n bladsy die eerste keer laai, lei die verandering van die grootte van die blaaiervenster daartoe dat die uitleg in daardie bladsy weer vertoon word. Maar op hierdie stadium, as die bladsy die Masonry JS-biblioteek gebruik, is dit nie nodig om die skrif weer te laai nie, want dit is reedshier. Die kode wat items op die regte plekke skuif, moet egter loop. Nou blyk dit dat hierdie spesifieke biblioteek redelik vinnig is om dit te doen wanneer die bladsy laai. Dit animeer egter die items wanneer hulle na 'n ander plek moet skuif met venstergrootte, en dit maak 'n groot verskil. Natuurlik spandeer gebruikers nie tyd om hul blaaiervensters soveel te verander as wat ons ontwikkelaars doen nie. Maar hierdie geanimeerde verandering van grootte-ervaring kan redelik skokkend wees en dra by tot die waargenome tyd wat dit neem vir die bladsy om by sy nuwe grootte aan te pas. Gebruiksgemak en eenvoudiger kode Hoe maklik dit is om 'n webfunksie te gebruik en hoe eenvoudig die kode lyk, is belangrike faktore wat 'n groot verskil vir jou span kan maak. Hulle kan natuurlik nooit so belangrik wees soos die finale gebruikerservaring nie, maar ontwikkelaarervaring het 'n impak op die onderhoubaarheid. Die gebruik van 'n ingeboude webfunksie het belangrike voordele op daardie front:
Ontwikkelaars wat reeds HTML, CSS en JS ken, sal heel waarskynlik daardie kenmerk maklik kan gebruik omdat dit ontwerp is om goed te integreer en konsekwent met die res van die webplatform te wees. Daar is geen risiko dat veranderinge aangebring word in hoe die kenmerk gebruik word nie. Daar is amper geen risiko dat daardie kenmerk afgekeur of ononderhou word nie.
In die geval van ingeboude messelwerk, omdat dit 'n primitiewe uitleg is, gebruik jy dit vanaf CSS, net soos Grid of Flexbox, geen JS betrokke nie. Ander uitlegverwante CSS-eienskappe, soos gaping, werk ook soos u van hulle verwag. Daar is geen truuks of oplossings om van te weet nie, en die dinge wat jy wel leer, word op MDN gedokumenteer. Vir die Masonry JS lib is inisialisering 'n bietjie kompleks: dit vereis 'n data-kenmerk met 'n spesifieke sintaksis, saam met verborge HTML-elemente om die kolom- en gapingsgroottes te stel. Plus, as jy kolomme wil oorspan, moet jy self die gapingsgrootte insluit om probleme te vermy:
Kom ons vergelyk dit met hoe 'n ingeboude Masonry-implementering sal lyk:
Eenvoudiger, meer kompakte kode wat net dinge soos gaping en waar spanningspore kan gebruik, word met span 2 gedoen, net soos in rooster, en vereis nie dat jy die regte breedte bereken wat die gapingsgrootte insluit nie. Hoe om te weet wat beskikbaar is en wanneer dit beskikbaar is? Oor die algemeen is die vraag nie regtig of jy ingeboude messelwerk oor 'n JS-biblioteek moet gebruik nie, maar eerder wanneer. Die Masonry JS-biblioteek is ongelooflik en vul al vir baie jare 'n gaping in die webplatform, en vir baie gelukkige ontwikkelaars en gebruikers. Dit het natuurlik 'n paar nadele as jy dit vergelyk met 'n ingeboude messelwerk-implementering, maar dit is nie belangrik as daardie implementering nie gereed is nie. Dit is maklik vir my om hierdie oulike nuwe webplatformkenmerke te lys, want ek werk by 'n blaaierverskaffer, en ek is dus geneig om te weet wat kom. Maar ontwikkelaars deel dikwels, opname na opname, dat dit moeilik is om tred te hou met nuwe dinge. Dit is moeilik om ingelig te bly, en maatskappye prioritiseer in elk geval nie altyd leer nie. Om hiermee te help, is hier 'n paar hulpbronne wat opdaterings op eenvoudige en kompakte maniere verskaf sodat jy vinnig die inligting kan kry wat jy nodig het:
Die webplatform beskik oor ontdekkingsreisigerwebwerf: Jy sal dalk belangstel in sy vrystellingnotas-bladsy. En, as jy van RSS hou, kyk na die vrystellingnotas-feed, sowel as die Baseline Nuut Beskikbare en Wyd Beskikbare feeds.
Die WebPlatformstatus-kontroleskerm: Jy hou dalk van sy verskillende basislynjaarbladsye.
Chrome Platform Status se padkaartbladsy.
As jy 'n bietjie meer tyd het, sal jy dalk ook belangstel in blaaierverskaffers se vrystellingsnotas:
Chrome Rand Firefox Safari
Vir nog meer hulpbronne, kyk na my Navigeer deur die webplatform-cheatsheet. My ding is steeds nie geïmplementeer nie Dit is die ander kant van die probleem. Selfs al vind jy die tyd, energie en maniere om tred te hou, is daar steeds frustrasie om jou stem te laat hoor en jou gunsteling kenmerke te geïmplementeer. Miskien wag jy al jare vir 'n spesifieke fout om opgelos te word, of 'n spesifieke kenmerk om in 'n blaaier te stuur waar dit nog ontbreek. Wat ek sal sê, is blaaierverkopers luister. Ek is deel van verskeie kruisorganisasiespanne waar ons heeltyd ontwikkelaarseine en -terugvoer bespreek. Ons kyk na baie verskillende bronne van terugvoer, beide intern by elke blaaierverskaffer en ekstern/publiek op forums, oopbronprojekte, blogs en opnames. En ons probeer altyd om beter maniere te skep vir ontwikkelaars om hul spesifieke behoeftes en gebruiksgevalle te deel. Dus, as jy kan, eis asseblief meer van blaaierverkopers en druk ons om die funksies wat jy nodig het te implementeer. Ek verstaan dat dit tyd neem, en ook intimiderend kan wees (om nie eens te praat van 'n hoë versperring tot toegang nie), maar dit werk ook. Hier is 'n paar maniere waarop jy jou (of jou maatskappy se) stem kan laat hoor: Neem die jaarlikse State of JS, State of CSS, en State of HTML-opnames. Hulle speel 'n groot rol in hoe blaaierverkopers hul werk prioritiseer. As jy 'n spesifieke standaard-gebaseerde API nodig het om konsekwent oor blaaiers geïmplementeer te word, oorweeg dit om 'n voorstel by die volgende Interop-projek-iterasie in te dien. Dit verg meer tyd, maar oorweeg hoe Shopify en RUMvision hul wenslyste vir Interop 2026 gedeel het. Gedetailleerde inligting soos hierdie kan baie nuttig wees vir blaaierverkopers om te prioritiseer. Vir meer nuttige skakels om blaaierverkopers te beïnvloed, kyk na my Navigeer deur die webplatform-cheatsheet. Gevolgtrekking Om af te sluit, hoop ek dat hierdie artikel jou 'n paar dinge gelaat het om oor na te dink:
Opwinding vir messelwerk en ander opkomende webkenmerke. 'n Paar webkenmerke wat jy dalk wil begin gebruik. 'n Paar stukke pasgemaakte of derdeparty-kode wat jy dalk kan verwyder ten gunste van ingeboude kenmerke. 'n Paar maniere om tred te hou met wat kom en blaaierverkopers te beïnvloed.
Nog belangriker, ek hoop ek het jou oortuig van die voordele van die gebruik van die webplatform tot sy volle potensiaal.
