6 ms·

Svelte5: A Less Favorable Vue3

64 points by rxliuli 2y ago

deleted 2y ago
[deleted]
gg2222 2y 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.
- zwnow 2y ago
  >> SolidJS seems designed right so that it doesn't need so many major revisions Which is exactly what is said about every framework
  - Wazako 2y ago
    It's different with solid-js, which is more of a library than a real framework. The solid-js surface is relatively small, the jsx / css is identical to the native, the Hook simply builds the DOM once. solid-js therefore brings above all a createSignal that adds an observer where it is called in the DOM to directly update the DOM accordingly. You might think of solid-js more as a signal primitive than a real framework.
    - gg2222 2y ago
      Exactly. SolidJS api itself is very small, there is not much you actually have to learn. This makes it simple to reason about and at the same time gives you the confidence to wield it, which makes it actually feel more powerful.
    - zwnow 2y ago
      Its funny because "its different with [insert framework]" is also said about every new framework ever.
    - bossyTeacher 2y ago
      May I remind you that React was originally a library. Didn't stop it from morphing into...whatever it is now
- tglide 2y ago
  > SolidJS seems designed right so that it doesn't need so many major revisions and it feels quite stable. lol https://github.com/solidjs/solid/discussions/2425 https://github.com/solidjs/solid/discussions/2425
  - gg2222 2y ago
    Yes I know SolidJS 2.0 is coming. I said "it doesn't need so many major revisions", key word being "so many". (Telling myself: damn should of put that in my original comment cause of course someone's gonna comment that.)
    - dartos 2y ago
      These frameworks have so many versions over time because the web, browsers, and people’s expectations of the capabilities of websites are a moving target. Over time you’ll see many major revisions as you do in every other framework in existence.
  - 0xblinq 2y ago
    It’s major version 2. Compare that to the amount of major (and really breaking, like Vue) for all other frameworks. LOL
    - tglide 2y ago
      Solid is much more recent, of course it has less major versions.
- mkl 2y ago
  Svelte dates back to 2016: https://en.wikipedia.org/wiki/Svelte#History https://en.wikipedia.org/wiki/Svelte#History
  - gg2222 2y ago
    Yes, so actually SolidJS is newer.
    - yurishimo 2y ago
      That’s technically true but Svelte had a major paradigm shift in v4 and an extension of that paradigm in v5. The name is older, but the underlying code is newer.
- rizky05 2y ago
  [dead]
- sesm 2y ago
  Looked at SolidJS, it's primary mechanism is signals, which are essentially runtime edit maps. They have the same downside as all other types of edit maps - programmer needs to compose them manually, which becomes messy very quickly with loops and conditions.
  - baxuz 2y ago
    What are edit maps?
    - sesm 2y ago
      Mapping between reactive variable and DOM element. I first heard this term in Million.js docs, but it explains very well what most 'reactive' frameworks are doing. For example, a Signal creates the mapping at runtime on first render.
- 0xblinq 2y ago
  Solid is so underrated. The simplicity and the power it brings is so good. I’ve also used SolidStart for a project and it’s by far the best meta framework I’ve tried so far. Again, simplicity, power and extensibility.
  - flessner 2y ago
    SolidJS is extremely well crafted signaling, I like it. However, the SolidJS ecosystem falls behind when building a full web application: The router is okay? Metadata is very separate... and SolidStart isn't pulling it all together in the way it should. Working with async is also a mess. This makes it feel like you're having to learn 3-4 entirely separate systems.
- rxliuli 2y ago
  Yes, what I want might be some better React, like JSX, but I don't like the complexity introduced by hooks and the binding of Next.js.
  - bossyTeacher 2y ago
    The best time to learn React and use it was while it was small and literally just a library.
bhaney 2y ago
I didn't even know there was a Svelte 2
- elaus 2y ago
  I think people usually only talk about "Svelte", but that doesn't really imply a "Svelte v1". So it's very plausible to miss the existence of major versions of not working with it.
- ilrwbwrkhv 2y ago
  Earlier svelte was: let x = 10 <div>{x}</div> x = 12 now the div changes. It had its own unique, clean way of doing things and had its own identity. Now they went down the route of looking like exactly like the others while doing everything much worse. Of course a bunch of people keep telling me that yeah, this is much better. But they are brainwashed.
authorfly 2y 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.
- d1sxeyes 2y ago
  > 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 Yes, but then you can just use a class. > using folders for routing and using standard page.svelte.js and server.svelte.js naming for everything This wasn’t introduced with Svelte 5, this is SvelteKit. > Despite all this, Svelte 5 introduces $writable No it doesn’t? Do you mean $state()?
  - rxliuli 2y ago
pablopang 2y 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
- agnishom 2y ago
  This kind of enthusiastic debate is why I love the internet /semisarcasm
  - atypeoferror 2y ago
    Give them time, it’s only been 11 hours. Now I just want to hear about the trip back to the desk
    - pablopang 2y ago
      You know, on Saturday I generally spend my day with my family rather than answering snarky comments. But since I have some time now let's get down to the answer: > Runes Only Work in Svelte Components or .svelte.ts Files Yes and this is actually a positive thing: you want the compiler to touch a very contained part of your application, when you know you can expect magic. This also allow us to be more "aggressive" in the transformation since we know regular js libraries will not be affected by it. > Hooks Using Runes Must Wrap State in Functions This is true for svelte, Vue, solid and whatever signal based framework: the difference? Other frameworks can't deal with primitive values so you feel like you have to do extra work in svelte. In reality you can actually build both Vue and solid styles in svelte (the opposite is not true). $state({ value: "myval" }); if basically Vue ref. > Classes as First-Class Citizens for Runes... or Not? You start talking about classes and then complain that pojos don't have the same treatment? Those are two very different things, and again, it was a specific design choice...it might be a quirk that you have to know about (that the compiler literally highlight for you) but it serves as a guardrail for you to write less bug prone code. P.s. as said above you can actually build a ref function a la Vue pretty easily and you can use your ref function just like in Vue if you really want this behavior. > Svelte Templates Include Features That Cannot Be Implemented in JavaScript This is just blatantly false: you can test a bindable props by passing in state as props and that's literally it. If you want you can do ```ts const props = $state({ value: "" }); render(Component, { props }); ``` or if you want to have a literal prop you can just use getters and setters ```ts const value = $state(""); render(Component, { props: { get value(){ return value; }, set value(new_value){ value = new_value; } }}); ``` > Form Components Are Uncontrolled by Default, Which Can Cause Issues As you've said this isn't specific to svelte...the controlled nature is specific to react. Why this would be the right thing? Most of the times having an uncontrolled form is much better and you can sync the state on submit or even better just use normal forms with enhance and sync the state on the server by getting progressive enhancement for free. And if you need it to be controlled, you have the tools to do it. > Small Ecosystem If you search for svelte specific packages you will certainly find less than react...but you can literally just use any JS package with ease in svelte. That said even for the things you describe in the post it seems you are a bit nitpicking: there a router but not an in memory one, there's shadcn/svelte but it has problems with shadow Dom...the rest you probably just need to search better: `virtua` is a wonderful virtual list, LayerChart a wonderful chart library. > Community Response We are definitely trying to work to reduce the apparent complexity...a lot of people looked at svelte 5 superficially and deemed it too complex. The same people after trying it for good agreed that is not complex at all and a huge step forward for composability and performance. Just try it out, trust us. That said: despite almost all the point being imho invalid this is still a good post because it show us where we can improve the docs and the explainers to ease out this experience. Peace out
seanwilson 2y 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. https://vuejs.org/guide/extras/render-function#v-for https://vuejs.org/guide/extras/render-function#v-for, https://vuejs.org/guide/extras/render-function.html#jsx-tsx https://vuejs.org/guide/extras/render-function.html#jsx-tsx) 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!
- apatheticonion 2y ago
  Awesome! How do you use Vue with tsx/jsx?
  - zwnow 2y ago
    When you set up a project it asks you if you want to use jsx afaik
  - seanwilson 2y ago
    This documentation is pretty good for this, it's a supported option rather than something you have to hack in but I rarely hear it mentioned: https://vuejs.org/guide/extras/render-function.html#jsx-tsx https://vuejs.org/guide/extras/render-function.html#jsx-tsx Edit: Yes, oops, wrong link.
DannyBee 2y 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: https://github.com/TanStack/table/pull/5943 https://github.com/TanStack/table/pull/5943 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): rg "SnippetReturn.*unique symbol" types/index.d.ts 268: const SnippetReturn: unique symbol; src/index.d.ts 271:declare const SnippetReturn: unique symbol 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) - http://tiny.cc/wnkc001 http://tiny.cc/wnkc001 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 shot Also, 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.
pjmlp 2y 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.
- brainzap 2y ago
  vuejs is 10 years old
  - pjmlp 2y ago
    And in 10 years I only took part in a single project using it, back in 2019. I would put Vue on third place of FE JavaScript frameworks.
  - Etheryte 2y ago
    And it has changed a lot in that time. The code we wrote in 0.x is very different from the paradigm of 3.x, and while I agree it's largely a change for the better, it's still a chore to keep up with it if that isn't the only thing you do.
    - yurishimo 2y ago
      The change from V2 to today is much smaller. So small in fact that the paradigm of v2 is now a simple extraction under the hood of v3. V2 came out in 2016. The number of apps written before v2 is minuscule compared to even newer JS frameworks of today. I would argue that Vue has been one of the most stable frameworks in JS world and that stability and focus on simplifying the state mental model (aka, it just works) has been the reason for Vue’s continued steady growth across organizations and projects of all sizes.
      - Etheryte 2y ago
        I'm not really sure if I can agree on stability. For all its warts and flaws, you can largely still write React 18.x the same way you wrote React 0.x. There's many new features and fancy tools in your pocket, but underneath it all, you can take the knowledge you had of 0.x and go straight to writing 18.x. It might not be whatever is the current vogue best practices, but it will work. While React has had many breaking changes over the years, I would argue that all of them are fairly minor, whereas Vue, Angular and now Svelte have introduced big breaking changes. Stability wise I feel like React comes out on top in that regard. I do agree that Vue is clearly the better paradigm, but unfortunately it's still very much lagging behind React in terms of adoption. I think big breaking changes might have a considerable part in that, it's hard to sell that upwards.
teekoiv 2y 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: class Wrapper { dom: HTMLElement = $state() constructor(el: HTMLElement) { this.dom = el } } 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: class Wrapper { dom: HTMLElement constructor(el: HTMLElement) { let d = $state(el) this.dom = d } } 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: class Wrapper { constructor(el: HTMLElement) { this.dom = $state(el) } } Which is incompatible with rules of runes. I did whine about this already https://github.com/sveltejs/svelte/issues/14600 https://github.com/sveltejs/svelte/issues/14600 but so far no clear answer
- hmry 2y ago
  Use $state()! to fix the undefined is not assignable error.
- beremaki 2y ago
  > You could fix it by eg. `$state(undefined as unknown as HTMLElement)` but that's dumb I think the generic is what you are looking for class Wrapper { dom = $state<HTMLElement>(); constructor(el: HTMLElement) { this.dom = el; } } the dom property will still be HTMLElement | undefined, if the 'undefined' bothers you have to add an exclamation mark and write "$state<HTMLElement>()!"
  - Etheryte 2y ago
    That's still a manual type assertion though, and if a regular usage pattern demands one, then the library is doing it wrong. Regardless of how you annotate it, every manual override reduces the effectiveness of the type system.
tglide 2y ago
> Runes Only Work in Svelte Components or .svelte.ts Files This is like complaining that types only work in .ts files > Hooks Using Runes Must Wrap State in Functions This 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 JavaScript This 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 Issues Same 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 > Ecosystem If 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 Response Criticism 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 https://github.com/sveltejs/svelte/pull/15469 https://github.com/sveltejs/svelte/pull/15469 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.
- rxliuli 2y ago
  > This is like complaining that types only work in .ts files It reminds me that React hooks must start with "use," which is a very strange thing, no matter how they explain it. Additionally, I mention this because Vue 3/SolidJS, which also uses proxies, does not require you to use special file names; you can use it in any regular JS. > This 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. It just adds extra boilerplate work. Unless you use a custom Proxy to wrap the runes state, I don't think it's possible to implement the Vue Composition API, and if you do that, there will be a double proxy, and even $state.snapshot won't save me. > 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. Because the escape hatch left by svelte5 is very strange and seems inconsistent, in the four situations I listed, svelte5 can only make half of them effective, while vue3 and similar frameworks can make them all work properly. > Same 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 Yes, it has always existed, but svelte5 still hasn't addressed it. Also, I don't think vue3 is better than svelte4 because I believe their APIs are very different and not easy to compare. The runes API of svelte5 looks very familiar, and I will certainly try to compare them.
KolmogorovComp 2y ago
All these irks to avoid redraw()ing when needed
Taterr 2y 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.
- vlod 2y ago
  >I don't have the confidence to make something that won't suck later. Well that's just development right there! Sucking for a long period of time is 'The Way', the path to greatness, which devs (IMHO) over-rely on LLM to shortcut. However I get your point. lol
nasso_dev 2y 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.
vlod 2y 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.

64 points by rxliuli 2y ago

deleted 2y ago

[deleted]

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.

zwnow 2y ago
>> SolidJS seems designed right so that it doesn't need so many major revisions Which is exactly what is said about every framework
- Wazako 2y ago
  It's different with solid-js, which is more of a library than a real framework. The solid-js surface is relatively small, the jsx / css is identical to the native, the Hook simply builds the DOM once. solid-js therefore brings above all a createSignal that adds an observer where it is called in the DOM to directly update the DOM accordingly. You might think of solid-js more as a signal primitive than a real framework.
  - gg2222 2y ago
    Exactly. SolidJS api itself is very small, there is not much you actually have to learn. This makes it simple to reason about and at the same time gives you the confidence to wield it, which makes it actually feel more powerful.
  - zwnow 2y ago
    Its funny because "its different with [insert framework]" is also said about every new framework ever.
  - bossyTeacher 2y ago
    May I remind you that React was originally a library. Didn't stop it from morphing into...whatever it is now
tglide 2y ago
> SolidJS seems designed right so that it doesn't need so many major revisions and it feels quite stable. lol https://github.com/solidjs/solid/discussions/2425 https://github.com/solidjs/solid/discussions/2425
- gg2222 2y ago
  Yes I know SolidJS 2.0 is coming. I said "it doesn't need so many major revisions", key word being "so many". (Telling myself: damn should of put that in my original comment cause of course someone's gonna comment that.)
  - dartos 2y ago
    These frameworks have so many versions over time because the web, browsers, and people’s expectations of the capabilities of websites are a moving target. Over time you’ll see many major revisions as you do in every other framework in existence.
- 0xblinq 2y ago
  It’s major version 2. Compare that to the amount of major (and really breaking, like Vue) for all other frameworks. LOL
  - tglide 2y ago
    Solid is much more recent, of course it has less major versions.
mkl 2y ago
Svelte dates back to 2016: https://en.wikipedia.org/wiki/Svelte#History https://en.wikipedia.org/wiki/Svelte#History
- gg2222 2y ago
  Yes, so actually SolidJS is newer.
  - yurishimo 2y ago
    That’s technically true but Svelte had a major paradigm shift in v4 and an extension of that paradigm in v5. The name is older, but the underlying code is newer.
rizky05 2y ago
[dead]
sesm 2y ago
Looked at SolidJS, it's primary mechanism is signals, which are essentially runtime edit maps. They have the same downside as all other types of edit maps - programmer needs to compose them manually, which becomes messy very quickly with loops and conditions.
- baxuz 2y ago
  What are edit maps?
  - sesm 2y ago
    Mapping between reactive variable and DOM element. I first heard this term in Million.js docs, but it explains very well what most 'reactive' frameworks are doing. For example, a Signal creates the mapping at runtime on first render.
0xblinq 2y ago
Solid is so underrated. The simplicity and the power it brings is so good. I’ve also used SolidStart for a project and it’s by far the best meta framework I’ve tried so far. Again, simplicity, power and extensibility.
- flessner 2y ago
  SolidJS is extremely well crafted signaling, I like it. However, the SolidJS ecosystem falls behind when building a full web application: The router is okay? Metadata is very separate... and SolidStart isn't pulling it all together in the way it should. Working with async is also a mess. This makes it feel like you're having to learn 3-4 entirely separate systems.
rxliuli 2y ago
Yes, what I want might be some better React, like JSX, but I don't like the complexity introduced by hooks and the binding of Next.js.
- bossyTeacher 2y ago
  The best time to learn React and use it was while it was small and literally just a library.

bhaney 2y ago

I didn't even know there was a Svelte 2

elaus 2y ago
I think people usually only talk about "Svelte", but that doesn't really imply a "Svelte v1". So it's very plausible to miss the existence of major versions of not working with it.
ilrwbwrkhv 2y ago
Earlier svelte was: let x = 10 <div>{x}</div> x = 12 now the div changes. It had its own unique, clean way of doing things and had its own identity. Now they went down the route of looking like exactly like the others while doing everything much worse. Of course a bunch of people keep telling me that yeah, this is much better. But they are brainwashed.

authorfly 2y 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.

d1sxeyes 2y ago
> 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 Yes, but then you can just use a class. > using folders for routing and using standard page.svelte.js and server.svelte.js naming for everything This wasn’t introduced with Svelte 5, this is SvelteKit. > Despite all this, Svelte 5 introduces $writable No it doesn’t? Do you mean $state()?
- rxliuli 2y ago

pablopang 2y 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

agnishom 2y ago
This kind of enthusiastic debate is why I love the internet /semisarcasm
- atypeoferror 2y ago
  Give them time, it’s only been 11 hours. Now I just want to hear about the trip back to the desk
  - pablopang 2y ago
    You know, on Saturday I generally spend my day with my family rather than answering snarky comments. But since I have some time now let's get down to the answer: > Runes Only Work in Svelte Components or .svelte.ts Files Yes and this is actually a positive thing: you want the compiler to touch a very contained part of your application, when you know you can expect magic. This also allow us to be more "aggressive" in the transformation since we know regular js libraries will not be affected by it. > Hooks Using Runes Must Wrap State in Functions This is true for svelte, Vue, solid and whatever signal based framework: the difference? Other frameworks can't deal with primitive values so you feel like you have to do extra work in svelte. In reality you can actually build both Vue and solid styles in svelte (the opposite is not true). $state({ value: "myval" }); if basically Vue ref. > Classes as First-Class Citizens for Runes... or Not? You start talking about classes and then complain that pojos don't have the same treatment? Those are two very different things, and again, it was a specific design choice...it might be a quirk that you have to know about (that the compiler literally highlight for you) but it serves as a guardrail for you to write less bug prone code. P.s. as said above you can actually build a ref function a la Vue pretty easily and you can use your ref function just like in Vue if you really want this behavior. > Svelte Templates Include Features That Cannot Be Implemented in JavaScript This is just blatantly false: you can test a bindable props by passing in state as props and that's literally it. If you want you can do ```ts const props = $state({ value: "" }); render(Component, { props }); ``` or if you want to have a literal prop you can just use getters and setters ```ts const value = $state(""); render(Component, { props: { get value(){ return value; }, set value(new_value){ value = new_value; } }}); ``` > Form Components Are Uncontrolled by Default, Which Can Cause Issues As you've said this isn't specific to svelte...the controlled nature is specific to react. Why this would be the right thing? Most of the times having an uncontrolled form is much better and you can sync the state on submit or even better just use normal forms with enhance and sync the state on the server by getting progressive enhancement for free. And if you need it to be controlled, you have the tools to do it. > Small Ecosystem If you search for svelte specific packages you will certainly find less than react...but you can literally just use any JS package with ease in svelte. That said even for the things you describe in the post it seems you are a bit nitpicking: there a router but not an in memory one, there's shadcn/svelte but it has problems with shadow Dom...the rest you probably just need to search better: `virtua` is a wonderful virtual list, LayerChart a wonderful chart library. > Community Response We are definitely trying to work to reduce the apparent complexity...a lot of people looked at svelte 5 superficially and deemed it too complex. The same people after trying it for good agreed that is not complex at all and a huge step forward for composability and performance. Just try it out, trust us. That said: despite almost all the point being imho invalid this is still a good post because it show us where we can improve the docs and the explainers to ease out this experience. Peace out

seanwilson 2y 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. https://vuejs.org/guide/extras/render-function#v-for https://vuejs.org/guide/extras/render-function#v-for, https://vuejs.org/guide/extras/render-function.html#jsx-tsx https://vuejs.org/guide/extras/render-function.html#jsx-tsx) 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!

apatheticonion 2y ago
Awesome! How do you use Vue with tsx/jsx?
- zwnow 2y ago
  When you set up a project it asks you if you want to use jsx afaik
- seanwilson 2y ago
  This documentation is pretty good for this, it's a supported option rather than something you have to hack in but I rarely hear it mentioned: https://vuejs.org/guide/extras/render-function.html#jsx-tsx https://vuejs.org/guide/extras/render-function.html#jsx-tsx Edit: Yes, oops, wrong link.

DannyBee 2y 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: https://github.com/TanStack/table/pull/5943 https://github.com/TanStack/table/pull/5943 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): rg "SnippetReturn.*unique symbol" types/index.d.ts 268: const SnippetReturn: unique symbol; src/index.d.ts 271:declare const SnippetReturn: unique symbol 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) - http://tiny.cc/wnkc001 http://tiny.cc/wnkc001 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 shot Also, 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.

pjmlp 2y 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.

brainzap 2y ago
vuejs is 10 years old
- pjmlp 2y ago
  And in 10 years I only took part in a single project using it, back in 2019. I would put Vue on third place of FE JavaScript frameworks.
- Etheryte 2y ago
  And it has changed a lot in that time. The code we wrote in 0.x is very different from the paradigm of 3.x, and while I agree it's largely a change for the better, it's still a chore to keep up with it if that isn't the only thing you do.
  - yurishimo 2y ago
    The change from V2 to today is much smaller. So small in fact that the paradigm of v2 is now a simple extraction under the hood of v3. V2 came out in 2016. The number of apps written before v2 is minuscule compared to even newer JS frameworks of today. I would argue that Vue has been one of the most stable frameworks in JS world and that stability and focus on simplifying the state mental model (aka, it just works) has been the reason for Vue’s continued steady growth across organizations and projects of all sizes.
    - Etheryte 2y ago
      I'm not really sure if I can agree on stability. For all its warts and flaws, you can largely still write React 18.x the same way you wrote React 0.x. There's many new features and fancy tools in your pocket, but underneath it all, you can take the knowledge you had of 0.x and go straight to writing 18.x. It might not be whatever is the current vogue best practices, but it will work. While React has had many breaking changes over the years, I would argue that all of them are fairly minor, whereas Vue, Angular and now Svelte have introduced big breaking changes. Stability wise I feel like React comes out on top in that regard. I do agree that Vue is clearly the better paradigm, but unfortunately it's still very much lagging behind React in terms of adoption. I think big breaking changes might have a considerable part in that, it's hard to sell that upwards.

teekoiv 2y 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: class Wrapper { dom: HTMLElement = $state() constructor(el: HTMLElement) { this.dom = el } } 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: class Wrapper { dom: HTMLElement constructor(el: HTMLElement) { let d = $state(el) this.dom = d } } 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: class Wrapper { constructor(el: HTMLElement) { this.dom = $state(el) } } Which is incompatible with rules of runes. I did whine about this already https://github.com/sveltejs/svelte/issues/14600 https://github.com/sveltejs/svelte/issues/14600 but so far no clear answer

hmry 2y ago
Use $state()! to fix the undefined is not assignable error.
beremaki 2y ago
> You could fix it by eg. `$state(undefined as unknown as HTMLElement)` but that's dumb I think the generic is what you are looking for class Wrapper { dom = $state<HTMLElement>(); constructor(el: HTMLElement) { this.dom = el; } } the dom property will still be HTMLElement | undefined, if the 'undefined' bothers you have to add an exclamation mark and write "$state<HTMLElement>()!"
- Etheryte 2y ago
  That's still a manual type assertion though, and if a regular usage pattern demands one, then the library is doing it wrong. Regardless of how you annotate it, every manual override reduces the effectiveness of the type system.

tglide 2y ago

> Runes Only Work in Svelte Components or .svelte.ts Files This is like complaining that types only work in .ts files > Hooks Using Runes Must Wrap State in Functions This 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 JavaScript This 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 Issues Same 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 > Ecosystem If 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 Response Criticism 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 https://github.com/sveltejs/svelte/pull/15469 https://github.com/sveltejs/svelte/pull/15469 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.

rxliuli 2y ago
> This is like complaining that types only work in .ts files It reminds me that React hooks must start with "use," which is a very strange thing, no matter how they explain it. Additionally, I mention this because Vue 3/SolidJS, which also uses proxies, does not require you to use special file names; you can use it in any regular JS. > This 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. It just adds extra boilerplate work. Unless you use a custom Proxy to wrap the runes state, I don't think it's possible to implement the Vue Composition API, and if you do that, there will be a double proxy, and even $state.snapshot won't save me. > 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. Because the escape hatch left by svelte5 is very strange and seems inconsistent, in the four situations I listed, svelte5 can only make half of them effective, while vue3 and similar frameworks can make them all work properly. > Same 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 Yes, it has always existed, but svelte5 still hasn't addressed it. Also, I don't think vue3 is better than svelte4 because I believe their APIs are very different and not easy to compare. The runes API of svelte5 looks very familiar, and I will certainly try to compare them.

KolmogorovComp 2y ago

All these irks to avoid redraw()ing when needed

Taterr 2y 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.

vlod 2y ago
>I don't have the confidence to make something that won't suck later. Well that's just development right there! Sucking for a long period of time is 'The Way', the path to greatness, which devs (IMHO) over-rely on LLM to shortcut. However I get your point. lol

nasso_dev 2y 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.

vlod 2y 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.