Svelte - a recipe for a successful framework?
Tags: webdev, javascript, svelte
Published: 2020-01-22 17:38:48

**This post was taken from [my blog](https://areknawo.com), so be sure to check it out for more up-to-date content.**

Every time a new framework (that is *JavaScript UI framework*) enters the market people are questioning it openly - "Why another framework?". From a certain point of view, it seems like a logical standpoint - the JS ecosystem is already *flooded* with frameworks and with their growth, the choice becomes increasingly harder.

With that said, I tend to disagree with such an opinion. Sure - a new framework means one more (seemingly unnecessary) option to choose from and comes at the cost of hours of work that could be better utilized. But, in reality, the *decision-making* process is the part of all of our lives and the author's (or authors') choice to make the given framework in the first place is their's and their's alone.

Apart from all that, each new framework comes with at least a small possibility of *disrupting* the JS ecosystem - rather painful but necessary process to move it forward. And even if it doesn't become the "next React", it'll certainly serve as an inspiration for future developers to create some even more impressive tools. That's just how things are. An unstoppable cycle - one that no single "Why another framework?" question can stop.

But let's get back to the topic, as in this post I want to talk a little about such a "disruptive framework", which, right now, is [Svelte](https://svelte.dev/). If you watch the world of web development closely, you might know that it's a relatively *new player* to the framework game. With that said, it's even more surprising that's it's being compared to "industry standards", such as *React*, *Vue*, and *Angular*. But why is this so, and is there some kind of a recipe for a successful framework? That's what we'll try to uncover today!

# Svelte

