11 ms·

Svelte 5 is not JavaScript

194 points by jonstaab 2y ago

ilrwbwrkhv 2y ago
Ya I knew Svelte took a wrong turn when it went from var foo = "something" foo = "something else" -> ui updates to: $state('hello') Runes and other nonsense immediately made me turn off Svelte. Even Vue sort of moved away and started looking like React. I think there is an opportunity now for another new framework which goes back to simplicity which Vue and Svelte tried to do. Mithril really was as close to perfection as one can get.
- ChocolateGod 2y ago
  I disagree, yes it feels less VanillaJS-ey but having unwanted reactivity made Svelte annoying at times and caused reactivity loops that just made code ugly to avoid. Anyway, if you don't want it like that you can continue to use the old system.
- deleted 2y ago
  [deleted]
- recursive 2y ago
  Interesting. The new Svelte seems clearer to me. In fact, Svelte seems to be moving toward vue to me, and away from react. That is components have stable identities and each piece of state has a subscriber list, which may directly update a DOM element or another piece of state. None of which requires re-"rendering".
  - dapperdrake 2y ago
    At what point will they reach SQLite?
    - recursive 2y ago
      I don't understand this at all. There's no plans to support a query language. Scalar values can exist. Heterogeneous lists can exist. The use case is explicitly tightly coupled to a UI layer. What would it mean to reach SQLite?
- mgrandl 2y ago
  As somebody who maintains a very large Svelte app and upgraded from 4 to 5, I couldn’t be happier with the changes. For simple components the old approach was just fine, but the larger the codebase gets the harder it gets to work with.
  - terminalbraid 2y ago
    I appreciate someone working on a sizable codebase to put in their opinion. Too often it's just feedback on their experience with a Hello World analog and it's easy to get hyperbolic opinions off of that.
    - ihateolives 2y ago
      Yes, but not everybody builds the next social network or complex commercial app with 50 pages and 150 forms. It used to be that svelte was the perfect choice to build simple spa fronts to backend services, there already was react for complex applications. Now we have 2 additional reacts with svelte and vue and no mainstream simple framework for smaller stuff. Why does everybody feel they need to build eventually the same thing, but slightly different?
  - bangaladore 2y ago
    My opinion exactly. Svelte 4 is simple in a single component. Svelte 5 needs a bit more boilerplate. Svelte 4 was always very confusing in multi component/files workflows, especially when working with .ts/.js files. Svelte 5 is way better in this regard. I'd pay the "slightly more boilerplate" price every day.
- Muromec 2y ago
  >Even Vue sort of moved away and started looking like React. Did it? Vue has composables that look kinda like react hooks syntaxically, but aren't the same thing at all, they are just better scoped mixins.
- sensanaty 2y ago
  Vue moved the exact opposite way, and in fact Svelte moved more towards Vue 3 and its composables/CompositionAPI.
- npn 2y ago
  To be fair, the reason svelte 5 is that awkward to use is because they still need to be compatible with svelte 4 code. Without svelte 4 compatibility, you can just replace `$state` with `$`, `$derived` with `$$` or even some simpler mechanisms. Heck, I have vague intuition that we can reuse the `$: ` statements someway too, and still keep the new deep reactivity feature. Might be svelte 6 will give us the proper answer. Or some newer fancy framework will take the hint and do it sooner.
  - bangaladore 2y ago
    > To be fair, the reason svelte 5 is that awkward to use is because they still need to be compatible with svelte 4 code. The way the compatibility works is by seemingly identifying the file and either treating it in legacy mode or runes mode. I don't think what you are suggesting would have blocked them from doing what they are doing now.
    - npn 2y ago
      It does thought. You can't assign new meaning to $ and $$ and expect that it works flawlessly with magic statements and the stores. At the very least the conversion between the versions will be very messy and error prones, especially using the migration tools. Not to mention the designs of runes was still unstable back then. Heck even now it is still very awkward to use runes with sveltekit. You need $state and $effect everywhere for the page data.
- forvelin 2y ago
  why mithril.js was though ? it is still a solid choice.
rikafurude21 2y ago
Frontend work sounds like hell. You're telling me you updated YOUR code to work with the latest framework release? What was even new in that release? They seem to have no respect for peoples time or any consideration for longtermism or even just the common decency of backwards compatibility. What are we at now, React 19? Is it just a reason to keep people employed?
- wetpaws 2y ago
  [dead]
- golergka 2y ago
  > You're telling me you updated YOUR code to work with the latest framework release? I work on frontend right now, but I've worked on backend earlier, as well as gamedev and desktop applications. And it was always like that in every area: when your major dependency has a major version upgrade, you will have to spend effort on migrating your code to support it.
  - bastardoperator 2y ago
    It a software problem, not a frontend/backend problem. We've all been subjected this insanity in some way.
    - int_19h 2y ago
      Its severity varies between ecosystems, though, and JavaScript is especially crazy in this regard. Frontend JS, doubly so.
  - fiddlerwoaroof 2y ago
    The issue I had when I still worked in the frontend world is the frequency of major version updates. If you used standard project bootstrapping tools in approximately 2017, you got a whole bunch of libraries and tools that would have significant breaking changes multiple times over the next three years or so (I know because I had to maintain them).
  - 2y ago
wetpaws 2y ago
People who use observables-based frameworks are asking for trouble. Every single industrial scale project I saw was inevitably breaking apart on seams.
- mrj 2y ago
  Very different in my experience but implementation matters. I've been using mobx for years with great results, largely because I move all of the logic out of components into stores. I think that's the actual key, since most hooks-based and other solutions rely on a lot of component logic that becomes frail and error-prone. Instead, making the view layer only view vastly improves development complexity by making a layer responsible for the data that is separate from rendering. My components do as little as possible other than render html and bind the occasional event handler to a store function. With this in place, development scales much more easily than layers of hooks.
  - wetpaws 2y ago
    [dead]
brink 2y ago
That's why I like it. I did 8 years of React, and I hope I never have to touch it again. When I was forced to use Remix, it just about broke me.
- dimgl 2y ago
  This sounds like a Remix problem more than a React problem. I really enjoyed the ideas behind Remix actually! In fact, I found that having both server and client code in a single file (a-la Next.js) made me super productive. And nowadays I bet it pairs well with LLMs due to having the full vertical slice available in the agent's context. I really wanted that framework to take off. But that community is straight toxic... I have not seen a more toxic community than the React Router community. It's one of the reasons I stopped using Remix. React Router 7 is actually pretty cool; I recently built a prototype on it and was surprised by how well it worked. But I know I'll eventually need some kind of support and feedback, and I can't imagine engaging with those devs/that community again...
  - brink 2y ago
    It's worth noting that I only did Remix for like 6 months last year. My big issue was it's intentional inflexibility. It creates a very narrow and inflexible mold for you to build your site into, creating a framework where the "cure" is worse than the problem. They make a huge selling point of loading nested data, loading the nested components with their data in parallel. I have never seen that to be a huge problem, in my experience of React - complexity has been the problem, and that's something that Remix makes worse, not better.
  - clgeoio 2y ago
    I too quite like Remix and I think the framework is taking off! The support of Shopify has made Remix quite popular, especially with the Hydrogen offering. I cannot comment on the community though, I've only had decent experiences during the earlier Remix days.
- k__ 2y ago
  Yeah, React really fumbled the bag with server components.
DeathArrow 2y ago
Want a sane frontend experience? Use vanilla Javascript, use web components, use htmx, use Blazor. JS frameworks for some reason or other are a madness.
- graynk 2y ago
  That last one is a big stretch. Blazor is uhh.. not pleasant to use
- OtomotO 2y ago
  Absolutely! I am killing a huge React app step by step and replacing it with HTMX. Best thing I did in many years for that project.
  - davely 2y ago
    I often read these threads on HN and they make me feel like that I am perhaps a horrible software engineer or just weird… I _like_ building things with React.
    - sampullman 2y ago
      I think it's really context dependent. If you've been banging your head against the wall working on a poorly architected React codebase for years, anything else probably feels like a breath of fresh air. If you have a nice codebase with good separation of concerns (that everybody adheres to) and reasonable library choices, you'll be happy regardless of what framework you're using.
    - greenchair 2y ago
      as long as you like it, keep using it! I wouldn't try to make generalizations from the HN or reddit bubbles.
    - OtomotO 2y ago
      I dislike all the warts of React, all the rules that fail at runtime... If hooks and the rules of them would be enforced at compile time, it could be great. I prefer solid
