[HN Gopher] Svelte5: A Less Favorable Vue3
___________________________________________________________________
Svelte5: A Less Favorable Vue3
Author : rxliuli
Score : 50 points
Date : 2025-03-08 06:41 UTC (16 hours ago)
(HTM) web link (gist.github.com)
(TXT) w3m dump (gist.github.com)
| gg2222 wrote:
| 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 wrote:
| >> SolidJS seems designed right so that it doesn't need so many
| major revisions
|
| Which is exactly what is said about every framework
| Wazako wrote:
| 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 wrote:
| 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 wrote:
| Its funny because "its different with [insert framework]"
| is also said about every new framework ever.
| tglide wrote:
| > 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
| gg2222 wrote:
| 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 wrote:
| 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 wrote:
| It's major version 2. Compare that to the amount of major
| (and really breaking, like Vue) for all other frameworks.
|
| LOL
| tglide wrote:
| Solid is much more recent, of course it has less major
| versions.
| mkl wrote:
| Svelte dates back to 2016:
| https://en.wikipedia.org/wiki/Svelte#History
| gg2222 wrote:
| Yes, so actually SolidJS is newer.
| yurishimo wrote:
| 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.
| sesm wrote:
| 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.
| 0xblinq wrote:
| 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.
| rxliuli wrote:
| 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.
| bhaney wrote:
| I didn't even know there was a Svelte 2
| elaus wrote:
| 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.
| authorfly wrote:
| 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 wrote:
| > 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 wrote:
| > Yes, but then you can just use a class.
|
| Yes, but I immediately pointed out the oddities of the
| combination of class and runes below, which looks very
| strange and inconsistent.
|
| > Despite all this, Svelte 5 introduces $writable
|
| I don't know what this is.
| d1sxeyes wrote:
| > I immediately pointed out the oddities of the combination
| of class and runes
|
| True, and it is a bit weird, but you made it difficult to
| understand your point by talking about a function which
| creates and returns a class for some reason.
|
| It took me a second to work out you were the author of the
| original article, rather than OP by the way, didn't really
| understand properly for a moment.
| pablopang wrote:
| 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 wrote:
| This kind of enthusiastic debate is why I love the internet
| /semisarcasm
| atypeoferror wrote:
| Give them time, it's only been 11 hours. Now I just want to
| hear about the trip back to the desk
| seanwilson wrote:
| 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.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 wrote:
| Awesome! How do you use Vue with tsx/jsx?
| zwnow wrote:
| When you set up a project it asks you if you want to use jsx
| afaik
| seanwilson wrote:
| 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
|
| Edit: Yes, oops, wrong link.
| mcintyre1994 wrote:
| I think that link should be:
| https://vuejs.org/guide/extras/render-function.html#jsx-tsx
| apatheticonion wrote:
| Oh right, sorry I thought that was docs for the original
| vue-templates. Should have checked.
|
| Do you happen to know if I can I use my own bundler set
| up with this? (esbuild, rspack, etc?)
| stevage wrote:
| I prefer Pug with Vue3. Your example would be:
|
| ``` li.card.card-body.fw-bold.small(v-if="items.length > 2"
| v-for="{ id, text } in items" :key="id") | {{ text }} ```
|
| Personally I find this really readable. The HTML element is the
| most visible thing, then we get classes, then all the logic in
| parentheses. Then, standing by itself, the content. And we
| don't need any closing tag.
| luminarious wrote:
| Pug templates have been the most readable in my projects.
| Underappreciated imho, wish Astro also supported it.
| psychoslave wrote:
| Agree, but isn't the project very low in activity?
|
| https://github.com/pugjs/pug/activity
|
| That is not necessarily a bad thing, sometime stability is
| what matters the most. But here the last commit was removal
| of a security and bugs branch...
| seanwilson wrote:
| Yeah, regular HTML is overly verbose. Being able to compose
| JSX generating functions and using regular JavaScript logic
| for loops, conditions etc. wins out for me though because
| realistic HTML gets big and messy otherwise. Can you do
| something like this in Pug? (where the actual HTML would be
| more complex, so you'd want to split it up like this)
| const elToolbar = generateToolbar(toolbarItems) // returns
| JSX const elUserCards = users.map(user => <div
| class="card card-body fw-bold">{{ user.name }}</div>)
| return <div> {elToolbar}
| {elUserCards} </div>
|
| I find doing something similar with Vue HTML templates has
| far too much boilerplate, and I have to learn/recall all this
| Vue specific boilerplate instead of using regular functions
| so I end up not breaking up my HTML as much. Unless there's a
| way to do something similar within in a single file?
| bvrmn wrote:
| This approach is a classic footgun for beginners in the
| context of "hook rules". In general it's quite fragile.
| seanwilson wrote:
| Can you explain more? You're talking about React (hooks)
| here? Or this applies to Vue + JSX as well?
| bvrmn wrote:
| It's React thing. In maintenance context it's always
| better to not extract component instantiation. They could
| start to use hooks or they could be wrapped in conditions
| in a parent component and it would lead to severe quite
| hard to find issues.
| seanwilson wrote:
| This is a bonus of using Vue then if this kind of code
| doesn't pose a problem there?
|
| Makes me wonder why this is all so difficult. Vue has a
| lot less problems for me than previous iterations and
| frameworks, but it's still frustrating how many footguns
| still exist. Like gotchas where you lose reactivity where
| linters/compilers won't catch the problem for you, and
| you forget the gotchas if you're not immersed in that
| framework for a while.
|
| I'm not getting why we can't have robust static checking
| for this stuff vs trusting every developer to be careful.
| dmix wrote:
| Those smaller template languages make it really hard to
| switch to another system in the future. The further you stray
| from HTML the more technical overhead you're creating for
| yourself and others in the future, just to save a small
| amount of time on template code which IDEs heavily automates
| now (closing tags, refactoring, etc).
|
| It also makes debugging harder because there's a heavier
| translation of stuff you see in dev tools vs your codebase.
| It also makes gripping and automated project code replacement
| harder.
|
| You also can't easily copy paste HTML code examples from
| other places. Other developers have to learn and might resist
| it so you have a mix of template systems.
|
| I could keep going...
| stevage wrote:
| First, the point of pug is not saving time typing. It's
| creating a more readable format.
|
| I have never needed to move pug code to non pug. If I
| switched from Vue to Svelte I'd keep using Pug.
|
| I have sometimes needed to do the opposite. There are tools
| to automate it, but even manually it's much less effort
| than say converting Vue to React.
|
| Lastly, the promise of your comment, that technical debt is
| always an important consideration in all projects, is not
| correct.
| Timon3 wrote:
| I loved using Pug with Vue, but after coming across issues
| with tooling integration (e.g. eslint) too many times, I've
| returned to the default templates.
| uallo wrote:
| The one thing that bugs me tremendously with Vue template
| syntax is slots. They are so annoying to use and hardly visible
| in code completion. Passing template/HTML fragments as _props_
| is so much nicer in JSX. This is the only reason, why I even
| consider using JSX instead of Vue 's template syntax. Thus, I'm
| very much interested in your experiences with Vue+JSX.
| Especially in regards of (third-party) tooling support. While
| JSX is officially supported by Vue, it does not seem to be
| encouraged and may have subpar support in the ecosystem. But
| that is only something I'm afraid of, I do not have any
| experience with it, yet.
| seanwilson wrote:
| > Passing template/HTML fragments as props is so much nicer
| in JSX.
|
| Ha, I do this in places but I'm not sure if this approach is
| encouraged? Compared to slots, I like this too, it's a lot
| less verbose and the syntax is simple and easy to remember.
|
| > While JSX is officially supported by Vue, it does not seem
| to be encouraged and may have subpar support in the
| ecosystem. But that is only something I'm afraid of, I do not
| have any experience with it, yet.
|
| Worst case, you can switch to Vue HTML templates in some
| files and use JSX in others. I've not found issues mixing
| them together like this.
| yurishimo wrote:
| Does this also allow you to write multiple components in
| one file? I guess there wouldn't be a problem with it if
| you use the primitive inside of a normal JS file.
|
| I've seen the third party package for the compiler that has
| popped up to try and handle this, but I don't like the
| limitations.
|
| I'm hoping with Vue 4 they will find a way to support
| multiple components in one SFC file (which kinda violates
| the naming but hey...)
| seanwilson wrote:
| > Does this also allow you to write multiple components
| in one file? I guess there wouldn't be a problem with it
| if you use the primitive inside of a normal JS file.
|
| Yes, as in a component would be a regular JavaScript
| function that takes some parameters and gives you back
| some JSX to render. It's really concise and there's no
| need to muck around with plugins or anything special,
| it's just regular JavaScript.
|
| When I'm working on projects that use Vue HTML templates,
| I've often got pages that have some small HTML snippet
| that appears two or three times, and just don't want to
| go through the effort of having to break the snippet out
| into its own component file because its so verbose. JSX
| makes this really low friction so you do it more often.
| crabmusket wrote:
| I have only tried your approach on small side projects. I quite
| liked it, for the reasons you mention.
|
| And for one more reason: the only tooling needed is esbuild,
| which can handle TSX. No finding a Vue SFC plugin, just a
| single dependency and you're off.
|
| (Of course you'll probably also want to install typescript
| itself as IDE type checking isn't adequate for a real project.)
| seanwilson wrote:
| Yeah, I like that JSX is built into TypeScript like this so
| it's more standardised with less tooling required. JSX is
| probably less likely to change given its relatively wide
| usage compared to each framework having it's own template
| language and JSX is well supported by linters and formatters
| too.
| rk06 wrote:
| Personally i prefer to put v-for/v-if/else in a separate
| <template> tag. It makes it easier to identify and makes order
| explicit
| DannyBee wrote:
| 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
|
| 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
|
| 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.
| rxliuli wrote:
| > 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):
|
| Yes, when I posted this content on Reddit, someone immediately
| brought up "Svelte's reactivity doesn't exist at runtime" to
| refute me, which isn't even a valid argument in Svelte 5.
| https://www.reddit.com/r/sveltejs/comments/1j6ayaf/comment/m...
|
| > 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
|
| I did remove some of them, such as the issue of "data
| ownership," which is the first time I've heard this term
| outside of Rust's web framework, but it was just a warning, not
| a blocking issue, so I deleted it.
| https://svelte.dev/docs/svelte/runtime-warnings#Client-warni...
|
| > 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.
|
| Yes, the current project has been underway for 3 months, and I
| won't replace the entire web framework now, but I will
| definitely consider whether there are better options for the
| next project.
| pjmlp wrote:
| 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 wrote:
| vuejs is 10 years old
| pjmlp wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| CharlieDigital wrote:
| I would strongly recommend Vue3.
|
| I am also an old timer. Hand rolled HTML and JavaScript since
| '97?
|
| Came up with ASP (both VBScript and JSCript (it's like we're
| full circle with JS SSR)). Move to ASP.NET when it was in beta.
| jQuery, Prototype, Knockout.js.
|
| Vue.js SFC is the thing that _feels closest to HTML +
| JavaScript components done right_. It 's reactivity model is
| the same as that of JS whereas React's reactivity model is
| "inverted" [0]
|
| The state model (Pinia or just composable reactive primitives)
| is simple, Just Works, and never gets in your way.
|
| Lots of folks like JSX because they don't like HTML and CSS.
| I'm the opposite; I like Vue _because I like HTML and CSS_ and
| I like JavaScript. Vue is HTML + JavaScript done right with a
| congruent reactivity model.
|
| [0] https://chrlschn.dev/blog/2025/01/the-inverted-reactivity-
| mo...
| pjmlp wrote:
| My use of Next.js is due to SaaS products that only support
| Next.js on their first party support and teams I work with,
| thus I won't be using Vue, regardless of how great it happens
| to be.
|
| Privately I seldom use any kind of JavaScript frameworks,
| other than when doing WebGL/WebGPU side projects, and then it
| is mostly Babylonjs.
| rxliuli wrote:
| I think Vue 3 is better than Svelte 5's runes, but
| unfortunately, in my 7 years of using Vue, I've realized
| that Vue is just a follower of React and may never catch
| up, as it is only trying to optimize the status quo rather
| than break the deadlock.
| CharlieDigital wrote:
| The exact opposite is probably true at a technical level.
|
| Vue 3.6, for example, is incorporating a new signals
| rebuild that's several times faster and probably the
| fastest signals implementation out there[0]
|
| Vue Vapor will also release in experimental mode in 3.6
| and once it's mainstreamed, will probably also be among
| the fastest render models.
|
| Both changes do not affect the DX and require no
| migrations, but will provide faster performance for ever
| more complex apps.
|
| [0] https://www.youtube.com/watch?v=zvjOT7NHl4Q
| rxliuli wrote:
| Yes, that's exactly my point. Vue 3 just improves things
| using existing technologies instead of creating truly
| fresh solutions.
| CharlieDigital wrote:
| Wait, wait: so your take is that the upcoming alien-
| signals[0] library integration -- created from scratch to
| improve Vue's signals performance -- is just "using
| existing technologies instead of creating truly fresh
| solutions"?
|
| Basically, if I understand correctly, it's not "shiny"
| enough -- even though it is going to significantly
| improve signals performance.
|
| [0] https://github.com/stackblitz/alien-signals
| teekoiv wrote:
| 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 but so
| far no clear answer
| hmry wrote:
| Use $state()! to fix the undefined is not assignable error.
| beremaki wrote:
| > 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 wrote:
| 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 wrote:
| > 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
|
| 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 wrote:
| > 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 wrote:
| All these irks to avoid redraw()ing when needed
___________________________________________________________________
(page generated 2025-03-08 23:01 UTC)