Webdev voelde nog nooit zo svelte

Waarom we een “niche” frontend-taal zijn gaan gebruiken in productie.

React domineert het webontwikkelingslandschap al bijna 10 jaar. Bij We Do Dev Work hebben we talloze projecten gedaan in zowel React als NextJS, dat server-side rendering introduceerde nog voordat React dat zelf deed. React is fantastisch voor single page applications (SPA's)!

Maar de wereld van webontwikkeling omvat veel meer dan alleen SPA's.

Het belang van server-side rendering

De tekortkomingen van React waren bekend binnen de community. Ontwikkelaars zochten naar een manier om SEO-vriendelijke websites te bouwen zonder de enorme overhead van JavaScript.

Vercel sprong in het gat met een oplossing: NextJS was geboren. In plaats van elk element aan de client-zijde te renderen, voert NextJS een deel van je JSX-code uit op een server en rendert daar de elementen. Gecombineerd met caching zorgt dit voor snellere laadtijden, minder verbruik van resources aan de client-zijde en betere SEO-scores op het web.

Waar NextJS de mist in ging

Voor Vercel is het bouwen van een framework echter geen geweldig verdienmodel; het vereist veel hoogwaardige software-engineers en is lastig te gelde te maken omdat er zoveel open-source alternatieven zijn. Vercel zit niet in de business van frameworks bouwen; ze zijn primair een serverless cloudprovider. En dat is precies waar het misgaat met NextJS…

Omdat Vercel hun eigen servers wil verkopen en je factureert voor elk verzoek aan die servers, zijn ze twijfelachtige praktijken gaan aanbevelen in hun NextJS-framework. Volgens hun officiële documentatie moet nu alles aan de server-zijde gebeuren. Server-side operaties zijn geabstraheerd en de standaardinstellingen verbruiken over het algemeen meer serverbronnen (denk bijvoorbeeld aan NextJS Image). Dit maakt het ontzettend lastig om een NextJS-applicatie te optimaliseren voor kosten, en het resulteert vaak in langere laadtijden vergeleken met statische rendering-technieken.

Om een lang verhaal kort te maken: NextJS is een enshittified\* framework geworden, waardoor de markt weer openligt voor een echt SEO-vriendelijk framework.

• https://en.wikipedia.org/wiki/Enshittification

En dat is waar Svelte goed begint te voelen

Svelte is in essentie een framework dat een applicatie direct compileert naar HTML- en JavaScript-code. Het leunt niet op een grote bibliotheek (zoals een virtuele DOM) die in de client-applicatie moet worden geïmporteerd. Het biedt ook server-side rendering, componenten, routing op basis van mappenstructuur en andere bekende features van React en NextJS.

De keuze voor Svelte hangt af van het project! De aanpak van Svelte biedt een slankere codebase en een kleinere bundle size, wat het perfect maakt voor projecten waarbij prestaties en onderhoudbaarheid van de code prioriteit hebben. Maar voor complexe zakelijke vereisten, centraal state-management en diverse integraties met derde partijen, geniet React nog steeds de voorkeur.

In ons eerste project met Svelte, onze eigen website (www.wedodevwork.com), gaven we prioriteit aan performance. We kozen voor een statische site-aanpak met de svelte static adapter, die zeer voordelig kan worden gehost op een cloud distributienetwerk. We merkten dat de overstap naar Svelte soepel verliep omdat onze developers al bekend waren met TailwindCSS en Svelte bovendien de standaard HTML-syntaxis gebruikt binnen de codebase.

Wat Svelte geweldig maakt voor SEO is de eenvoud van data laden. Het laden van data gebeurt op de server, of op zowel de server als de client. Het is mogelijk om data te laden bij elk verzoek (met behulp van hooks), maar meestal gebeurt dit eenmalig en kan de data ongeldig worden gemaakt door een dependency te wijzigen of door de "invalidate" functie aan te roepen. Je kunt responses ook streamen met een promise, waardoor je content zoals laadbalken kunt tonen terwijl je wacht op de data.

Onze toekomst met Svelte

De Svelte-community is relatief klein vergeleken met React, wat resulteert in een beperkter aanbod aan tools en bibliotheken van derden. En hoewel Svelte nog steeds groeit, zorgt de beperkte hoeveelheid open-source codebases voor een minder soepele 'vibe-coding' ervaring. We vinden het niet erg om in de documentatie te duiken om gaten op te vullen, maar het betekent wel dat we meer moeten investeren in de leercurve die bij Svelte komt kijken. Bovendien is het makkelijker om nieuwe React-developers aan te trekken voor het onderhoud van een grote bestaande codebase.

Daarom blijven we voorzichtig voordat we elk project naar Svelte verhuizen. Maar voor prestatiekritische kleine tot middelgrote projecten is het een uitstekende kandidaat als frontend-framework. Als je alleen een hamer hebt, lijkt alles op een spijker. Gelukkig hebben we nu zowel Svelte als React in onze vingers, en kennen we de sterke en zwakke punten van beide frameworks om de juiste beslissing te nemen!

Als je iets wilt bouwen met Svelte (of React), laat het ons weten. We Do Dev Work kan je helpen bij het bouwen en optimaliseren van je webapplicaties.