Hacker News new | ask | show | jobs
by lf-non 1073 days ago
I disagree. But I am someone who deals with frontend tech sporadically as opposed to spending all/most of my time working on UI.

I was excited about svelte, but have found that coming back to my svelte project after a month or two of not using it was arduous because of all the myriad language level things. There are just too many little svelte specific things to keep track of in head.

In contrast coming back to a react/vue project is much easier for me, because even if I forget something at the end of the day any vue-directive or react hook is just another js/ts api I can easily lookup.

In particular, I find the DX that volar+vscode offer in a project with vue3, composition API & pug templates to be better than anything else I have seen in the FE ecosystem in last 5 years.

I also don't find the enhancements for local reactivity to be major value additions because most of the times my state resides in a shared store. I find the vue reactivity model to be simpler to deal with because I can create shared stores which can be (deep) mutated from any component and it all just works seamlessly.

2 comments

I've done a lot of contracting jobs and I get to see a lot of codebases and had the exact opposite experience, Whenever I see react or vue code, and in particular react, I feel like I have to relearn everything because the combination of external state libraries and to top it with translation specific code and libraries makes it such that each code base is very different from the other. It almost feels like you are learning a new framework altogether. The other issue is not directly related but because there are so many external dependencies, there is this constant slog work to keep everything updated due to constant vulnerabilities that keep popping in our CI tool.

Familiarity wise Angular has been probably the easiest to jump into and maintain long term, but it is a pain to work with due to the amount of ceremony involved to do even the simplest of things.

Svelte codebases due to the very nature of Svelte are simpler and very straightforward to get into, there are some svelte specific things but they aren't too many of them and are simpler to reason about when compared to codebases built on hooks, and even worse are hooks in combination with junior Devs. It is very very easy to write bad react code and you see this way way too often. Most react code out in the wild is badly written, you don't see problems because the browsers and modern computers are performant enough to hide them away but you do notice as the codebase grows and you realize it too late that the very foundation was wrong.

I don't mind Vue and just see svelte as a nicer DSL over it.

You can create a shared store and mutate it from any component, not sure what’s missing there.
I was primarily saying that I find the DX of vue's reactivity to be more intuitive in the context of my application. I didn't intend to say there was something that was possible with vue which wasn't with svelte.

Last I checked (and things may have changed since) is that svelte didn't support transparent reactivity for deeply nested objects. So something like `$myStore.foo.bar = "baz"` wouldn't trigger a component update, you need to remember to use .set, .update etc. You could assign to local reactive variables but you couldn't assign to stores.

I am sure the library authors made these trade offs thoughtfully, I was just disagreeing with the blanket statement that Svelte is generally a major improvement over Vuejs.

This is true and is a fair point.
Or use a module context depending on your scoping needs. Agreed, not sure what the GP is talking about.