Comment by dissent
5 years ago
I have recently joined a team that had invested in Svelte. I had previous experience in Angular and React. I was happy with React, but I decided to drink the koolaid and go all-in and do my best with Svelte.
6 months later, we're moving to React. It is partly because our Svelte code was messy enough to warrant a rewrite, and partly because we wanted to leverage the React ecosystem in that rewrite. It was also partly because I just don't like Svelte very much.
I think Svelte is clever, and interesting, and I'm glad it exists. But I found a few points insurmountable:
- Too much magic. The abstraction leaks and when it does, it requires a good mental model of Svelte's magic. I noticed this threw our juniors off.
- Special syntax for reactivity is not javascript
- I find the javascript-native flexibility of JSX far more expressive than any custom templating
- There are major tradeoffs made by doing things at compile time. Things that are easy in React at runtime turn out to be surprisingly difficult in Svelte
- Two-way data binding is a constant source of bugs
- Svelte practically requires let-style variable rebinding, often at a file wide scope, which again caused our juniors in particular to write bad code
- The style system is too opinionated for me. I also find it necessary to break into the global scope for any minor restyling of a subcomponent (or worse, pass in the style as a prop)
- Built in reactive store is cool, but our developers all ended up using it for tight coupling and global variables
- The strict one component per file approach can be cumbersome. It's not possible to write a one-line function component or similar
- Much smaller ecosystem than React, requiring much more to be done in house (exacerbated by all of the above).
- The faster runtime speed in no way made up for any of the above. Bad Svelte code is still slow compared to good React code.
I've not used any Svelte significantly yet, so your points may stand.
I have, however, written React for years. If anything in Svelte is more confusing to juniors than how useEffect works, especially in conjunction with unstable references, I would be literally amazed.
useEffect is a loaded automatic pointed at your face if you don't fully understand it. It is truly a terrible API due to how intimately you have to understand JavaScript for it to always work properly.
I can't imagine anything worse in Svelte. If there is, I'd love to hear it.
Agree 100%. The migration from componentDidMount, componentDidUpdate, etc to useEffect was a major regression in terms of readability.
The return function in useEffect vs. componentWillUnmount is just terrible. This is always a bizarre topic for juniors.
I actually think that useEffect is an amazing abstraction. It lets you group related functionality like subscribing and unsubscribing into one place and makes it very difficult to leak stuff or use stale values.
I didn’t write many class components beforehand though, so my mental model didn’t have to change all that much.
4 replies →
As someone familiar with the old react API, I agree 100% about useEffect being super arcane.
There's just too much magic going on, which is the same thing that makes me reluctant to write Vue or Svelte (after reading this)
1 reply →
I agree, but it can be made easier by exposing named functions that help like useUnmount
https://github.com/streamich/react-use/blob/master/src/useUn...
Why do you think it's terrible?
7 replies →
useEffect makes easy things easy and hard things very hard indeed.
After building a few non trivial apps in React with hooks I'm convinced that what you really need for that model to work smoothly is a new language that tracks things like hook dependencies for you.
Eslint will ensure all dependencies are listed in the array. Is there something more you’re wishing for?
2 replies →
mobx tracks dependencies for you, and it's not magic if you understand the basic concepts of proxies and dereference
MobX does that.
Yeah useEffects was the start over overcomplicating react.
Perhaps a shift in mindset about how to approach using Svelte would help. Svelte is not React, and using React for an extended period really changes how you think about frontend code (structure-wise etc).
As a quick example, the Svelte 'ecosystem' is simply the Javascript ecosystem, which existed well before React. You can import any npm module to a Svelte app. Outside of the React-specific packages (which I argue are overkill), such as Redux or Redux-enabled form libraries, what are you missing? Pre-styled components like calendars, modals, popups, are available in a range of vanilla-JS packages. Anything more than that and it's possible that React thinking has over-complicated your approach.
Redux is not React specific. I assume you could use it with Svelte somehow.
That said, most React components are lightyears ahead of native Javascript components, simply because everyone uses React.
Yes, and in fact we even have a demo of our new RTK Query data fetching API (part of our official Redux Toolkit package) being used with Svelte:
https://redux-toolkit.js.org/rtk-query/usage/examples#svelte
I'm looking forward to picking up Svelte and just going back OOP for state management. Immutable state with React was a massive eye opener, but right now I think OOP is just better for state management, especially with all the insights gained from using React.
How about unstyled components like a dropdown menu or a multi-select with autocomplete?
I am really curious to hear about specific examples of some of these points. Specifically:
> The abstraction leaks and when it does, it requires a good mental model of Svelte's magic.
Maybe because I have familiarized myself with how Svelte works I haven't noticed anything like that.
> Things that are easy in React at runtime turn out to be surprisingly difficult in Svelte
I suspect this is from trying to use React patterns in Svelte, which I've seen quite a lot in people asking questions on Reddit. But I'm sure there are some things like that, could you give an example?
> Two-way data binding is a constant source of bugs
Again, very curious to see an example of this.
> It's not possible to write a one-line function component or similar
What was your use case here? I haven't found myself wanting to do that anywhere.
Is it surprising that two-way data binding is a source of bugs? We learned that lesson from Angular, and it influenced React’s preference for one-way dataflow.
2-way data binding is still a useful pattern with discipline, and still also common in React (using event handlers).
8 replies →
What do you mean by two-way and one-way exactly? (Asking it because web sometimes has a different history for terms.)
Not the GP, but here's an example of abstraction leaking straight from their intro tutorial:
> A simple rule of thumb: the name of the updated variable must appear on the left hand side of the assignment. For example this...
> ...won't trigger reactivity on obj.foo.bar, unless you follow it up with obj = obj.
This looks like a huge footgun to me, and it's not even an exotic usecase. It's in the very first page talking about reactivity in the docs.
It's not an abstraction leaking, it's an important point to understand about mutating objects.
You are allowed to use `const` to declare an object and then modify its properties, because modifying properties is not the same as reassigning.
You're absolutely right that it's something that might catch you out, but not understanding the difference between reassigning and mutating is likely to lead to other bugs and falling into other traps in future.
(by 'it's not an abstraction leaking', I mean 'the abstraction's behaviour is consistent with the behaviour of the language' - I guess it's a subjective opinion that it's not leaking)
2 replies →
This is unfortunate for your team, but most of your conclusions are not adequate.
1. Actually, Svelte has much less "magic" involved than React. Sveltes abstractions are not leaky. The reactivity might be more difficult to understand. But the rules are well defined. They are strange - no doubt - but not leaky. When looking at the generated code it's actually much more obvious what is going on than what React is doing. React on the other hand has some leaky abstractions. The biggest one is the effort you have to put into to make it efficient (memoization). Also, hooks.
2. Two way data binding is not a constant source of bugs. Then every team using Vue, Svelte, Angular, React with MobX would have those troubles. I've done 8 years frontend dev in a large company using React and Angular (and recently Vue 3) with different teams. The bugs come from people not technology. I've seen no other correlation there.
Granted, React has the largest ecosystem of all of them, but what do you actually need?. In that regard, Vue hits the sweet spot.
> Two way data binding is not a constant source of bugs
Every team using AngularJS _did_ have those problems (not to say it didn’t have some niceties also). It was one of the big architectural changes in Angular (2+) as a direct result. React does not have this feature; passing down a setter function is not the same as automatic 2-way binding.
As to your first point, different things feel like magic to different people, so it’s really hard to debate this with other people with different perspectives unless maybe your talking about single specific instances. It’s like trying to tell someone they don’t feel cold because you don’t feel cold or vice versa.
> - Special syntax for reactivity is not javascript
> - I find the javascript-native flexibility of JSX far more expressive than any custom templating
These are odd points to combine – JSX is special syntax not JavaScript as well.
Sure, but it maps 100% to an expected JS syntax and improves readability (subjective). From <div attr1="str">{children}</div> To React.createElement("div", { attr1: "str" }, children) Custom templating is not like that.
Subjective indeed. If the goal is to leverage the full expressiveness of JavaScript, you could just alias React.createElement to something like `h`. Or use something like https://github.com/caderek/react-plain
4 replies →
JSX is more akin to a macro than a DSL, which is why I strongly prefer it. Debugging errors in templating languages is invariably more frustrating and time consuming.
More on point, being constrained within the special language is miles away from the constraint of JSX, which is essentially limited to only allowing expressions, because the macro expands to expressions. Everything else is fair game, and that makes it far more expressive.
> Built in reactive store is cool, but our developers all ended up using it for tight coupling and global variables
I see this in every project where juniors or just undisciplined developers get to run without oversight. There's nothing special about Svelte stores here. Any store has this trap. There's no framework or library solution for good discipline about if, where, and how you share data.
> - Special syntax for reactivity is not javascript
Well, JSX syntax isn't JS either. And hooks semantics is not JS.
Learning new syntax is easy but we should consider how much the new semantics cause mistakes and to what extent they are incompatible with tools such as linters.
As I see it, the main issue with new syntaxes is the fact that they break compatibility with existing tooling. JSX is not fundamentally different in this regard, except for the fact that it gained so much mindshare that it brute-forced its way to getting first-class support in editors, language servers, different frameworks, even TypeScript. I don't predict that very many new JS-adjacent syntaxes will get that treatment from the industry.
True, although Svelte's syntax is chosen cleverly in a way that is not incompatible with existing tooling. (Starting a statement with $: is syntactically legal JS and a no-op.)
Another question is how much of Vercel's resources would it take to contribute Svelte support into all the major tools.
3 replies →
> I find the javascript-native flexibility of JSX far more expressive than any custom templating
JSX is the most significant contribution that React brought to front-end programming. Personally I don't always use React, but I use JSX quite often. It's intuitive in a way custom syntax (the dozens of) never will be.
JSX popularized it but we built it with opalang.org first (also with strong static typing before TS)
Opa was pioneering. Very impressive. Ahead of it's time.
What stack do you prefer these days?
It seems some folks still have their eye on the "full stack / single language" holy grail.
1 reply →
Funny as when I used React back in 2015 it was my least favorite feature (I moved to Vue since then).
React has special syntax for reactivity. What is useEffect? Is it a native JS function?
I don't understand why JSX is still being used. Why should I a HTML developer change how I write HTML for a framework? And why doesn't it allow style tags?
Svelte lets me use HTML, style tags even a script tag. The only framework that is close to HTML is Svelte. The second version even had .html extension which is now .svelte.
============== Svelte > React ==============
> And why doesn't it allow style tags?
You can 100% use style tags in React, they just aren’t automatically wrapped in module/component scope. Just like normal HTML style tags, actually.
As for JSX, I personally have always hated HTML template languages (“now which slightly-different version of the for iterator does this template get use?”) but I also recognize that there are other people who have opposite preferences. JSX-in-JS and template-directives-in-HTML are both valid approaches and it’s great that there are solutions to cater to various preferences. Trying to argue one down because you don’t like it is like arguing that your favorite color is factually superior.
> Built in reactive store is cool, but our developers all ended up using it for tight coupling and global variables
I don't see how having a reactive store has anything to do with the latter. But I find this ironic because every React codebase I've ever seen has components that import globals from other files (whether they be constants or POJOs). I don't find this inherently wrong, but it's exacerbated further by "Providers" and React.Context which seems idiomatic at this point.
Every reason you’ve stated are reasons I’ve switched from one proprietary or open source framework before react to react. 2 way data binding is a mental prison in big apps, I’m sure there’s a good implementation somewhere but I’ve yet to see it.
I don't like templating, it's too restrictive, feels like back to the 90s. This is typically aimed at coders who secretly don't want to code, and fall for tools that seems like they can avoid it.
What I like most about React is being able to break down views into functions and compose them. And if I have the choice, I prefer pure javascript and just a small helper function for Document.createElement instead of JSX, it makes it even more powerful, flexible and less verbose. You can already programmatically create elements in Javascript, I don't understand at all why people use "frameworks" for this, JS and HTML is already a view and a controller, just write the app? A complex single page application needs a couple of dozen lines of helper functions, that's all, why invent a whole new language on top of the language that in the end only restricts what you already have in the first place? This is spring framework enterprise hell all over again in the frontend
> Things that are easy in React at runtime turn out to be surprisingly difficult in Svelte
Do you have some specific examples?
I've been developing websites and apps with Svelte for almost 2 years now, and my experience couldn't be more different from yours.
> - Too much magic. The abstraction leaks and when it does, it requires a good mental model of Svelte's magic. I noticed this threw our juniors off.
Since Svelte runs vanilla JS and works with the DOM directly, my experience debugging any "magic" has been extremely straightforward compared to other frameworks. I'm curious what specific issues you have encountered.
> - I find the javascript-native flexibility of JSX far more expressive than any custom templating
Not once have I wished I had JSX in a Svelte project, and the readability of Svelte's minimal templating sugar is a breath of fresh air for myself. What's an example of a limitation you've faced in practice?
> - There are major trade offs made by doing things at compile time. Things that are easy in React at runtime turn out to be surprisingly difficult in Svelte.
I would love an example of this, as I've yet to run into any situations where I felt there was something I couldn't accomplish at runtime.
> - Two-way data binding is a constant source of bugs
It's rare that I use two-way data binding, but in the rare cases where it's appropriate, it's very convenient. The improper use of a utility doesn't necessarily discredit the value of said utility.
> - Svelte practically requires let-style variable rebinding, often at a file wide scope, which again caused our juniors in particular to write bad code
I'm not sure this is true- with access to JS modules, stores, nullish coalescing, and lifecycle hooks, let-style rebinding can be avoided entirely.
> - Built in reactive store is cool, but our developers all ended up using it for tight coupling and global variables
Inexperienced developers will write bad code with or without powerful tools like Svelte stores. I don't think a framework is meant to replace experience, guidance, and coaching.
> - The style system is too opinionated for me. I also find it necessary to break into the global scope for any minor restyling of a subcomponent (or worse, pass in the style as a prop)
Considering you Svelte lets you style things in a plethora of different ways (including the traditional method of external css files), I'm curious how you came to the conclusion that it's opinionated.
> - The strict one component per file approach can be cumbersome. It's not possible to write a one-line function component or similar
While it _can_ be, a single function shouldn't be a "component"- but Svelte "actions" are an awesome feature designed to make single functions easy to compose and reuse across components. That being said, there is talk of supporting multiple Svelte components per file (although it's rather controversial and largely unnecessary in Svelte projects).
> - Much smaller ecosystem than React, requiring much more to be done in house (exacerbated by all of the above).
Considering any JS library (most importantly, ones that interact with the DOM) is plug-and-play in a Svelte file- I've never found myself needing something that didn't exist on NPM. Nonetheless, the DX and power of Svelte enables us to create complex libraries and components that would ordinarily be too cumbersome or time consuming to produce in-house, and with much less code than with React. This usually pays dividends in the long-run, as custom solutions are typically easier to debug and extend.
> - The faster runtime speed in no way made up for any of the above. Bad Svelte code is still slow compared to good React code.
The runtime speed is pretty low on my list of reasons I prefer Svelte above other solutions. While the performance gains from Svelte are amazing for users (especially ones with low-end devices or shotty internet speeds), the unparalleled DX, development speed, maintainability (do more with less code = less bugs = easier to maintain), community, and overall fun involved in working with Svelte overshadow the free optimization done by the compiler at build-time.
Anyways, I hope that round 2 will be more fruitful for you and your team! I'm highly skeptical that React will solve more problems than it causes when your primary bottleneck is developer experience, but I'm sure we will both be able to learn from your experience regardless of the outcome!
> Inexperienced developers will write bad code with or without powerful tools like Svelte stores. I don't think a framework is meant to replace experience, guidance, and coaching.
This is the gist of the whole comment. The person posting is not complaining about a bad Svelte experience, they're complaining about bad programming practices.
>- Special syntax for reactivity is not javascript
Are you referring to Svelte using the $: dollar label prefix syntax for reactivity?
Yes, that is most certainly is standard JavaScript syntax. Read the docs:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
>label: The labeled statement can be used with break or continue statements. It is prefixing a statement with an identifier which you can refer to.
https://svelte.dev/docs
>3. $: marks a statement as reactive
>Any top-level statement (i.e. not inside a block or a function) can be made reactive by prefixing it with the $: JS label syntax. Reactive statements run immediately before the component updates, whenever the values that they depend on have changed.
https://dev.to/itsjzt/understanding-svelte-s-dollar-label-sy...
>Understanding Svelte's $: (dollar label) syntax
>In the long list of cool features of svelte, The one which I use more often is this dollar label thing. Initially, it looked strange to me but later I realized it is a valid javascript syntax. You can use it for doing side effects like useEffect of React, there is also a syntactic sugar way of declaring computed properties.
The Svelte compiler does add special SEMANTICS to JavaScript (and that's what makes it so great), but it does NOT add any special SYNTAX at all.
Although it might mistakenly appear to you that it does, if you're not entirely familiar with the well documented standard JavaScript syntax definition that I linked to above.
Your off-the-shelf code highlighters and linters will work just fine inside the standard <script> tags in svelte files, exactly like they should. That was the whole point behind Svelte's design.
However that's not the case with JSX, because JSX is definitely NOT the same as JavaScript, no matter how fuzzy and inconsistent a definition of "equality" and how many equal signs you use.
> Special syntax for reactivity is not javascript
That's because there is no syntax for reactivity in JavaScript, period.
Much of this I would have expected, but this was less obvious:
> There are major tradeoffs made by doing things at compile time. Things that are easy in React at runtime turn out to be surprisingly difficult in Svelte
What are some examples of this?
“ - The faster runtime speed in no way made up for any of the above. Bad Svelte code is still slow compared to good React code.”
What? Can you expand on that? Makes no sense.
I read it as: Svelte is faster in theory, but since people write bad Svelte code, it is slower than the React code the same developers would write.
My interpretation is that this can be attributed to either svelte being hard to write, or people being used to React. Both of which are a challenge to companies looking to switch to Svelte.
Yes, clearly it is not for purists.