xrd 2y ago
I wasn't so excited about runes when they first came out. But, when I could create a reactive external component that I can import into a .svelte template, AND that internally encapsulates reactivity, my opinions changed. That means you can write vitest tests against it, but get the benefits of reactivity. That is truly powerful and, AFAIK, unique in the frontend world. But, most frontend people don't do testing at all. Typescript is the tool people use to guarantee correctness, and for good reason. But, svelte people have always cast a narrow eye towards typescript and for good reasons as well. So, here we are. I personally prefer writing testable frontend code, and Svelte 5 is revolutionary in that way. It is as good as unit testing, but reactive in the browser. Having said all this, the blog post rings true. Adding proxies feels very uncomfortable. React and Vue lost me when they started adding abstractions on top of abstractions and proxies were the gateway drugs.
- CharlieDigital 2y ago
  > ...when I could create a reactive external component that I can import into a .svelte template...That means you can write vitest tests against it, but get the benefits of reactivity. That is truly powerful and, AFAIK, unique in the frontend world. Isn't this the same as Vue composables? Composable: https://github.com/CharlieDigital/vue3-state-definemodel/blob/main/src/example6/useDetailsEditor.ts https://github.com/CharlieDigital/vue3-state-definemodel/blo... Vue Component: https://github.com/CharlieDigital/vue3-state-definemodel/blob/main/src/example6/Details.vue#L39 https://github.com/CharlieDigital/vue3-state-definemodel/blo... BTW, I agree it's a very good pattern in general; especially good if you end up reusing logic with different templates/UI.
  - xrd 2y ago
    Can you share an example of a testable vue component? I would like to see that. I got disillusioned around Vue 2. When they had proxies in front of class attributes that looked like functions, it really made it hard to instrument inside of tests. Maybe this is fixed now. But, it left a bad taste in my mouth.
    - CharlieDigital 2y ago
voat 2y ago
I appreciate that the author acknowledged that there must exist some reason(s) for the changes that he is unaware of. I appreciate Svelte's new architecture, it's going to help people make smaller, faster apps, even it requires you to learn about how it's reactive system works.
amazingamazing 2y ago
It's a shame EmberJS fell by the wayside. The API has been pretty stable for a decade now. Ironically someone who wrote their EmberJS app last decade would have less trouble migrating than someone who did the same with React, Svelte, Vue, etc. Sadly the Ember team made some strange decisions in the beginning and it wasn't easily grokable compared to regular JavaScript (most of that has been fixed now, though). This is all to say that whether or not it's JavaScript doesn't really matter, compared to the stability of the API. My personal problem with JavaScript is that things keep changing too much.
- lelandfe 2y ago
  I unfortunately learn best by book. I hunted for a React book, against the advice of the community, and found one that was current circa v18. It opens by saying the absolute standard for making React sites is create-react-app… which just got deprecated. And any book older than that is useless due to class syntax or predating hooks. Just 3 years to turn a resource into a door stop.
  - yourapostasy 2y ago
    So how up to date and idiomatic all the React code shoveled into production servers by LLM's can be, if their training data is mostly riddled with deprecated styles?
    - deleted 2y ago
      [deleted]
    - combyn8tor 2y ago
      The linter picks them up. Then you pass the linter warning/error back into the LLM until the linter stops complaining. Then the slop compiles.
- TSiege 2y ago
  I haven't used EmberJS in 10 years and was eyeing svelte for some personal projects. Given this article it's made me shy about that. Maybe it's time to look at ember again. I know vanilla JS + htmx is mentioned elsewhere here and worth exploring too. However, as you've said a stable API is very nice these days in the JS world
beders 2y ago
And here I am flinging hiccup and Reagent for years now without any major changes. Reagent has been around since 2013. They even survived the transition to functional React components without major changes. The hiccup I wrote 5 years ago is still perfectly fine. The only issue we have is JS UI libraries we depend on who have a funny understanding of backwards compatibility.
- jonstaab 2y ago
  I wish I had stuck with clojurescript. I found clojure in 2013 or so but could never justify putting it in production. But that would have been a good 12 years of frontend development bliss. The clojure team has the right mindset.
locallost 2y ago
It's a really really well written article, I wish more people wrote like this, instead of lazy, tired discourses on frontend hell. I did not dive too deep in his examples on Svelte as I don't use it, but I understood the gist of it. And I agree with the conclusion: "...there is a tradeoff between doing things for the user, and giving the user agency". There was always something about a lot of developers where they treat the users of their code as incompetent and unable to get anything done. So they do all sorts of things to make it idiot proof, but this ends up making everything more complex. The take about AI is also interesting, I didn't think about that before. If AI is now able to generate a lot of code, maybe being able to quickly understand that code is more important than that code being clever.
dimgl 2y ago
Stores really turned me off in Svelte 4 so I was eager to start using Svelte 5. I've been using Sveltekit and Svelte 5 for a new project and I have to say... React's productivity is still unmatched, even if the Sveltekit and Svelte tech is technically better. A couple of things that I found really annoying: all pages being named `+page.server.ts` or `+page.svelte` or a variation of that makes it hard to easily search for code. The tooling for Svelte is also separate from `tsc` and ESLint, making it tricker to both integrate into CI and use in dev. And then there's just weird incompatibility stuff with the previous version. For instance, most Svelte packages still use stores, like SuperForms, so you have to contend with two versions of the world, making writing code really confusing at times. Plus, Svelte HMR is still kinda early AFAICT, so it will clobber your state when a Svelte module reloads. I _really_ want to like Svelte. It's significantly faster to render and I like the ideas behind it. But React's productivity is unmatched.
- jonstaab 2y ago
  Funny, because I love svelte stores and use them as much as I can over the compiler magic. But that's probably because I've never taken the time to learn observables properly.
- brulard 2y ago
  > React's productivity is still unmatched I'm React developer since 2015 and working on side with svelte+sveltekit for the last 3 years. For me it's exactly the opposite. React was huge upgrade from Angular 1 and jQuery development before, but everything goes so much more quickly together with Svelte. I understand that there is no one-size-fits-all for UI frameworks, and we have different thought-processes for lack of a better word, but saying React's productivity is unmatched, is very much untrue.
deleted 2y ago
[deleted]
Fergusonb 2y ago
I've been actively developing a commercially deployed SvelteKit application, and I'd like to share some thoughts on my experience. What initially drew me to SvelteKit was its simplicity. After setting up the project, I could work on one HTML/JS/CSS file at a time, leveraging the benefits of a modern framework without the accompanying complexity. This approach reminded me of the early days of web development, where dropping HTML files into an Apache server was all it took to get things running. However, it's disheartening to see Svelte shifting away from that straightforward paradigm. From the outset, Rich Harris positioned Svelte's ease of use and simplicity as its key selling points. The current version of SvelteKit isn't bad per se, but I found myself preferring the earlier iterations. Back then, I didn't have to deal with constructs like `+page` for routing. I could place Svelte files wherever I wanted, and they would render seamlessly, all while enjoying the advantages of a modern framework. This change adds layers of complexity that weren't necessary before, potentially moving away from what made Svelte appealing in the first place. I picked it up because I already knew what I needed to know.
- barnabee 2y ago
  I also can’t get along with SvelteKit. Astro + Svelte seems nice enough if you need it but for most of what I do, plain Svelte 5 is great.
  - sureglymop 2y ago
    I also use Astro + Svelte. It's nice but I wouldn't say it's less complex than sveltekit. But I just like being able to introduce dynamic components and server side functionality gradually into a base static site.
