Svelte is Ready for Use Today
This is the first in a series of articles outlining what makes Svelte a (truly) game-changing framework for your current project. [Update: Svelte 3 was recently released, so this article has been updated to reflect the latest changes. Also, if you want to get up to speed fast on what make Svelte a top framework, go check out Rich Harris’s mind blowing YGLF “Rethinking reactivity” talk and accompanying blog post.]
But first, a bit of ontology…
Recently, Michael Jackson of React lore posited that “React should be built in to the freaking browser,” kicking off a chain of literalist pro and con answers for such a thing. He clarified: “[let’s][build equivalent native APIs](https://twitter.com/mjackson/status/1050737976156639233).” In theory (not necessarily convention), I fully agree.
But this begs a larger question. Don’t these APIs already exist?
In some sense, yes, but in another, no. The power of modern frameworks is the magic glue that holds these APIs together, a modern jQuery for APIs, if you will. The missing sauce that makes the web more powerful and easier to work with for developers. On all accounts, modern frameworks like React are a tour de force. They directly solve “the problem,” so to speak, with browser conventions. To that point, Jackson is thoroughly on point. That is, HTML really does lack a universal framework.
At some point in time, like jQuery, we’ll want to start removing these frameworks from
tags and start using native APIs, because the browsers will have something baked in. In essence, much of this “YavaScript fatigue” will become a thing of the past. And arguably it’s already happening—
—in some ways, the end of JS churn started happening without people even noticing. Developers rallied around a handful of established frameworks, flocked to Twitter, evangelized (sometimes to a fault), and so forth. And the devil of any new HTML API framework conventions is in the details. Here’s a problem that different communities will likely disagree fairly strongly over, because the implementation details between, say, Angular, Vue, and React frameworks really are that different.
A solution based on current standards: Svelte
So, soliloquy aside, why stop and talk shop about YetAnotherLibrary™? Because—despite all the advances—Svelte introduces some truly amazing breakthrough features, all while advancing current APIs.
Let me stop and say that again because it’s so darn important and something that really does make Svelte a leader among all the frameworks. Svelte is a true game changer because it spends an awful lot of energy not trying to reinvent the wheel, but rather work with the flow of existing APIs. The power of this convention can’t be overemphasized, and, until you’ve tried working with something that feels so natural (one of the consequences of going with the flow), you don’t know what you’re missing.
This then is Svelte’s grand and brilliant mission. Work with the grain of what exists, and it will take us all so much further. In practical terms, this ultimately means developing less APIs and getting to that grand framework-in-the-browser vision of the future.
Working with the Grain
There’s one more reason you can and start using Svelte right now, in any project. Svelte bundles stand-alone components, without including a framework script as a dependency. This can be hard to understand until you realize that Svelte is a compiler; it’s only a framework during the build process. Svelte compiles the code away, which means your end result are tiny and performant components, tiny processes designed to do exactly what you built them to do; no more, no less.
So what does this mean? Because the end result is so light and performant, you can bundle it with other projects, easily.
Have a huge app with lots of legacy code that needs replacing? Svelte is perfect for this. You can swap as you go and not worry about bundling some large 100k+ library to get all the features you need. You can swap out individual components, almost at no cost (or, in terms of legacy, less cost) than it would take to rebuild something from the ground up in a different framework with a bit more rigidity in how it lets you piece things together.
Using React or Vue already? No problem. Svelte fits right in. Just use Svelte as you normally would. You may find in time that you’ll want to completely replace another framework, but you’re not obligated to right off the bat, because Svelte just does what you want it to do, at the component level.
Essentially, because Svelte tried to work around the existing ecosystem, surprisingly, it fits very well into the existing ecosystem. At one level, coding in Svelte feels effortless. One feels powerful. It’s like playing with a complete set of some of the best legos in the world. And it’s almost like those legos already existed, because, well, those standards mostly already do.
Originally I planned on writing a series of articles outlining additional top reasons for using Svelte. It’s such a well-designed library and ecosystem, there really is plenty to talk about. But since I first wrote this article, the community has since penned an official tutorial, which covers about all the ground you’d want to get going. You’ll note you can live-code in that tutorial, due to one of the best-kept secrets of the internet, the Svelte REPL.
In the meantime, in case I don’t get around to any other posts, here’s an easy five to draw from:
- As outlined above, Svelte is the framework that best meets the API of the web. It does it’s best to adhere to standard, and really only builds on what exists, doesn’t invent anything new like JSX.
- Along with point 1, because Svelte follows the web’s lead, learning Svelte is ridiculously easy. It takes no longer than 5 minutes to grok, and no longer than an hour or so to get fully up and running.
- The performance is rock solid—Svelte is often beating out other frameworks on UI and JS speed. And it’s increasingly used in production on various popular and traction heavy sites.
- It’s the “disappearing framework.” This feature is probably Svelte’s greatest innovation, and every framework should (and many are trying to) adopt it. There are zero client-side dependencies. Zilch. None. Just the end JS of the component itself.
- Which means: drop in components—yes, it really can be used in any project! Now!
…Did I say top 5 reasons? Here’s a few more to whet your appetite…
- Common to other prominent frameworks, Svelte enforces single-file components to help organize things.
- Out-of-the-box scoped styles. No need to ever worry again about chaotic cascading styles. Everything is scoped directly to the component.
- Svelte ditches legacy browsers, but also has a straightforward approach to handling legacy, if needed.
- Because of keeping with existing standards, the developer experience is truly remarkable. The legos just fit.
- This one’s just a tease: Svelte might entirely change the WebGL terrain in the future. Want to know more? Come over to the Discord channel and ask, become involved, contribute, etc. etc.