Svelte5: A Less Favorable Vue3

64 pointsby rxliuli2 months ago

13 comments

gg22222 months ago

To the author: Yes, do consider SolidJS seriously. I find that its reactivity system is simple and the easiest to reason about, with none of the messiness and constant changes to "the best practice way to do things" like React has gone through the years.SolidJS seems designed right so that it doesn't need so many major revisions and it feels quite stable.It feels like an evolved React that is simpler to use.Also its signals and stores can be used in normal .ts files, so it is easier to create re-usable "stores".edit: BTW haven't been following Svelte but it's already version 5? I thought it was the newest framework.

评论 #43299874 未加载

评论 #43299243 未加载

评论 #43299395 未加载

评论 #43299890 未加载

评论 #43300278 未加载

评论 #43299663 未加载

评论 #43299814 未加载

seanwilson2 months ago

My current preference in Vue 3 (with the Composition API) but using JSX (which is generally only mentioned with React) instead of Vue HTML templates (e.g. <a href="https://vuejs.org/guide/extras/render-function#v-for" rel="nofollow">https://vuejs.org/guide/extras/render-function#v-for</a>, <a href="https://vuejs.org/guide/extras/render-function.html#jsx-tsx" rel="nofollow">https://vuejs.org/guide/extras/render-function.html#jsx-tsx</a>) with TypeScript. Correct me if I'm out-of-date, but my understanding is Vue is more batteries included, and state management is more concise. I strongly prefer JSX :- I can write for-loops, conditions, etc. in the same language I write my logic in with the same TypeScript and (Vscode) IDE support (e.g. refactoring, formatting, error reporting) vs using a special template language + IDE plugin.- I find HTML templates really ugly and harder to read in that your dynamic logic code gets lost inside the static markup and presentation code e.g. `<li v-if="items.length > 2" v-for="{ id, text } in items" :key="id" class="card card-body fw-bold small"> {{ text }} </li>` vs `{items.length > 2 && items.map(({ id, text }) => (<li key={id} class="card card-body fw-bold small">{text}</li>))}` (still quite ugly but most of the logic is on the outside now).- I can easily assign chunks of HTML to variables or generate HTML snippets via concise functions in regular TypeScript instead of being forced to create a new verbose component via HTML templates each time e.g. the arrow function above can be assigned to variable and reused. HTML templates feel very limiting in comparison.It's sometimes awkward finding the JSX syntax (like for using Vue slots), but this is more because it's less common.Would be curious of others who have tried this Vue 3 + JSX combination!

评论 #43299369 未加载

评论 #43299550 未加载

评论 #43299555 未加载

评论 #43299843 未加载

评论 #43299207 未加载

nasso_dev2 months ago

As a "Svelte5 enthusiast", I didn't stop reading and I wasn't particularly surprised... All frameworks/libraries/languages have quirks. I was perfectly aware of every single point listed yet I still enjoy Svelte 5 a lot more than 4.> Form Components Are Uncontrolled by Default, Which Can Cause Issues > [...] > What happens if you remove the bind? One-way binding? No, it only sets the initial value, then the input's internal state takes over, contrary to expectations.I strongly disagree. This is literally how HTML works. This makes forms with default values MUCH less awkward to author.

vlod2 months ago

You know I've fallen in love with Svelte (specifically Sveltekit). I would strongly recommend giving it a shot.I'm an experienced React dev and thought I'd try something new for a side project. I tried and liked SolidJS (and agree with a lot of the positive comments here) and Ryan seems super knowledgeably about everything front end. (It was a close second).However I wanted to give Sveltekit a shot as it's so different to React (and SolidJS is not).For me it seems to put me back to those good olde days (insert rose tinted glasses and violin music), where web dev was just html, css and js/jquery (yes, it was hard for it not to turn into spaghetti). However I coded like I was being chased by demons and loved every minute of it.I don't get that with React. Having to fix stupid race conditions and constant rendering glitches gets to become grating.Sveltekit (with it's signals approach, like SolidJS) sort of puts me back there. It's all just html, css (or tailwind), simple js and event driven.You set up some state at the top <script> block and have loaders/actions (superforms is great) in external files. To me it all seems super intuitive.

authorfly2 months ago

