For omtrent 15 år siden jobbet jeg i et selskap der vi bygde apper for reisebyråer, flyplassarbeidere og flyselskaper. Vi bygde også vårt eget interne rammeverk for UI-komponenter og enkeltside-appfunksjoner. Vi hadde komponenter for alt: felt, knapper, faner, områder, datatabeller, menyer, datovelgere, utvalg og multivalg. Vi hadde til og med en div-komponent. Div-komponenten vår var flott forresten, den tillot oss å gjøre avrundede hjørner på alle nettlesere, noe som, tro det eller ei, ikke var en enkel ting å gjøre på den tiden.
Arbeidet vårt fant sted på et tidspunkt i vår historie da JS, Ajax og dynamisk HTML ble sett på som en revolusjon som brakte oss inn i fremtiden. Plutselig kunne vi oppdatere en side dynamisk, hente data fra en server og slippe å navigere til andre sider, som ble sett på som treg og blinket med et stort hvitt rektangel på skjermen mellom de to sidene. Det var en setning, gjort populær av Jeff Atwood (grunnleggeren av StackOverflow), som lød: "Enhver applikasjon som kan skrives i JavaScript vil til slutt bli skrevet i JavaScript." - Jeff Atwood
For oss på den tiden føltes dette som en tørre å faktisk gå og lage disse appene. Det føltes som en generell godkjenning å gjøre alt med JS. Så vi gjorde alt med JS, og vi tok oss egentlig ikke tid til å undersøke andre måter å gjøre ting på. Vi følte egentlig ikke insentiv til å lære hva HTML og CSS kunne gjøre. Vi oppfattet egentlig ikke nettet som en appplattform i utvikling i sin helhet. Vi så det stort sett som noe vi trengte å omgå, spesielt når det kom til nettleserstøtte. Vi kunne bare kastet mer JS på det for å få ting gjort. Ville det hjulpet meg å ta meg tid til å lære mer om hvordan nettet fungerte og hva som var tilgjengelig på plattformen? Jada, jeg kunne sannsynligvis ha barbert en haug med kode som egentlig ikke var nødvendig. Men på den tiden, kanskje ikke så mye. Du skjønner, nettleserforskjellene var ganske betydelige den gang. Dette var en tid da Internet Explorer fortsatt var den dominerende nettleseren, med Firefox som den nærmeste andre, men begynte å tape markedsandeler på grunn av at Chrome raskt ble populær. Selv om Chrome og Firefox var ganske gode til å bli enige om nettstandarder, gjorde miljøene appene våre kjørte i at vi måtte støtte IE6 i lang tid. Selv da vi fikk støtte IE8, måtte vi fortsatt forholde oss til mange forskjeller mellom nettlesere. Ikke bare det, men datidens nett hadde bare ikke så mange funksjoner innebygd rett inn i plattformen.
Spol frem til i dag. Ting har endret seg enormt. Ikke bare har vi flere av disse egenskapene enn noen gang før, men hastigheten de blir tilgjengelige med har også økt. La meg stille spørsmålet igjen, da: Ville det å ta deg tid til å lære mer om hvordan nettet fungerer og hva som er tilgjengelig på plattformen hjelpe deg i dag? Absolutt ja. Å lære å forstå og bruke nettplattformen i dag gir deg en stor fordel i forhold til andre utviklere. Enten du jobber med ytelse, tilgjengelighet, respons, alt sammen, eller bare sender brukergrensesnittfunksjoner, hvis du ønsker å gjøre det som en ansvarlig ingeniør, hjelper det å kjenne verktøyene som er tilgjengelige for deg å nå dine mål raskere og bedre. Noen ting du kanskje ikke trenger et bibliotek for lenger Når vi vet hva nettlesere støtter i dag, er spørsmålet: Hva kan vi droppe? Trenger vi en div-komponent for å gjøre avrundede hjørner i 2025? Selvfølgelig gjør vi ikke det. Border-radius-egenskapen har blitt støttet av alle nettlesere som brukes nå i mer enn 15 år. Og hjørneform kommer også snart, for enda mer avanserte hjørner. La oss ta en titt på relativt nyere funksjoner som nå er tilgjengelige i alle større nettlesere, og som du kan bruke til å erstatte eksisterende avhengigheter i kodebasen din. Poenget er ikke å umiddelbart droppe alle dine elskede biblioteker og omskrive kodebasen din. Når det gjelder alt annet, må du først ta hensyn til nettleserstøtte og bestemme deg basert på andre faktorer som er spesifikke for prosjektet ditt. Følgende funksjoner er implementert i de tre hovednettlesermotorene (Chromium, WebKit og Gecko), men du kan ha forskjellige nettleserstøttekrav som hindrer deg i å bruke dem med en gang. Nå er det fortsatt et godt tidspunkt å lære om disse funksjonene, og kanskje planlegge å bruke dem på et tidspunkt. Popovers og dialoger Popover API,
Jada, Internett-tilkoblingshastigheten din har sannsynligvis økt også, men det er ikke tilfelle for alle. Og ikke alle har de samme enhetsmulighetene heller. Å trekke inn tredjepartskode for ting du kan gjøre med plattformen, betyr i stedet mest sannsynlig at du sender mer kode, og derfor når færre kunder enn du vanligvis ville gjort. På nettet fører dårlig lasteytelse til høye avbruddsrater og skader merkevarens omdømme. Kjøre mindre kode på enheter Dessuten kjører koden du sender på kundenes enheter sannsynligvis raskere hvis den bruker færre JavaScript-abstraksjoner på toppen av plattformen. Det er sannsynligvis også mer responsivt og mer tilgjengelig som standard. Alt dette fører til flere og mer fornøyde kunder. Sjekk min kollega Alex Russells årlige blogg om ytelsesulikhet, som viser at premiumenheter stort sett er fraværende på markeder med milliarder av brukere på grunn av ulikhet i formuen. Og dette gapet vokser bare over tid.
Innebygd muroppsett En nettplattformfunksjon som kommer snart, og som jeg er veldig spent på, er CSS Masonry.
La meg starte med å forklare hva murverk er. Hva er murverk Murverk er en type layout som ble gjort populær av Pinterest for mange år siden. Det skaper uavhengige spor med innhold der gjenstandene pakker seg sammen så nært starten av sporet de kan.
Mange ser på murverk som et flott alternativ for porteføljer og fotogallerier, noe det absolutt kan gjøre. Men Masonry er mer fleksibelt enn det du ser på Pinterest, og det er ikke begrenset til bare fosselignende layouter. I en Masonry layout:
Spor kan være kolonner eller rader:
Spor med innhold trenger ikke alle være like store:
Elementer kan spenne over flere spor:
Gjenstander kan plasseres på bestemte spor; de trenger ikke alltid å følge den automatiske plasseringsalgoritmen:
Demoer Her er noen enkle demoer jeg laget ved å bruke den kommende implementeringen av CSS Masonry i Chromium. En bildegalleridemo som viser hvordan elementer (tittelen i dette tilfellet) kan spenne over flere spor:
Et annet bildegalleri som viser spor i forskjellige størrelser:
Et nyhetssideoppsett med noen spor bredere enn andre, og noen elementer som spenner over hele oppsettets bredde:
En kanban-tavle som viser at gjenstander kan plasseres på bestemte spor:
Merk: Dentidligere demoer ble laget med en versjon av Chromium som ennå ikke er tilgjengelig for de fleste nettbrukere, fordi CSS Masonry bare så vidt begynner å bli implementert i nettlesere. Imidlertid har nettutviklere med glede brukt biblioteker for å lage Masonry-oppsett i mange år allerede. Nettsteder som bruker murverk i dag Faktisk er murverk ganske vanlig på nettet i dag. Her er noen eksempler jeg fant i tillegg til Pinterest:
Og noen flere, mindre åpenbare, eksempler:
Så hvordan ble disse oppsettene laget? Løsninger Et triks jeg har sett brukt er å bruke en Flexbox-layout i stedet, endre retningen til kolonne og sette den til å bryte. På denne måten kan du plassere gjenstander med forskjellig høyde i flere uavhengige kolonner, noe som gir inntrykk av en Masonry-layout:
Det er imidlertid to begrensninger med denne løsningen:
Rekkefølgen på gjenstandene er forskjellig fra hva den ville vært med en ekte Masonry layout. Med Flexbox fyller elementer den første kolonnen først, og når den er full, går du til neste kolonne. Med Masonry vil gjenstander stables i hvilket spor (eller kolonne i dette tilfellet) har mer plass tilgjengelig. Men også, og kanskje enda viktigere, krever denne løsningen at du setter en fast høyde på Flexbox-beholderen; ellers ville ingen innpakning forekomme.
Tredjeparts murbiblioteker For mer avanserte tilfeller har utviklere brukt biblioteker. Det mest kjente og populære biblioteket for dette heter ganske enkelt Masonry, og det blir lastet ned omtrent 200 000 ganger per uke ifølge NPM. Squarespace tilbyr også en layoutkomponent som gjengir en Masonry-layout, for et kodefritt alternativ, og mange nettsteder bruker det. Begge disse alternativene bruker JavaScript-kode for å plassere elementer i oppsettet. Innebygd murverk Jeg er veldig spent på at Masonry nå begynner å vises i nettlesere som en innebygd CSS-funksjon. Over tid vil du kunne bruke Masonry akkurat som du gjør Grid eller Flexbox, det vil si uten å trenge noen løsning eller tredjepartskode. Teamet mitt hos Microsoft har implementert innebygd Masonry-støtte i Chromium åpen kildekode-prosjektet, som Edge, Chrome og mange andre nettlesere er basert på. Mozilla var faktisk den første nettleserleverandøren som foreslo en eksperimentell implementering av Masonry tilbake i 2020. Og Apple har også vært veldig interessert i å gjøre dette nye nettoppsettet primitive. Arbeidet med å standardisere funksjonen går også fremover, med enighet i CSS-arbeidsgruppen om den generelle retningen og til og med en ny skjermtype: grid-baner. Hvis du vil lære mer om Masonry og spore fremgang, sjekk ut min CSS Masonry-ressursside. Med tiden, når Masonry blir en Baseline-funksjon, akkurat som Grid eller Flexbox, vil vi bare kunne bruke det og dra nytte av:
Bedre ytelse, Bedre respons, Brukervennlighet og enklere kode.
La oss se nærmere på disse. Bedre ytelse Å lage ditt eget Masonry-lignende layoutsystem, eller bruke et tredjepartsbibliotek i stedet, betyr at du må kjøre JavaScript-kode for å plassere elementer på skjermen. Dette betyr også at denne koden vil blokkere. Faktisk vil enten ingenting vises, eller ting vil ikke være på de riktige stedene eller i riktig størrelse før den JavaScript-koden har kjørt. Masonry-layout brukes ofte for hoveddelen av en nettside, noe som betyr at koden vil få hovedinnholdet ditt til å vises senere enn det ellers kunne ha gjort, og forringe LCP-en din, eller Largest Contentful Paint-metrikken, som spiller en stor rolle i oppfattet ytelse og søkemotoroptimalisering. Jeg testet Masonry JS-biblioteket med en enkel layout og ved å simulere en treg 4G-tilkobling i DevTools. Biblioteket er ikke veldig stort (24KB, 7,8KB gzipped), men det tok 600ms å laste under mine testforhold. Her er et ytelsesopptak som viser den lange lastetiden på 600 ms for Masonry-biblioteket, og at ingen annen gjengivelsesaktivitet skjedde mens det skjedde:
I tillegg, etter den første lastetiden, måtte det nedlastede skriptet analyseres, kompileres og deretter kjøres. Alt dette, som nevnt før, blokkerte gjengivelsen av siden. Med en innebygd Masonry-implementering i nettleseren har vi ikke noe skript å laste og kjøre. Nettlesermotoren vil bare gjøre sitt under det første sidegjengivelsestrinnet. Bedre respons På samme måte som når en side først lastes inn, fører endring av størrelsen på nettleservinduet til å gjengi oppsettet på den siden igjen. På dette tidspunktet, men hvis siden bruker Masonry JS-biblioteket, er det ikke nødvendig å laste skriptet på nytt, fordi det allerede erher. Imidlertid må koden som flytter elementer på de riktige stedene kjøre. Nå ser det ut til at akkurat dette biblioteket er ganske raskt til å gjøre dette når siden lastes. Den animerer imidlertid elementene når de trenger å flytte til et annet sted ved å endre størrelse på vinduet, og dette utgjør en stor forskjell. Selvfølgelig bruker ikke brukere tid på å endre størrelsen på nettleservinduene så mye som vi utviklere gjør. Men denne animerte opplevelsen av å endre størrelse kan være ganske skurrende og øker den oppfattede tiden det tar for siden å tilpasse seg den nye størrelsen. Brukervennlighet og enklere kode Hvor enkelt det er å bruke en nettfunksjon og hvor enkel koden ser ut er viktige faktorer som kan utgjøre en stor forskjell for teamet ditt. De kan selvfølgelig aldri være like viktige som den endelige brukeropplevelsen, men utvikleropplevelsen påvirker vedlikeholdet. Å bruke en innebygd nettfunksjon kommer med viktige fordeler på den fronten:
Utviklere som allerede kjenner til HTML, CSS og JS vil mest sannsynlig kunne bruke den funksjonen enkelt fordi den er designet for å integrere godt og være konsistent med resten av nettplattformen. Det er ingen risiko for at brytende endringer blir introdusert i hvordan funksjonen brukes. Det er nesten null risiko for at funksjonen blir avviklet eller ikke vedlikeholdt.
Når det gjelder innebygd murverk, fordi det er et primitivt layout, bruker du det fra CSS, akkurat som Grid eller Flexbox, ingen JS involvert. Også andre layoutrelaterte CSS-egenskaper, for eksempel gap, fungerer som du forventer at de skal. Det er ingen triks eller løsninger å vite om, og tingene du lærer er dokumentert på MDN. For Masonry JS lib er initialisering litt kompleks: den krever et dataattributt med en spesifikk syntaks, sammen med skjulte HTML-elementer for å angi kolonne- og gapstørrelser. I tillegg, hvis du vil spenne over kolonner, må du inkludere gapstørrelsen selv for å unngå problemer:
La oss sammenligne dette med hvordan en innebygd Masonry-implementering vil se ut:
Enklere, mer kompakt kode som bare kan bruke ting som gap og hvor spennspor gjøres med span 2, akkurat som i rutenett, og krever ikke at du beregner riktig bredde som inkluderer gapstørrelsen. Hvordan vite hva som er tilgjengelig og når det er tilgjengelig? Totalt sett er spørsmålet egentlig ikke om du skal bruke innebygd murverk over et JS-bibliotek, men heller når. Masonry JS-biblioteket er fantastisk og har fylt et tomrom i nettplattformen i mange år, og for mange fornøyde utviklere og brukere. Den har noen ulemper hvis du sammenligner den med en innebygd Masonry-implementering, men de er ikke viktige hvis implementeringen ikke er klar. Det er lett for meg å liste opp disse kule nye nettplattformfunksjonene fordi jeg jobber hos en nettleserleverandør, og jeg har derfor en tendens til å vite hva som kommer. Men utviklere deler ofte, undersøkelse etter undersøkelse, at det er vanskelig å holde styr på nye ting. Det er vanskelig å holde seg informert, og bedrifter prioriterer ikke alltid læring uansett. For å hjelpe med dette, her er noen ressurser som gir oppdateringer på enkle og kompakte måter, slik at du raskt kan få informasjonen du trenger:
Nettplattformen har utforskerside: Du kan være interessert i siden med utgivelsesnotater. Og, hvis du liker RSS, sjekk ut feeden for utgivelsesnotater, så vel som Baseline Newly Available og Widely Available feeds.
InternettPlattformstatus dashbord: Du vil kanskje like de forskjellige sidene for basisår.
Chrome Platform Status’ veikartside.
Hvis du har litt mer tid, kan du også være interessert i nettleserleverandørenes utgivelsesnotater:
Chrome Edge Firefox Safari
For enda flere ressurser, sjekk ut min Navigering på nettplattformens jukseark. Min ting er fortsatt ikke implementert Det er den andre siden av problemet. Selv om du finner tid, energi og måter å holde oversikt på, er det fortsatt frustrasjon med å få stemmen din hørt og favorittfunksjonene dine implementert. Kanskje du har ventet i årevis på at en spesifikk feil skal løses, eller at en spesifikk funksjon skal sendes i en nettleser der den fortsatt mangler. Det jeg vil si er at nettleserleverandører lytter. Jeg er en del av flere team på tvers av organisasjoner hvor vi diskuterer utviklersignaler og tilbakemeldinger hele tiden. Vi ser på mange forskjellige kilder til tilbakemelding, både interne hos hver nettleserleverandør og eksterne/offentlige på fora, åpen kildekode-prosjekter, blogger og undersøkelser. Og vi prøver alltid å skape bedre måter for utviklere å dele deres spesifikke behov og brukssaker. Så hvis du kan, vennligst krev mer fra nettleserleverandører og press oss til å implementere funksjonene du trenger. Jeg skjønner at det tar tid, og også kan være skremmende (for ikke å snakke om høy inngangsbarriere), men det fungerer også. Her er noen måter du kan få din (eller bedriftens) stemme til å bli hørt: Ta de årlige undersøkelsene State of JS, State of CSS og State of HTML. De spiller en stor rolle i hvordan nettleserleverandører prioriterer arbeidet sitt. Hvis du trenger et spesifikt standardbasert API som skal implementeres konsekvent på tvers av nettlesere, bør du vurdere å sende inn et forslag ved neste interoperasjonsprosjekt. Det krever mer tid, men tenk på hvordan Shopify og RUMvision delte ønskelistene sine for Interop 2026. Detaljert informasjon som dette kan være svært nyttig for nettleserleverandører å prioritere. For flere nyttige lenker for å påvirke nettleserleverandører, sjekk ut min Navigering på nettplattformens jukseark. Konklusjon For å avslutte håper jeg at denne artikkelen har gitt deg noen ting å tenke på:
Spenning for Murverk og andre kommende nettfunksjoner. Noen nettfunksjoner du kanskje vil begynne å bruke. Noen få stykker tilpasset kode eller tredjepartskode du kanskje kan fjerne til fordel for innebygde funksjoner. Noen måter å holde styr på hva som kommer og påvirke nettleserleverandører.
Enda viktigere, jeg håper jeg har overbevist deg om fordelene ved å bruke nettplattformen til sitt fulle potensial.
