It's just "JavaScript" in that it needs a translation layer and has a bunch of special syntax/semantics around reactive variables. Lol.
I don't understand the cult following around Svelte. There's a lot of magic and complexity hiding in there.
At the end of the day state management is not trivial and something has to handle it. React doesn't impose a specific state solution which is what I like about it. But while React isn't perfect, Svelte is not the next step imho.
I’ve been using Svelte for a about 3 years on smaller visualization projects and it works really well in that context. Being able to declaratively define your UI behavior is massive for tools like D3js compared to the more traditional imperative JS style. This unlocks the ability to abstract your UI in really nice ways for defining complex visualization behavior.
The other thing that I really like about Svelte is that’s a compiler and not a runtime framework. This keeps builds performant and makes it easy to import vanilla JS packages without needing framework-specific bindings
I also find Svelte’s syntax to be very intuitive and easy to pick up. The Svelte REPL tutorial docs are some of the best I’ve seen as far as getting up to speed with the tooling.
> React doesn't impose a specific state solution which is what I like about it. But while React isn't perfect, Svelte is not the next step imho.
This one area where we’re going to disagree. Svelte feels more like Rails in that it ships with most of your basic utilities to build a UI, which allows the community to agree on a preferred solution to a given problem. I prefer this because it makes it easier to find solutions to problems that aren’t dependent on some package that I don’t have. Solution discoverability is a massive pain point in react compared to Rails, where there’s pretty uniform agreement on how to solve problems.
All that said, I’ve never worked on a large commercial Svelte codebase so I can’t speak to the ways it which it becomes painful. For smaller projects, I find the DX to be far superior than react.
Perhaps, but given the issues I’ve seen with the larger react codebases I’ve worked with around performance and shifting best practices, I wouldn’t necessarily write Svelte off without giving it a fair shot. It’s not like large React apps are much fun to work on either.
Ultimately, big codebases are hard to manage, regardless of the language or framework. I don’t see a particular dealbreaker with Svelte compared to React in this regard.
> There's a lot of magic and complexity hiding in there
I mean there's a lot of magic and complexity hidden in frameworks, interpreters, compilers, all the way down, not to mention browser engines. Or did I miss something?
when you code in svelte you name the files .svelte, it can't be parsed as javascript. This is more than framework magic, it is a new language. You can't create a preact like framework based on svelte.
Magic is only magic to the ignorant. Complexity is only complex because of humans (mostly). My issue with all of this is that vanilla is better than any framework. It’s fast, it’s has dependency trees, module loading, components, it works well with npm, and it doesn’t force me to learn yet another flavor of the same broken concept.
> I don't understand the cult following around Svelte. There's a lot of magic and complexity hiding in there.
What's new is old again :) People started doing React because they got tired of mixing languages for logic, structure and styles, why not do it all in JS? They got tired of that, so why not separate them? They got tired of manually doing bindings, so now that's hidden behind abstractions ("Hello 2000s templating magic"). I wonder what they'll get tired of next.
My point being: If I ask you today, I'm very likely to get a difference answer compared to in 2-3 years, and if I wait yet again 2-3 years, another answer :)
Next is writing code entirely. Whatever has the most robust documentation will be the next big thing, since AI agents will be writing the code for the programmers.
I'm concerned about the opposite possibility. All the effort will go into tweaking models and adjusting their training data until they generate acceptable output, and documentation for human consumption will be an afterthought.
> documentation for human consumption will be an afterthought.
The documentation just changed a layer upwards in the abstraction ladder. Instead of docs for the code that runs on the machines, we'll write docs for the programs we've built that can generate the code that runs on the machines.
>There's a lot of magic and complexity hiding in there.
That's kind of the point. It's for people who want that magic, not for people who are likely just going to start using Rust instead of continuing to force such rigidity and verbosity into JS/TS.
>> There's a lot of magic and complexity hiding in there.
> That's kind of the point.
But it goes against the title of this post: "You Don't Need to “Learn” Svelte: Embracing the Simplicity of JavaScript". If the point of Svelte is the magic, why tell people they don't need to learn anything? The magic isn't part of JavaScript, so they'll have to learn it.
There's complexity in there, but magic? I'm not sure what you mean. Metaprogramming? The reactivity layer? Otherwise, it's hardly more complex than competing "frameworks". The internals of the rendering engine are a bit cryptic but are otherwise very straight forward to figure out if you want to add custom behavior.
Reactive declarations using label syntax definitely qualify as magic. It’s clever, maybe even the good kind of clever, but it’s definitely magic. And it’s definitely not “just JavaScript”.
Most front-end devs already use a translation layer - Typescript. So I don't understand the need to draw an arbitrary line between what can and cannot be used to make a good web application.
Alright but the types are a wholly different language and cannot be parsed by JavaScript linters. Same as Svelte. People need to learn Typescript in order to use it, it does not come naturally. I don't understand how the same argument cannot be applied for Typescript. I do remember people complaining about Typescript before it became popular. Eventually people understood it made their projects more maintainable and dropped the purist arguments that provide no value to the product.
>I don't understand the cult following around Svelte.
What I don't get is how I never (at least on HN) see any criticism of it. Like... never ever. And sure I've probably missed the odd negative post about it, but as someone who has never used it and whose entire knowledge of it is based on what I've read on here, I couldn't tell you a single supposed downside of using Svelte. And sure, it could just be That Good, but... I dunno? There's something off about that.
My team switched from React to Svelte a couple of years ago. We were working on new app, not refactoring or rewriting an old one, so we had the opportunity to choose whatever tooling we wanted.
The whole team loved Svelte. It did the stuff React did, without a lot of the ceremony or boilerplate. It was easy for the junior devs to pick up, and powerful enough for the senior devs to what needed doing.
We weren't pushing it very hard; the app was basically data entry and data display, and I assume that if you got deep enough into corner cases, it would break down like any other framework. But for our purposes, Svelte felt like someone had taken the time to understand React's issues, and fixed them.
If you want to see some criticism of svelte, one of the core maintainers recently asked about some things that could be improved about svelte in the next major version: https://twitter.com/trueadm/status/1676694161188159490
That should give you some rough ideas about the things that the community itself thinks need improvements.
I have no expectations, but I thought I might as well ask: do you know if there are any apps that will unroll a Twitter thread given a link like the one in your comment? The web version of Twitter no longer shows threads, and I've spent enough time scrolling through the shitty Twitter user page UI looking for old tweets that I'd really prefer an alternative if there is one.
I tried using it 2 years ago on a mid complexity webapp and it blew up in my face as soon as things got a little more complex. The hidden mechanics of everything made it absolutely horrible to debug. Including some serverside rendering issues in the svelte code base at the time. The pain wasn't worth it in the end. I'm probably never gonna touch svelte again without having to.
Similar experience with preact.
It works till it doesn't.
In many cases, compared to what people were using before, it really is that good.
That's not to say it doesn't have its flaws, but when people talk about how it's cleaner, they can dev and debug faster, it takes less of a cognitive load, etc. - they are being genuine.
Some of it is subjective probably, but I'd die if I had to go back to e.g. React. :)
I've been using Svelte exclusively for my projects (and at my day job) for the last 3 years. I've converted several large projects over from React to Svelte. I also do some part time work as contractor on a very large React app. I can provide you with some downsides for Svelte:
1. The developer experience with Svelte just isn't that great. Unfortunately, the Svelte team has (understandably) optimized for VS Code. I've been a WebStorm user for about 8 years and have no plans of switching over to VS Code. They just introduced Svelte LSP integration in WebStorm, but it's buggy. For the longest time you didn't get autocomplete on props with the Svelte plugin. With the Svelte LSP, you do, but I'm getting a bunch of errors from the LSP saying "x is not a module". This may be a configuration issue (I'm using pnpm workspaces and TS path aliasing). But I don't really want to go down that rabbit hole, so I just turn the LSP stuff off. It has gotten better, but it comes nowhere near the DX you get with React.
2. You technically can spread props down the component tree using $$props and $$restProps, but the documentation recommends you don't because there's a performance hit. So for stuff like "aria-" attributes, you either need to define them explicitly as props (e.g. "export let ariaLabel"), which is sort of gross, or you bite the bullet and use $$props or $$restProps.
3. Unless I'm doing something totally wrong here, using CSS nesting doesn't work the way I expect it to for scoped styles. I get that they are scoped, which is good. But if I have a button element with a child Icon component, and I want to change some CSS property in the Icon component's inner svg element using CSS nesting, it won't work:
<script>
// Icon has an inner svg element:
import Icon from "./Icon.svelte";
</script>
<style>
button {
& svg {
width: 1rem;
height: 1rem;
}
}
</style>
<button><Icon name="close" /></button>
The Icon's svg won't pick up that 1rem x 1rem sizing. I guess this makes sense because that is essentially just button > svg, which also doesn't work. But I end up having to fall back to CSS modules (or Emotion, which I stopped using because it needs a runtime).
4. I feel like the whole "$" reactivity gets overused, which leads to confusing and, in some cases, difficult to debug code. Maybe this is the ol' React dev in me (one way data flow), but 9 times out of 10, instead of binding a value to an input component, and listening for changes in a "$" block, I'm going to use the "on:input" or "on:change" event listener to capture that and just reassign the value variable.
<script>
let value = "";
// Instead of this:
$: {
// Do something with value.
}
// I do this:
function handleValueChange(event) {
value = event.currentTarget.value;
// Do something with value.
}
</script>
<input id="use-binding" bind:value />
<input id="use-event" {value} on:change={handleValueChange} />
5. This isn't a Svelte-specific issue, but I'm not crazy about single file components. I really like how components === functions in React, so you can put multiple components in the same file. In lieu of a function that returns a bunch of JSX based on some args, you can switch that over to a component with props. I think that's a really clean design that encourages good separation of concerns. In Svelte, you either end up with a bunch of extra files that need to use context + store or prop passing for state, or a giant component file.
6. Unless there have been major improvements in the testing space that I haven't taken advantage of recently, you can pretty much throw any hopes of reliable test coverage out of the window. At some point I just stopped testing my Svelte components and moved as much logic as I could outside of of the component so I could write unit/integration tests against that to get reliable branch coverage. This sort of ties into point #1, but I feel pretty strongly about having a comprehensive test suite to avoid regressions (enough to make this it's own bullet point). I don't put a lot of emphasis on the coverage percentage because that way lies madness, but it is nice to see at a glance if I'm missing a test case for a branch in the coverage report.
There's probably a few more minor gripes that I can't think of right now, but those are the heavy hitters. That all being said, two of the biggest advantages Svelte offers over React:
1. No virtual DOM. This allows you to do things like change the style of something based solely on an HTML attribute using CSS, no state variable needed. Also mentioned in the original post: you can use plain ol' JS libraries and everything just works. This is a big deal for stuff like D3, because you don't need to add any wrappers. I've had problems with React + D3 in the past, and it drove me bananas.
2. Much fewer footguns. I know this is a controversial take, but I don't like React Hooks. They're a pretty big footgun. They often require you to break up a component needlessly so you adhere to the "Rules of Hooks". Stale closures are a thing. I never had a problem with class components. I never understood the confusion around "this", which was a common defense for using hooks whenever the topic of the weirdness of hooks came up. If writing class components was still acceptable, I would be more amenable to using React in my projects. But whenever anyone I work with at the contractor gig encounters a class component, they immediately want to refactor it to a functional component with hooks. It's never even up for debate, class components bad, functional components good. Svelte doesn't have anything analogous to a hook, which makes me happy.
I don't understand the cult following around Svelte. There's a lot of magic and complexity hiding in there.
At the end of the day state management is not trivial and something has to handle it. React doesn't impose a specific state solution which is what I like about it. But while React isn't perfect, Svelte is not the next step imho.