Could someone give a one or two sentence explanation of why I would want to use Svelte over something like React? I have heard it is "better", but have never understood why.
JS frameworks are like coffee, some people like them milky and full of sugar, some people like them like them lean and black, some are obsessed with making the "worlds best coffee" at home every morning, and some drink whatever brown water comes out of a vending machine.
We all like our coffee different, just as we all have favourite features and designs of frameworks. There is no correct, or best, framework, only personal preference and what's good enough for the job in hand.
Svelte is a Flat White with locally roasted coffee beans from an independent coffee shop.
React is a Starbucks Vanilla Late.
Vue is a Starbucks Caramel Machiato.
Angular is the Vanilla Late from your staff canteen, it used to be a bit rough, but seems to be better in recent years.
Not using a framework, is carefully weighing out the "correct amount" of beans, grinding them by hand, tampering it with the "correct force", and then making the "perfect" espresso.
Big disagree on the not using a framework part: far too often that's not so much a lovingly honed craft but an echo of the "websites should work just fine without JavaScript" that has long been given up as a goal but still haunts decisionmaking as an ideal that now serves as an excuse to consider everything client side secondary citizen. "It's JavaScript, right? It's supposed to an unmaintainable mess." If you dig deeper you will often hear something like "And anyways, jquery 3 is still the latest major release so this is definitely state of the art"
It's definitely not a perfect metaphor but I enjoy working with vanilla JS or without a framework and I think it's very different from "no JS" (I mean... seems obvious given that it's JS).
You can technically do anything a framework does in your own JS, since they're all just opinionated JS libraries. You can make your own SPA or implement your own VDOM or SSG but it might take a long time and not be as battle tested. On the other hand you're also free to make your own optimizations that might work well for your needs without worrying about a huge framework.
I'm not saying that there's no good handcrafted bare browser code out there, and I guess some of the bad wasn't made without love at all. But I've just seen too much of the stuff that seems like it's still standing with half a leg in the age of internet explorer vs netscape, and that was perhaps crafted laboriously but certainly with more contempt than love to consider the loved stuff mow than a rare exception. I guess part of my gut reasoning goes like this: chances are the loved ones have been modernised three times over, while the contemptful implementations live on.
But I can't come up with any coffee analogy for that, there's just no mapping between those spaces that makes any sense.
I was curious how ChatGPT would actually compare these frameworks to each other in coffee metaphors, so here you go:
- Vue is like a latte. It's smooth, easy to drink, and has a nice balance of sweetness and bitterness. It's also very popular and widely available. Vue is a progressive, incrementally-adoptable JavaScript framework for building UI on the web. It has a good and intuitive documentation, a large community, and a simple syntax. Vue is also performant and fast, and supports component-based development.
- React is like an espresso. It's strong, concentrated, and gives you a lot of energy. It's also the most searched and used framework among the four. React is a JavaScript library for building user interfaces. It has a large community, a lot of resources, and a high performance. React also uses JSX, which is a syntax extension that allows you to write HTML in JavaScript.
- Angular is like a cappuccino. It's rich, creamy, and has a lot of foam on top. It's also very complex and requires a lot of skills to make and enjoy. Angular is a development platform for building mobile and desktop web applications using TypeScript/JavaScript and other languages. It has a fast server performance, an MVC architecture implementation, and a good documentation. Angular also has a steep learning curve and is very complex.
- Svelte is like a cold brew. It's refreshing, smooth, and has no bitterness. It's also relatively new and innovative in the coffee world. Svelte is a new way to build web applications. It's a compiler that takes your declarative components and converts them into efficient JavaScript that surgically updates the DOM. It has no virtual DOM, no frameworks on top of frameworks, and no framework at runtime. Svelte is also truly reactive, easy to learn and use, and supports component-based development.
This is always a personal judgement, but here's my personal list:
- I find it so much easier to understand. I don't have to useState/useEffect/whatever, I just assign variables and the component re-renders
the relevant parts whenever I assign a new value.
- Styling is "just" CSS. No messing around with CSS-in-JS libraries and their various ways of being invoked. The CSS is automatically scoped to your component without you having to think about it (though IMO there’s work to do there with CSS variables and the like)
- The end-user bundle is so much smaller. This doesn't matter so much if you're creating a giant web app (e.g. Gmail) but I often work on smaller sites and it's very gratifying for users to only have to download ~20KB of JS rather than the hundreds (if not megabytes) you'd get with React. Has a positive impact on page performance scores, SEO etc too.
> I find it so much easier to understand. I don't have to useState/useEffect/whatever, I just assign variables and the component re-renders the relevant parts whenever I assign a new value.
What's frustrating for me is that I'm so used to thinking in hooks that when I first gave Svelte a try, it didn't click. And I knew that was wrong, lol. The release of Svelte 4 is good timing, I might have a use-case at work for a small project to try it out, so I'm going to give it another shot.
I find reactive systems to be at least as complicated as React's declarative model. I was glad to move on from Knockout more than a decade ago and Svelte is conceptually the same thing in how they work, but with a different proprietary syntax and a faster renderer.
I also don't understand the styling complaint. React devs used "just CSS" for years before some of them started pushing for CSS-in-JS. In fact, SCSS/CSS is the default for the still nearly ubiquitous create react app system.
End-user bundle argument is a red herring. What is true for "hello world" isn't true for large applications. The overhead of React is a one-time payment while each new Svelte component drags along all the code needed to support it (copying similar code over and over).
React's F + N * C (where F is framework size, N is component count, and C is average component size) is smaller for large values of N than Svelte's N * (F + C) approach.
That N is very large. E.g. here's a page that talks about it: https://github.com/halfnelson/svelte-it-will-scale. I'll note that was done with Svelte 3 and that with Svelte 4 components are at least 10% smaller, so it's actually even better than that. SvelteKit is also very efficient at JS splitting per-route thanks to Vite. It ensures only the JS that is necessary for a page is loaded and you're extremely unlikely to be using anywhere near that many components. Based on the article above, you'd have to have three entire sites worth of components on a single page.
What code does Svelte use internally vs what code winds up compiled into your components? Last I checked, MOST of the code wound up in your components. In fact, this was their entire argument for why people should use Svelte when it launched.
Just look at their "Hello World" application on the Svelte website. 5 lines of code transform into 45 lines of code.
Massive reduction in boilerplate. As someone who attempted to onboard onto both react and svelte for a couple days each, react continued to feel hyper unintuitive with a bunch of magic constructs. Svelte felt like I could guess what would work and it just did.
Caveat: since I went react -> svelte it's possible I was just warmed up to JS by that point
It's the opposite for me. React can be verbose but that's because a lot of it is explicit and has escape hatches. Svelte has magic that works until it doesn't and then you're stuck in Svelte land. It's not "just JS" despite people marketing it as such
I was stuck once by abusing `bind:` and other time with global exit transitions + sveltekit routing, but that's about it.
React on the other hand feels like a pot warming up and we're the frogs being boiled alive at this point. You can write some perfectly valid, but naive React code and it's going to have some footguns. We're so used to write idiomatic React code we don't even notice that anymore. You learn to use stable references in callback functions, to be careful using Context, and so on. But the list is not short, and it only grows.
Wanna write some naive code in svelte two days in? There's a good chance it's the same code you'd write a year later. Maybe that's what people mean by "just JS".
> You learn to use stable references in callback functions, to be careful using Context, and so on. But the list is not short, and it only grows.
It doesn't though. React adds new features that are optional and everyone goes "Pfft, I'm moving to Vue because they added [blank]" I've got old React projects that still work fine.
There are languages/frameworks that move fast and break things and then there are languages that just move fast. And Javascript itself is also very backwards compatible. You could still just be using class components and Redux and be fine. I have no interest in these server components right now.
Less code as everyone else mentioned, single file components (CSS is inside your .svelte files too, and isolated automatically), and a general feeling of on railsness that React for me lacked.
State in Svelte goes in stores. State in react seems to go in one of eighteen different mechanisms, which all begin with a 45 minute video of the author’s opinions about the true nature of reactive programming, when all I want to do is store a string.
> State in Svelte goes in stores. State in react seems to go in one of eighteen different mechanisms, which all begin with a 45 minute video of the author’s opinions about the true nature of reactive programming, when all I want to do is store a string.
So... useState? :)
Of course then I got to thinking about how I'd answer the question "How can I put make that useState value accessible at different points in the component tree?" and the answer was "Make a new context with createContext and wrap the context provider in a component which provides the state and write a hook to easily consume the context within a child component" and, yeah, that's not exactly a frictionless dev experience.
I work on several large react apps that are very data heavy and what I would consider complex. Honestly we just use useState and prop drilling. Most state is stored at optimal position within the hierarchy, so there really aren't that many props being passed down. The only place context is used is for session information.
It's really quite simple and elegant. Svelte's model would likely be more complex tbh.
I prefer an explicit function call over compiler voodoo magic, especially when it comes to reactivity (of which can have performance implications). Any solution where a compiler is changing the semantics of my code on the fly is just a hard pass.
Yeah, I think it's something you just have to get a feel for over time. Sometimes prop drilling is the lesser of two evils, other times it makes more sense to break related state up into a shared context.
At least the React ecosystem as a whole seems to have broken free from the delusion that Redux is the be-all-end-all of state management. Those were dark days.
Most folks would probably say "it's faster" but I think the real upside of using Svelte is the DX. It's just massively simpler and way easier to be productive.
Svelte tries to improve upon the relatively complex/heavyweight runtime of something like React by shifting as much of that complexity to the build step as possible. It also takes a more "batteries-included" approach compared to React by including some opinionated features like state management, animation, transitions and the like.
I haven't dug too deeply into Svelte because last I checked it didn't play particularly nicely with TypeScript but this release may prompt me to give it another look.
One of the things released today was dedicated documentation for TypeScript: https://svelte.dev/docs/typescript. The site was also updated today to include a JS/TS toggle so that you can see all the examples written in TypeScript if you prefer it to JS.
I'm not sure how long ago you tried or what issues you ran into, but hopefully this will help with getting started with Svelte and TypeScript much more easily.
I'd argue that Svelte is less opinionated than React in most areas. The whole hook system depends on a ton of hidden state that React manages itself.
Svelte state management, for example, is just the `subscribe(callback: () => void) => Unsubscriber` interface. A couple of utility store functions are provided like `writable` and `derived` but state management libraries don't need to know anything about Svelte, just provide that single life cycle method. The context API looks almost exactly like React's.
The most important thing to know about Svelte is that it doesn't have a runtime. All the magic occurs in places that look magic, and all the magic happens at compile time; at runtime it's simply a library. By contrast, React's VDOM system not only adds significant cognitive complexity but performs terribly too.
As someone who came from a self-taught backend background (Python), Svelte is way easier to learn, read and write than React (to me) due to requiring was less boilerplate. The example in the “Developer Experience” section of this article was all I needed to see to ditch my attempts at learning React and go all-in on Svelte.
You get a legible stack trace that actually points to something looking very much like your code.
There's also stuff like generally fewer LoC, more incentive to use native APIs and rebuild times measured in hundreds of milliseconds, but that first thing is what got me sold on Svelte.
Because you can deliver a better product, faster, with Svelte. The total cost of development goes down, as the productivity is better, bugs per lines less, total lines of code less.
It's basically a different flavor of modern web app development. It's key difference is that it doesn't download a full JS library to the client. The saves some ms/s on initial load. For most applications, that is not really an issue but, of course, there are some scenarios that it suits.
We all like our coffee different, just as we all have favourite features and designs of frameworks. There is no correct, or best, framework, only personal preference and what's good enough for the job in hand.
Svelte is a Flat White with locally roasted coffee beans from an independent coffee shop.
React is a Starbucks Vanilla Late.
Vue is a Starbucks Caramel Machiato.
Angular is the Vanilla Late from your staff canteen, it used to be a bit rough, but seems to be better in recent years.
Not using a framework, is carefully weighing out the "correct amount" of beans, grinding them by hand, tampering it with the "correct force", and then making the "perfect" espresso.