barnabee 2y ago
Svelte 5 is not JavaScript is why I like Svelte 5. There are two major ways I think it's reasonable to do frontend/web: 1. Static HTML or server rednered templates with maybe HTMX . 2. Compile-to-JavaScript languages/platforms. At a minimum TypeScript but given that I think HTML and CSS are actually pretty good (for many things), JSX, React, Tailwind, etc, are right out, and Svelte 5 along with a few other frameworks actually improve things over vanilla TypeScript in my opinion. So much so that Svelte 5 is the clear winner in category 2 for me. It has nice HTML templating, easy and sane state propagation, and features that make it easy to write modular code. It works great with CSS and you can often build simple throwaway apps and tools in one or two files, as well as bigger, more serious applications. It's less magical and surprising that Svelte 4, and honestly a joy to use. Luckily I don't care about IndexedDB. I have no clue why anyone would choose to write a single line of JavaScript in this day and age, but each to their own.
- prophesi 2y ago
  You'll still be writing Javascript/Typescript with Svelte. What the article means by "Svelte 5 is not Javascript" is that all of your code outside things like Stores will be compiled in a manner that makes it harder to debug, since it's not normal Javascript but a Svelte-compiled JS that won't make sense in the debugger. I would opt for better debugger tooling specifically for Svelte than strip away the abstractions. Its the lack of a runtime managing a virtual DOM that makes it unique and performant, and frameworks like React also essentially have their own compilation step that obfuscates code. Source maps won't help much by itself; the React debugger is where you have a better view on your components and how things are wired up.
  - barnabee 2y ago
    Debugging seems fine to me, theres even the {@debug …} tag. TypeScript is a better scripting language than JavaScript, Svelte is a better language/model/platform than HTML+TypeScript. React may be your cup of tea but I’d rather write Svelte templates every day! Not to mention per-component styles. Sure, a component inspector devtool would be neat, though. Nobody’s going to complain about better tooling :)
  - deleted 2y ago
dondraper36 2y ago
Those who say that they just use htmx instead of frameworks, how does it work for you? Do you use libraries like alpine for client side interactivity or just write vanilla JS?
- rasso 2y ago
  Using Alpine.js is not preventing you from also using vanilla JavaScript in the same project. Combined with alpine-ajax it‘s absolutely enough for progressively enhanced semi-dynamic web experiences. An example: https://filter-munich.com https://filter-munich.com
GrumpyCat42 2y ago
It was very disappointing to see Svelte 5 go the way of React. Yes, yes, I understand that it theoretically simplifies things and yadda yadda yadda, but after trying to actually use it, it felt like I was just using React with a much smaller ecosystem. Svelte 4 felt awesome because it felt like I was just writing an HTML file, sure there was some magic ($:) but for the most part things were simple, easy to understand, and it all just worked. Runes totally changed that, maybe for the better because of all of the things previously cited, but not for my personal experience. I'll stop there because I'm 100% covering already-treaded ground. I'm "joining the dark side" by trying the HTMX & Golang combo, just to see if I can hack together an on-par DX (which is going to be a herculean task, I know).
- stuckinhell 2y ago
  htmx has a whole world of major issues too. No silver bullet. I'm simply switching back to React, it just seems the dominant standard right now.
sonicgear1 2y ago
SolidJS is what Svelte5 should have been
evbogue 2y ago
I wonder how much of these issues are because the author is developing a Nostr app with Svelte 5? As a fellow developer of a distributed social networking application and protocol I find myself making a lot of decisions about where to store and validate data that is simply not an issue if you're making a traditional SPA working with one server that has username/password authentication.
- jonstaab 2y ago
  It definitely has bearing on the indexeddb complaint. If I was sending proxies over fetch, I would never have noticed. But I would expect the callbacks/props thing to be pretty annoying for any app that uses portals.
NetOpWibby 2y ago
The two Github links the author lists at the top of his post point to the same issue and in that issue is a solution to his problem (use $state.raw). I've been a fan of Svelte since version 2 or 3 because it was the closest I could get to writing vanilla HTML/CSS/JS, whilst also enjoying the benefits of a framework (and then using Sass and TypeScript). Fantastic. Svelte 5 made me feel uneasy because runes are weird. After upgrading a project with it and working on another project, it's not so bad. I like that Svelte 5 disallows you from mixing the old and new ways of handling state and the error messages are mostly informative. I see people in these comments talking about htmx and vanilla JS being objectively better and...no? For what YOU do, sure. Personally, Svelte is still a lot simpler to grok than React and for the people that care about benchmarks, Svelte is just as fast as SolidJS (I feel like the React crowd could pretty easily switch to Solid, the syntax feels similar).
- jonstaab 2y ago
  Oops, you're right, here's the other issue: https://github.com/sveltejs/svelte/issues/15325 https://github.com/sveltejs/svelte/issues/15325 That should shed more light on my problem, which is not just due to proxies, but is also a result of props being getters under the hood.
