This post was taken from my blog, so be sure to check it out for more up-to-date content.
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. 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!
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 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 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.
But, not to leave you with nothing but a simple claim, let's investigate Svelte's performance a bit further.
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 pair is a perfect example of that. Preact (without the compatibility layer) weights about 9.6KB, while React (with the required addition of 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 (a tree-shake-enabled bundler)?
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 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.
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 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, 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.
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.
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, with some really interesting concepts, and the process behind its current look.
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 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!
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, Facebook or simply checking out my personal blog. As always, thanks for reading this piece and have a nice day!
Top comments (3)
Instead of learning Svelte (or any other), I prefer to put all my time in studying and exploring best practices and different design patterns in pure Vanilla JS.
Reason being = that knowledge is transferable to any framework in any language, meaning you can pick up (name your framework here) in less time, if you have to.
I've heard a lot of good things about it, tho.
I feel like I should say: knowledge with vanilla web components and js does not transfer as well as you suggest into frameworks in any language. Frameworks have their own hell.
Svelte - while it's certainly better than most in structuring its patterns and practices - is still a code generator.
And yes, I'd love it if svelte generated rust code as well...
Hi Madza check out this post by Rich Harris
Maybe it will give you confidence about at less check out Svelte