Thank you to author for pointing out some negatives here.The 5th version made two "non-error", but ergonomic changes, for the sake of larger code bases and standard formats over quick, yet reliable, reactive and testable code (which first attracted me to svelte): - the need for getters and setters when using $runes in functions; this is a waste of time and almost always unnecessary in the contexts in which one uses small store classes. Not that Svelte 4 was better, it was different.. in a pinch, I'd take 4 though. - using folders for routing and using standard page.svelte.js and server.svelte.js naming for everything; it clutters your IDE file list. You could say it's good practise, but limiting to one component per file also causes more files in some cases than multiple components per file (as is possible in React)Despite all this, Svelte 5 introduces $writable, which is kind of for the use case of one-off simple state - which doesn't need getters/setters - so the whole thing doesn't feel that consistent.I don't mind using consistent runes - that is a bit of boilerplate, but makes it easier to reason about. I still love the reactivity of using bind (like Vue) and using $effect with it automatically figuring out what to do without the footguns of Reacts useEffect. I love that I can just start writing files and routing will work, css can just go there without a node module to process it.Increasingly, I've realised React is probably going to remain my number 1: - Recent changes are mostly just shorthands to reduce boilerplate - Mobx has got state down - Hooks have footguns, but I know them - The eco-system is still unmatched - `use` and other statements allowing async loading (like other recent shorthands) is helpful, a lot of my components used to have boilerplate to do async stuff, and it took effort to make failure cases/loading work well. This pairs very well with server functions too.

评论 #43299580 未加载

pablopang2 months ago

All the points in the gist are basically wrong...I will comment after point to point as soon as I'm back at the desk

评论 #43299286 未加载

Taterr2 months ago

As a new comer to JS frameworks Svelte 5 convinced me to use Vue instead.I think Svelte has a nicer template syntax and the reactivity is cleaner is some cases, but it feels like there's no "best practice" or "recommended" patterns in a lot of common cases and I don't have the confidence to make something that won't suck later.Vue has been more stable for longer so it's easier to find dozens of examples of the thing you're trying to do with less argument over how to do it, and LLMs seem to produce much better Vue code.

评论 #43310778 未加载

pjmlp2 months ago

As old timer I have framework fatigue.It is either plain ASP.NET MVC, Spring or Next.js, depending on the programming language, and that is it.

评论 #43299913 未加载

评论 #43299502 未加载

tglide2 months ago

> Runes Only Work in Svelte Components or .svelte.ts FilesThis is like complaining that types only work in .ts files> Hooks Using Runes Must Wrap State in FunctionsThis is on purpose, as you know. They want reactivity to be explicit. The benefit of runes is, that if you like Vue and Solid so much, you can literally create their reactive primitives in Runes, and it works.> Classes as First-Class Citizens for Runes... or Not?This entire section is weird. The title complains about classes, but then the second code snippet is a function back again. And the third is also equally weird, why would you ever need that.> Svelte Templates Include Features That Cannot Be Implemented in JavaScriptThis one I don't know sufficiently about. I'll let others argue about it. But I do think this was already present before> Form Components Are Uncontrolled by Default, Which Can Cause IssuesSame here, Svelte always had this behavior. As you also state, this is present in other frameworks, such as Vue itself, which you're promoting as better than Svelte> EcosystemIf you want someone to point out the issues people had when migrating to Vue3, and still have to this day, sure. Every framework really, when they go through such a big change.> Community ResponseCriticism is fine. But a lot of the things have been discussed over and over tbh, and a lot of it is poorly structured, e.g. saying "svelte is react now", which just brings noise to the table. I've personally seen a lot of other criticism which has led to action being taken.As a proof of that, recently here in hacker news there was a post criticizing Svelte 5. It is now mentioned on this PR as a change for it <a href="https://github.com/sveltejs/svelte/pull/15469">https://github.com/sveltejs/svelte/pull/15469</a>I do criticize things in Svelte as well, e.g. I do like the patterns for passing reactivity through boundaries, but I do think it needs to be well documented on how to, as people can get a bit lost. Or maybe some utilities shipped to it. But I don't personally like `ref` and `createSignal`. They come with their own issues.

评论 #43300423 未加载

teekoiv2 months ago

I very much agree with the overall thesis of the post. Runes are just irksome in subtle ways.One big point that the post misses, is that the Class escape hatch for runes is incompatible with constructor-set parameters.Say you have a class that wraps a HTMLElement which you set in the constructor. This doesn't work:<pre><code> class Wrapper { dom: HTMLElement = $state() constructor(el: HTMLElement) { this.dom = el } } </code></pre> as TypeScript throws an error about `Type 'undefined' is not assignable to type 'HTMLElement' for the $state()`. You could fix it by eg. `$state(undefined as unknown as HTMLElement)` but that's dumb. Interesting enough you could do something like:<pre><code> class Wrapper { dom: HTMLElement constructor(el: HTMLElement) { let d = $state(el) this.dom = d } } </code></pre> Moreover, Vite/esbuild mangles class-field parameters with esnext into constructor-set parameters as they are just more versatile. So the original code becomes something like:<pre><code> class Wrapper { constructor(el: HTMLElement) { this.dom = $state(el) } } </code></pre> Which is incompatible with rules of runes. I did whine about this already <a href="https://github.com/sveltejs/svelte/issues/14600">https://github.com/sveltejs/svelte/issues/14600</a> but so far no clear answer