Let's start with a quick overview of what's Svelte and why it's so special. I've already covered it a little bit in my [2020 web development predictions](https://areknawo.com/web-development-in-2020-a-look-forward/) blog post, but it deserves far more attention than that.

As a fun fact - one that you might already know about - svelte is not a random word, but an actual [adjective](https://dictionary.cambridge.org/dictionary/english/svelte) to describe an elegant person! I think it nicely represents the nature of Svelte as a framework, or should I say *compiler*. Because the very thing that differentiates Svelte from all the other frameworks is the additional compile step, which processes your Svelte app for more compact and performance-optimized results.

# Performance

But, not to leave you with nothing but a simple claim, let's investigate Svelte's performance a bit further.

## Size

You might know that the rule of a thumb is the *smaller* the codebase the more *performant* and *efficient* it is. I think the React and [Preact](https://preactjs.com/) pair is a perfect example of that. Preact (without the [compatibility layer](https://github.com/preactjs/preact-compat)) weights about [9.6KB](https://bundlephobia.com/result?p=preact), while [React](https://bundlephobia.com/result?p=react) (with the required addition of [React DOM](https://bundlephobia.com/result?p=react-dom)) comes at a staggering *121KB*! Keep in mind that the provided numbers don't take into account the *Gzip compression*, as it wouldn't be representative of the actual size of the executed code. In the case of Svelte, it's much harder to provide the actual size of the codebase. Because Svelte uses compilation, it has an "unfair" advantage over the more usual frameworks. The resulting code still uses functionalities provided by Svelte itself, but the compiler can optimize their use and so, e.g. it doesn't have to include the *transition engine* unless you use it.

All of that makes for a simple, most basic Svelte app taking just *2.95KB*. Even when keeping in mind all the features that can optionally be added, such a small footprint is very impressive! Besides, the ability to *cherry-pick* the necessary features can only be considered an advantage!

Either way, we still haven't talked about the elephant in the room - *tree-shaking*. But I think all who have experienced it before know how different the results can be. The "tree-shakability" of the code varies, and so do the result of this kind of optimization. And even if it does optimize the bundle size, nothing stops you from using it with Svelte, and gaining even more precious KBs! Have I already told you that Svelte plays nicely with [Rollup](https://github.com/sveltejs/rollup-plugin-svelte) (a tree-shake-enabled bundler)?

## Benchmark

So, we've got some really nice size metrics, but how do they translate to *real-world performance*? Honestly, I can't tell. Most modern frameworks are so fast, that it's usually not them causing the bottlenecks. Thus, we can only use an *artificial benchmark* to have at least some knowledge of what's going on. I've found a [nice one](https://krausest.github.io/js-framework-benchmark/current.html) that involves rendering a large table (1.000 and 10.000 rows), and already covers a lot of different frameworks. If you're interested, it's source code is available on [GitHub](https://github.com/krausest/js-framework-benchmark).

![Benchmark results table snippet](https://areknawo.com/content/images/2020/01/benchmark.png)

Benchmark results table snippet

So, in this particular benchmark, when looking at keyed implementations only (ones that use keys when rendering array data), *Svelte (v3.5.1)* ranked quite high - higher than the 3 most popular frameworks. But, what's also very important, is the fact that some frameworks are even faster than Svelte, and don't use any compiling techniques. One that caught my attention is the [hyperHTML](https://github.com/WebReflection/hyperHTML) library - not only because of my prior experiences with it but also because it bet Svelte without the use of pre-processing. If you're interested in this *lightweight* library and its unique use of [tagged template literals](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals), you should check it out!

Again, rendering a large table isn't necessarily the best way to determine real-world performance. However, it gives us a glimpse of how different tools compare in a more *standardized scenario*. It's important not to develop the false "compiled is always better" mindset. It can be true in many cases, but definitely not always.

# Magic of pre-processing

About that compilation process though. I think you'd agree with me that it's a unique feature of Svelte - one that separates it from the rest of nowadays frameworks. Sure, maybe some other frameworks that came before it used a similar technique, but either it wasn't *highlighted* enough or the framework itself simply didn't get enough *traction*.

The point I'm making here is just how important having a unique feature is in the modern "framework wars". I think no React clone - no matter how good it might be - will ever beat React in terms of popularity and usage. Being *unique* is very important in today's world - a world in which many things have already been done.

But compilation, or *pre-processing* as I like to call, isn't something new. However, the way that Svelte introduced it to the wider web development community was truly *innovative*. In the near future, when this concept will gain more traction (and it definitely will), I could imagine Svelte (or some other, currently non-existent framework) leading the way in both the compilation technology, as well as the unbeatable performance and efficiency.

# Marketing

But putting the innovation aside, there's yet another thing that's important for making a successful framework - one that most of its end users most likely don't enjoy that much - *marketing*. You know the phrase "if you write it, they'll come" (or something along those lines). Sadly, with the current size of the open-source ecosystem, it no longer works like that.

## Important details

Now, I'm not talking about *advertising* your framework with paid ads or treating it as a paid product - no. In open-source, it's more about *social engagement*, a great *logo*, a *README* file, complete *documentation*, and things like that. If you just put your great new library out there, publicly on GitHub, without spreading a word, I bet very few people would even notice it. But, if you do share your new creation and people like it, there's a great possibility that they'll share it further and further. And then people like me write stuff that you read and get hooked on the concept even more, to the point where you're finally convinced to use it. ;) It's all just a pretty simple *mechanism*, but one that's really hard to be utilized correctly to its full extent.

But back to Svelte. If you've seen it before it "boomed in popularity", you should know that it didn't always have the same nice logo or landing page as it has now. Sure, some people know that the outside isn't what really should be judged but I think everyone would agree about how important the *first impressions* are, right? Speaking of which, if you're interested in the Svelte's *visual identity*, I recommend you check out [this issue](https://github.com/sveltejs/v2.svelte.dev/issues/335), with some really interesting concepts, and the process behind its current look.

## Buzz-words

But apart from the visuals, there's also another part of open-source marketing that's even less enjoyed by the public - so-called *buzz-words*. You've certainly seen them before - "reactive", "progressive", "blazing", or in case of Svelte - "cybernetically enhanced" (earlier "magical disappearing" or something like that). Obviously, all these and similar words are meant to indicate something, but their real purpose is just to make you interested in what they have to offer. It's really kind of funny you know - people always complain about how they don't like all these catchphrases, and yet they usually aren't compelled to look at products that don't use them. ;)

What's even more interesting is that Svelte's "cybernetically enhanced" slogan serves one more purpose - *keyword building*. It evolved into a keyword that's now strongly related to the framework - even if it wasn't originally meant to. Like really, just go ahead and [search the web](https://www.google.com/search?q=cybernetically+enhanced) for "cybernetically enhanced". You might think that you'd get some kind of cyborgs, robots, and prostheses, but instead, you get Svelte as the top result! Quite funny, but also really good for *SEO*!

# What does it take?

So, to summarize all that we've discussed, let's answer our original question - what does it take to make a successful framework?

Well, a *good idea* and a bit of *enthusiasm* to have at least something to start with. But, later on, for it to take off, you have to have a good *marketing strategy* - logo, landing page, social media reach, and, of course, a nice catchphrase. If you have all of that, you can expect your project to boom - especially when you add some *unique features* and *innovative solutions* to the mix.

Naturally, it's easier said than done. But, as it turns out, it is possible and Svelte is the latest example of that. With its unique use of the pre-processing, catchy slogan, nice logo and visuals (after redesign), semi-complete docs, and a growing community, it appears the future is bright for Svelte!

# Thoughts?

But what are your thoughts on that matter? Do you think that it's useful to create "yet another framework"? And if so, how to make it succeed? I'd love to see your opinions down in the *comments section* below. Also, let me know if you'd like to see some more practical Svelte content on this blog in the future!

If you like this post consider *sharing it* and *following me* on [Twitter](https://twitter.com/areknawo), [Facebook](https://facebook.com/areknawoblog) or simply checking out [my personal blog](https://areknawo.com). As always, thanks for reading this piece and have a nice day!