Webdev never svelte so good
Why we started using a “niche” frontend language in production.
React rules the web development landscape for almost 10 years. At We Do Dev Work, we’ve done plenty of projects in React as well as NextJS, which added server-side before React did themselves. React is great for single page applications (SPA’s)!
But, the world of web development includes much more than SPA’s.
The importance of server side rendering
The flaws of React were well known in the community. Developers needed some way of building SEO friendly websites that don’t require huge JavaScript overhead.
Vercel stepped in with a solution and NextJS was born. Instead of rendering every element on the client side, NextJS runs some of your JSX code on a server and renders elements there. Combined with some caching, this allows for faster loading times, less resource consumption on the client side and better SEO scores on the web.
What NextJS got wrong
For Vercel however, building a framework isn’t a great business model, it requires a lot of very good software engineers and generally isn’t monetizable because there are so many open source options out there. Vercel isn’t in the business of building frameworks, they are primarily a serverless cloud provider. And that’s where NextJS goes wrong…
Because Vercel wants to sell you their servers and bills you for every request made to those servers, they started recommending questionable practices in their NextJS framework. Everything now has to be done on the server side, according to their official documentation. Server-side operations are abstracted, and default settings generally take up more server resources (think of NextJS Image for example). This makes it incredibly difficult to optimize a NextJS application for cost, and often comes with longer loading times compared to static rendering techniques.
To blatantly tell a short story: NextJS is an enshittified* framework, reopening the market for a true SEO friendly framework.
And that’s where Svelte starts to feel good
Svelte is essentially a framework that compiles an application directly into HTML and JavaScript code. It doesn’t rely on a large library (such as a virtual DOM) that has to be imported in the client application. It also offers server-side rendering, components, folder-structure based routing and other known features from React and NextJS.
The choice to use Svelte depends on the project! The Svelte approach offers a leaner codebase and smaller bundle size, making it perfect for projects that prioritize performance and code maintainability. But for complex business requirements, central state management and diverse third party integrations, React would still be preferred.
In our first project with Svelte, our own website (www.wedodevwork.com), we prioritized performance. We opted for a static site approach using the svelte static adapter that could be deployed very cheaply on a cloud distribution network. We noticed that moving to Svelte was easy because our developers were already familiar with TailwindCSS and Svelte also uses the HTML syntax within the codebase.
What makes Svelte great for SEO is its simplicity of loading data. Loading data happens either on the server, or both the server and client. It is possible to load data on every request (using hooks), but generally it’s done once and the data can be invalidated by either changing a dependency or by an intervention calling the “invalidate” function. You can also stream responses with a promise, allowing you to render content such as loading bars while waiting for the data response.
Our future with Svelte
The Svelte community is relatively small compared to React, resulting in a limited set of third party tools and libraries. And while Svelte is still growing, its small sample size of open-source codebases results in a poor vibe-coding experience. We don’t mind digging through some documentation to fill in the gaps, but it does mean we need to invest more into the learning curve that comes with Svelte adoption. It is also easier to hire new React developers to maintain a large existing codebase.
That’s why we’ll be using caution before moving every project to Svelte. But for performance critical small- to mid-sized projects it’s a great candidate as a frontend framework. If all you have is a hammer, everything looks like a nail. Luckily, we have both Svelte and React in our skillset now, and we know both frameworks’ strengths and weaknesses to make the right decision on which one to use!
If you want to build something with Svelte (or React), let us know. We Do Dev Work can help you build and optimize your web applications.