p0w3n3d 2y ago
The article mentions https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a... which is an opening article for me. TBH I was always sure I was supposed to go into details, but with more and more people around me starting to operate only in high-level abstractions, I started to doubt this. Meanwhile, the abstractions ARE leaky, and I NEED to and SHOULD understand the underlying UNIX filesystem because it IS different from the Windows filesystem. Should know the inner workings of my PostgreSQL RDBMS rather than relying only on hibernate. And so on. Last but not least, I just realised that it is impossible to write code in an unknown-to-me framework using LLM, because sooner or later I will need to fix the problems that arise exactly by going deeper into the inner workings.
Ameo 2y ago
The part of Svelte 5 which bothers me the most isn't the syntax changes for Runes, but rather the significant increase in complexity that the new API brings. The `Proxy`-based state management API is a perfect example of this. The intention was to make working with mutable state like arrays feel better, but it creates this layer of added complexity under the hood with non-trivial performance and functionality implications (like the IndexedDB sync issue the author ran into). Compared to the `let x = 1` paradigm from before, we now have three different Runes for state (`$state`, `$state.raw`, and `$state.snapshot`) which you need to choose and understand the differences between. The added nuance to the way `$effect` works which is detailed in the post is in the same vein. Another issue is that stores are pretty much deprecated. I love stores because of their simplicity all the way through; you could click "go to source definition" on a `writable()` call in your text editor and read through the simple implementation in the Svelte source code. [1] You could confidently create custom stores that integrated seamlessly into Svelte's reactivity system all using plain JS; you just had to match the expected API. With hooks, that transparency is greatly reduced and all of the magic happens invisibly under the hood in the compiler. In `.svelte` files this was totally fine since it was operating within the Svelte model. But now, any random assignment to `self.foo` in a class might actually be to a reactive `$state` rune which could cause UI components to re-render elsewhere. Besides that, there are bugs when using both stores and Runes (some of which I've reported on Github [2]). Stores and Runes have slightly different reactivity models which aren't quite compatible. The response was basically a wontfix, so the expectation is that if you upgrade you go all the way. ---- I will say that I'm still a fan of Svelte and will probably keep using it as my favored UI framework despite my feelings about Svelte 5. And from other discussions I've seen on places like the Svelte subreddit, it seems that there are big parts of the community which are very happy about these changes. Maybe what some people are saying is true and that this added complexity is needed as a framework like Svelte matures in order for it to find adoption with larger teams and organizations. [1] https://github.com/sveltejs/svelte/blob/98734433376e99909fb6f2f141d9e66d0531ff4e/packages/svelte/src/store/shared/index.js#L34 https://github.com/sveltejs/svelte/blob/98734433376e99909fb6... [2] https://github.com/sveltejs/svelte/issues/11626 https://github.com/sveltejs/svelte/issues/11626
- ravenstine 2y ago
kristiandupont 2y ago
I wish that the Crank library (https://crank.js.org/ https://crank.js.org/) would get more attention. It takes everything in the exact opposite direction, which in my opinion is much more promising. But alas, it just doesn't seem to be catching on so I don't see an ecosystem ever really evolving there.
- herpdyderp 2y ago
  This looks interesting but a headline of "Just JavaScript" fell flat when all but one example are code that won't even run in any browser (JSX) and the example that will is only "roughly the same thing".
skrebbel 2y ago
Mostly offtopic, but I just want to drive-by namedrop Legend State, which provides a deep reactivity state system similar to the one in SolidJS or Svelte 5, but with substantially fewer gotchas because its design makes it abundantly clear when you're working with a proxy (which tracks dependencies) and when you're working with plain data. The key trick is that its "observables" (similar to Solid Stores or Svelte runes) aren't mixed with the actual data, and instead are sort of pointers to the data. This makes it very clear when you're passing reactive observables around, and when you just have vanilla data. There's never confusion about whether a particular property access is properly tracked or not. There's never that feeling that it "is not JavaScript". It works well with React but is fundamentally framework-independent. We moved to it after trying SolidJS (which Svelte 5 is strongly influenced by) and we haven't looked back. IMO it deserves a lot more mindshare than it currently has. https://legendapp.com/open-source/state/v3/ https://legendapp.com/open-source/state/v3/
- jzig 2y ago
  They've turned React into Angular 19 with signals. Heh.
  - skrebbel 2y ago
    I'll admit I'm not deeply familiar with Angular signals, but simply signals are IMO not that useful beyond a conference demo. The real hard part is keeping fine-grained reactivity when you have large-ish amounts of hierarchical data. You'll need to somehow nest signals (like SolidJS and Svelte Runes do) or hierarchically mirror the data in a signal-like data structure (like Legend State observables). From a quick glance at the Angular docs, it doesn't seem like they've solved that at all.
- jonstaab 2y ago
  This seems promising. I agree observables are probably the right way forward, although I haven't used them much beyond svelte stores. Observables via hooks might be a good way to eliminate the bad parts of hooks too.
- dhucerbin 2y ago
brap 2y ago
Svelte never sat right with me, from the very beginning, but I could never exactly put my finger on it and articulate why. “Svelte is not JavaScript” is spot on.
spankalee 2y ago
If you're looking for a library to build components and apps with that does let you use plain JavaScript - to the degree that you can write working components in your devtools console - check out Lit: https://lit.dev/ https://lit.dev/ For deep reactivity, we have add-on packages for signals, and we're aiming towards integration with the upcoming Signals TC39 proposal: https://lit.dev/blog/2024-10-08-signals/ https://lit.dev/blog/2024-10-08-signals/ Lit's used by pretty major apps like Photoshop, Reddit, Home Assistant, and The Internet Archive.
- replete 2y ago
  What are the best resources for approaching complex enterprise apps with Lit?
teekoiv 2y ago
Runes annoy me because they ruined the use of Svelte components as rendered widgets outside a Svelte site. I like using them in rich-text as rendered views but when Svelte 5 came out, the old way of simply setting the component props directly was thrown out and you implicitly are now expected to use runes for the props you pass to the components. Which means, that anywhere I render those components I have to suffix the file as .svelte.ts Or switch to svelte/store but it's quite dumb to wrap everything as a Writable<T> I still like Svelte regardless, but I just thought "why" as over-abstraction wasn't the original tenets of Svelte
- jonstaab 2y ago
  Yeah, I opted not to talk about that in my post, but runes do tend to infect all of your code if you use them as intended.
ericyd 2y ago
Feels weird to say Svelte is not JavaScript because of an unexpected behavior when passing a closure as a callback. I think a better title would be "I dislike Svelte 5 because it surprised me."
- favorited 2y ago
  As someone who transitioned from JS to native apps before Node hit 1.0, unexpected behavior with closure callbacks make it sound more like JavaScript to me.
ForHackernews 2y ago
Svelte compiles to Javascript. I don't think it's ever claimed to be Javascript. It's less weird and magical than React, IMHO.
k__ 2y ago
For me it was the other way around. Was a huge React enthusiast, even wrote a book on it. But with version 5, Svelte got really interesting. Runes really feel like a breath of fresh air.
- machiaweliczny 2y ago
  Have you used MobX? It was there 10 years ago and still working. Svelte runes are basically the same with some perf wins but require compilation
  - aitchnyu 2y ago
    The MobX back then froze completely on any error and we had to convert its data types for certain components. Did they completely address both issues?
rezmason 2y ago
I thought this was especially well said: > Don't choose tools that alienate you from your work. Choose tools that leverage the wisdom you've already accumulated, and which help you to cultivate a deeper understanding of the discipline.
daft_pink 2y ago
My only complaint about Svelte 5 is that its so new that the LLMs aren’t good at it yet.
jcuenod 2y ago
The problem is that Svelte 5 is not Javascript in the worst way. It doesn't solve the problems of js, it provides leaky abstractions around some frontend issues. I think Solid is a better direction than Svelte because Solid doesn't depend on a new language. But the reason there's an instinct to create something that's not quite js is that js is not ideal. Elm is the precursor to svelte. But I think we can do better...[0] [0] https://jcuenod.github.io/bibletech/2025/02/16/beyond-typescript/ https://jcuenod.github.io/bibletech/2025/02/16/beyond-typesc...
jgilias 2y ago
I for one am just excited that a Nostr post has organically made it to HN front page!
pier25 2y ago
I love Svelte and runes but because of its compiled nature and custom language it does require a serious dev tools effort. You're also basically coupled to VSCode. Unfortunately the Svelte team doesn't have the resources to support other editors. And now with TS these dev tools need to be more sophisticated than ever. As much as I love Svelte this worries me. Vercel is pretty invested into React and Next and who knows how long they'll be funding the project.
jmull 2y ago
I liked svelte quite a bit, but I wouldn't recommend it for most projects. Whatever version of svelte you use will be dead and abandoned soon, so if you have any hope for a long-lived project, you're jumping on the update treadmill, where the value proposition is 100% backwards... If your project fails, then great, no problem! If it succeeds you'll have to spend a proportion of your time upgrading. Worst case scenario is your project succeeds and grows. The time you spend upgrading grows in proportion with how much you use it. And in complex projects you tend to get these spikes of exponential upgrade work, which outright blocks your progress. No thanks. (Of course, this isn't restricted to svelte. React and all the crap you have to use with it are even worse.)
- deleted 2y ago
  [deleted]
mrgoldenbrown 2y ago
Anybody figure out how to hide the big orange useless button that's getting in the way of the article text at the bottom of the screen? (on Firefox on Android). There's a three dot button next to it but when I press it there's no "close" or "hide" option.
Jean-Papoulos 2y ago
>Sure, sometimes I had to delete my project and port it to a fresh repository every so often, but the framework was truly a pleasure to use. Jesus Christ, I didn't know how bad Javascript devs had it. I'm so sorry.
0xblinq 2y ago
Totally agree. We used it for a customer's medium size project and we ended up regretting it. We're now using Solid for another project, and so far we're very happy with it.
blue_waters 2y ago
We've built applications in nearly every major framework there is - from plain old PHP, to Rails, to Laravel, to Vue.js, to React SPAs, and now SSR/RPC-style frameworks like Next.js and React Server Components. The one thing that has really caught our eye - and I feel is the real breakthrough these days - is the new generation of SSR/RPC-style frameworks like Solid Start, SvelteKit (I'm assuming?), TanStack Start, and of course Next.js and React Server Components (oh and React Router 7 née Remmix ¯\_(ツ)_/¯). Being able to code in 'server module space' and have data available in advance of the render cycle, without having to write a separate API layer - is great. For example, we can - if we chose to, write a Next.js application as an all dynamic app (no statically generated or cached pages) and treat it pretty much as we would a PHP application that renders a template on initial renders. The only remaining hill to climb is the performance of the initial render in SSR as this is catastrophically slow in React (we implement short TTL Level 1 caches in Nginx so that we can survive scaling a response to any 'popular' dynamic pages in our applications). I've heard (but not tested) that Solid's SSR life cycle is better in this respect. We can do the same in Astro 'server' mode. We've not yet looked at SvelteKit. As for the rest, I agree that this quote nails it: "Don't choose tools that alienate you from your work. Choose tools that leverage the wisdom you've already accumulated and help you to cultivate a deeper understanding of the discipline.". For us this translates into CSS and CSS Modules as our style system, as we watched - mortified, as an entire CSS-in-JS ecosystem (ala Styled components, Motion.js) was basically told to get stuffed when the shift to SSR/RPC and streamed responses occurred. We narrowly dodged that bullet. It also means casting a very cautious eye over Tailwind CSS (ignoring how it can be abused, and arguably encourages duplication and bad practices in component reuse), as the recent Tailwind 4 release demonstrated by the manner in which guidance on migration was published for first-party plugins like Typography. I love the web - despite the complexity. And I agreed whole hardheartedly with statements from people like Rich Harris when he says the web is ours to nurture and protect [paraphrased].
oloila 2y ago
svelte <5 versions were sometimes hard, but they were, you know, pretty understandable. rxjs/reactive like, stores subscriptions, ah that's nice. But i was disappointed about svelte v5, because it changed paradigm. runes force you to change your mind and it is no more rxjs, it is class-based enterprise angular-js. New version added a lot of new things, but they are not described well. I also hate some things like your class fields that have state are undefined by design and you need to do cast or null-check every time. Also your getter can't return derived, it should be class field, meh. Ah, also I HATE how they force SvelteKit. Guys, hello, I need just plain svelte, why do your starter template creates for me non-ssr sveltekit project? Do you really think that I'll choose this new sapper? ==== But, svelte is the only non-runtime framework that is trending and has big community. Hope Rich will do better new versions :)
0xblinq 2y ago
I don’t get why anyone would use Svelte to be honest (other than because of the hype/marketing). If you like template like syntax and single file components the. Vue provides the same benefits, with a bigger ecosystem and better team behind it (non vercel backed, that’s a big advantage). If you prefer JSX, performance, simplicity and integration with vanilla js then why not use Solid instead? I’ve used svelte for a medium size project and ended up regretting it. (For the above reasons).

