I switched my game's UI from Vue2 to Svelte maybe a year ago, and I agree with almost all of the article.
One thing I think the author overlooks: the appeal of Svelte's built-in animations and transitions is that they work correctly when the element's lifecycle is being managed by Svelte. E.g. with code like this:
When `showFoo` changes to false, Svelte will first play a flyout transition and then remove the element from the DOM, and it will correctly handle things if `showFoo` toggles back to true again before the flyout finishes, etc. You could do the same thing with CSS animations, but it would be hairy and you'd need to learn more about svelte internals than you probably want to.
Co-opting my comment to add another thought. For me, Svelte's big superpower is that it does a great job of looking like plain JS sitting next to templated HTML, and the two just magically react to each other.
The reason this is huge is because 90% of my coding is not Svelte. Usually I'm working on app logic, so I might go weeks or occasionally months without touching any UI code. With Vue I used to dread making UI changes, because I always wound up needing to re-learn which properties I needed to put in which return value to which callback (or somesuch, I don't remember the details). I'm sure it's very intuitive if one uses it every day, but it never was for me after a six week gap.
In contrast with Svelte I feel comfortable doing UI work after a long hiatus, even with nontrivially reactive bits, because apart from the templating it's basically just plain JS (or looks like it). It took a bit of bother initially architecting stuff, but I don't think I've checked its docs since I first switched to it.
That said, the big tradeoff is that Svelte's reactivity is quite magical. Personally this doesn't bother me, because as a JS main I find it easy to intuit what Svelte must be doing behind the scenes in order to work the way it does. But if you're an occasional JS user you might hate Svelte's magicalness for the same reason I disliked Vue - e.g. you might keep needing to re-learn when to use $: statements, etc.
Re: magic in Svelte, I haven't used it but that sounds like something I'd be wary of. I like how Vue 3 takes a functional and explicit approach to defining reactivity. It's no longer grouped into buckets ala Vue 2 (data vs computed vs methods etc) but rather you write normal non-reactive JS by default and wrap values in reactive() or computed() when you need reactivity.
The only syntactic downside is reactive values always need to use foo.value to access foo's data which causes occasional bugs when you forget it (and it tends to fail quietly) but it makes sense why it is that way. Maybe better LSP/IDE integration can detect that.
It's good to hear Svelte has .svelte files like .vue SFC. That would be the biggest thing I'd miss with React.
Oh neat, I hadn't seen Vue3/script-setup, it looks very similar to Svelte. The magic I referred to was basically just wrapping reactive logic around variable assignments, so if you're familiar with Vue3 then you it sounds like you may not consider Svelte magical at all.
> Usually I'm working on app logic, so I might go weeks or occasionally months without touching any UI code.
This is a very interesting point, because my experience is quite the opposite.
Most of the time changes to the apps that I typically worked on (ERP/CRM platforms) involved both DB migrations, as well as back end and front end work. And with the front end, changes to the logic almost always resulted in changes to the template, even if only within a single component. The only exceptions to this were validation changes (changed logic only) or visual bugs (changed template only).
I wonder what qualities of the system design this points towards, apart from coupling.
Yeah, it's very subjective - the above has been my experience, but I wouldn't argue that it will necessarily reflect anyone else's.
But for why I go so long without touching the UI code, it's just because the project is a 3D voxel game and there's a lot of big complicated parts to work on that don't involve any HTML UI.
I just had to do this in React, and you're correct in that it makes you write logic around the lifecycles in ways that feels like I'm abusing their lifecycle methods. It's a lot of the reason Framer Motion and React Transition Group exist.
However, seeing the way Svelte does it sounds like a dream. I wish that could've been all I reasoned about last week.
It is actually not that hard in CSS plus vanilla JS using stuff like the `animationend` event (https://developer.mozilla.org/en-US/docs/Web/API/Element/ani...). Of course svelte provides a much easier interface, then having to have to deal with event listeners.
given that Svelte aims to be mainly pre-processed, how hard is it to combine it with more real-time solutions like Vue for instance? (you mention that you migrated from Vue2)
is it possible to use Svelte more for client-only or client-mainly views, and use other solutions for stuff that communicates more with the back-end? or do they get into each other's way?
The important difference to note compared to React, is that Svelte doesn't virtualize the DOM. It works in the same way vanilla JS works when it comes to DOM manipulation.
Even though it is compiled, you are still working closer to the browser. You can still use all vanilla JS DOM manipulation methods in your code and it will work as expected. Which is an enormous advantage over React, at least for me.
One thing I think the author overlooks: the appeal of Svelte's built-in animations and transitions is that they work correctly when the element's lifecycle is being managed by Svelte. E.g. with code like this:
When `showFoo` changes to false, Svelte will first play a flyout transition and then remove the element from the DOM, and it will correctly handle things if `showFoo` toggles back to true again before the flyout finishes, etc. You could do the same thing with CSS animations, but it would be hairy and you'd need to learn more about svelte internals than you probably want to.