Thoughts on Svelte(Kit), one year and 3 billion requests later

Last year my company, was tasked with the mission of building a news website.

Since the project went live, it has experienced significant audience growth, handling hundreds of thousands of visitors every day. Each visitor navigates and interacts with the pages and their components, resulting in approximately 3 billion requests in the last 12 months.

In this article I will talk about what made me chose Svelte for this project, and what I consider being the good and bad sides of working with both Svelte and SvelteKit.

The project

To sum it up: Our customer approached us with a website made years ago that featured old technology, was hard to add features to, had poor performance, and had expensive vertical infrastructure. After several meetings, we came to the conclusion that the best approach was to simply halt the old website development and build a new one from scratch using the best technologies and practices.

Given the malleability and scalability needs for this project, a new CMS would also need to be built from the ground up. And due to a tight schedule (an MVP had to be in production in ~2 months), we proposed the use of SvelteKit.

Why propose SvelteKit in the first place?

I first heard about Svelte back in 2018 in its former version (v2), which was considerably more verbose, but even then it felt like a breath of fresh air for building performant UI at a fast pace.

Then in 2019 Svelte 3 was introduced with an even simpler syntax to the point where you basically wrote JavaScript + HTML + CSS and got fast reactivity as a bonus.

As a “good tech” enthusiast, that’s hard to ignore.

Then came the era of SSR. Svelte first responded with Sapper (which was the “official” way of doing SSR with Svelte at the time), and then with SvelteKit. Sapper always seemed to be too “uncooked” to be adopted in large projects, but SvelteKit was a whole new league; it provided a robust SSR solution.

Since then, I’ve sporadically adopted Svelte, starting with small projects and gradually moving to bigger ones as it proved to be up to the task.

And now we had this project that:

• Would make good use of SSR and SEO features;
• Would have its components and styles written from scratch;
• Had a custom CMS with lots of custom reactive layout features;
• Had a deadline of ~2 months.

Having worked with both React and Svelte, I felt much more confident in meeting such deadline using Svelte due to its productivity, compared to React’s occasional rough edges (i.e. hooks hell, odd performance, verbosity, etc.).

Now, to be clear here: React is a great reactive library with a massive community and a thriving ecosystem, being the largest in the front-end world. React has a clear happy path that, as long as you follow, will hardly get you hurt. But once you leave this path you may (and more likely will) get into trouble at some point. And sometimes there are projects where you don’t want (or can’t) risk getting in trouble because of the tool you’ve chosen for your UI development. There simply isn’t any room for that.

This project was one of those cases, and so we moved with Svelte/SvelteKit instead of React/Next.js.

So, was Svelte/SvelteKit worth it?

Ok, let’s go down to business.

After deploying this project and running it for approximately 12 months, collaborating with other developers on daily basis for implementing features and fixing bugs, and handling billions of requests and millions of visits throughout this period, I feel like it’s time to talk about the good things, the bad things, and what concerns me.

The good things

Daily productivity boost: As mentioned earlier, working with Svelte is an absolute delight. It has a simple syntax that takes you no more than half a day to grasp, makes hard to write bad code, and most of the time it just works as expected. If you’re coming from Angular or React, once you learn Svelte you’ll probably feel like a super-hero in the first few days of writing components.

Svelte could be better described as a tool that gets out of your way. I’ve experienced countless occasions where I was solving a challenge that went like this:

– “hmm, I’ll try this crazy approach, but will the framework even accept that?”
– ”…”
– “whoa, oddly enough it did… Alright then, next task…”

When you try crazy approaches in other frameworks, you generally end up with bizarre loops, lifecycle rough edges, and simply refusal to comply (happy path, remember?). In this sense Svelte makes you feel like a hacker with minimal constraints.

Plays well with vanilla libs: Svelte syntax is essentially plain HTML, CSS and JS with a little bit of directives on top. This means that vanilla CSS and JS libraries are easy to integrate into it with minimal changes and bindings. And by wrapping a vanilla lib to a component or an action, you’ve essentially created basic Svelte version of that lib. This is important since Svelte’s community and ecossystem are still relatively small (will talk more about it down below).

Hard to find devs, easy to convert devs: If your company adopts Svelte and SvelteKit, you’ll probably have a hard time finding Svelte developers out in the wild. But Svelte is basically HTML + CSS and JS, remember? This means that any front-end developer can easily turn into a Svelte proactive dev in no time. It’s also easier to introduce people that would often stay away from code to coding (e.g. Designers, interns, etc) because the learning curve is so low, and since Svelte isn’t reinventing the wheel, they can always refer to the decades of HTML and CSS tutorials on the internet.

In this project, one of our devs was a React user with no past Svelte knowledge. After a single day studying Svelte docs, he was already solving tasks. In about two weeks he was already working on some of the most complex components the website had.

A bittersweet routing: SvelteKit has a kinda weird route naming convention, but once you give it a try it starts to make sense. And in bigger projects with lots of routes, this forced convention helps A LOT to quickly scan and understand what is happening just by glancing at your editor file tree.

Seriously? Every week a new framework, make it stop!

If you’ve never played with Svelte or SvelteKit, and feel like it’s just yet another front-end framework™, consider following these two steps:

1. Watch this video to understand why Svelte exists.
2. Give it a try for a small side project. Really, you’ll thank me later.

The bad things

Not all roses, right?

Lack of “Svelte” things: As said, Vanilla JavaScript (and HTML/CSS) libs often play well with Svelte, but it gets annoying fast having to search for a Svelte component only to find a GitHub with 2 stars or a npm package with 6 weekly downloads. Sometimes searching for things made in Svelte may look like visiting a ghost town, so if you like to simply plug in well maintained open-source libraries into your project and go from there, take that into account.