194 points by jonstaab 2y ago

Ya I knew Svelte took a wrong turn when it went from var foo = "something" foo = "something else" -> ui updates to: $state('hello') Runes and other nonsense immediately made me turn off Svelte. Even Vue sort of moved away and started looking like React. I think there is an opportunity now for another new framework which goes back to simplicity which Vue and Svelte tried to do. Mithril really was as close to perfection as one can get.

ChocolateGod 2y ago
I disagree, yes it feels less VanillaJS-ey but having unwanted reactivity made Svelte annoying at times and caused reactivity loops that just made code ugly to avoid. Anyway, if you don't want it like that you can continue to use the old system.
deleted 2y ago
[deleted]
recursive 2y ago
Interesting. The new Svelte seems clearer to me. In fact, Svelte seems to be moving toward vue to me, and away from react. That is components have stable identities and each piece of state has a subscriber list, which may directly update a DOM element or another piece of state. None of which requires re-"rendering".
- dapperdrake 2y ago
  At what point will they reach SQLite?
  - recursive 2y ago
    I don't understand this at all. There's no plans to support a query language. Scalar values can exist. Heterogeneous lists can exist. The use case is explicitly tightly coupled to a UI layer. What would it mean to reach SQLite?
mgrandl 2y ago
As somebody who maintains a very large Svelte app and upgraded from 4 to 5, I couldn’t be happier with the changes. For simple components the old approach was just fine, but the larger the codebase gets the harder it gets to work with.
- terminalbraid 2y ago
  I appreciate someone working on a sizable codebase to put in their opinion. Too often it's just feedback on their experience with a Hello World analog and it's easy to get hyperbolic opinions off of that.
  - ihateolives 2y ago
    Yes, but not everybody builds the next social network or complex commercial app with 50 pages and 150 forms. It used to be that svelte was the perfect choice to build simple spa fronts to backend services, there already was react for complex applications. Now we have 2 additional reacts with svelte and vue and no mainstream simple framework for smaller stuff. Why does everybody feel they need to build eventually the same thing, but slightly different?
- bangaladore 2y ago
  My opinion exactly. Svelte 4 is simple in a single component. Svelte 5 needs a bit more boilerplate. Svelte 4 was always very confusing in multi component/files workflows, especially when working with .ts/.js files. Svelte 5 is way better in this regard. I'd pay the "slightly more boilerplate" price every day.
Muromec 2y ago
>Even Vue sort of moved away and started looking like React. Did it? Vue has composables that look kinda like react hooks syntaxically, but aren't the same thing at all, they are just better scoped mixins.
sensanaty 2y ago
Vue moved the exact opposite way, and in fact Svelte moved more towards Vue 3 and its composables/CompositionAPI.
npn 2y ago
To be fair, the reason svelte 5 is that awkward to use is because they still need to be compatible with svelte 4 code. Without svelte 4 compatibility, you can just replace `$state` with `$`, `$derived` with `$$` or even some simpler mechanisms. Heck, I have vague intuition that we can reuse the `$: ` statements someway too, and still keep the new deep reactivity feature. Might be svelte 6 will give us the proper answer. Or some newer fancy framework will take the hint and do it sooner.
- bangaladore 2y ago
  > To be fair, the reason svelte 5 is that awkward to use is because they still need to be compatible with svelte 4 code. The way the compatibility works is by seemingly identifying the file and either treating it in legacy mode or runes mode. I don't think what you are suggesting would have blocked them from doing what they are doing now.
  - npn 2y ago
    It does thought. You can't assign new meaning to $ and $$ and expect that it works flawlessly with magic statements and the stores. At the very least the conversion between the versions will be very messy and error prones, especially using the migration tools. Not to mention the designs of runes was still unstable back then. Heck even now it is still very awkward to use runes with sveltekit. You need $state and $effect everywhere for the page data.
forvelin 2y ago
why mithril.js was though ? it is still a solid choice.

rikafurude21 2y ago

Frontend work sounds like hell. You're telling me you updated YOUR code to work with the latest framework release? What was even new in that release? They seem to have no respect for peoples time or any consideration for longtermism or even just the common decency of backwards compatibility. What are we at now, React 19? Is it just a reason to keep people employed?

wetpaws 2y ago
[dead]
golergka 2y ago
> You're telling me you updated YOUR code to work with the latest framework release? I work on frontend right now, but I've worked on backend earlier, as well as gamedev and desktop applications. And it was always like that in every area: when your major dependency has a major version upgrade, you will have to spend effort on migrating your code to support it.
- bastardoperator 2y ago
  It a software problem, not a frontend/backend problem. We've all been subjected this insanity in some way.
  - int_19h 2y ago
    Its severity varies between ecosystems, though, and JavaScript is especially crazy in this regard. Frontend JS, doubly so.
- fiddlerwoaroof 2y ago
  The issue I had when I still worked in the frontend world is the frequency of major version updates. If you used standard project bootstrapping tools in approximately 2017, you got a whole bunch of libraries and tools that would have significant breaking changes multiple times over the next three years or so (I know because I had to maintain them).
- 2y ago

wetpaws 2y ago

People who use observables-based frameworks are asking for trouble. Every single industrial scale project I saw was inevitably breaking apart on seams.

mrj 2y ago
Very different in my experience but implementation matters. I've been using mobx for years with great results, largely because I move all of the logic out of components into stores. I think that's the actual key, since most hooks-based and other solutions rely on a lot of component logic that becomes frail and error-prone. Instead, making the view layer only view vastly improves development complexity by making a layer responsible for the data that is separate from rendering. My components do as little as possible other than render html and bind the occasional event handler to a store function. With this in place, development scales much more easily than layers of hooks.
- wetpaws 2y ago
  [dead]

brink 2y ago

That's why I like it. I did 8 years of React, and I hope I never have to touch it again. When I was forced to use Remix, it just about broke me.

dimgl 2y ago
This sounds like a Remix problem more than a React problem. I really enjoyed the ideas behind Remix actually! In fact, I found that having both server and client code in a single file (a-la Next.js) made me super productive. And nowadays I bet it pairs well with LLMs due to having the full vertical slice available in the agent's context. I really wanted that framework to take off. But that community is straight toxic... I have not seen a more toxic community than the React Router community. It's one of the reasons I stopped using Remix. React Router 7 is actually pretty cool; I recently built a prototype on it and was surprised by how well it worked. But I know I'll eventually need some kind of support and feedback, and I can't imagine engaging with those devs/that community again...
- brink 2y ago
  It's worth noting that I only did Remix for like 6 months last year. My big issue was it's intentional inflexibility. It creates a very narrow and inflexible mold for you to build your site into, creating a framework where the "cure" is worse than the problem. They make a huge selling point of loading nested data, loading the nested components with their data in parallel. I have never seen that to be a huge problem, in my experience of React - complexity has been the problem, and that's something that Remix makes worse, not better.
- clgeoio 2y ago
  I too quite like Remix and I think the framework is taking off! The support of Shopify has made Remix quite popular, especially with the Hydrogen offering. I cannot comment on the community though, I've only had decent experiences during the earlier Remix days.
k__ 2y ago
Yeah, React really fumbled the bag with server components.

DeathArrow 2y ago

Want a sane frontend experience? Use vanilla Javascript, use web components, use htmx, use Blazor. JS frameworks for some reason or other are a madness.

graynk 2y ago
That last one is a big stretch. Blazor is uhh.. not pleasant to use
OtomotO 2y ago
Absolutely! I am killing a huge React app step by step and replacing it with HTMX. Best thing I did in many years for that project.
- davely 2y ago
  I often read these threads on HN and they make me feel like that I am perhaps a horrible software engineer or just weird… I _like_ building things with React.
  - sampullman 2y ago
    I think it's really context dependent. If you've been banging your head against the wall working on a poorly architected React codebase for years, anything else probably feels like a breath of fresh air. If you have a nice codebase with good separation of concerns (that everybody adheres to) and reasonable library choices, you'll be happy regardless of what framework you're using.
  - greenchair 2y ago
    as long as you like it, keep using it! I wouldn't try to make generalizations from the HN or reddit bubbles.
  - OtomotO 2y ago
    I dislike all the warts of React, all the rules that fail at runtime... If hooks and the rules of them would be enforced at compile time, it could be great. I prefer solid

