Hacker News Reader

Comment by Vanit | Hacker News Reader

I'd really like to hear more from Svelte devs about what non-happy paths look like. I specialise in React.js and there are any number of escape hatches to make sure you can get something working just the way you want. What I fear about Svelte is getting to 95% complete and finding the one obscure thing a stakeholder will not budge on is not possible.

View on HN

Svelte is much closer to regular JavaScript. There really isn't anything you can't do with svelte that you cannot do with vanilla JavaScript. Everything is JavaScript in the end, but react forces you to go through their framework and that's why you need escape hatches. You just don't need that with svelte at all. It's wild when you get that part of it. The reactive part of svelte is just adding stuff during the compile process that at runtime does the DOM manipulation, rather than figuring that entire sequence out in runtime.

Yeah, this matches my experience moving from React (5+ yrs) to Svelte (2 shipped 3 month projects over the last couple of years at this point). Svelte clearly lacks the massive community support of React but I've found it easier to get by on my understanding of JS and the DOM when I get stuck. I've heard lots of gripeing from other React devs about the $ syntax and a few other things around lack of JSX but that feels like really small change when compared to the flexibility Svelte allows around things like transitions (no more hooks!).

I have been using Svelte for a couple of years now on small and large projects and I have yet to hit one of those "5%" problems that I used to hit routinely in larger React projects. Svelte mostly stays out of your way, unlike React where it everything is more ... forced ... in my opinion.

I have a lot of experience with React, Vue, and Angular and I have moved completely over to Svelte if the client will allow. Since it uses normal Javascript, normal HTML, and normal CSS it also doesn't seem to suffer as much regarding the ability to find other people to support it. If they can use normal JS, HTML, and CSS the "Svelte" part of it can be learned in a couple of hours max.

Early on, there was a custom component shortage, but it is so easy to wrap plain vanilla JS components in Svelte components that this is has mostly disappeared as well.

If I where going to point out anything negative about it, I would say that if you are used to developing by just plugging in pre-built components (very common in React development) then it won't be as easy.

Using Svelte for a quite large codebase.

Couple years ago, there was lot of hiccups especially with TS support or the vscode plugin. It's much better now.

There are some patterns to know to work around some reactivity issues with component reuse but overall, and still some TS issues with vscode (extra warnings due to lack of understanding of component context) but it's still ok.

The biggest drawback of Svelte is not the tech itself, but the lack of a well developed ecosystem of components, design systems, etc. You'll probably end up implementing many components yourself... whether it's a good thing is left for discussion.

The one 5% thing I’ve run into is a lack of proper generic component props when using Typescript.

Granted, that’s a rather advanced topic, but I miss having a <Component<MyType>> where all the type checking “just works”.

It’s not a dealbreaker - more like just something I noticed coming from the React world.

Reply on news.ycombinator.com