For omkring 15 år siden arbejdede jeg i en virksomhed, hvor vi byggede apps til rejsebureauer, lufthavnsarbejdere og flyselskaber. Vi byggede også vores egne interne rammer til UI-komponenter og enkeltsides app-funktioner. Vi havde komponenter til alt: felter, knapper, faner, intervaller, datatabeller, menuer, datepickers, selects og multiselects. Vi havde endda en div-komponent. Vores div-komponent var i øvrigt fantastisk, den gav os mulighed for at lave afrundede hjørner på alle browsere, hvilket, tro det eller ej, ikke var en nem ting at gøre på det tidspunkt.
Vores arbejde fandt sted på et tidspunkt i vores historie, hvor JS, Ajax og dynamisk HTML blev set som en revolution, der bragte os ind i fremtiden. Pludselig kunne vi opdatere en side dynamisk, hente data fra en server og undgå at skulle navigere til andre sider, hvilket blev set som langsomt og blinkede med et stort hvidt rektangel på skærmen mellem de to sider. Der var en sætning, gjort populær af Jeff Atwood (grundlæggeren af StackOverflow), som lød: "Enhver applikation, der kan skrives i JavaScript, vil i sidste ende blive skrevet i JavaScript." - Jeff Atwood
For os på det tidspunkt føltes det som en tur til rent faktisk at gå hen og lave de apps. Det føltes som en generel godkendelse at gøre alt sammen med JS. Så vi gjorde alt med JS, og vi tog os ikke rigtig tid til at undersøge andre måder at gøre tingene på. Vi følte ikke rigtigt incitamentet til ordentligt at lære, hvad HTML og CSS kunne gøre. Vi opfattede egentlig ikke nettet som en app-platform i udvikling i sin helhed. Vi så det for det meste som noget, vi skulle omgås, især når det kom til browserunderstøttelse. Vi kunne bare kaste mere JS på det for at få tingene gjort. Ville det hjælpe mig at tage mig tid til at lære mere om, hvordan nettet fungerede, og hvad der var tilgængeligt på platformen? Sikker på, jeg kunne nok have barberet en masse kode, der ikke virkelig var nødvendigt. Men på det tidspunkt, måske ikke så meget. Du kan se, browserforskelle var ret betydelige dengang. Dette var en tid, hvor Internet Explorer stadig var den dominerende browser, hvor Firefox var den nærmeste anden, men begyndte at tabe markedsandele på grund af Chrome, der hurtigt vandt popularitet. Selvom Chrome og Firefox var ret gode til at blive enige om webstandarder, betød miljøerne, som vores apps kørte i, at vi i lang tid skulle understøtte IE6. Selv da vi fik lov til at understøtte IE8, skulle vi stadig håndtere en masse forskelle mellem browsere. Ikke nok med det, men datidens web havde bare ikke så mange muligheder indbygget direkte i platformen.
Spol frem til i dag. Tingene har ændret sig enormt. Ikke alene har vi flere af disse muligheder end nogensinde før, men den hastighed, hvormed de bliver tilgængelige, er også steget. Lad mig stille spørgsmålet igen, så: Vil det hjælpe dig i dag at tage dig tid til at lære mere om, hvordan nettet fungerer, og hvad der er tilgængeligt på platformen? Absolut ja. At lære at forstå og bruge webplatformen i dag giver dig en enorm fordel i forhold til andre udviklere. Uanset om du arbejder med ydeevne, tilgængelighed, lydhørhed, dem alle sammen eller bare sender brugergrænsefladefunktioner, hvis du ønsker at gøre det som en ansvarlig ingeniør, hjælper det dig med at nå dine mål hurtigere og bedre, hvis du kender de værktøjer, der er tilgængelige for dig. Nogle ting, du måske ikke har brug for et bibliotek til længere Når vi ved, hvad browsere understøtter i dag, er spørgsmålet så: Hvad kan vi droppe? Har vi brug for en div-komponent til at lave afrundede hjørner i 2025? Selvfølgelig gør vi ikke. Egenskaben border-radius er blevet understøttet af alle aktuelt brugte browsere i mere end 15 år på dette tidspunkt. Og hjørneform kommer også snart, til endnu mere avancerede hjørner. Lad os tage et kig på relativt nyere funktioner, der nu er tilgængelige i alle større browsere, og som du kan bruge til at erstatte eksisterende afhængigheder i din kodebase. Pointen er ikke straks at droppe alle dine elskede biblioteker og omskrive din kodebase. Hvad angår alt andet, skal du først tage browsersupport i betragtning og beslutte dig baseret på andre faktorer, der er specifikke for dit projekt. Følgende funktioner er implementeret i de tre hovedbrowsermotorer (Chromium, WebKit og Gecko), men du har muligvis forskellige browsersupportkrav, der forhindrer dig i at bruge dem med det samme. Nu er det dog stadig et godt tidspunkt at lære om disse funktioner, og måske planlægge at bruge dem på et tidspunkt. Popovers og dialogbokse Popover API,
Sikker på, din internetforbindelseshastighed er sandsynligvis også steget, men det er ikke tilfældet for alle. Og det er heller ikke alle, der har de samme enhedsegenskaber. At trække tredjepartskode til ting, du kan gøre med platformen, betyder i stedet højst sandsynligt, at du sender mere kode og derfor når ud til færre kunder, end du normalt ville. På nettet fører dårlig indlæsningsydelse til høje afbrydelsesrater og skader brandets omdømme. Kører mindre kode på enheder Desuden kører den kode, du sender på dine kunders enheder, sandsynligvis hurtigere, hvis den bruger færre JavaScript-abstraktioner oven på platformen. Det er sandsynligvis også mere responsivt og mere tilgængeligt som standard. Alt dette fører til flere og gladere kunder. Tjek min kollega Alex Russells årlige blog om ulighedsgab i ydeevnen, som viser, at premium-enheder stort set er fraværende på markeder med milliarder af brugere på grund af ulighed i rigdom. Og denne kløft vokser kun over tid.
Indbygget Murværk Layout En webplatformsfunktion, der snart kommer, og som jeg er meget begejstret for, er CSS Masonry.
Lad mig starte med at forklare, hvad murværk er. Hvad er murværk Murværk er en type layout, der blev gjort populær af Pinterest for år siden. Det skaber uafhængige spor af indhold, inden for hvilke varer pakker sig selv så tæt på starten af sporet, som de kan.
Mange mennesker ser murværk som en fantastisk mulighed for porteføljer og fotogallerier, hvilket det bestemt kan. Men Masonry er mere fleksibelt end hvad du ser på Pinterest, og det er ikke begrænset til kun vandfaldslignende layouts. I et murværkslayout:
Spor kan være kolonner eller rækker:
Indholdsnumre behøver ikke alle at have samme størrelse:
Elementer kan strække sig over flere spor:
Genstande kan placeres på bestemte spor; de behøver ikke altid at følge den automatiske placeringsalgoritme:
Demoer Her er et par enkle demoer, jeg lavede ved at bruge den kommende implementering af CSS Masonry i Chromium. En fotogalleridemo, der viser, hvordan elementer (titlen i dette tilfælde) kan spænde over flere spor:
Et andet fotogalleri, der viser spor i forskellige størrelser:
Et nyhedssidelayout med nogle spor bredere end andre, og nogle elementer spænder over hele layoutets bredde:
En kanban-tavle, der viser, at genstande kan placeres på bestemte spor:
Bemærk: Dentidligere demoer blev lavet med en version af Chromium, der endnu ikke er tilgængelig for de fleste webbrugere, fordi CSS Masonry kun lige er begyndt at blive implementeret i browsere. Imidlertid har webudviklere med glæde brugt biblioteker til at skabe Masonry-layouts i årevis allerede. Websteder, der bruger murværk i dag Faktisk er murværk ret almindeligt på nettet i dag. Her er et par eksempler, jeg fandt udover Pinterest:
Og et par flere, mindre indlysende, eksempler:
Så hvordan blev disse layouts skabt? Løsninger Et trick, som jeg har set brugt, er at bruge et Flexbox-layout i stedet, at ændre dets retning til kolonne og indstille det til at ombryde. På denne måde kan du placere emner af forskellig højde i flere uafhængige kolonner, hvilket giver indtryk af et murværkslayout:
Der er dog to begrænsninger med denne løsning:
Rækkefølgen af emner er forskellig fra, hvad den ville være med et ægte murværkslayout. Med Flexbox udfylder elementer den første kolonne først, og når den er fuld, går du derefter til den næste kolonne. Med Masonry vil genstande stables i det spor (eller kolonne i dette tilfælde) der har mere plads til rådighed. Men også, og måske endnu vigtigere, kræver denne løsning, at du indstiller en fast højde på Flexbox-beholderen; ellers ville der ikke forekomme nogen indpakning.
Tredjeparts murværksbiblioteker For mere avancerede tilfælde har udviklere brugt biblioteker. Det mest kendte og populære bibliotek til dette hedder blot Masonry, og det bliver downloadet omkring 200.000 gange om ugen ifølge NPM. Squarespace giver også en layoutkomponent, der gengiver et Masonry-layout, for et kodefrit alternativ, og mange websteder bruger det. Begge disse muligheder bruger JavaScript-kode til at placere elementer i layoutet. Indbygget murværk Jeg er virkelig begejstret for, at Masonry nu begynder at dukke op i browsere som en indbygget CSS-funktion. Med tiden vil du være i stand til at bruge Masonry ligesom du gør Grid eller Flexbox, det vil sige, uden at du behøver nogen løsninger eller tredjepartskode. Mit team hos Microsoft har implementeret indbygget Masonry-understøttelse i Chromium open source-projektet, som Edge, Chrome og mange andre browsere er baseret på. Mozilla var faktisk den første browserleverandør, der foreslog en eksperimentel implementering af Masonry tilbage i 2020. Og Apple har også været meget interesseret i at gøre dette nye weblayout primitive. Arbejdet med at standardisere funktionen skrider også fremad, med enighed i CSS-arbejdsgruppen om den generelle retning og endda en ny displaytype: gitterbaner. Hvis du vil lære mere om murværk og spore fremskridt, så tjek min CSS-murværksressourceside. Med tiden, når Masonry bliver en Baseline-funktion, ligesom Grid eller Flexbox, vil vi blot kunne bruge det og drage fordel af:
Bedre ydeevne, Bedre lydhørhed, Brugervenlighed og enklere kode.
Lad os se nærmere på disse. Bedre ydeevne At lave dit eget murværkslignende layoutsystem eller bruge et tredjepartsbibliotek i stedet betyder, at du bliver nødt til at køre JavaScript-kode for at placere elementer på skærmen. Dette betyder også, at denne kode bliver blokerende. Ja, enten vises intet, eller også vil tingene ikke være de rigtige steder eller af de rigtige størrelser, før den JavaScript-kode er kørt. Masonry-layout bruges ofte til hoveddelen af en webside, hvilket betyder, at koden ville få dit hovedindhold til at blive vist senere, end det ellers kunne have, hvilket forringer din LCP eller Largest Contentful Paint-metrik, som spiller en stor rolle i opfattet ydeevne og søgemaskineoptimering. Jeg testede Masonry JS-biblioteket med et simpelt layout og ved at simulere en langsom 4G-forbindelse i DevTools. Biblioteket er ikke særlig stort (24KB, 7,8KB gzipped), men det tog 600ms at indlæse under mine testforhold. Her er en præstationsoptagelse, der viser den lange 600 ms indlæsningstid for Masonry-biblioteket, og at ingen anden gengivelsesaktivitet skete, mens det skete:
Derudover skulle det downloadede script efter den indledende indlæsningstid parses, kompileres og derefter køres. Alt dette, som før nævnt, blokerede gengivelsen af siden. Med en indbygget Masonry-implementering i browseren har vi ikke et script til at indlæse og køre. Browsermotoren vil bare gøre sit i det første sidegengivelsestrin. Bedre lydhørhed På samme måde som når en side indlæses første gang, fører en ændring af størrelsen på browservinduet til, at layoutet på den side gengives igen. Men på dette tidspunkt, hvis siden bruger Masonry JS-biblioteket, er der ingen grund til at indlæse scriptet igen, fordi det allerede erher. Koden, der flytter varer de rigtige steder, skal dog køre. Nu ser dette særlige bibliotek ud til at være ret hurtig til at gøre dette, når siden indlæses. Det animerer dog elementerne, når de skal flytte til et andet sted ved vinduesstørrelse, og det gør en stor forskel. Selvfølgelig bruger brugere ikke tid på at ændre størrelsen på deres browservinduer så meget, som vi udviklere gør. Men denne animerede oplevelse med ændring af størrelse kan være temmelig rystende og tilføjer den opfattede tid, det tager for siden at tilpasse sig sin nye størrelse. Brugervenlighed og enklere kode Hvor nemt det er at bruge en webfunktion, og hvor simpel koden ser ud, er vigtige faktorer, der kan gøre en stor forskel for dit team. De kan selvfølgelig aldrig være lige så vigtige som den endelige brugeroplevelse, men udvikleroplevelsen påvirker vedligeholdelsen. Brug af en indbygget webfunktion kommer med vigtige fordele på den front:
Udviklere, der allerede kender HTML, CSS og JS, vil højst sandsynligt være i stand til nemt at bruge denne funktion, fordi den er designet til at integrere godt og være i overensstemmelse med resten af webplatformen. Der er ingen risiko for, at der indføres brydende ændringer i, hvordan funktionen bruges. Der er næsten ingen risiko for, at den funktion bliver forældet eller ikke vedligeholdt.
I tilfælde af indbygget murværk, fordi det er et primitivt layout, bruger du det fra CSS, ligesom Grid eller Flexbox, ingen JS involveret. Også andre layout-relaterede CSS-egenskaber, såsom gap, fungerer, som du forventer, at de skal. Der er ingen tricks eller løsninger at vide om, og de ting, du lærer, er dokumenteret på MDN. For Masonry JS lib er initialisering en smule kompleks: den kræver en dataattribut med en specifik syntaks sammen med skjulte HTML-elementer for at indstille kolonne- og mellemrumsstørrelserne. Plus, hvis du vil spænde over kolonner, skal du selv inkludere mellemrummets størrelse for at undgå problemer:
Lad os sammenligne dette med, hvordan en indbygget Masonry-implementering ville se ud:
Enklere, mere kompakt kode, der bare kan bruge ting som mellemrum, og hvor spændingsspor udføres med span 2, ligesom i gitter, og kræver ikke, at du beregner den rigtige bredde, der inkluderer mellemrummets størrelse. Hvordan ved man, hvad der er tilgængeligt, og hvornår det er tilgængeligt? Overordnet set er spørgsmålet egentlig ikke, om du skal bruge indbygget Masonry over et JS-bibliotek, men snarere hvornår. Masonry JS-biblioteket er fantastisk og har udfyldt et hul i webplatformen i mange år, og for mange glade udviklere og brugere. Det har selvfølgelig et par ulemper, hvis du sammenligner det med en indbygget Masonry-implementering, men de er ikke vigtige, hvis implementeringen ikke er klar. Det er nemt for mig at nævne disse fede nye webplatformsfunktioner, fordi jeg arbejder hos en browserleverandør, og jeg har derfor en tendens til at vide, hvad der kommer. Men udviklere deler ofte, undersøgelse efter undersøgelse, at det er svært at holde styr på nye ting. Det er svært at holde sig orienteret, og virksomheder prioriterer alligevel ikke altid læring. For at hjælpe med dette er her et par ressourcer, der giver opdateringer på enkle og kompakte måder, så du hurtigt kan få de oplysninger, du har brug for:
Webplatformen byder på Explorer-webstedet: Du kan være interesseret i siden med udgivelsesbemærkninger. Og hvis du kan lide RSS, så tjek feedet med udgivelsesnoter, såvel som Baseline Newly Available og Widely Available feeds.
NettetPlatformstatus dashboard: Du kan måske lide dens forskellige basisårsider.
Chrome Platform Status' roadmap-side.
Hvis du har lidt mere tid, er du måske også interesseret i browserleverandørers udgivelsesnoter:
Chrome Edge Firefox Safari
For endnu flere ressourcer, tjek mit Navigering på webplatformens snydeark. Min ting er stadig ikke implementeret Det er den anden side af problemet. Selvom du finder tid, energi og måder at holde styr på, er der stadig frustration over at få din stemme hørt og dine yndlingsfunktioner implementeret. Måske har du ventet i årevis på, at en specifik fejl blev løst, eller at en bestemt funktion skulle sendes i en browser, hvor den stadig mangler. Hvad jeg vil sige er, at browserleverandører lytter. Jeg er en del af flere tværorganisatoriske teams, hvor vi diskuterer udviklersignaler og feedback hele tiden. Vi ser på mange forskellige kilder til feedback, både internt hos hver browserleverandør og eksternt/offentligt på fora, open source-projekter, blogs og undersøgelser. Og vi forsøger altid at skabe bedre måder, hvorpå udviklere kan dele deres specifikke behov og bruge cases. Så hvis du kan, kræve mere fra browserleverandører og pres os til at implementere de funktioner, du har brug for. Jeg forstår, at det tager tid, og også kan være skræmmende (for ikke at nævne en høj adgangsbarriere), men det virker også. Her er et par måder, hvorpå du kan få din (eller din virksomheds) stemme hørt: Tag de årlige undersøgelser State of JS, State of CSS og State of HTML. De spiller en stor rolle i, hvordan browserleverandører prioriterer deres arbejde. Hvis du har brug for en specifik standardbaseret API, der skal implementeres konsekvent på tværs af browsere, kan du overveje at indsende et forslag ved den næste Interop-projektiteration. Det kræver mere tid, men overvej hvordan Shopify og RUMvision delte deres ønskelister til Interop 2026. Detaljerede oplysninger som denne kan være meget nyttige for browserleverandører at prioritere. For flere nyttige links til at påvirke browserleverandører, tjek mit Snydeark til at navigere på webplatformen. Konklusion Afslutningsvis håber jeg, at denne artikel har efterladt dig et par ting at tænke over:
Spænding for Murværk og andre kommende webfunktioner. Et par webfunktioner, du måske vil begynde at bruge. Et par stykker tilpasset kode eller tredjepartskode kan du muligvis fjerne til fordel for indbyggede funktioner. Et par måder at holde styr på, hvad der kommer og påvirke browserleverandører.
Endnu vigtigere, jeg håber, at jeg har overbevist dig om fordelene ved at bruge webplatformen til dets fulde potentiale.