xrd 2y ago

I wasn't so excited about runes when they first came out. But, when I could create a reactive external component that I can import into a .svelte template, AND that internally encapsulates reactivity, my opinions changed. That means you can write vitest tests against it, but get the benefits of reactivity. That is truly powerful and, AFAIK, unique in the frontend world. But, most frontend people don't do testing at all. Typescript is the tool people use to guarantee correctness, and for good reason. But, svelte people have always cast a narrow eye towards typescript and for good reasons as well. So, here we are. I personally prefer writing testable frontend code, and Svelte 5 is revolutionary in that way. It is as good as unit testing, but reactive in the browser. Having said all this, the blog post rings true. Adding proxies feels very uncomfortable. React and Vue lost me when they started adding abstractions on top of abstractions and proxies were the gateway drugs.

CharlieDigital 2y ago
> ...when I could create a reactive external component that I can import into a .svelte template...That means you can write vitest tests against it, but get the benefits of reactivity. That is truly powerful and, AFAIK, unique in the frontend world. Isn't this the same as Vue composables? Composable: https://github.com/CharlieDigital/vue3-state-definemodel/blob/main/src/example6/useDetailsEditor.ts https://github.com/CharlieDigital/vue3-state-definemodel/blo... Vue Component: https://github.com/CharlieDigital/vue3-state-definemodel/blob/main/src/example6/Details.vue#L39 https://github.com/CharlieDigital/vue3-state-definemodel/blo... BTW, I agree it's a very good pattern in general; especially good if you end up reusing logic with different templates/UI.
- xrd 2y ago
  Can you share an example of a testable vue component? I would like to see that. I got disillusioned around Vue 2. When they had proxies in front of class attributes that looked like functions, it really made it hard to instrument inside of tests. Maybe this is fixed now. But, it left a bad taste in my mouth.
  - CharlieDigital 2y ago

voat 2y ago

I appreciate that the author acknowledged that there must exist some reason(s) for the changes that he is unaware of. I appreciate Svelte's new architecture, it's going to help people make smaller, faster apps, even it requires you to learn about how it's reactive system works.

amazingamazing 2y ago

It's a shame EmberJS fell by the wayside. The API has been pretty stable for a decade now. Ironically someone who wrote their EmberJS app last decade would have less trouble migrating than someone who did the same with React, Svelte, Vue, etc. Sadly the Ember team made some strange decisions in the beginning and it wasn't easily grokable compared to regular JavaScript (most of that has been fixed now, though). This is all to say that whether or not it's JavaScript doesn't really matter, compared to the stability of the API. My personal problem with JavaScript is that things keep changing too much.

lelandfe 2y ago
I unfortunately learn best by book. I hunted for a React book, against the advice of the community, and found one that was current circa v18. It opens by saying the absolute standard for making React sites is create-react-app… which just got deprecated. And any book older than that is useless due to class syntax or predating hooks. Just 3 years to turn a resource into a door stop.
- yourapostasy 2y ago
  So how up to date and idiomatic all the React code shoveled into production servers by LLM's can be, if their training data is mostly riddled with deprecated styles?
  - deleted 2y ago
    [deleted]
  - combyn8tor 2y ago
    The linter picks them up. Then you pass the linter warning/error back into the LLM until the linter stops complaining. Then the slop compiles.
TSiege 2y ago
I haven't used EmberJS in 10 years and was eyeing svelte for some personal projects. Given this article it's made me shy about that. Maybe it's time to look at ember again. I know vanilla JS + htmx is mentioned elsewhere here and worth exploring too. However, as you've said a stable API is very nice these days in the JS world

beders 2y ago

And here I am flinging hiccup and Reagent for years now without any major changes. Reagent has been around since 2013. They even survived the transition to functional React components without major changes. The hiccup I wrote 5 years ago is still perfectly fine. The only issue we have is JS UI libraries we depend on who have a funny understanding of backwards compatibility.

jonstaab 2y ago
I wish I had stuck with clojurescript. I found clojure in 2013 or so but could never justify putting it in production. But that would have been a good 12 years of frontend development bliss. The clojure team has the right mindset.

locallost 2y ago

It's a really really well written article, I wish more people wrote like this, instead of lazy, tired discourses on frontend hell. I did not dive too deep in his examples on Svelte as I don't use it, but I understood the gist of it. And I agree with the conclusion: "...there is a tradeoff between doing things for the user, and giving the user agency". There was always something about a lot of developers where they treat the users of their code as incompetent and unable to get anything done. So they do all sorts of things to make it idiot proof, but this ends up making everything more complex. The take about AI is also interesting, I didn't think about that before. If AI is now able to generate a lot of code, maybe being able to quickly understand that code is more important than that code being clever.

dimgl 2y ago

Stores really turned me off in Svelte 4 so I was eager to start using Svelte 5. I've been using Sveltekit and Svelte 5 for a new project and I have to say... React's productivity is still unmatched, even if the Sveltekit and Svelte tech is technically better. A couple of things that I found really annoying: all pages being named `+page.server.ts` or `+page.svelte` or a variation of that makes it hard to easily search for code. The tooling for Svelte is also separate from `tsc` and ESLint, making it tricker to both integrate into CI and use in dev. And then there's just weird incompatibility stuff with the previous version. For instance, most Svelte packages still use stores, like SuperForms, so you have to contend with two versions of the world, making writing code really confusing at times. Plus, Svelte HMR is still kinda early AFAICT, so it will clobber your state when a Svelte module reloads. I _really_ want to like Svelte. It's significantly faster to render and I like the ideas behind it. But React's productivity is unmatched.

jonstaab 2y ago
Funny, because I love svelte stores and use them as much as I can over the compiler magic. But that's probably because I've never taken the time to learn observables properly.
brulard 2y ago
> React's productivity is still unmatched I'm React developer since 2015 and working on side with svelte+sveltekit for the last 3 years. For me it's exactly the opposite. React was huge upgrade from Angular 1 and jQuery development before, but everything goes so much more quickly together with Svelte. I understand that there is no one-size-fits-all for UI frameworks, and we have different thought-processes for lack of a better word, but saying React's productivity is unmatched, is very much untrue.

deleted 2y ago

[deleted]

Fergusonb 2y ago

I've been actively developing a commercially deployed SvelteKit application, and I'd like to share some thoughts on my experience. What initially drew me to SvelteKit was its simplicity. After setting up the project, I could work on one HTML/JS/CSS file at a time, leveraging the benefits of a modern framework without the accompanying complexity. This approach reminded me of the early days of web development, where dropping HTML files into an Apache server was all it took to get things running. However, it's disheartening to see Svelte shifting away from that straightforward paradigm. From the outset, Rich Harris positioned Svelte's ease of use and simplicity as its key selling points. The current version of SvelteKit isn't bad per se, but I found myself preferring the earlier iterations. Back then, I didn't have to deal with constructs like `+page` for routing. I could place Svelte files wherever I wanted, and they would render seamlessly, all while enjoying the advantages of a modern framework. This change adds layers of complexity that weren't necessary before, potentially moving away from what made Svelte appealing in the first place. I picked it up because I already knew what I needed to know.

barnabee 2y ago
I also can’t get along with SvelteKit. Astro + Svelte seems nice enough if you need it but for most of what I do, plain Svelte 5 is great.
- sureglymop 2y ago
  I also use Astro + Svelte. It's nice but I wouldn't say it's less complex than sveltekit. But I just like being able to introduce dynamic components and server side functionality gradually into a base static site.

barnabee 2y ago

Svelte 5 is not JavaScript is why I like Svelte 5. There are two major ways I think it's reasonable to do frontend/web: 1. Static HTML or server rednered templates with maybe HTMX . 2. Compile-to-JavaScript languages/platforms. At a minimum TypeScript but given that I think HTML and CSS are actually pretty good (for many things), JSX, React, Tailwind, etc, are right out, and Svelte 5 along with a few other frameworks actually improve things over vanilla TypeScript in my opinion. So much so that Svelte 5 is the clear winner in category 2 for me. It has nice HTML templating, easy and sane state propagation, and features that make it easy to write modular code. It works great with CSS and you can often build simple throwaway apps and tools in one or two files, as well as bigger, more serious applications. It's less magical and surprising that Svelte 4, and honestly a joy to use. Luckily I don't care about IndexedDB. I have no clue why anyone would choose to write a single line of JavaScript in this day and age, but each to their own.