This is slowly changing though, several UI libs started to appear recently, for example.

Solo-dev projects: Another issue is that many projects are one-man armies. Perhaps this issue is more related to open-source ecosystem as a whole, as I’ve also experienced projects like that in Angular, React and React Native, but given the smaller community that Svelte has, it’s more perceivable. Solo OS projects often have prohibitive issues open for ages, lack detailed documentation, and may get abandoned relatively easily. This may be mitigated as the community grows.

Very few established patterns and good tutorials: Take Svelte Stores for instance, it has a simple and elegant contract, but gives you no patterns whatsoever on how to handle it properly as it grows in complexity. Sure, docs and the official tutorial helps, but I feel there is a lack of established patterns and in-depth tutorials for doing more advanced stuff in Svelte and SvelteKit. And once you dig too deep, you may end up facing problems not many have experienced before. This is hard to happen with more popular frameworks as there is always someone who carved instructions into the wall for the next explorers.

No SSR at the component level: Ok, I have some issues with React Server Components, not because the clear advantages it introduces but mainly because of the feeling React as a whole is making a shift in philosophy to “server-side first”, but this is topic for another article. The point here is that Server Components may actually be very useful, especially if you’re dealing with heavy-SEO-centered content.

Take this example: I have a layout builder, this layout works like a Lego, where you can arrange several “standalone” components together. Now some of these components make their own fetch calls to external high-available sport APIs, weather APIs and so on. How can you make these components SSR if your route do not know about them since the layout itself is dynamic and may change? Once you can only SSR at the route level, you simply can’t SSR your custom layout, the only way to “bypass” that is to use your route to actually read all the layout metadata and write a big switch ordering several fetches to actually feed the layout components dynamically. SSR to the component level would be way easier.

Lack of islands architecture: Islands architecture and partial hydration can help you render static HTML with just a small portion of JavaScript for those components who need it. For a website that is 80% static and 20% interactive, this can decrease the request payload dramatically. The smaller your payload, the faster you page loads, and the fewer your CDN bills will cost you. Again, for a website that depends on load time, SEO, and Google ranking, this kind of feature plays a huge part, and SvelteKit lacks it.

The ugly things

Ok, the bad things are bad, I would love to see them addressed in the future, but we can maneuver around them, the ugly things however, are dangerous and may cause serious problems to a project.

Reactive declarations and statements: Do you remember the Palantir from the great lore The Lord of the Rings? Or, to use a more contemporary pop reference, Marvel’s Power Infinity Stone? What both those powerful objects have in common is that during the story, many thought to be strong enough to tame their power, and most of those have fallen ill to the consequence of their naivety. Whenever you see a label statement ($:) in a Svelte code, you better treat it like a Palantir or a Power Stone. Reactive declarations and statements feel like powerful magic, and they are, but it’s very easy to hurt yourself by writing code that is almost impossible to debug, and end up having to refactor all your component tree that mixes with this reactivity.

Reactive declarations and statements are useful features, just remember not to abuse them, otherwise you may end up switching Svelte’s productivity by headaches and infinite debug sessions, which may directly affect your deadlines.

Svelte’s lack of protagonism: This may be a more anthropological and marketing issue than a technical one, but since technologies with low usage can eventually perish (taking the projects made using them along the grave), and the worst nightmare of a dev is losing support for their tech stack used in several production projects, this is still an important “ugly” topic to talk about.

Credit where is due, Svelte is always featuring as the most beloved tech in several surveys for years now, which obviously drives attention from the audience. But I still have a feeling that the community itself, especially the leaders, often ignore and even disengage from public debates, marketing and narratives in the web dev scenario.

What I mean by that? Well, take for instance Dan Abramov, Evan You, Ryan Carniato, Fred K. Schott, and many others. Brilliant minds solving hard problems and working on bleeding-edge technologies helping to push the web forward. They are influential voices shaping the ongoing debates in the web development landscape, and naturally, their technologies become part (often the center) of those discussions. Today, the web development scene is like a bustling public square, filled with ingenious minds shouting “Eureka!” as they interact and share their discoveries in a captivating dance of technical innovation. While Svelte used to be an active participant in this dance, I can’t help but feel it fading from the scene.

In my native-language we have this proverb that goes: “Quem não é visto, não é lembrado”. Which reads more blunt than it should in English but translates to something like: “Who isn’t being seen, ain’t gonna to be remembered”. I hold immense respect and admiration for Rich and his remarkable work not only in Svelte, but also Rollup, Ractive and many other technologies. Rich and others in the Svelte ecosystem are also brilliant minds, but I don’t see them engaging in this dance with the other brilliant minds anymore. Without this active engagement, I fear that Svelte may not be remembered as it should by the audience.

So in the end, was Svelte worth it?

In ~2 months we built a whole CMS from scratch along with a huge website and the backend to feed them both. We have been expanding the codebase continuously, and the overall experience has been fantastic, despite some of the issues discussed earlier.

Given our team size at the time, I don’t believe we would have been able to meet such a tight deadline without the productivity that Svelte provides. Despite the challenges and drawbacks discussed earlier, SvelteKit has demonstrated itself as a reliable SSR framework for production use, effortlessly handling massive traffic without significant flaws.

For future projects of all sizes that align with the strengths of Svelte and SvelteKit, I will certainly use them.

Perhaps you started to read this article with the expectation that it would solely promote Svelte, or go the opposite direction providing an opportunity to just criticize it. Neither of these assumptions is correct. It is what it is: Svelte has certainly many good parts that, for my reality, still outweight the bad ones, but there are certainly bad and ugly ones too, like any technology does.

In my case, Svelte has proven to be effective for both my team and our customers. It has served as a valuable tool for the job at hand, and as long as it keeps pursuing more of the “good things”, our paths will continue to align.