Ongeveer vijftien jaar geleden werkte ik bij een bedrijf waar we apps bouwden voor reisbureaus, luchthavenpersoneel en luchtvaartmaatschappijen. We hebben ook ons eigen interne raamwerk gebouwd voor UI-componenten en app-mogelijkheden voor één pagina. We hadden componenten voor alles: velden, knoppen, tabbladen, bereiken, gegevenstabellen, menu's, datumkiezers, selecties en multiselecties. We hadden zelfs een div-component. Onze div-component was trouwens geweldig, het stelde ons in staat om afgeronde hoeken te maken in alle browsers, wat, geloof het of niet, op dat moment niet eenvoudig was.
Ons werk vond plaats op een punt in onze geschiedenis waarin JS, Ajax en dynamische HTML werden gezien als een revolutie die ons naar de toekomst bracht. Plotseling konden we een pagina dynamisch bijwerken, gegevens van een server ophalen en voorkomen dat we naar andere pagina's moesten navigeren, wat als langzaam werd ervaren en er een grote witte rechthoek op het scherm tussen de twee pagina's flitste. Er was een zin, populair gemaakt door Jeff Atwood (de oprichter van StackOverflow), die luidde: “Elke applicatie die in JavaScript kan worden geschreven, zal uiteindelijk in JavaScript worden geschreven.” — Jeff Atwood
Voor ons destijds voelde dit als een uitdaging om die apps daadwerkelijk te gaan maken. Het voelde als een algemene goedkeuring om alles met JS te doen. Dus we deden alles met JS, en we namen niet echt de tijd om andere manieren te onderzoeken om dingen te doen. We voelden niet echt de prikkel om goed te leren wat HTML en CSS konden doen. We zagen het web niet echt als een evoluerend app-platform in zijn geheel. We zagen het vooral als iets waar we omheen moesten werken, vooral als het om browserondersteuning ging. We zouden er gewoon meer JS tegenaan kunnen gooien om dingen voor elkaar te krijgen. Zou het helpen om de tijd te nemen om meer te leren over hoe het internet werkte en wat er op het platform beschikbaar was? Natuurlijk had ik waarschijnlijk een heleboel code kunnen scheren die niet echt nodig was. Maar op dat moment misschien niet zo veel. Kijk, de browserverschillen waren toen behoorlijk groot. Dit was een tijd waarin Internet Explorer nog steeds de dominante browser was, met Firefox op de goede tweede plaats, maar marktaandeel begon te verliezen doordat Chrome snel aan populariteit won. Hoewel Chrome en Firefox het redelijk goed eens konden worden over webstandaarden, zorgden de omgevingen waarin onze apps draaiden ervoor dat we IE6 lange tijd moesten ondersteunen. Zelfs toen we IE8 mochten ondersteunen, hadden we nog steeds te maken met veel verschillen tussen browsers. Niet alleen dat, maar het web van die tijd had gewoon niet zoveel mogelijkheden die rechtstreeks in het platform waren ingebouwd.
Snel vooruit naar vandaag. De zaken zijn enorm veranderd. We beschikken niet alleen over meer van deze mogelijkheden dan ooit tevoren, maar de snelheid waarmee ze beschikbaar komen is ook toegenomen. Laat ik de vraag dan nog eens stellen: zou de tijd nemen om meer te leren over hoe het internet werkt en wat er op het platform beschikbaar is, u vandaag helpen? Absoluut ja. Als u het webplatform vandaag de dag leert begrijpen en gebruiken, heeft u een enorm voordeel ten opzichte van andere ontwikkelaars. Of u nu werkt aan prestaties, toegankelijkheid, reactievermogen, allemaal samen, of alleen maar UI-functies levert, als u het als verantwoordelijke ingenieur wilt doen, kunt u door te weten welke tools tot uw beschikking staan, uw doelen sneller en beter bereiken. Voor sommige dingen heb je misschien geen bibliotheek meer nodig Als we weten wat browsers tegenwoordig ondersteunen, is de vraag dus: wat kunnen we achterwege laten? Hebben we in 2025 een div-component nodig om afgeronde hoeken te maken? Natuurlijk niet. De eigenschap border-radius wordt inmiddels al meer dan 15 jaar door alle momenteel gebruikte browsers ondersteund. En binnenkort komt er ook corner-shape, voor nog mooiere hoeken. Laten we eens kijken naar relatief recente functies die nu beschikbaar zijn in alle grote browsers, en die u kunt gebruiken om bestaande afhankelijkheden in uw codebase te vervangen. Het gaat er niet om meteen al je geliefde bibliotheken te dumpen en je codebase te herschrijven. Wat al het andere betreft, moet u eerst rekening houden met browserondersteuning en beslissen op basis van andere factoren die specifiek zijn voor uw project. De volgende functies zijn geïmplementeerd in de drie belangrijkste browser-engines (Chromium, WebKit en Gecko), maar het kan zijn dat u andere browserondersteuningsvereisten heeft waardoor u ze niet meteen kunt gebruiken. Het is echter nog steeds een goed moment om deze functies te leren kennen, en misschien van plan te zijn ze ooit te gebruiken. Popovers en dialogen De Popover API, het
Natuurlijk is de snelheid van je internetverbinding waarschijnlijk ook toegenomen, maar dat is niet voor iedereen het geval. En ook niet iedereen heeft dezelfde apparaatmogelijkheden. Als u code van derden inschakelt voor dingen die u met het platform kunt doen, betekent dit hoogstwaarschijnlijk dat u meer code verzendt en daardoor minder klanten bereikt dan u normaal zou doen. Op internet leiden slechte laadprestaties tot grote verlatingspercentages en schade aan de merkreputatie. Minder code uitvoeren op apparaten Bovendien werkt de code die u op de apparaten van uw klanten verzendt waarschijnlijk sneller als er minder JavaScript-abstracties op het platform worden gebruikt. Het is waarschijnlijk standaard ook responsiever en toegankelijker. Dit alles leidt tot meer en gelukkigere klanten. Bekijk de jaarlijkse blog over de prestatie-ongelijkheidskloof van mijn collega Alex Russell, waaruit blijkt dat premium-apparaten grotendeels afwezig zijn op markten met miljarden gebruikers als gevolg van ongelijkheid in rijkdom. En deze kloof wordt in de loop van de tijd alleen maar groter.
Ingebouwde metselwerkindeling Eén webplatformfunctie die binnenkort beschikbaar komt en waar ik erg enthousiast over ben, is CSS Masonry.
Laat ik beginnen met uit te leggen wat metselwerk is. Wat is metselwerk Metselwerk is een type lay-out dat jaren geleden populair werd gemaakt door Pinterest. Het creëert onafhankelijke tracks met inhoud waarin items zichzelf zo dicht mogelijk bij het begin van de track inpakken.
Veel mensen zien Metselwerk als een geweldige optie voor portfolio's en fotogalerijen, wat zeker mogelijk is. Maar Metselwerk is flexibeler dan wat je op Pinterest ziet, en het is niet beperkt tot alleen maar watervalachtige lay-outs. In een metselwerk-indeling:
Tracks kunnen kolommen of rijen zijn:
Tracks met inhoud hoeven niet allemaal dezelfde grootte te hebben:
Items kunnen meerdere sporen omvatten:
Items kunnen op specifieke sporen worden geplaatst; ze hoeven niet altijd het automatische plaatsingsalgoritme te volgen:
Demo's Hier zijn een paar eenvoudige demo's die ik heb gemaakt met behulp van de aanstaande implementatie van CSS Masonry in Chromium. Een fotogalerijdemo die laat zien hoe items (in dit geval de titel) meerdere tracks kunnen omvatten:
Nog een fotogalerij met tracks van verschillende groottes:
Een lay-out van een nieuwssite waarbij sommige sporen breder zijn dan andere, en sommige items de gehele breedte van de lay-out beslaan:
Een kanbanbord dat laat zien dat items op specifieke sporen kunnen worden geplaatst:
Opmerking: deeerdere demo's zijn gemaakt met een versie van Chromium die nog niet beschikbaar is voor de meeste internetgebruikers, omdat CSS Masonry nog maar net in browsers wordt geïmplementeerd. Webontwikkelaars gebruiken echter al jaren met veel plezier bibliotheken om Masonry-lay-outs te maken. Sites die vandaag de dag metselwerk gebruiken Metselwerk is tegenwoordig vrij gebruikelijk op internet. Hier zijn een paar voorbeelden die ik naast Pinterest heb gevonden:
En nog een paar, minder voor de hand liggende, voorbeelden:
Hoe zijn deze lay-outs gemaakt? Oplossingen Eén truc die ik heb zien gebruiken is het gebruik van een Flexbox-indeling, waarbij de richting naar kolom wordt gewijzigd en deze op terugloop wordt ingesteld. Op deze manier kunt u items van verschillende hoogtes in meerdere, onafhankelijke kolommen plaatsen, waardoor de indruk ontstaat van een Metselwerk-indeling:
Er zijn echter twee beperkingen aan deze oplossing:
De volgorde van de items is anders dan bij een echte Masonry-indeling. Met Flexbox vullen items eerst de eerste kolom en, als deze vol is, gaan ze naar de volgende kolom. Met Metselwerk worden voorwerpen gestapeld op het spoor (of de kolom in dit geval) waar meer ruimte beschikbaar is. Maar ook, en wellicht nog belangrijker, vereist deze oplossing dat u een vaste hoogte instelt voor de Flexbox-container; anders zou er geen omwikkeling plaatsvinden.
Metselwerkbibliotheken van derden Voor meer geavanceerde gevallen hebben ontwikkelaars bibliotheken gebruikt. De meest bekende en populaire bibliotheek hiervoor heet simpelweg Masonry en wordt volgens NPM ongeveer 200.000 keer per week gedownload. Squarespace biedt ook een lay-outcomponent die een Masonry-lay-out weergeeft, als alternatief zonder code, en veel sites gebruiken deze. Beide opties gebruiken JavaScript-code om items in de lay-out te plaatsen. Ingebouwd metselwerk Ik ben erg enthousiast dat Masonry nu in browsers verschijnt als een ingebouwde CSS-functie. Na verloop van tijd zul je Masonry net zo kunnen gebruiken als Grid of Flexbox, dat wil zeggen, zonder dat je tijdelijke oplossingen of code van derden nodig hebt. Mijn team bij Microsoft heeft ingebouwde Masonry-ondersteuning geïmplementeerd in het open source-project Chromium, waarop Edge, Chrome en vele andere browsers zijn gebaseerd. Mozilla was feitelijk de eerste browserleverancier die in 2020 een experimentele implementatie van Masonry voorstelde. En Apple was ook erg geïnteresseerd in het realiseren van deze nieuwe weblay-out. Het werk om de functie te standaardiseren vordert ook, met overeenstemming binnen de CSS-werkgroep over de algemene richting en zelfs een nieuw weergavetype: grid-lanes. Als je meer wilt weten over metselwerk en de voortgang wilt volgen, bekijk dan mijn pagina met CSS-metselwerkbronnen. Als Masonry na verloop van tijd een Baseline-functie wordt, net als Grid of Flexbox, kunnen we het eenvoudig gebruiken en profiteren van:
Betere prestaties, Beter reactievermogen, Gebruiksgemak en eenvoudigere code.
Laten we deze eens nader bekijken. Betere prestaties Als u uw eigen Masonry-achtige lay-outsysteem maakt, of in plaats daarvan een bibliotheek van derden gebruikt, betekent dit dat u JavaScript-code moet uitvoeren om items op het scherm te plaatsen. Dit betekent ook dat deze code render-blocking zal zijn. Er zal inderdaad niets verschijnen, of de dingen zullen niet op de juiste plaatsen of in de juiste grootte staan, totdat de JavaScript-code is uitgevoerd. De lay-out van metselwerk wordt vaak gebruikt voor het hoofdgedeelte van een webpagina, wat betekent dat de code ervoor zorgt dat uw hoofdinhoud later verschijnt dan anders het geval zou zijn geweest, waardoor uw LCP of Largest Contentful Paint-statistiek wordt verslechterd, die een grote rol speelt in de waargenomen prestaties en zoekmachineoptimalisatie. Ik heb de Masonry JS-bibliotheek getest met een eenvoudige lay-out en door een trage 4G-verbinding te simuleren in DevTools. De bibliotheek is niet erg groot (24 KB, 7,8 KB gzipt), maar het duurde 600 ms om te laden onder mijn testomstandigheden. Hier is een uitvoeringsopname die de lange laadtijd van 600 ms voor de Masonry-bibliotheek laat zien, en dat er geen andere weergaveactiviteit plaatsvond terwijl dat gebeurde:
Bovendien moest het gedownloade script na de initiële laadtijd worden geparseerd, gecompileerd en vervolgens uitgevoerd. Dit alles blokkeerde, zoals eerder vermeld, de weergave van de pagina. Met een ingebouwde Masonry-implementatie in de browser hoeven we geen script te laden en uit te voeren. De browserengine doet gewoon zijn ding tijdens de eerste stap voor het renderen van de pagina. Betere responsiviteit Net als wanneer een pagina voor het eerst wordt geladen, leidt het wijzigen van de grootte van het browservenster ertoe dat de lay-out op die pagina opnieuw wordt weergegeven. Als de pagina op dit moment echter de Masonry JS-bibliotheek gebruikt, is het niet nodig om het script opnieuw te laden, omdat het alhier. De code die items naar de juiste plaatsen verplaatst, moet echter worden uitgevoerd. Nu lijkt deze specifieke bibliotheek dit behoorlijk snel te doen wanneer de pagina wordt geladen. Het animeert de items echter wanneer ze naar een andere plaats moeten worden verplaatst bij het wijzigen van het venster, en dit maakt een groot verschil. Natuurlijk besteden gebruikers niet zoveel tijd aan het aanpassen van de grootte van hun browservensters als wij, ontwikkelaars. Maar deze geanimeerde ervaring met het wijzigen van de grootte kan behoorlijk schokkend zijn en vergroot de waargenomen tijd die nodig is voordat de pagina zich aanpast aan de nieuwe grootte. Gebruiksgemak en eenvoudigere code Hoe gemakkelijk het is om een webfunctie te gebruiken en hoe eenvoudig de code eruit ziet, zijn belangrijke factoren die een groot verschil kunnen maken voor uw team. Ze kunnen natuurlijk nooit zo belangrijk zijn als de uiteindelijke gebruikerservaring, maar de ervaring van ontwikkelaars heeft invloed op de onderhoudbaarheid. Het gebruik van een ingebouwde webfunctie biedt op dat vlak belangrijke voordelen:
Ontwikkelaars die HTML, CSS en JS al kennen, zullen deze functie waarschijnlijk gemakkelijk kunnen gebruiken, omdat deze is ontworpen om goed te integreren en consistent te zijn met de rest van het webplatform. Er is geen risico dat er wijzigingen worden geïntroduceerd in de manier waarop de functie wordt gebruikt. Er is vrijwel geen risico dat deze functie verouderd of niet meer wordt onderhouden.
In het geval van ingebouwde Masonry, omdat het een primitieve lay-out is, gebruik je het vanuit CSS, net als Grid of Flexbox, zonder dat er JS bij betrokken is. Ook andere layout-gerelateerde CSS-eigenschappen, zoals gap, werken zoals je zou verwachten. Er zijn geen trucjes of oplossingen waar je meer over hoeft te weten, en de dingen die je wel leert, worden gedocumenteerd op MDN. Voor de Masonry JS-lib is initialisatie een beetje ingewikkeld: het vereist een data-attribuut met een specifieke syntaxis, samen met verborgen HTML-elementen om de kolom- en tussenruimtegroottes in te stellen. Bovendien moet u, als u kolommen wilt overspannen, zelf de tussenruimte opgeven om problemen te voorkomen:
Laten we dit vergelijken met hoe een ingebouwde metselwerkimplementatie eruit zou zien:
Eenvoudigere, compactere code die gewoon zaken als gap en overspanningssporen kan gebruiken, wordt gedaan met span 2, net als in grid, en vereist niet dat u de juiste breedte berekent, inclusief de gap-grootte. Hoe weet u wat er beschikbaar is en wanneer het beschikbaar is? Over het algemeen is de vraag niet echt of je ingebouwde Masonry moet gebruiken in plaats van een JS-bibliotheek, maar eerder wanneer. De Masonry JS-bibliotheek is geweldig en vult al jaren een leemte in het webplatform, en voor veel tevreden ontwikkelaars en gebruikers. Als je het vergelijkt met een ingebouwde Masonry-implementatie heeft het uiteraard een aantal nadelen, maar die zijn niet belangrijk als die implementatie nog niet klaar is. Het is gemakkelijk voor mij om deze coole nieuwe webplatformfuncties op te sommen, omdat ik bij een browserleverancier werk en daarom de neiging heb om te weten wat er gaat komen. Maar ontwikkelaars delen vaak, enquête na enquête, dat het moeilijk is om nieuwe dingen bij te houden. Op de hoogte blijven is moeilijk, en bedrijven geven sowieso niet altijd prioriteit aan leren. Om u hierbij te helpen vindt u hier een aantal bronnen die op eenvoudige en compacte wijze updates bieden, zodat u snel de informatie kunt krijgen die u nodig heeft:
Het webplatform beschikt over een verkennersite: Mogelijk bent u geïnteresseerd in de pagina met release-opmerkingen. En als u van RSS houdt, bekijk dan de release-opmerkingenfeed, evenals de Baseline Newly Available en Widely Available-feeds.
Het webDashboard Platformstatus: Misschien vind je de verschillende Baseline-jaarpagina's leuk.
Roadmappagina van Chrome Platform Status.
Als u wat meer tijd heeft, bent u wellicht ook geïnteresseerd in de release-opmerkingen van browserleveranciers:
Chroom Rand Firefox Safari
Voor nog meer bronnen, bekijk mijn Cheatsheet Navigeren op het webplatform. Mijn ding is nog steeds niet geïmplementeerd Dat is de andere kant van het probleem. Zelfs als je de tijd, energie en manieren vindt om het overzicht bij te houden, is er nog steeds frustratie als je je stem laat horen en je favoriete functies implementeert. Misschien wacht je al jaren tot een specifieke bug is opgelost, of dat een specifieke functie in een browser wordt geleverd waar deze nog steeds ontbreekt. Wat ik wil zeggen is dat browserverkopers luisteren. Ik maak deel uit van verschillende organisatieoverschrijdende teams waar we voortdurend de signalen en feedback van ontwikkelaars bespreken. We kijken naar veel verschillende bronnen van feedback, zowel intern bij elke browserleverancier als extern/openbaar op forums, open source-projecten, blogs en enquêtes. En we proberen altijd betere manieren te creëren waarop ontwikkelaars hun specifieke behoeften en gebruiksscenario's kunnen delen. Dus als u kunt, eis dan alstublieft meer van browserleveranciers en zet ons onder druk om de functies te implementeren die u nodig heeft. Ik begrijp dat het tijd kost en ook intimiderend kan zijn (om nog maar te zwijgen van de hoge toegangsdrempel), maar het werkt ook. Hier zijn een paar manieren waarop u uw stem (of die van uw bedrijf) kunt laten horen: Neem de jaarlijkse State of JS-, State of CSS- en State of HTML-enquêtes. Ze spelen een grote rol in de manier waarop browserleveranciers prioriteit geven aan hun werk. Als u een specifieke, op standaarden gebaseerde API nodig heeft die consistent in alle browsers moet worden geïmplementeerd, kunt u overwegen een voorstel in te dienen bij de volgende Interop-projectiteratie. Het vergt meer tijd, maar bedenk eens hoe Shopify en RUMvision hun verlanglijstjes voor Interop 2026 deelden. Dergelijke gedetailleerde informatie kan voor browserleveranciers erg handig zijn om prioriteiten te stellen. Voor meer nuttige links om browserleveranciers te beïnvloeden, bekijk mijn Cheatsheet Navigeren op het webplatform. Conclusie Ter afsluiting hoop ik dat dit artikel u een aantal zaken heeft gegeven om over na te denken:
Opwinding voor metselwerk en andere aankomende webfuncties. Een paar webfuncties die u misschien wilt gaan gebruiken. Een paar stukjes aangepaste code of code van derden die u mogelijk kunt verwijderen ten gunste van ingebouwde functies. Een paar manieren om bij te houden wat er gaat komen en browserleveranciers te beïnvloeden.
Wat nog belangrijker is, ik hoop dat ik u heb overtuigd van de voordelen van het optimaal benutten van het webplatform.