prophesi 2y ago
You'll still be writing Javascript/Typescript with Svelte. What the article means by "Svelte 5 is not Javascript" is that all of your code outside things like Stores will be compiled in a manner that makes it harder to debug, since it's not normal Javascript but a Svelte-compiled JS that won't make sense in the debugger. I would opt for better debugger tooling specifically for Svelte than strip away the abstractions. Its the lack of a runtime managing a virtual DOM that makes it unique and performant, and frameworks like React also essentially have their own compilation step that obfuscates code. Source maps won't help much by itself; the React debugger is where you have a better view on your components and how things are wired up.
- barnabee 2y ago
  Debugging seems fine to me, theres even the {@debug …} tag. TypeScript is a better scripting language than JavaScript, Svelte is a better language/model/platform than HTML+TypeScript. React may be your cup of tea but I’d rather write Svelte templates every day! Not to mention per-component styles. Sure, a component inspector devtool would be neat, though. Nobody’s going to complain about better tooling :)
- deleted 2y ago

dondraper36 2y ago

Those who say that they just use htmx instead of frameworks, how does it work for you? Do you use libraries like alpine for client side interactivity or just write vanilla JS?

rasso 2y ago
Using Alpine.js is not preventing you from also using vanilla JavaScript in the same project. Combined with alpine-ajax it‘s absolutely enough for progressively enhanced semi-dynamic web experiences. An example: https://filter-munich.com https://filter-munich.com

GrumpyCat42 2y ago

It was very disappointing to see Svelte 5 go the way of React. Yes, yes, I understand that it theoretically simplifies things and yadda yadda yadda, but after trying to actually use it, it felt like I was just using React with a much smaller ecosystem. Svelte 4 felt awesome because it felt like I was just writing an HTML file, sure there was some magic ($:) but for the most part things were simple, easy to understand, and it all just worked. Runes totally changed that, maybe for the better because of all of the things previously cited, but not for my personal experience. I'll stop there because I'm 100% covering already-treaded ground. I'm "joining the dark side" by trying the HTMX & Golang combo, just to see if I can hack together an on-par DX (which is going to be a herculean task, I know).

stuckinhell 2y ago
htmx has a whole world of major issues too. No silver bullet. I'm simply switching back to React, it just seems the dominant standard right now.

sonicgear1 2y ago

SolidJS is what Svelte5 should have been

evbogue 2y ago

I wonder how much of these issues are because the author is developing a Nostr app with Svelte 5? As a fellow developer of a distributed social networking application and protocol I find myself making a lot of decisions about where to store and validate data that is simply not an issue if you're making a traditional SPA working with one server that has username/password authentication.

jonstaab 2y ago
It definitely has bearing on the indexeddb complaint. If I was sending proxies over fetch, I would never have noticed. But I would expect the callbacks/props thing to be pretty annoying for any app that uses portals.

NetOpWibby 2y ago

The two Github links the author lists at the top of his post point to the same issue and in that issue is a solution to his problem (use $state.raw). I've been a fan of Svelte since version 2 or 3 because it was the closest I could get to writing vanilla HTML/CSS/JS, whilst also enjoying the benefits of a framework (and then using Sass and TypeScript). Fantastic. Svelte 5 made me feel uneasy because runes are weird. After upgrading a project with it and working on another project, it's not so bad. I like that Svelte 5 disallows you from mixing the old and new ways of handling state and the error messages are mostly informative. I see people in these comments talking about htmx and vanilla JS being objectively better and...no? For what YOU do, sure. Personally, Svelte is still a lot simpler to grok than React and for the people that care about benchmarks, Svelte is just as fast as SolidJS (I feel like the React crowd could pretty easily switch to Solid, the syntax feels similar).

jonstaab 2y ago
Oops, you're right, here's the other issue: https://github.com/sveltejs/svelte/issues/15325 https://github.com/sveltejs/svelte/issues/15325 That should shed more light on my problem, which is not just due to proxies, but is also a result of props being getters under the hood.

p0w3n3d 2y ago

The article mentions https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a... which is an opening article for me. TBH I was always sure I was supposed to go into details, but with more and more people around me starting to operate only in high-level abstractions, I started to doubt this. Meanwhile, the abstractions ARE leaky, and I NEED to and SHOULD understand the underlying UNIX filesystem because it IS different from the Windows filesystem. Should know the inner workings of my PostgreSQL RDBMS rather than relying only on hibernate. And so on. Last but not least, I just realised that it is impossible to write code in an unknown-to-me framework using LLM, because sooner or later I will need to fix the problems that arise exactly by going deeper into the inner workings.

Ameo 2y ago