评论 #43306818 未加载

评论 #43299755 未加载

评论 #43299428 未加载

KolmogorovComp2 months ago

All these irks to avoid redraw()ing when needed

bhaney2 months ago

I didn't even know there was a Svelte 2

评论 #43306781 未加载

评论 #43299144 未加载

DannyBee2 months ago

I use svelte a lot, because react's rules and such tend to drive me nuts.It's not that i can't get used to them, it's that i just don't want to have to deal with them when they exist mainly because it made it easier to implement, not easier to use. It just gets the balance wrong for me. To each their own. I've met people who love them.Some of these arguments resonate, some don't.In the case of Svelte 5, it is (unfortunately) easier to understand if you look at the post-compiled code. Which often makes it totally obvious what is going on and what works or doesn't. Which is not great. It also often issues error messages that remind me of C++ 20 years ago in their unhelpfulness, before a lot of time was spent making the error message better. For example, I walked the tanstack folks through an example of generated code, because totally reasonable and smart people have trouble wrapping their head around what happens under the covers and what the error messages mean: <a href="https://github.com/TanStack/table/pull/5943">https://github.com/TanStack/table/pull/5943</a>IMHO, trying to teach people this level of idiosyncrasy is a bit silly, and regardless of theoretical benefit, seems unlikely to work long term. It feels like there is not enough compiler help here to make it feel really magical, though at a glance it looks like their good be. I hope they adjust this.I also agree the community is frustrating to deal with a not insignificant amount of time. There are lots of good people, mind you, but also lots of "you are holding it wrong", etc. I reported what is a blazingly clear bug (once you know it exists):Svelte5 ships two incompatible Snippet types because of the use of unique symbols for SnippetReturn. Different unique symbols are never compatible in TS.So these two SnippetReturn types (which are then used in the Snippet type in each file):<pre><code> rg "SnippetReturn.*unique symbol" types/index.d.ts 268: const SnippetReturn: unique symbol; src/index.d.ts 271:declare const SnippetReturn: unique symbol </code></pre> are incompatible.The error message you get if you trigger this is .. hilarious and hurts your brain (the two syntax highlighted types in this picture that look 100% identical are not compatible, one is from types/index.d.ts, one is from src/index.d.ts) - <a href="http://tiny.cc/wnkc001" rel="nofollow">http://tiny.cc/wnkc001</a>I also reported a bug to the typescript folks about the error message.The difference in how the triagers handled it were night and day. Amusingly, the svelte side has a bog simple and obvious fix - share the (typeof'd) unique symbol type between the two files so there are not two unique symbols. 5-10 line fix, at most. You just have to decide how much to share (IE just SnippetReturn or the whole Snippet type, or what). In the vast majority of projects i work on, someone would look at this, go "oh shit yeah we fucked that up whoops", fix it with the 10 line fix, and move on. There is absolutely zero reason or advantage to have the code like this. It is an obvious bug, it should be fixed, it's not worth a lot of time. But after many messages, I actually gave up on the svelte bug. To be fair i clearly got frustrated but man not a great experience ....Compare to typescript - the typescript side requires work to issue a good error message here, and more thought.Yet I'm in the midst of finishing a changelist on the typescript side to improve the compiler error message, because the experience dealing with the community was so much better.Plenty of people I talk with have some story like this with Svelte :(I will say, some of the other complaints here seem weird. SVAR grid works fine for tables. It supports variable heights and widths for columns. Maybe they specifically want unstyled tables? I dunno.The usual ui complaint for svelte is not grid, but good tree components. They also pick a few things they admit are not unique to svelte, and exist in other popular frameworks. Seems like a weird shotAlso, complaining about file naming and "unpleasant code infection" is also weird.The other arguments seem much stronger - the lawyer in me wants to yell "put your arguments in order of strength, and remove the weakest ones. Quality wins over volume, and most people are not going to read the whole thing". If i'm really trying to make an effective argument, i make short ones, not long ones. On HN i'll do longform because i don't care enough most of the time to spend the time editing to make it effective. But if i was really trying to be convincing i would make much shorter ones.In any case, i think some of this is reasonable. But having spent lots of time with frameworks, i'll keep using Svelte5, but I do hope things improve. I feel like i'd spend the same amount of time with other idiosyncrasies if i moved to Solid.

评论 #43300453 未加载