←back to thread

Svelte 5 Released

(www.npmjs.com)
415 points begoon | 6 comments | | HN request time: 0.993s | source | bottom
Show context
sansseriff ◴[] No.41890232[source]
Svelte 5 has been very nice to work with over the past few months. Yes, runes require you to think more carefully about lifecycles and updates. And you may end up writing a little more code initially than with svelte 4. But it serves you better in the long run with complex apps. I found a process for gradually turning a simple app into a more complex one that works for me. I iteratively move $state() runes out of .svelte files and into .svelte.ts files where I build a more abstract data-oriented structure for my app from a series of mutually linked classes. Then those runes can be re-imported into the .svelte files, or used and updated wherever you need. If you plan it right, I think it avoids the need for heavy redux-like state management. (at least I think so. I haven't worked with redux much myself)
replies(4): >>41890939 #>>41891144 #>>41891258 #>>41893765 #
jwilber ◴[] No.41891258[source]
Just my personal opinion: I love svelte for small projects but the whole runes rewrite just feels so much less ergonomic. A step in the direction away from the simplicity that drew me to svelte in the first place.

That said, there is backwards compatibility with the older syntax, so this isn’t a dealbreaker, and the team does a good job of explaining the reasons behind their selected design patterns.

(Interestingly, I’ve felt the opposite with react lately - they’ve been making the dx simpler).

replies(1): >>41892076 #
cageface ◴[] No.41892076[source]
This is more or less where I’ve landed lately. There are some things I really like in Svelte and Solid but not enough to overcome the massive ecosystem advantage React has.
replies(1): >>41893701 #
1. dtj1123 ◴[] No.41893701[source]
I never understood the ecosystem argument as applied to Svelte. Vanilla js libraries integrate with it pretty much perfectly, meaning you don't need a Svelte port of a given library. The ecosystem is effectively huge.
replies(1): >>41894135 #
2. cageface ◴[] No.41894135[source]
There aren't very many good modern, maintained vanilla js libraries. But for just about anything I need in React I can find something polished and well supported that just works.
replies(1): >>41918633 #
3. RadiozRadioz ◴[] No.41918633[source]
I'm not sure I understand. What types of libraries? When I think of libraries, I think of ExpressJS, lodash, JQuery, left-pad, etc. There are absolute tonnes of vanilla JS libraries.

I've rarely used React, are you talking about React-specific libraries? I find it hard to believe that there are more maintained React libraries than vanilla JS libraries.

replies(3): >>41921606 #>>41921972 #>>41990991 #
4. keyserj ◴[] No.41921606{3}[source]
I don't have a strong opinion on the whole, but as someone who's been building a diagramming app for 2+ years, I've found react-flow to be the most solid free & open-source node-based diagram component, by far. At least in terms of quantity/quality of features and UX/DX. Though admittedly I haven't thoroughly looked at alternatives in about a year.

It basically singlehandedly convinced me that the ecosystem was worth going with react when I started my project, despite really enjoying svelte.

5. cageface ◴[] No.41921972{3}[source]
All those libraries also work in React of course. The only vanilla js libraries that don't work well with React are UI libraries that assume they can control the DOM. But I can't think of many of those I'd prefer to the many excellent React UI libraries.
6. satvikpendem ◴[] No.41990991{3}[source]
Framer Motion, react-three-fiber, react dnd, just a few that come to mind.