The part of Svelte 5 which bothers me the most isn't the syntax changes for Runes, but rather the significant increase in complexity that the new API brings. The `Proxy`-based state management API is a perfect example of this. The intention was to make working with mutable state like arrays feel better, but it creates this layer of added complexity under the hood with non-trivial performance and functionality implications (like the IndexedDB sync issue the author ran into). Compared to the `let x = 1` paradigm from before, we now have three different Runes for state (`$state`, `$state.raw`, and `$state.snapshot`) which you need to choose and understand the differences between. The added nuance to the way `$effect` works which is detailed in the post is in the same vein. Another issue is that stores are pretty much deprecated. I love stores because of their simplicity all the way through; you could click "go to source definition" on a `writable()` call in your text editor and read through the simple implementation in the Svelte source code. [1] You could confidently create custom stores that integrated seamlessly into Svelte's reactivity system all using plain JS; you just had to match the expected API. With hooks, that transparency is greatly reduced and all of the magic happens invisibly under the hood in the compiler. In `.svelte` files this was totally fine since it was operating within the Svelte model. But now, any random assignment to `self.foo` in a class might actually be to a reactive `$state` rune which could cause UI components to re-render elsewhere. Besides that, there are bugs when using both stores and Runes (some of which I've reported on Github [2]). Stores and Runes have slightly different reactivity models which aren't quite compatible. The response was basically a wontfix, so the expectation is that if you upgrade you go all the way. ---- I will say that I'm still a fan of Svelte and will probably keep using it as my favored UI framework despite my feelings about Svelte 5. And from other discussions I've seen on places like the Svelte subreddit, it seems that there are big parts of the community which are very happy about these changes. Maybe what some people are saying is true and that this added complexity is needed as a framework like Svelte matures in order for it to find adoption with larger teams and organizations. [1] https://github.com/sveltejs/svelte/blob/98734433376e99909fb6f2f141d9e66d0531ff4e/packages/svelte/src/store/shared/index.js#L34 https://github.com/sveltejs/svelte/blob/98734433376e99909fb6... [2] https://github.com/sveltejs/svelte/issues/11626 https://github.com/sveltejs/svelte/issues/11626

ravenstine 2y ago

kristiandupont 2y ago

I wish that the Crank library (https://crank.js.org/ https://crank.js.org/) would get more attention. It takes everything in the exact opposite direction, which in my opinion is much more promising. But alas, it just doesn't seem to be catching on so I don't see an ecosystem ever really evolving there.

herpdyderp 2y ago
This looks interesting but a headline of "Just JavaScript" fell flat when all but one example are code that won't even run in any browser (JSX) and the example that will is only "roughly the same thing".

skrebbel 2y ago

Mostly offtopic, but I just want to drive-by namedrop Legend State, which provides a deep reactivity state system similar to the one in SolidJS or Svelte 5, but with substantially fewer gotchas because its design makes it abundantly clear when you're working with a proxy (which tracks dependencies) and when you're working with plain data. The key trick is that its "observables" (similar to Solid Stores or Svelte runes) aren't mixed with the actual data, and instead are sort of pointers to the data. This makes it very clear when you're passing reactive observables around, and when you just have vanilla data. There's never confusion about whether a particular property access is properly tracked or not. There's never that feeling that it "is not JavaScript". It works well with React but is fundamentally framework-independent. We moved to it after trying SolidJS (which Svelte 5 is strongly influenced by) and we haven't looked back. IMO it deserves a lot more mindshare than it currently has. https://legendapp.com/open-source/state/v3/ https://legendapp.com/open-source/state/v3/

jzig 2y ago
They've turned React into Angular 19 with signals. Heh.
- skrebbel 2y ago
  I'll admit I'm not deeply familiar with Angular signals, but simply signals are IMO not that useful beyond a conference demo. The real hard part is keeping fine-grained reactivity when you have large-ish amounts of hierarchical data. You'll need to somehow nest signals (like SolidJS and Svelte Runes do) or hierarchically mirror the data in a signal-like data structure (like Legend State observables). From a quick glance at the Angular docs, it doesn't seem like they've solved that at all.
jonstaab 2y ago
This seems promising. I agree observables are probably the right way forward, although I haven't used them much beyond svelte stores. Observables via hooks might be a good way to eliminate the bad parts of hooks too.
dhucerbin 2y ago

brap 2y ago

Svelte never sat right with me, from the very beginning, but I could never exactly put my finger on it and articulate why. “Svelte is not JavaScript” is spot on.

spankalee 2y ago

If you're looking for a library to build components and apps with that does let you use plain JavaScript - to the degree that you can write working components in your devtools console - check out Lit: https://lit.dev/ https://lit.dev/ For deep reactivity, we have add-on packages for signals, and we're aiming towards integration with the upcoming Signals TC39 proposal: https://lit.dev/blog/2024-10-08-signals/ https://lit.dev/blog/2024-10-08-signals/ Lit's used by pretty major apps like Photoshop, Reddit, Home Assistant, and The Internet Archive.

replete 2y ago
What are the best resources for approaching complex enterprise apps with Lit?

teekoiv 2y ago

Runes annoy me because they ruined the use of Svelte components as rendered widgets outside a Svelte site. I like using them in rich-text as rendered views but when Svelte 5 came out, the old way of simply setting the component props directly was thrown out and you implicitly are now expected to use runes for the props you pass to the components. Which means, that anywhere I render those components I have to suffix the file as .svelte.ts Or switch to svelte/store but it's quite dumb to wrap everything as a Writable<T> I still like Svelte regardless, but I just thought "why" as over-abstraction wasn't the original tenets of Svelte

jonstaab 2y ago
Yeah, I opted not to talk about that in my post, but runes do tend to infect all of your code if you use them as intended.

ericyd 2y ago

Feels weird to say Svelte is not JavaScript because of an unexpected behavior when passing a closure as a callback. I think a better title would be "I dislike Svelte 5 because it surprised me."

favorited 2y ago
As someone who transitioned from JS to native apps before Node hit 1.0, unexpected behavior with closure callbacks make it sound more like JavaScript to me.

ForHackernews 2y ago

Svelte compiles to Javascript. I don't think it's ever claimed to be Javascript. It's less weird and magical than React, IMHO.

k__ 2y ago

For me it was the other way around. Was a huge React enthusiast, even wrote a book on it. But with version 5, Svelte got really interesting. Runes really feel like a breath of fresh air.

machiaweliczny 2y ago
Have you used MobX? It was there 10 years ago and still working. Svelte runes are basically the same with some perf wins but require compilation
- aitchnyu 2y ago
  The MobX back then froze completely on any error and we had to convert its data types for certain components. Did they completely address both issues?

rezmason 2y ago

I thought this was especially well said: > Don't choose tools that alienate you from your work. Choose tools that leverage the wisdom you've already accumulated, and which help you to cultivate a deeper understanding of the discipline.

daft_pink 2y ago

My only complaint about Svelte 5 is that its so new that the LLMs aren’t good at it yet.

jcuenod 2y ago

The problem is that Svelte 5 is not Javascript in the worst way. It doesn't solve the problems of js, it provides leaky abstractions around some frontend issues. I think Solid is a better direction than Svelte because Solid doesn't depend on a new language. But the reason there's an instinct to create something that's not quite js is that js is not ideal. Elm is the precursor to svelte. But I think we can do better...[0] [0] https://jcuenod.github.io/bibletech/2025/02/16/beyond-typescript/ https://jcuenod.github.io/bibletech/2025/02/16/beyond-typesc...

jgilias 2y ago

I for one am just excited that a Nostr post has organically made it to HN front page!

pier25 2y ago

I love Svelte and runes but because of its compiled nature and custom language it does require a serious dev tools effort. You're also basically coupled to VSCode. Unfortunately the Svelte team doesn't have the resources to support other editors. And now with TS these dev tools need to be more sophisticated than ever. As much as I love Svelte this worries me. Vercel is pretty invested into React and Next and who knows how long they'll be funding the project.

jmull 2y ago

I liked svelte quite a bit, but I wouldn't recommend it for most projects. Whatever version of svelte you use will be dead and abandoned soon, so if you have any hope for a long-lived project, you're jumping on the update treadmill, where the value proposition is 100% backwards... If your project fails, then great, no problem! If it succeeds you'll have to spend a proportion of your time upgrading. Worst case scenario is your project succeeds and grows. The time you spend upgrading grows in proportion with how much you use it. And in complex projects you tend to get these spikes of exponential upgrade work, which outright blocks your progress. No thanks. (Of course, this isn't restricted to svelte. React and all the crap you have to use with it are even worse.)

deleted 2y ago
[deleted]

mrgoldenbrown 2y ago

Anybody figure out how to hide the big orange useless button that's getting in the way of the article text at the bottom of the screen? (on Firefox on Android). There's a three dot button next to it but when I press it there's no "close" or "hide" option.

Jean-Papoulos 2y ago

>Sure, sometimes I had to delete my project and port it to a fresh repository every so often, but the framework was truly a pleasure to use. Jesus Christ, I didn't know how bad Javascript devs had it. I'm so sorry.

0xblinq 2y ago

Totally agree. We used it for a customer's medium size project and we ended up regretting it. We're now using Solid for another project, and so far we're very happy with it.

blue_waters 2y ago

We've built applications in nearly every major framework there is - from plain old PHP, to Rails, to Laravel, to Vue.js, to React SPAs, and now SSR/RPC-style frameworks like Next.js and React Server Components. The one thing that has really caught our eye - and I feel is the real breakthrough these days - is the new generation of SSR/RPC-style frameworks like Solid Start, SvelteKit (I'm assuming?), TanStack Start, and of course Next.js and React Server Components (oh and React Router 7 née Remmix ¯\_(ツ)_/¯). Being able to code in 'server module space' and have data available in advance of the render cycle, without having to write a separate API layer - is great. For example, we can - if we chose to, write a Next.js application as an all dynamic app (no statically generated or cached pages) and treat it pretty much as we would a PHP application that renders a template on initial renders. The only remaining hill to climb is the performance of the initial render in SSR as this is catastrophically slow in React (we implement short TTL Level 1 caches in Nginx so that we can survive scaling a response to any 'popular' dynamic pages in our applications). I've heard (but not tested) that Solid's SSR life cycle is better in this respect. We can do the same in Astro 'server' mode. We've not yet looked at SvelteKit. As for the rest, I agree that this quote nails it: "Don't choose tools that alienate you from your work. Choose tools that leverage the wisdom you've already accumulated and help you to cultivate a deeper understanding of the discipline.". For us this translates into CSS and CSS Modules as our style system, as we watched - mortified, as an entire CSS-in-JS ecosystem (ala Styled components, Motion.js) was basically told to get stuffed when the shift to SSR/RPC and streamed responses occurred. We narrowly dodged that bullet. It also means casting a very cautious eye over Tailwind CSS (ignoring how it can be abused, and arguably encourages duplication and bad practices in component reuse), as the recent Tailwind 4 release demonstrated by the manner in which guidance on migration was published for first-party plugins like Typography. I love the web - despite the complexity. And I agreed whole hardheartedly with statements from people like Rich Harris when he says the web is ours to nurture and protect [paraphrased].

oloila 2y ago

svelte <5 versions were sometimes hard, but they were, you know, pretty understandable. rxjs/reactive like, stores subscriptions, ah that's nice. But i was disappointed about svelte v5, because it changed paradigm. runes force you to change your mind and it is no more rxjs, it is class-based enterprise angular-js. New version added a lot of new things, but they are not described well. I also hate some things like your class fields that have state are undefined by design and you need to do cast or null-check every time. Also your getter can't return derived, it should be class field, meh. Ah, also I HATE how they force SvelteKit. Guys, hello, I need just plain svelte, why do your starter template creates for me non-ssr sveltekit project? Do you really think that I'll choose this new sapper? ==== But, svelte is the only non-runtime framework that is trending and has big community. Hope Rich will do better new versions :)

0xblinq 2y ago

I don’t get why anyone would use Svelte to be honest (other than because of the hype/marketing). If you like template like syntax and single file components the. Vue provides the same benefits, with a bigger ecosystem and better team behind it (non vercel backed, that’s a big advantage). If you prefer JSX, performance, simplicity and integration with vanilla js then why not use Solid instead? I’ve used svelte for a medium size project and ended up regretting it. (For the above reasons).