För ungefär 15 år sedan arbetade jag på ett företag där vi byggde appar för resebyråer, flygplatsarbetare och flygbolag. Vi byggde också vårt eget interna ramverk för UI-komponenter och ensidiga appfunktioner. Vi hade komponenter för allt: fält, knappar, flikar, intervall, datatabeller, menyer, datumväljare, markeringar och multival. Vi hade till och med en div-komponent. Vår div-komponent var bra förresten, den tillät oss att göra rundade hörn på alla webbläsare, vilket, tro det eller ej, inte var en lätt sak att göra på den tiden.
Vårt arbete ägde rum vid en tidpunkt i vår historia då JS, Ajax och dynamisk HTML sågs som en revolution som förde oss in i framtiden. Plötsligt kunde vi uppdatera en sida dynamiskt, hämta data från en server och undvika att behöva navigera till andra sidor, vilket sågs som långsamt och blinkade med en stor vit rektangel på skärmen mellan de två sidorna. Det fanns en fras, som blev populär av Jeff Atwood (grundaren av StackOverflow), som löd: "Alla program som kan skrivas i JavaScript kommer så småningom att skrivas i JavaScript." - Jeff Atwood
För oss då kändes det som att våga gå och skapa de där apparna. Det kändes som ett heltäckande godkännande att göra allt med JS. Så vi gjorde allt med JS, och vi tog oss inte riktigt tid att undersöka andra sätt att göra saker på. Vi kände inte riktigt incitamentet att lära oss vad HTML och CSS kunde göra. Vi uppfattade inte riktigt webben som en appplattform i utveckling i sin helhet. Vi såg det mest som något vi behövde komma runt, särskilt när det kom till webbläsarstöd. Vi kunde bara kasta mer JS på det för att få saker gjorda. Skulle ta mig tid att lära mig mer om hur webben fungerade och vad som fanns tillgängligt på plattformen ha hjälpt mig? Visst, jag kunde förmodligen ha rakat en massa kod som inte verkligen behövdes. Men just då, kanske inte så mycket. Du förstår, webbläsarskillnaderna var ganska betydande då. Detta var en tid då Internet Explorer fortfarande var den dominerande webbläsaren, med Firefox som den närmaste andra, men började tappa marknadsandelar på grund av att Chrome snabbt blev populärt. Även om Chrome och Firefox var ganska bra på att komma överens om webbstandarder, innebar miljöerna där våra appar kördes att vi var tvungna att stödja IE6 under lång tid. Även när vi fick stödja IE8 var vi fortfarande tvungna att hantera en hel del skillnader mellan webbläsare. Inte bara det, utan dåtidens webb hade helt enkelt inte så många funktioner inbyggda direkt i plattformen.
Snabbspola fram till idag. Saker och ting har förändrats enormt. Vi har inte bara fler av dessa möjligheter än någonsin tidigare, utan takten med vilken de blir tillgängliga har också ökat. Låt mig ställa frågan igen, då: Skulle ta dig tid att lära dig mer om hur webben fungerar och vad som finns tillgängligt på plattformen hjälpa dig idag? Absolut ja. Att lära sig att förstå och använda webbplattformen idag ger dig en enorm fördel gentemot andra utvecklare. Oavsett om du arbetar med prestanda, tillgänglighet, lyhördhet, allt tillsammans, eller bara skickar UI-funktioner, om du vill göra det som en ansvarsfull ingenjör, kan du genom att känna till verktygen som är tillgängliga för dig nå dina mål snabbare och bättre. Vissa saker du kanske inte behöver ett bibliotek för längre När vi vet vad webbläsare stöder idag är frågan: Vad kan vi avstå från? Behöver vi en div-komponent för att göra rundade hörn 2025? Självklart gör vi inte det. Egenskapen border-radius har stöds av alla för närvarande använda webbläsare i mer än 15 år vid denna tidpunkt. Och hörnform kommer också snart, för ännu snyggare hörn. Låt oss ta en titt på relativt nya funktioner som nu är tillgängliga i alla större webbläsare, och som du kan använda för att ersätta befintliga beroenden i din kodbas. Poängen är inte att omedelbart ta bort alla dina älskade bibliotek och skriva om din kodbas. När det gäller allt annat måste du först ta hänsyn till webbläsarstöd och bestämma dig utifrån andra faktorer som är specifika för ditt projekt. Följande funktioner är implementerade i de tre huvudsakliga webbläsarmotorerna (Chromium, WebKit och Gecko), men du kan ha olika webbläsarsupportkrav som hindrar dig från att använda dem direkt. Nu är det dock ett bra tillfälle att lära sig om dessa funktioner och kanske planera att använda dem någon gång. Popovers och dialoger Popover API, HTML-elementet
Visst, din internetanslutningshastighet har förmodligen ökat också, men det är inte fallet för alla. Och alla har inte heller samma enhetskapacitet. Om du drar in tredjepartskod för saker du kan göra med plattformen innebär det troligen att du skickar mer kod och därför når färre kunder än du normalt skulle göra. På webben leder dålig laddningsprestanda till höga avhoppsfrekvenser och skadar varumärkets rykte. Kör mindre kod på enheter Dessutom går koden du skickar till dina kunders enheter sannolikt snabbare om den använder färre JavaScript-abstraktioner ovanpå plattformen. Det är förmodligen också mer responsivt och mer tillgängligt som standard. Allt detta leder till fler och nöjdare kunder. Kolla min kollega Alex Russells årliga prestationsojämlikhetsblogg, som visar att premiumenheter till stor del saknas på marknader med miljarder användare på grund av ojämlikhet i välstånd. Och denna klyfta bara växer med tiden.
Inbyggd murverkslayout En webbplattformsfunktion som kommer snart och som jag är väldigt exalterad över är CSS Masonry.
Låt mig börja med att förklara vad murverk är. Vad är murverk Murverk är en typ av layout som gjordes populär av Pinterest för flera år sedan. Det skapar oberoende spår av innehåll inom vilka föremål packar sig så nära banans början de kan.
Många människor ser murverk som ett bra alternativ för portföljer och fotogallerier, vilket det verkligen kan göra. Men Masonry är mer flexibelt än vad du ser på Pinterest, och det är inte begränsat till bara vattenfallsliknande layouter. I en murad layout:
Spår kan vara kolumner eller rader:
Spår med innehåll behöver inte alla ha samma storlek:
Objekt kan sträcka sig över flera spår:
Föremål kan placeras på specifika spår; de behöver inte alltid följa den automatiska placeringsalgoritmen:
Demos Här är några enkla demos som jag gjorde genom att använda den kommande implementeringen av CSS Masonry i Chromium. En fotogalleridemo som visar hur objekt (titeln i det här fallet) kan sträcka sig över flera spår:
Ett annat fotogalleri som visar spår av olika storlekar:
En nyhetssajtlayout med vissa spår bredare än andra, och vissa objekt som spänner över hela layoutens bredd:
En kanban-tavla som visar att föremål kan placeras på specifika spår:
Obs: DenTidigare demos gjordes med en version av Chromium som ännu inte är tillgänglig för de flesta webbanvändare, eftersom CSS Masonry bara har börjat implementeras i webbläsare. Men webbutvecklare har med glädje använt bibliotek för att skapa Masonry-layouter redan i flera år. Webbplatser som använder murverk idag Faktum är att murverk är ganska vanligt på webben idag. Här är några exempel jag hittade förutom Pinterest:
Och några fler, mindre uppenbara, exempel:
Så, hur skapades dessa layouter? Lösningar Ett knep som jag har sett använt är att använda en Flexbox-layout istället, ändra dess riktning till kolumn och ställa in den till wrap. På så sätt kan du placera föremål av olika höjd i flera, oberoende kolumner, vilket ger intrycket av en Masonry-layout:
Det finns dock två begränsningar med denna lösning:
Ordningen på föremålen skiljer sig från vad den skulle vara med en äkta Masonry-layout. Med Flexbox fyller artiklar den första kolumnen först och, när den är full, gå sedan till nästa kolumn. Med Masonry skulle föremål staplas i vilket spår (eller kolumn i det här fallet) som har mer utrymme tillgängligt. Men också, och kanske ännu viktigare, den här lösningen kräver att du ställer in en fast höjd på Flexbox-behållaren; annars skulle ingen omslag inträffa.
Tredjeparts murverksbibliotek För mer avancerade fall har utvecklare använt bibliotek. Det mest kända och populära biblioteket för detta heter helt enkelt Masonry, och det laddas ner cirka 200 000 gånger per vecka enligt NPM. Squarespace tillhandahåller också en layoutkomponent som återger en Masonry-layout, för ett kodfritt alternativ, och många webbplatser använder det. Båda dessa alternativ använder JavaScript-kod för att placera objekt i layouten. Inbyggt murverk Jag är verkligen glad över att Masonry nu börjar dyka upp i webbläsare som en inbyggd CSS-funktion. Med tiden kommer du att kunna använda Masonry precis som du gör Grid eller Flexbox, det vill säga utan att behöva några lösningar eller tredjepartskod. Mitt team på Microsoft har implementerat inbyggt Masonry-stöd i Chromium open source-projektet, som Edge, Chrome och många andra webbläsare är baserade på. Mozilla var faktiskt den första webbläsarleverantören som föreslog en experimentell implementering av Masonry redan 2020. Och Apple har också varit mycket intresserade av att göra denna nya webblayout primitiv. Arbetet med att standardisera funktionen går också framåt, med enighet inom CSS-arbetsgruppen om den allmänna inriktningen och till och med en ny displaytyp: rutnät. Om du vill lära dig mer om Masonry och spåra framsteg, kolla in min CSS Masonry-resurssida. Med tiden, när Masonry blir en Baseline-funktion, precis som Grid eller Flexbox, kommer vi helt enkelt att kunna använda det och dra nytta av:
Bättre prestanda, Bättre lyhördhet, Enkel att använda och enklare kod.
Låt oss ta en närmare titt på dessa. Bättre prestanda Att göra ditt eget Masonry-liknande layoutsystem, eller använda ett tredjepartsbibliotek istället, innebär att du måste köra JavaScript-kod för att placera objekt på skärmen. Detta betyder också att den här koden kommer att rendera blockerande. Ja, antingen kommer ingenting att visas, eller så kommer saker inte att vara på rätt ställen eller i rätt storlek förrän den JavaScript-koden har körts. Masonry-layout används ofta för huvuddelen av en webbsida, vilket innebär att koden skulle få ditt huvudinnehåll att visas senare än det annars skulle kunna ha, vilket försämrar din LCP, eller Largest Contentful Paint-måttet, vilket spelar en stor roll i upplevd prestanda och sökmotoroptimering. Jag testade Masonry JS-biblioteket med en enkel layout och genom att simulera en långsam 4G-anslutning i DevTools. Biblioteket är inte särskilt stort (24KB, 7,8KB gzippad), men det tog 600ms att ladda under mina testförhållanden. Här är en prestandainspelning som visar den långa 600 ms laddningstiden för Masonry-biblioteket och att ingen annan renderingsaktivitet hände medan det hände:
Dessutom, efter den första laddningstiden, behövde det nedladdade skriptet analyseras, kompileras och sedan köras. Allt detta, som nämnts tidigare, blockerade renderingen av sidan. Med en inbyggd Masonry-implementering i webbläsaren kommer vi inte att ha något skript att ladda och köra. Webbläsarmotorn kommer bara att göra sitt under det första sidrenderingssteget. Bättre lyhördhet På samma sätt som när en sida laddas först, leder storleksändring av webbläsarfönstret till att layouten på den sidan renderas igen. Men vid denna tidpunkt, om sidan använder Masonry JS-biblioteket, finns det inget behov av att ladda skriptet igen, eftersom det redan ärhär. Koden som flyttar objekt på rätt ställen måste dock köras. Nu verkar just det här biblioteket vara ganska snabbt på att göra detta när sidan laddas. Den animerar dock objekten när de behöver flytta till en annan plats när fönstret ändrar storlek, och detta gör stor skillnad. Naturligtvis lägger användare inte tid på att ändra storlek på sina webbläsarfönster så mycket som vi utvecklare gör. Men denna animerade upplevelse av storleksändring kan vara ganska jobbig och ökar den upplevda tiden det tar för sidan att anpassa sig till sin nya storlek. Användarvänlighet och enklare kod Hur enkelt det är att använda en webbfunktion och hur enkel koden ser ut är viktiga faktorer som kan göra stor skillnad för ditt team. De kan naturligtvis aldrig vara lika viktiga som den slutliga användarupplevelsen, men utvecklarupplevelsen påverkar underhållet. Att använda en inbyggd webbfunktion kommer med viktiga fördelar på den fronten:
Utvecklare som redan känner till HTML, CSS och JS kommer med största sannolikhet att kunna använda den funktionen enkelt eftersom den har utformats för att integrera väl och vara konsistent med resten av webbplattformen. Det finns ingen risk att brytande ändringar införs i hur funktionen används. Det finns nästan ingen risk för att den funktionen blir utfasad eller inte underhålls.
När det gäller inbyggt murverk, eftersom det är en primitiv layout, använder du det från CSS, precis som Grid eller Flexbox, ingen JS inblandad. Även andra layoutrelaterade CSS-egenskaper, som gap, fungerar som du förväntar dig. Det finns inga knep eller lösningar att veta om, och de saker du lär dig dokumenteras på MDN. För Masonry JS lib är initiering lite komplex: den kräver ett dataattribut med en specifik syntax, tillsammans med dolda HTML-element för att ställa in kolumn- och gapstorlekar. Plus, om du vill spänna över kolumner måste du själv inkludera gapets storlek för att undvika problem:
Låt oss jämföra detta med hur en inbyggd Masonry-implementering skulle se ut:
Enklare, mer kompakt kod som bara kan använda saker som gap och var spännspår görs med span 2, precis som i rutnät, och kräver inte att du beräknar rätt bredd som inkluderar gapstorleken. Hur vet man vad som är tillgängligt och när det är tillgängligt? Sammantaget är frågan egentligen inte om du ska använda inbyggt murverk över ett JS-bibliotek, utan snarare när. Masonry JS-biblioteket är fantastiskt och har fyllt ett tomrum i webbplattformen i många år, och för många glada utvecklare och användare. Det har några nackdelar om du jämför det med en inbyggd Masonry-implementering, men de är inte viktiga om implementeringen inte är klar. Det är lätt för mig att lista dessa coola nya webbplattformsfunktioner eftersom jag arbetar hos en webbläsarleverantör, och därför tenderar jag att veta vad som kommer. Men utvecklare delar ofta, undersökning efter undersökning, att det är svårt att hålla reda på nya saker. Att hålla sig informerad är svårt och företag prioriterar inte alltid lärande ändå. För att hjälpa till med detta, här är några resurser som tillhandahåller uppdateringar på enkla och kompakta sätt så att du snabbt kan få den information du behöver:
Webbplattformen har en explorer-webbplats: Du kanske är intresserad av dess release notes-sida. Och, om du gillar RSS, kolla in flödet för releasenotes, såväl som Baseline Newly Available och Widely Available feeds.
WebbenPlattformsstatus instrumentpanel: Du kanske gillar dess olika Baseline-årssidor.
Chrome Platform Statuss färdplanssida.
Om du har lite mer tid, kanske du också är intresserad av webbläsarleverantörers release notes:
Chrome Edge Firefox Safari
För ännu fler resurser, kolla in mitt fuskblad för att navigera på webbplattformen. Min grej är fortfarande inte implementerad Det är den andra sidan av problemet. Även om du hittar tid, energi och sätt att hålla reda på, finns det fortfarande frustration över att få din röst hörd och dina favoritfunktioner implementerade. Kanske har du väntat i flera år på att ett specifikt fel ska lösas, eller att en specifik funktion ska skickas i en webbläsare där den fortfarande saknas. Vad jag kommer att säga är att webbläsarleverantörer lyssnar. Jag är en del av flera tvärorganisationsteam där vi diskuterar utvecklarsignaler och feedback hela tiden. Vi tittar på många olika källor för feedback, både interna hos varje webbläsarleverantör och externa/offentliga på forum, öppen källkodsprojekt, bloggar och undersökningar. Och vi försöker alltid skapa bättre sätt för utvecklare att dela sina specifika behov och användningsfall. Så om du kan, kräv mer från webbläsarleverantörer och pressa oss att implementera de funktioner du behöver. Jag förstår att det tar tid, och kan också vara skrämmande (för att inte tala om en hög inträdesbarriär), men det fungerar också. Här är några sätt du kan få din (eller ditt företags) röst hörd: Ta de årliga undersökningarna State of JS, State of CSS och State of HTML. De spelar en stor roll i hur webbläsarleverantörer prioriterar sitt arbete. Om du behöver ett specifikt standardbaserat API som ska implementeras konsekvent i alla webbläsare, överväg att skicka in ett förslag vid nästa Interop-projektiteration. Det kräver mer tid, men tänk på hur Shopify och RUMvision delade sina önskelistor för Interop 2026. Detaljerad information som denna kan vara mycket användbar för webbläsarleverantörer att prioritera. För mer användbara länkar för att påverka webbläsarleverantörer, kolla in mitt fuskblad för att navigera på webbplattformen. Slutsats Avslutningsvis hoppas jag att den här artikeln har lämnat dig med några saker att tänka på:
Spänning för Masonry och andra kommande webbfunktioner. Några webbfunktioner som du kanske vill börja använda. Några delar av anpassad kod eller kod från tredje part som du kanske kan ta bort till förmån för inbyggda funktioner. Några sätt att hålla reda på vad som kommer och påverka webbläsarleverantörer.
Ännu viktigare, jag hoppas att jag har övertygat dig om fördelarna med att använda webbplattformen till dess fulla potential.
