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.
> ...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.
BTW, I agree it's a very good pattern in general; especially good if you end up reusing logic with different templates/UI.
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.
The VueUse library is a really good place for these since it's all composables like `useClipboard`.
I'm pretty certain that Svelte took inspiration from Vue composables and I'd also guess that the community will have a bit of friction before people start to get its use cases (same as it was with Vue when it was introduced).
With Vue 3 and the composition API, you can do basically the same things you're doing in Svelte. You can also add SolidJS and Preact to this list as well - the magic ingredient in all these frameworks is signals, which allow you to have reactive data without having to have a UI framework to provide lifecycle events.
A good example in Vue is the top example in this page: https://test-utils.vuejs.org/guide/advanced/reusability-comp... The other examples show some other things you can do if you want, although I'd typically recommend against it - keep your signal-related code free of component/lifecycle-related logic, and it will almost always be much easier to test.
(As an aside, I'd add Angular to the list of frameworks that are easy to test, although the framework feels like it goes out of its way to convince you of the opposite. Services are just classes that maintain reactive data - originally via RxJS/Observables, although now signals are also supported - and if you keep them like that, they're fairly easy to test. Unfortunately, Angular's decorators/DI/module system is very pervasive, and at least when I was last using it, meant that even theoretically simple tests still needed lots of boilerplate. But theoretically, it belongs in the same category as the frameworks above.)
> ...the magic ingredient in all these frameworks is signals, which allow you to have reactive data without having to have a UI framework to provide lifecycle events
That's just reactive programming, nothing new. It's sad that some people think it can only be achieved with wacky non-standard syntax.
This is something I didn't cover in my post, but I feel that's a bug, not a feature. Using runes instead of stores (which did the same thing in svelte 4) implicates the svelte compiler in every source file. This is ok if you're married to svelte, but it makes vendor lock-in even more rigid, since you would have to refactor all your regular utilities too when moving to a new framework.
One of my biggest gripe with svelte.
In the js world you're shooting yourself in the foot by choosing a framework that is as locked in as svelte (no vdom,domain-specific-language and their design philosophy), had to find this out the hard way.
I still respect svelte for it's engineering capability, but it's a 100% commitment with no off-road options ever, but if you need a framework for js and don't like react or angular then vue would be my choice.
I'm a bit confused about this - if I build something in React/Vue... I'm never going to be using Vue/React alongside it, or anything else. Am I missing something? Who's out there changing frameworks in existing projects?
Or is this about something else?
Not a lot of situations, but React in theory can be used down to specific pages enabling progressive adoption/ easier Swapping
Also, it's a things metaframeworks enable (Like Astro)
These days, vendor lock-in hardly feels like a worthwhile consideration when evaluating frameworks. A near complete rewrite feels inevitable when transitioning from, say, React to Svelte.
I don't understand this comment. How is it different from hooks and JSX components? In React codebases theres a lot of logic in React-specific files.
I don’t even think it would be possible to "move to a new framework" without starting from near scratch.
If it's a similar transition to the one from Vue 2 Options API to Vue 3 Composition, then I expect there will be a bit of a bump, but it'll make a lot more sense afterwards. The VueUse library is probably the poster child for why this pattern is super useful.
One way to reduce the lock-in would be to wrap runes in a Vue ref lookalike, it'd be no more worse than relying on Svelte 3/4's built-in store implementation.
[deleted]
I feel like I must be misunderstanding you. React is certainly unit testable and developers do test it - just ask react-testing-library (10M weekly downloads).
I'm not a Svelte dev, so I don't really follow the distinction you're drawing. What is it that supposedly makes Svelte more testable?
I haven't used React in a while so I'm happy to learn more.
When I look at this example it does not look like the code I would be using inside my webapp. I have a rule of thumb: my test code should look the same as the code when it is inside my app.
My Svelte 5 runes test code uses the code in exactly the same way that I use it inside my .svelte templates. That's very different in my opinion.
testing-library (and react-testing-library by extension) has a very dogmatic "black box" approach to testing FE code. In many ways it more closely resembles e2e testing than more traditional unit testing does.
Personally, I think it's a PITA since it's pretty rare that copy (such as text labels) ever remains stable for very long, or are sufficiently unique on the page, so I do the "strongly discouraged" route of using data-testid attributes for everything (which also has the side effect of making people who write e2e tests happy, but I digress).
With all of that said, I find myself rather appreciating the approach. I don't need tests to mirror the implementation, only the interface.
Can you link to/post an example of how Svelte is tested that's different?
In the Full Example linked, the only code that it makes sense to talk about being in the app itself is the code to render the component, and that does look precisely the same.
The rest is the testing logic - inspecting the state of the DOM post-render, interacting with components by simulating events, and so on. I don't see how this could correspond to anything in the app proper.
Yeah to be fair testing a fetch request is not the best example right off the bat. That's an outlier IMO.
That said it's very very easy to write similar looking code using react testing library as long as you're good about separating business logic into a hook. Where it gets dicy & hard to test is when components have complex state/effects co-mingling with render logic.
Business logic is very easily testable as a hook, something like:
Fact is testing frontend code is really hard _because_ people don't build frontend code in isolation. I found that testing is much easier when using tools like storybook and browser-based testing tool (so no snapshot testing, no fake-dom).
Right now I am working on a legacy project with ~10 years of work into it, about 15% of the code in there I don't even know how to trigger in the application (lots of weird specific circumstances that require special types of accounts to trigger). I just had to make a small change to hundreds of files and it was hell to manually test it everywhere.
IMO almost all components should be able to be renderable in isolation and mocked data. Type systems help with this problem because they remove a whole layer of tests required, but it is not enough.
> It is as good as unit testing, but reactive in the browser.
I am confused about this because on the one hand, you seem to be hinting at my favorite, under-hyped aspect of testing, which is its use (via TDD) as a controlled-state print/debugger, but on the other you seem to be eliding the most popular--albeit, in my view, less important aspect (insofar as one aims for "working software over comprehensive documentation"[0])--the preservation of behavior across commits and into the future.
What am I missing?
Edit: re "reactive in the browser," that's how I run @benchristel/taste[1]
> svelte people have always cast a narrow eye towards typescript and for good reasons as well.
Out of curiosity, could you elaborate on this a little?
But, briefly, TS is tricky if the entirety of the ecosystem isn't TS. It's becoming less of a problem, and things like deno and bun that have native support for TS are solving the problem, but Rich Harris made compelling arguments for why they went with JSDoc. And, I don't think that is a perfect solution either, but I can write code that runs even if the JSDoc isn't correct, and I can't do that when the TS compiler refuses to compile for some reason like an external library isn't right.
This is why the types-as-comments proposal for ecmascript could be a game changer, most ts files would magically become valid js files; no compilation needed
Svelte supports TypeScript, but the project itself dropped it for JSDocs a year or so back.
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.
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.
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]
> 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.
You should already have a clue, you have to write a lot of JavaScript in order to get Svelte doing what you'd expect outside of very simple components. See these actions as an example, and check out the JS file! https://svelte.dev/tutorial/svelte/actions
Svelte makes more sense if you enjoy the JavaScriptisms. In which it provides enough "magic" for most things, but still lets you enjoy JavaScript.
No, I write a fair bit of TypeScript when I need to make a frontend in Svelte.
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.
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.
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.
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.
I've witnessed a company that started moving away from their KnockoutJS solution to react.
In that time, the knockout parts have kept going strong. The react parts have seen three different paradigms ( React classes, Functional react with redux, React Hooks ) and still hasn't fully settled down given there's also churn in the CSS-in-JS space.
The very occassional time something in the remaining knockout parts need fixing, it's just a harsh reminder that it worked fine.
I'm fairly sure the react portion is still not even on the very latest version of react because some other dependencies are stuck on older versions and they themselves have breaking "API changes" (i.e. complete rewrites with no semblance to the original ).
As someone here also said, maintainers in the JS/TS ecosystem appear to have no respect for their users.
It might sound entitled, but sometimes not completely rewriting your framework's API to a completely incompatible one is a better choice. Even if that means putting up with a slightly worse API than you'd like.
I guess everyone moves so fast that there's a fear that sticking on the old API would just lead to dying off at the hands of a new upstart with a smoother API.
But the alternative is a constant abandonment of projects. If a major version change requires a complete re-write then really the new version is a new project entirely that's re-using the namespace and maintainership.
But perhaps emberJS fell away precisely because it didn't rewrite itself to stay "modern". Maybe this is a "worse is better" situation where the world optimises for the wrong things.
"Has had a mostly stable API for a decade" just isn't something people select for. If it were, then things like ASP.NET would be far more popular.
React has had a mostly stable API for over a decade
How so? Hooks are only ~5 years old.
Meanwhile they've deprecated parts of the class components.
> My personal problem with JavaScript is that things keep changing too much.
JavaScript itself barely changes - it's the flavor-of-the-month frontend frameworks that do. What language feature is commonly used now that wasn't 5 years ago? Some nicer builtin Array methods I guess?
There's a lot of dislike on here for Typescript as a backend language. But the difference with the frontend world with its dozen everchanging frameworks is striking. On the backend side, most projects don't even use a framework, and for those that do basically all of them use the same one (NestJS). And the rate of breaking changes on that has been much lower than something like React.
Of course, many will say that this lack of industry-wide adopted framework in itself is what they dislike about it. But it's hard to settle on that golden mean inbetween both extremes when it's the most popular language in the world (in terms of "Yearly new LOC going into production"). Python makes for a good contrast, with a dozen popularish backend frameworks. Not sure if that's really a better situation to be in, there's pros and cons.
And to expand on this further, I think the real driver of the "javascript always changes" is React. Depending on when your React project was built, it can be incompatible in so many different ways with a React project from a different vintage. Sure, a lot of other frameworks and tools that pop up here and there, but none of them are ever widely adopted. When compared to Vue and Angular which I think we can all agree are the other two frameworks of note, React has been very unstable, Vue and Angular appear quite stable.
The javascript language itself hasn't really had a breaking change of note that I can remember in the last 15 years? It's just expanded its API from years and years of browser implementations trying stuff and trying to get to an actual standard. HTML5/ES6/CSS3 brought a new kind of baseline sanity to the whole thing. That's not to say it's a perfect language without quirks, but to say it keeps changing is just not even accurate at all.
python has version evolution, C++ has version evolution, they kinda all do...
Have you worked with Angular much? I've built extensive component libraries (internal) for my org and maintaining the Angular one has been a nightmare. The frequency of breaking changes and conventions has been awful, particularly in the last few years. React, by contrast, has been a breeze ever since they introduced Context and Hooks.
On the app development side, we dealt with 3 major overhauls of PrimeNG's style system before we decided to invest in a custom library just to eliminate the risk of future upgrades. It took us 6 months to migrate our Angular 9 app to 18 because of the PrimeNG dependency. Granted, it's a massive application and they didn't maintain it properly, but I'd hardly call Angular stable regardless.
And then you have the Vue composition API, which was a major shift from Vue 2.
This isn't to say that React has been perfect. Depending on your stack, there are certainly a fair degree of breaking changes (looking at you, Next.js and react router). But that is far from abnormal in the JS world.
A React class component from 10 years ago will still work in React today perfectly well, and is doing so in large codebases around the world.
Then again, React projects tend to use fast-moving things on top of React, like Redux or NextJS or CRA or whatever. Personally, I enjoy writing stuff in bare React since I like its model, but people tend to steer well clear of that, especially these days with compilers and bundlers and whatnot attached to the frameworks.
I agree, bundlers and bundler plugins have probably been the main thing people see with JS ecosystem and think is overly complicated.
> A React class component from 10 years ago will still work in React today perfectly well,
This isn't true.
ComponentWillMount and related methods were deprecated and then removed.
Yes, they allowed an escape hatch of UNSAFE_ComponentWillMount etc, but that still requires work to make it compatible, so it definitely doesn't "[work] perfectly well".
> Vue and Angular appear quite stable.
I take it you didn’t have to deal with porting an AngularJS app to some other framework, like Angular 2.
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.
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?
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.
[deleted]
I have a number of ember projects on vite if anyone wants to take a look:
Agree, overall ember has felt stable and only improved with age, unfortunately becoming increasingly niche.
At my company I mentioned using it in passing to our cto as we were discussing a project to move our core web app from angular to react, and he laughed saying "maybe if this was 10 years 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
Ember is working through a migration replacing their build system and bundler with Vite -- all while maintaining backwards compatibility to a version released in 2021. Ember will be fun to watch in the coming year.
Depending on how you count it that could be a version originally released in 2018 i.e. the version they are aiming to support is 3.28 which you should be able to easily update to from 3.0 (which was released in 2018) since it's a minor update with no breaking changes
[deleted]
> My personal problem with JavaScript is that things keep changing too much.
Yeah.
Last year I realized in my 10 or so years using Node I've changed my stack so many times (Express, Hapi, Fastify, Hono, Sequelize, Objection, Prisma, Drizzle, Mongo, Fauna, Postgres, Firebase, etc etc). So much time wasted.
Surprisingly, on the frontend I've found stability with Svelte. I've been using for 4-5 years now and still very happy with. I also love runes.
I used Ember and it sucked. It was too complicated and the community was elitist and hostile. Then it got extremely woke and political and even shut down the docs which made me lol and really dislike the project and its authors.
Nothing woke as far as i can see.
Sorry there was hostility when you were around. We try hard to keep hostility out and keep everyone civil now a days
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).
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.
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]
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.
> 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.
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.
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/
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/
Lit's used by pretty major apps like Photoshop, Reddit, Home Assistant, and The Internet Archive.
What are the best resources for approaching complex enterprise apps with Lit?
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."
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.
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.
Reminds me of karet [0]. I used it with great success for making interactive visualizations. This duality of passing a value or passing a stream of values was great.
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.
They've turned React into Angular 19 with signals. Heh.
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.
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.
Honest question - have you ever tried to use the actual web components API? It very much feels like a set of primitives to build a framework on top of. I can't imagine the amount of boiler plate you would need to write to just use web components.
Right and Lit is that exact framework and it’s amazing.
Using blazor as an example of sane web development is so odd to me. Have you actually used it? Not only is it a mess in terms of development (live reloading basically does not work, you either depend on SignalR and your website becomes unusable the second you lose connection, or use wasm and have a terrible mess of a canvas based frontend that barely works), but it's also terrible for users.
I know hating on frontend dev is trendy, and I guess blazor is the logical end to that aversion to actually using frontend tools, but if anything it's the perfect example to show how much worse web dev would be without JavaScript frameworks. There's a reason it's only used for internal tools.
I really have not liked htmx at all. Anything dynamic with it is a big, big pain...
IME a lot of the pain comes from picking the wrong tool for the layer.
By that I mean saying everything has to be a JS framework or everything has to be server-delivered-HTML.
For very dynamic & interactive things maybe it makes sense to write it just in JS without a framework?
For full pages for data-powered applications (that heavily benefit from types & Typescript), maybe it makes sense to use something like Golang on the server.
And then you can embed those interactive dynamic islands inside the data-intensive application, with a thin layer of communication between the two.
Just my 2c - I've found that pattern to be super compelling
I agree but the dominant view is that everything has to be a SPA and having some html delivered by the server is considered bad.
I agree. I really wanted to like it, I do think a lot of what it purports to try to do would be better for the web and development in general, but my experience is that HTMX (even with Alpine) fails to succeed in practice.
Use Alpine for dynamic client-side. Htmx is focused on talking with the server.
I should have clarified that yes, I used Alpine with htmx.
State management for smaller vanilla JS projects that works 9/10 times for me:
const state = new Proxy(
{},
{
set(target, property, value) {
target[property] = value;
renderUpdate();
return true;
},
}
);
I'm only 1/4(.0000000004) serious here. That said, I've been doing this for almost 30 years, I was a kid when I picked up Netscape, I have gone through every mainstream and many niche libraries/languages replacing libraries. Now, in my late 30s I finally can grow a moustache (a big achievement in my family gene pool) but the analysis paralysis is still making me anxious every time I pick up a new project.
- preact w. signals or Svelte are still my libraries of choice if I need to spike something, but that's partially because of signals and vite. The development experience is good, there isn't much magic you need to deal with on a daily basis.
- Web Components are great in many ways, but they don't solve the problems I usually have with bigger projects (scaling state, orchestration for the lack of a better phrase). Lit makes it a bit better though.
- JSX is actually not that bad, as long as you treat it as a DSL around functional composition. Native JSX + signals would probably make most of my node_modules redundant.
(please don't overthink this, I didn't)
What most people need is good routing solution but it’s hard to make it with SSR. Seems like frameworks are somewhat converging now on this app router concept.
Agree that JSX is great (but styles like in Svelte also).
> Agree that JSX is great (but styles like in Svelte also).
Oh yeah, 100%. One of the reasons I like Svelte are colocated CSS modules.
> seems like frameworks are somewhat converging now on this app router concept.
That for sure, and signals in one way or another. It took us 10+ years, Solid.js then preact to bring back a pattern from 2010s (IIRC) implemented in Knockout.js.
People are talking about declarative signals in HTML. I don't have a formed opinion about them yet.
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.
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.
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.
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
as long as you like it, keep using it! I wouldn't try to make generalizations from the HN or reddit bubbles.
If you want your own Web Components, you're going to build an entire framework around the creation and management of them because making proper 'web components' for your project is in effect a whole other project
How is Blazor not a JS framework?
That last one is a big stretch. Blazor is uhh.. not pleasant to use
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.
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...
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.
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.
Yeah, React really fumbled the bag with server components.
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.
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
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?
I wish that the Crank library (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.
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".
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
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.
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.
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.
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.
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.
The article mentions 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.
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?
Front end development is a 90% self-induced hell. There are real challenges like accessibility, processing data from service calls, architecture, and more.
Those aren't the things most developers complain about. Most front end developers spend their energy on concerns of code style, tools, build steps, framework madness, state management, and more. Those are fashion concerns. A decent programmer can solve for most of those themselves without external tooling in a fraction of the time and code size, but not everybody that does this work is confident writing original code.
I can't even begin to count the number of codebases I've seen where developers rolled with this idea and ended up with royal spaghetti. Everyone thinks they can build these frameworks from scratch, but they overlook the unknown unknowns. Nearly every custom implementation of state management, complex forms, async flow management, etc I've seen in the wild is riddled with countless bugs that could've been avoided if they just picked a boring and widely used library. And I've seen plenty, because I'm usually the guy that gets called up when no one else can untangle it anymore.
Yes, I have seen that countless times too. Developers that have no idea how to write original software think they can go without a framework and then write a framework. That is stupid, and its because those developers know something about frameworks but never learned to program. Stop toying with irrelevant nonsense and actually release a product for users that solves from some real business requirement, which is certainly not a framework.
State management is absolutely a real front end concern. That's what you're going to be spending a lot of your time on; you better make sure you do it well. Code style is roughly a solved problem thanks to Prettier, as is build steps with Vite. And I don't know what you mean that "framework madness" is a fashion concern. You have to pick a framework, you can't just avoid that part.
> State management is absolutely a real front end concern
That’s because most SPAs are duplicating backend logic.
They often do that because of the REST/CRUD chokehold where the backend does a bunch of stuff, squeezes the resulting data into extremely basic primitive actions (e.g. GET, POST, PATCH, DELETE), forcing the frontend to recreate a complex state all over again. GraphQL tries to solve this, and usually frontends that rely on that avoid a lot of that duplication of the backend, but devs sometimes manage to scream up even that.
If we kill REST, a lot of the complexity around frontends would be reduced significantly. You don't even need GraphQL or RPC protocols to do that.
REST is not a browser concept, it’s just a pattern. There’s no need to “kill” it. The HTTP protocol is more than enough to interact with a server that store resources and a client that display them. If you’re sure you need another set of verbs and nouns, use http as a tunnel.
> REST is not a browser concept
I didn't say that it was specifically. REST is still a convention that is usually tied to and influenced by HTTP and its methods. It doesn't necessarily have to be that way exactly, but that's how many web applications are typically written.
> There’s no need to “kill” it.
We don't necessarily need it around either.
> If you’re sure you need another set of verbs and nouns, use http as a tunnel.
That is somewhat along the lines of what I'm suggesting. REST is not necessarily better than an API that just takes POST requests in a way that serves the application's needs directly rather than some abstract standard that homogenizes data in ways that require extra work to be done. For some odd reason, many frontend-oriented developers look at me like I've got bugs crawling out of my ears when I say this, yet the idea of allowing the server to do the bulk of the work is both old and resurging in popularity (e.g. Hotwire, LiveView, HTMX).
Yes, because in the scenarios where a SPA is appropriate, round-tripping on every state change is terrible UX.
In such scenarios, there's no need for round tripping because the state are different. But in every SPA that should be an MPA, it's always state duplication.
A certain subset of SPAs need to duplicate backend logic because they necessarily and unavoidably have local state. For instance, optimistic updates require some redundancy with backend logic.
thanks, I'll reuse that one!
Yes, it is a real concern, but its supremely trivial to solve for. Frameworks make this into chaos madness because frameworks have to solve for both the goal of state management in addition to their own divisible component concerns that come and go with user interactions.
I'd be very interested to hear how state management is supremely trivial to solve for.
Ummm, no. I have been through this before and its always a paradox.
The paradox works like this: If you were capable of writing your own software the triviality of state management becomes self evident. If you are not capable of writing your own software, such as full eternal reliance on some tool set or framework, then the answer doesn't matter.
I've written my own software, both with and without state management frameworks. To be honest, I didn't find state management to be particularly "trivial", except when I worked on trivial applications.
In many cases this is true (typical CRUD apps), the tools (react etc) are too way too heavyweight for the job. It may even be some large % the case that it is a self-induced hell.
However, I think frontend is often quite underrated in its essential complexity. I don't share the opinion that state management is a fashion, it's often tightly intertwined with the UX requirements, which can be varied and have all kinds of difficult essential complexity of their own (often complexity that is under-specified, and up to the programmer to discover).
The lack of experience of many frontend devs, combined with the limitations of dynamically typed Javascript, is a recipe for a lot of very gnarly code. Maybe it would be fair to say that this is self-inflicted, but I am sympathetic. It's quite a difficult problem.
When I think of 'total own-goal', completely pointless self-inflicted hell, I think of Python package management.
I'm so tired of those comments. It's almost always come from those who refuse to research before they talk, only echo what they learned from other people.
Do you know why there are new frameworks, new versions every time? Because web is a moving target. New js/css/html5 features are released every day and the libraries have to update to adopt them.
Back in the day you do not have css variables, so you have either use sass and do all the math inside the preprocessing process, or crazier, using those shitty css-in-js libraries to calculate css properties on the fly. Nowadays you can pass around the variables and it can cover almost all the case. In able to pass the css property to the component, you need to improve your framework.
Another example is html5 history API, back in the old days people implemented link components in SPA with buttons (hilarious but it happened), only after History API is introduced there raised the need to manipulate the history properly, thus another rewrite issued.
before that, ES5 introduced `class`, proving yet another way to write js code, which in some situation make cleaner code than the plain old js functions.
everything in the web is moving, new nice things are introduced every month, if you want to create a modern and performant web application, you need to keep up with the new fancy things, frameworks are no exception for that.
What does this have to do with frontend work? Major version updates are common across any part of the stack. Just off the top of my head, SQLAlchemy has a seven step migration process[1] from 1.4 to 2.0, and it's absolutely not the kind of thing you could pull off in a few days if your code base has grown past a certain size.
> 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.
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).
It a software problem, not a frontend/backend problem. We've all been subjected this insanity in some way.
Its severity varies between ecosystems, though, and JavaScript is especially crazy in this regard. Frontend JS, doubly so.
That seems to be a problem that is getting worse with time though, with increasingly frequent "major" releases and fewer that consider backwards compatibility much at all. Also it used to be much more common to have published specs and standards that you could code to for a good chance to not have to rewrite your code next month.
Except usual time to upgrade to next version of .net is less than man day.
No one is forcing you to upgrade, Svelte 4 still works just fine? Svelte has had basically no major API changes since 2019, that's a better part of a decade. And with this new architecture change, they released a sophisticated codemod to do most of the work of updating for you.
Great until your dependency scanner picks up a vulnerability in the framework or a dependency that can't be upgraded without breaking v4, no exemptions can be given and the only updated version is 5. [1]
If it's already end of life you can fork it and upgrade the dependency. You'll miss nothing. This is only difficult if you need to maintain changes upstream, but that's not the case here.
Security support lifetimes make sense for a widely used language or runtime, but not really a frontend web framework on the most backwards compatible language you can have.
In fact, you can still use Svelte 4-style components with Svelte 5, even in the same project.
Honestly it’s exhausting seeing endless posts from people who don’t do frontend development saying “wow, looks awful!” having made zero effort to actually understand the scenario.
> They seem to have no respect for peoples time or any consideration for longtermism or even just the common decency of backwards compatibility
You mean Svelte 5, the backwards compatible framework that makes all of its new features an optional opt-in? That one?
> What are we at now, React 19?
Allow me to introduce you to the concept of semantic versioning, otherwise known as “a versioning system that has defined meaning”. Any breaking change means a new major version, which is why the numbers increment at a rate that is apparently terrifying. These breaking changes are often absolutely tiny and trivial to adapt to.
I don’t even like React but the upgrade path between major versions is rarely a big deal. You’re taking a non-semantic versioning mindset (new version number? Guess I have to rewrite everything!!) and applying it in a scenario where it doesn’t fit.
> Honestly it’s exhausting seeing endless posts from people who don’t do frontend development saying “wow, looks awful!” having made zero effort to actually understand the scenario.
Inevitably we will see it in every front-end related thread until the end of time.
> Honestly it’s exhausting seeing endless posts from people who don’t do frontend development saying “wow, looks awful!” having made zero effort to actually understand the scenario.
There's much bigger topics afoot in the world that also make me think humanity desperately needs better tools to defend & equip ourselves with broadscale collaborative efforts to shut down & reject-by-default negative-valence posts.
The hater-squad has the easiest job on the planet attracting some fellow people who also want to resist learning, change, or who want to feel more secure in their current position. The Dark Side is strong.
"What are we at now, Ubuntu 24?"
For what it's worth, between 2011 and 2016, React shipped versions 0.0.1 to 0.14.0. Then in 2016 they said "fuck it, we're stable now" and jumped immediately to 15.0.0 (they considered 0.14.0 to be mostly equal to 14.0.0).
Then they did 16 in 2017, 17 in 2020, 18 in 2022, and 19 finally in Dec 2024. I don't think 4 major versions in ~9 years is a world breaking amount of churn. I have my problems with the team's development of React, but I think they have a pretty sensible view of breaking changes and limiting churn.
> You're telling me you updated YOUR code to work with the latest framework release?
Next time I'll tell you how people used to update their code to use Python 3! Shocky-shocky.
That was also an obviously terrible idea, iirc to the point even python leadership aims to never do it again
And yet Scala did it next. And both were dramatically worse than what is happening here. Just frontend FUD
There is really no place where updating dependencies is dramatically better. Back end frameworks and even whole languages have this problem. On the front end, I mostly use React and it has been fairly backwards compatible. It's a tradeoff. If you never ever make breaking changes you can end up constrained by previous design decisions. If you make them all the time users won't be able to keep up.
> There is really no place where updating dependencies is dramatically better
This is absolutely untrue. There's a huge gap in how easy it is to upgrade some stacks vs. others.
Updating dependencies in a language with strong, static types and/or an expressive type system is incredibly easy, for example:
Step 1: update dependencies
Step 2: fix compiler errors
Upgrading major versions of .NET, for example, sometimes requires no work at all.
This is not true in JavaScript, Python, and some other languages where you're only going to discover issues during runtime.
TypeScript makes things a lot better, but you're relying on the authors of your dependencies either using TypeScript or keeping types up to date.
> There's a huge gap in how easy it is to upgrade some stacks vs. others.
This I can agree with.
> Updating dependencies in a language with strong, static types and/or an expressive type system is incredibly easy
Java would typically be regarded a pretty close to .NET in regards to its type system, yet I've seen plenty of issues with updating dependencies, whenever you have any sort of dynamic class loading or reflection going on: be it Lombok or MapStruct not liking a specific version of Java, or Spring Boot or one of its many integrations throwing errors during startup after a successful compile, sometimes even disliking specific annotations that worked previously.
A decent type system will help you make sure that the code compiles, sure (and I'm thankful for that), but with some styles of writing code and handling, for example, dependency injection, all bets are off. The same goes for any dependencies that make liberal use of those features. I'd have to dig around for specific examples, but I know for a fact that there are plenty of projects that are stuck on old versions of Spring for that very reason.
Or the fact that there are plenty of pre-.NET Core projects out there that won't be upgraded to anything new anytime soon for similar reasons.
In my experience, updates suck across the board, the only variable is how much. And that applies to everything not just dependencies in code (and runtimes): I've also had seemingly innocuous Debian updates break GRUB and prevent the OS from booting, or even upgrades making exim4 start up for some reason and taking up the port that my mail server needed, preventing it from starting.
I was a bit broad here. I am sure certain projects get things better than others. When I said no place I was more referring to whole categories of development like, front-end, back-end, embedded, data pipelines, ect...
I love types and advocate their use whenever possible. They help a lot but they are a spectrum. Thanks to static analysis tools like TypeScript or even eslint you can get a bit towards automated checks on front end code. Also even compiled languages can miss some things, different languages have type systems that give you different kinds of guarantees. For example, Java has NPEs that can't be caught at compile time.
Personally I've picked Vue over React like height years ago and it's been mostly great, never regretted it.
Also StimulusJS and htmx are good for simple cases as long as you don't need a global state IMHO.
React has been almost fully backwards compatible going back to version 1. If you have react code that worked 10 years ago it will almost certainly still work just fine right now. That's more than a lot of other platforms. Higher number doesn't mean less backwards compatible.
> What are we at now, Rails 8? Is it just a reason to keep people employed?
8 major releases over 20 years vs 19 over 10.
Yet react 19 is almost (except for some edge cases that only affect very specific stuff) fully compatible with version 1. Try running a rails 3 app on rails 8 or vice versa.
The React versioning is a bit silly, but React 15 was the first major version (in 2016) which makes it more like 4 major releases in 9 years. Not that different from 8 major releases over 20 years.
developers get what they pay for. When one values their time at zero, vendors also value it at zero.
Tailwind v4 just gave everyone who uses sass the middle finger. It's rampant in the front end to rewrite because it's actually a solved problem. They need to explain their salary by reinventing constantly..
[dead]
[deleted]
That's javascript ecosystem in general. A revolving door of breaking changes and yet another web framework. Not to mention many many many tiny libraries.
To give you a simple example.
"What's the best web framework these days for fullstack JS work?"
Ok, Hono, found that. Installed it, great, it even runs well with Bun. Holy shit, it seems like JS is catching up! But now how do I talk to my database? Hono has no such thing, you're on your own.
Ok, let's use Prisma but setting that up there is no one-true-way, it's all blog posts and praying you followed the right one. Also Prisma seems to now work with joins?
Migrations? You set that up manually.
Deploying is another story.
Very painful.
---
Compare to Laravel, Rails or Phoenix. All these things baked in, one blessed paved road to tackle the common things 99.9% of web apps need. We are blessed to have all this great work for free, right at our fingertips. People donated a lot of time and love into building them. I hope javascript one day reaches that level.
It's still cowboyitis out there.
I've never heard of any of these tools. Maybe you should be more critical of the answers you get?
I've been sitting here as a react developer, quite stagnent in my toolset, using the same React I've been writing since 2015. The 'newest' technology I picked up was Typescript back in 2019.
> Ok, Hono, found that.
Weird that you went with some framework I've never heard of, and that definitely does not come up when I google for best fullstack JS framework.
> Ok, let's use Prisma but setting that up there is no one-true-way
I mean deployment always brings some complexity, but for the majority of JS frameworks you can get started by building it, throwing it in a docker container, and hosting that somewhere. I don't see what's difficult about that
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.
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.
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).
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]
SolidJS is what Svelte5 should have been
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?
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
[deleted]
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.
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.
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).
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.
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.
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.
Svelte compiles to Javascript. I don't think it's ever claimed to be Javascript. It's less weird and magical than React, IMHO.
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.
svelte <5 versions were sometimes hard, but they were, you know, pretty understandable.
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 :)
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.
That's exactly why I disagree with frontend framework fanatics. Before long, something your app was using in a legitimate way is obsolete because of someone's opinion, and you have to modify your already working code if you want to get bug fixes. We are told that frameworks save time, but do they really? Web components are supposedly not good enough or too hard to write... really? Making a router and a good-enough renderer that uses template strings and passes down state in a functional way can be accomplished in a matter of hours, or a few days if you have other things to do.
The Svelte API shouldn't have changed, IMO. If you want what Runes do, then why not use React? Svelte will probably look like React in a few years, and maybe even like Backbone after that.
My only complaint about Svelte 5 is that its so new that the LLMs aren’t good at it yet.
>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.
I for one am just excited that a Nostr post has organically made it to HN front page!
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.
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".
At what point will they reach SQLite?
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?
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.
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.
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.
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?
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.
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.
> 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.
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.
[deleted]
>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.
Vue moved the exact opposite way, and in fact Svelte moved more towards Vue 3 and its composables/CompositionAPI.
why mithril.js was though ? it is still a solid choice.
People who use observables-based frameworks are asking for trouble.
Every single industrial scale project I saw was inevitably breaking apart on seams.
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.
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.
Composable: https://github.com/CharlieDigital/vue3-state-definemodel/blo...
Vue Component: 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.
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.
The VueUse library is a really good place for these since it's all composables like `useClipboard`.
Here's an example of a Vue composable for the clipboard: https://github.com/vueuse/vueuse/blob/main/packages/core/use...
Here is an example of how it's used: https://github.com/vueuse/vueuse/blob/main/packages/core/use...
And the unit tests: https://github.com/vueuse/vueuse/blob/main/packages/core/use...
Another one from the same lib: https://github.com/vueuse/vueuse/blob/main/packages/core/use...
Unit test: https://github.com/vueuse/vueuse/blob/main/packages/core/use...
I'm pretty certain that Svelte took inspiration from Vue composables and I'd also guess that the community will have a bit of friction before people start to get its use cases (same as it was with Vue when it was introduced).
With Vue 3 and the composition API, you can do basically the same things you're doing in Svelte. You can also add SolidJS and Preact to this list as well - the magic ingredient in all these frameworks is signals, which allow you to have reactive data without having to have a UI framework to provide lifecycle events.
A good example in Vue is the top example in this page: https://test-utils.vuejs.org/guide/advanced/reusability-comp... The other examples show some other things you can do if you want, although I'd typically recommend against it - keep your signal-related code free of component/lifecycle-related logic, and it will almost always be much easier to test.
(As an aside, I'd add Angular to the list of frameworks that are easy to test, although the framework feels like it goes out of its way to convince you of the opposite. Services are just classes that maintain reactive data - originally via RxJS/Observables, although now signals are also supported - and if you keep them like that, they're fairly easy to test. Unfortunately, Angular's decorators/DI/module system is very pervasive, and at least when I was last using it, meant that even theoretically simple tests still needed lots of boilerplate. But theoretically, it belongs in the same category as the frameworks above.)
And short video walkthrough: https://youtu.be/7OhyP8H7KW0
That's just reactive programming, nothing new. It's sad that some people think it can only be achieved with wacky non-standard syntax.
This is something I didn't cover in my post, but I feel that's a bug, not a feature. Using runes instead of stores (which did the same thing in svelte 4) implicates the svelte compiler in every source file. This is ok if you're married to svelte, but it makes vendor lock-in even more rigid, since you would have to refactor all your regular utilities too when moving to a new framework.
One of my biggest gripe with svelte.
In the js world you're shooting yourself in the foot by choosing a framework that is as locked in as svelte (no vdom,domain-specific-language and their design philosophy), had to find this out the hard way.
I still respect svelte for it's engineering capability, but it's a 100% commitment with no off-road options ever, but if you need a framework for js and don't like react or angular then vue would be my choice.
I'm a bit confused about this - if I build something in React/Vue... I'm never going to be using Vue/React alongside it, or anything else. Am I missing something? Who's out there changing frameworks in existing projects?
Or is this about something else?
Not a lot of situations, but React in theory can be used down to specific pages enabling progressive adoption/ easier Swapping
Also, it's a things metaframeworks enable (Like Astro)
These days, vendor lock-in hardly feels like a worthwhile consideration when evaluating frameworks. A near complete rewrite feels inevitable when transitioning from, say, React to Svelte.
I don't understand this comment. How is it different from hooks and JSX components? In React codebases theres a lot of logic in React-specific files.
I don’t even think it would be possible to "move to a new framework" without starting from near scratch.
If it's a similar transition to the one from Vue 2 Options API to Vue 3 Composition, then I expect there will be a bit of a bump, but it'll make a lot more sense afterwards. The VueUse library is probably the poster child for why this pattern is super useful.
One way to reduce the lock-in would be to wrap runes in a Vue ref lookalike, it'd be no more worse than relying on Svelte 3/4's built-in store implementation.
I feel like I must be misunderstanding you. React is certainly unit testable and developers do test it - just ask react-testing-library (10M weekly downloads).
I'm not a Svelte dev, so I don't really follow the distinction you're drawing. What is it that supposedly makes Svelte more testable?
I haven't used React in a while so I'm happy to learn more.
When I look at this example it does not look like the code I would be using inside my webapp. I have a rule of thumb: my test code should look the same as the code when it is inside my app.
https://testing-library.com/docs/react-testing-library/examp...
My Svelte 5 runes test code uses the code in exactly the same way that I use it inside my .svelte templates. That's very different in my opinion.
testing-library (and react-testing-library by extension) has a very dogmatic "black box" approach to testing FE code. In many ways it more closely resembles e2e testing than more traditional unit testing does.
Personally, I think it's a PITA since it's pretty rare that copy (such as text labels) ever remains stable for very long, or are sufficiently unique on the page, so I do the "strongly discouraged" route of using data-testid attributes for everything (which also has the side effect of making people who write e2e tests happy, but I digress).
With all of that said, I find myself rather appreciating the approach. I don't need tests to mirror the implementation, only the interface.
Can you link to/post an example of how Svelte is tested that's different?
In the Full Example linked, the only code that it makes sense to talk about being in the app itself is the code to render the component, and that does look precisely the same.
The rest is the testing logic - inspecting the state of the DOM post-render, interacting with components by simulating events, and so on. I don't see how this could correspond to anything in the app proper.
Yeah to be fair testing a fetch request is not the best example right off the bat. That's an outlier IMO.
That said it's very very easy to write similar looking code using react testing library as long as you're good about separating business logic into a hook. Where it gets dicy & hard to test is when components have complex state/effects co-mingling with render logic.
Business logic is very easily testable as a hook, something like:
``` it('toggles switch state', () => { const {current} = renderHook(() => useSwitchState);
} ```Render logic is a bit different because React Testing Library's philosophy is to test as a user would interact with the UI, so that looks more like:
``` it('switches state on button click', () => { render(<Switch onToggle={mockOnToggle} checked={false} />);
}); ```Fact is testing frontend code is really hard _because_ people don't build frontend code in isolation. I found that testing is much easier when using tools like storybook and browser-based testing tool (so no snapshot testing, no fake-dom).
Right now I am working on a legacy project with ~10 years of work into it, about 15% of the code in there I don't even know how to trigger in the application (lots of weird specific circumstances that require special types of accounts to trigger). I just had to make a small change to hundreds of files and it was hell to manually test it everywhere.
IMO almost all components should be able to be renderable in isolation and mocked data. Type systems help with this problem because they remove a whole layer of tests required, but it is not enough.
> It is as good as unit testing, but reactive in the browser.
I am confused about this because on the one hand, you seem to be hinting at my favorite, under-hyped aspect of testing, which is its use (via TDD) as a controlled-state print/debugger, but on the other you seem to be eliding the most popular--albeit, in my view, less important aspect (insofar as one aims for "working software over comprehensive documentation"[0])--the preservation of behavior across commits and into the future.
What am I missing?
Edit: re "reactive in the browser," that's how I run @benchristel/taste[1]
0. https://agilemanifesto.org/
1. https://github.com/benchristel/taste
> svelte people have always cast a narrow eye towards typescript and for good reasons as well.
Out of curiosity, could you elaborate on this a little?
But, briefly, TS is tricky if the entirety of the ecosystem isn't TS. It's becoming less of a problem, and things like deno and bun that have native support for TS are solving the problem, but Rich Harris made compelling arguments for why they went with JSDoc. And, I don't think that is a perfect solution either, but I can write code that runs even if the JSDoc isn't correct, and I can't do that when the TS compiler refuses to compile for some reason like an external library isn't right.
This is why the types-as-comments proposal for ecmascript could be a game changer, most ts files would magically become valid js files; no compilation needed
Svelte supports TypeScript, but the project itself dropped it for JSDocs a year or so back.
Here's a discussion on it, with the first post from Rich Harris himself with some reasoning: https://news.ycombinator.com/item?id=35891259
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.
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.
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 :)
> 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.
You should already have a clue, you have to write a lot of JavaScript in order to get Svelte doing what you'd expect outside of very simple components. See these actions as an example, and check out the JS file! https://svelte.dev/tutorial/svelte/actions
Svelte makes more sense if you enjoy the JavaScriptisms. In which it provides enough "magic" for most things, but still lets you enjoy JavaScript.
No, I write a fair bit of TypeScript when I need to make a frontend in Svelte.
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.
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.
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.
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.
I've witnessed a company that started moving away from their KnockoutJS solution to react.
In that time, the knockout parts have kept going strong. The react parts have seen three different paradigms ( React classes, Functional react with redux, React Hooks ) and still hasn't fully settled down given there's also churn in the CSS-in-JS space.
The very occassional time something in the remaining knockout parts need fixing, it's just a harsh reminder that it worked fine.
I'm fairly sure the react portion is still not even on the very latest version of react because some other dependencies are stuck on older versions and they themselves have breaking "API changes" (i.e. complete rewrites with no semblance to the original ).
As someone here also said, maintainers in the JS/TS ecosystem appear to have no respect for their users.
It might sound entitled, but sometimes not completely rewriting your framework's API to a completely incompatible one is a better choice. Even if that means putting up with a slightly worse API than you'd like.
I guess everyone moves so fast that there's a fear that sticking on the old API would just lead to dying off at the hands of a new upstart with a smoother API.
But the alternative is a constant abandonment of projects. If a major version change requires a complete re-write then really the new version is a new project entirely that's re-using the namespace and maintainership.
But perhaps emberJS fell away precisely because it didn't rewrite itself to stay "modern". Maybe this is a "worse is better" situation where the world optimises for the wrong things.
"Has had a mostly stable API for a decade" just isn't something people select for. If it were, then things like ASP.NET would be far more popular.
React has had a mostly stable API for over a decade
How so? Hooks are only ~5 years old.
Meanwhile they've deprecated parts of the class components.
> My personal problem with JavaScript is that things keep changing too much.
JavaScript itself barely changes - it's the flavor-of-the-month frontend frameworks that do. What language feature is commonly used now that wasn't 5 years ago? Some nicer builtin Array methods I guess?
There's a lot of dislike on here for Typescript as a backend language. But the difference with the frontend world with its dozen everchanging frameworks is striking. On the backend side, most projects don't even use a framework, and for those that do basically all of them use the same one (NestJS). And the rate of breaking changes on that has been much lower than something like React.
Of course, many will say that this lack of industry-wide adopted framework in itself is what they dislike about it. But it's hard to settle on that golden mean inbetween both extremes when it's the most popular language in the world (in terms of "Yearly new LOC going into production"). Python makes for a good contrast, with a dozen popularish backend frameworks. Not sure if that's really a better situation to be in, there's pros and cons.
And to expand on this further, I think the real driver of the "javascript always changes" is React. Depending on when your React project was built, it can be incompatible in so many different ways with a React project from a different vintage. Sure, a lot of other frameworks and tools that pop up here and there, but none of them are ever widely adopted. When compared to Vue and Angular which I think we can all agree are the other two frameworks of note, React has been very unstable, Vue and Angular appear quite stable.
The javascript language itself hasn't really had a breaking change of note that I can remember in the last 15 years? It's just expanded its API from years and years of browser implementations trying stuff and trying to get to an actual standard. HTML5/ES6/CSS3 brought a new kind of baseline sanity to the whole thing. That's not to say it's a perfect language without quirks, but to say it keeps changing is just not even accurate at all.
python has version evolution, C++ has version evolution, they kinda all do...
Have you worked with Angular much? I've built extensive component libraries (internal) for my org and maintaining the Angular one has been a nightmare. The frequency of breaking changes and conventions has been awful, particularly in the last few years. React, by contrast, has been a breeze ever since they introduced Context and Hooks.
On the app development side, we dealt with 3 major overhauls of PrimeNG's style system before we decided to invest in a custom library just to eliminate the risk of future upgrades. It took us 6 months to migrate our Angular 9 app to 18 because of the PrimeNG dependency. Granted, it's a massive application and they didn't maintain it properly, but I'd hardly call Angular stable regardless.
And then you have the Vue composition API, which was a major shift from Vue 2.
This isn't to say that React has been perfect. Depending on your stack, there are certainly a fair degree of breaking changes (looking at you, Next.js and react router). But that is far from abnormal in the JS world.
A React class component from 10 years ago will still work in React today perfectly well, and is doing so in large codebases around the world.
Then again, React projects tend to use fast-moving things on top of React, like Redux or NextJS or CRA or whatever. Personally, I enjoy writing stuff in bare React since I like its model, but people tend to steer well clear of that, especially these days with compilers and bundlers and whatnot attached to the frameworks.
I agree, bundlers and bundler plugins have probably been the main thing people see with JS ecosystem and think is overly complicated.
> A React class component from 10 years ago will still work in React today perfectly well,
This isn't true.
ComponentWillMount and related methods were deprecated and then removed.
Yes, they allowed an escape hatch of UNSAFE_ComponentWillMount etc, but that still requires work to make it compatible, so it definitely doesn't "[work] perfectly well".
> Vue and Angular appear quite stable.
I take it you didn’t have to deal with porting an AngularJS app to some other framework, like Angular 2.
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.
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?
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.
I have a number of ember projects on vite if anyone wants to take a look:
- https://github.com/krausest/js-framework-benchmark/pull/1835... - https://github.com/NullVoxPopuli/markdown-table-viewer - https://github.com/NullVoxPopuli/package-majors (older, needs update, which i can do pretty quickly if i remember to do it)
Agree, overall ember has felt stable and only improved with age, unfortunately becoming increasingly niche.
At my company I mentioned using it in passing to our cto as we were discussing a project to move our core web app from angular to react, and he laughed saying "maybe if this was 10 years 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
Ember is working through a migration replacing their build system and bundler with Vite -- all while maintaining backwards compatibility to a version released in 2021. Ember will be fun to watch in the coming year.
Depending on how you count it that could be a version originally released in 2018 i.e. the version they are aiming to support is 3.28 which you should be able to easily update to from 3.0 (which was released in 2018) since it's a minor update with no breaking changes
> My personal problem with JavaScript is that things keep changing too much.
Yeah.
Last year I realized in my 10 or so years using Node I've changed my stack so many times (Express, Hapi, Fastify, Hono, Sequelize, Objection, Prisma, Drizzle, Mongo, Fauna, Postgres, Firebase, etc etc). So much time wasted.
Surprisingly, on the frontend I've found stability with Svelte. I've been using for 4-5 years now and still very happy with. I also love runes.
I used Ember and it sucked. It was too complicated and the community was elitist and hostile. Then it got extremely woke and political and even shut down the docs which made me lol and really dislike the project and its authors.
Nothing woke as far as i can see.
Sorry there was hostility when you were around. We try hard to keep hostility out and keep everyone civil now a days
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).
Oops, you're right, here's the other issue: 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.
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-typesc...
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.
> 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.
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.
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/
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/
Lit's used by pretty major apps like Photoshop, Reddit, Home Assistant, and The Internet Archive.
What are the best resources for approaching complex enterprise apps with Lit?
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."
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.
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/
Reminds me of karet [0]. I used it with great success for making interactive visualizations. This duality of passing a value or passing a stream of values was great.
[0] https://github.com/calmm-js/karet
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.
They've turned React into Angular 19 with signals. Heh.
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.
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.
Honest question - have you ever tried to use the actual web components API? It very much feels like a set of primitives to build a framework on top of. I can't imagine the amount of boiler plate you would need to write to just use web components.
With a simple 500-line lib you can write Web Components just like React, here's an example: https://github.com/wisercoder/uibuilder/blob/master/WebCompo...
Right and Lit is that exact framework and it’s amazing.
Using blazor as an example of sane web development is so odd to me. Have you actually used it? Not only is it a mess in terms of development (live reloading basically does not work, you either depend on SignalR and your website becomes unusable the second you lose connection, or use wasm and have a terrible mess of a canvas based frontend that barely works), but it's also terrible for users.
I know hating on frontend dev is trendy, and I guess blazor is the logical end to that aversion to actually using frontend tools, but if anything it's the perfect example to show how much worse web dev would be without JavaScript frameworks. There's a reason it's only used for internal tools.
I'd take any react+JavaScript "bloated" websites over this. Especially on mobile. https://bootstrap5demo.blazorise.com/
I really have not liked htmx at all. Anything dynamic with it is a big, big pain...
IME a lot of the pain comes from picking the wrong tool for the layer.
By that I mean saying everything has to be a JS framework or everything has to be server-delivered-HTML.
For very dynamic & interactive things maybe it makes sense to write it just in JS without a framework?
For full pages for data-powered applications (that heavily benefit from types & Typescript), maybe it makes sense to use something like Golang on the server.
And then you can embed those interactive dynamic islands inside the data-intensive application, with a thin layer of communication between the two.
Just my 2c - I've found that pattern to be super compelling
I agree but the dominant view is that everything has to be a SPA and having some html delivered by the server is considered bad.
I agree. I really wanted to like it, I do think a lot of what it purports to try to do would be better for the web and development in general, but my experience is that HTMX (even with Alpine) fails to succeed in practice.
Use Alpine for dynamic client-side. Htmx is focused on talking with the server.
I should have clarified that yes, I used Alpine with htmx.
State management for smaller vanilla JS projects that works 9/10 times for me:
I'm only 1/4(.0000000004) serious here. That said, I've been doing this for almost 30 years, I was a kid when I picked up Netscape, I have gone through every mainstream and many niche libraries/languages replacing libraries. Now, in my late 30s I finally can grow a moustache (a big achievement in my family gene pool) but the analysis paralysis is still making me anxious every time I pick up a new project.- preact w. signals or Svelte are still my libraries of choice if I need to spike something, but that's partially because of signals and vite. The development experience is good, there isn't much magic you need to deal with on a daily basis.
- Web Components are great in many ways, but they don't solve the problems I usually have with bigger projects (scaling state, orchestration for the lack of a better phrase). Lit makes it a bit better though.
- JSX is actually not that bad, as long as you treat it as a DSL around functional composition. Native JSX + signals would probably make most of my node_modules redundant.
(please don't overthink this, I didn't)
What most people need is good routing solution but it’s hard to make it with SSR. Seems like frameworks are somewhat converging now on this app router concept.
Agree that JSX is great (but styles like in Svelte also).
> Agree that JSX is great (but styles like in Svelte also).
Oh yeah, 100%. One of the reasons I like Svelte are colocated CSS modules.
> seems like frameworks are somewhat converging now on this app router concept.
That for sure, and signals in one way or another. It took us 10+ years, Solid.js then preact to bring back a pattern from 2010s (IIRC) implemented in Knockout.js.
People are talking about declarative signals in HTML. I don't have a formed opinion about them yet.
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.
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.
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.
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
as long as you like it, keep using it! I wouldn't try to make generalizations from the HN or reddit bubbles.
If you want your own Web Components, you're going to build an entire framework around the creation and management of them because making proper 'web components' for your project is in effect a whole other project
How is Blazor not a JS framework?
That last one is a big stretch. Blazor is uhh.. not pleasant to use
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.
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...
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.
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.
Yeah, React really fumbled the bag with server components.
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.
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
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?
I wish that the Crank library (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.
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".
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
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.
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.
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.
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.
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.
The article mentions 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.
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?
Front end development is a 90% self-induced hell. There are real challenges like accessibility, processing data from service calls, architecture, and more.
Those aren't the things most developers complain about. Most front end developers spend their energy on concerns of code style, tools, build steps, framework madness, state management, and more. Those are fashion concerns. A decent programmer can solve for most of those themselves without external tooling in a fraction of the time and code size, but not everybody that does this work is confident writing original code.
I can't even begin to count the number of codebases I've seen where developers rolled with this idea and ended up with royal spaghetti. Everyone thinks they can build these frameworks from scratch, but they overlook the unknown unknowns. Nearly every custom implementation of state management, complex forms, async flow management, etc I've seen in the wild is riddled with countless bugs that could've been avoided if they just picked a boring and widely used library. And I've seen plenty, because I'm usually the guy that gets called up when no one else can untangle it anymore.
Yes, I have seen that countless times too. Developers that have no idea how to write original software think they can go without a framework and then write a framework. That is stupid, and its because those developers know something about frameworks but never learned to program. Stop toying with irrelevant nonsense and actually release a product for users that solves from some real business requirement, which is certainly not a framework.
State management is absolutely a real front end concern. That's what you're going to be spending a lot of your time on; you better make sure you do it well. Code style is roughly a solved problem thanks to Prettier, as is build steps with Vite. And I don't know what you mean that "framework madness" is a fashion concern. You have to pick a framework, you can't just avoid that part.
> State management is absolutely a real front end concern
That’s because most SPAs are duplicating backend logic.
They often do that because of the REST/CRUD chokehold where the backend does a bunch of stuff, squeezes the resulting data into extremely basic primitive actions (e.g. GET, POST, PATCH, DELETE), forcing the frontend to recreate a complex state all over again. GraphQL tries to solve this, and usually frontends that rely on that avoid a lot of that duplication of the backend, but devs sometimes manage to scream up even that.
If we kill REST, a lot of the complexity around frontends would be reduced significantly. You don't even need GraphQL or RPC protocols to do that.
REST is not a browser concept, it’s just a pattern. There’s no need to “kill” it. The HTTP protocol is more than enough to interact with a server that store resources and a client that display them. If you’re sure you need another set of verbs and nouns, use http as a tunnel.
> REST is not a browser concept
I didn't say that it was specifically. REST is still a convention that is usually tied to and influenced by HTTP and its methods. It doesn't necessarily have to be that way exactly, but that's how many web applications are typically written.
> There’s no need to “kill” it.
We don't necessarily need it around either.
> If you’re sure you need another set of verbs and nouns, use http as a tunnel.
That is somewhat along the lines of what I'm suggesting. REST is not necessarily better than an API that just takes POST requests in a way that serves the application's needs directly rather than some abstract standard that homogenizes data in ways that require extra work to be done. For some odd reason, many frontend-oriented developers look at me like I've got bugs crawling out of my ears when I say this, yet the idea of allowing the server to do the bulk of the work is both old and resurging in popularity (e.g. Hotwire, LiveView, HTMX).
Yes, because in the scenarios where a SPA is appropriate, round-tripping on every state change is terrible UX.
In such scenarios, there's no need for round tripping because the state are different. But in every SPA that should be an MPA, it's always state duplication.
A certain subset of SPAs need to duplicate backend logic because they necessarily and unavoidably have local state. For instance, optimistic updates require some redundancy with backend logic.
thanks, I'll reuse that one!
Yes, it is a real concern, but its supremely trivial to solve for. Frameworks make this into chaos madness because frameworks have to solve for both the goal of state management in addition to their own divisible component concerns that come and go with user interactions.
I'd be very interested to hear how state management is supremely trivial to solve for.
Ummm, no. I have been through this before and its always a paradox.
The paradox works like this: If you were capable of writing your own software the triviality of state management becomes self evident. If you are not capable of writing your own software, such as full eternal reliance on some tool set or framework, then the answer doesn't matter.
I've written my own software, both with and without state management frameworks. To be honest, I didn't find state management to be particularly "trivial", except when I worked on trivial applications.
In many cases this is true (typical CRUD apps), the tools (react etc) are too way too heavyweight for the job. It may even be some large % the case that it is a self-induced hell.
However, I think frontend is often quite underrated in its essential complexity. I don't share the opinion that state management is a fashion, it's often tightly intertwined with the UX requirements, which can be varied and have all kinds of difficult essential complexity of their own (often complexity that is under-specified, and up to the programmer to discover).
The lack of experience of many frontend devs, combined with the limitations of dynamically typed Javascript, is a recipe for a lot of very gnarly code. Maybe it would be fair to say that this is self-inflicted, but I am sympathetic. It's quite a difficult problem.
When I think of 'total own-goal', completely pointless self-inflicted hell, I think of Python package management.
I'm so tired of those comments. It's almost always come from those who refuse to research before they talk, only echo what they learned from other people.
Do you know why there are new frameworks, new versions every time? Because web is a moving target. New js/css/html5 features are released every day and the libraries have to update to adopt them.
Back in the day you do not have css variables, so you have either use sass and do all the math inside the preprocessing process, or crazier, using those shitty css-in-js libraries to calculate css properties on the fly. Nowadays you can pass around the variables and it can cover almost all the case. In able to pass the css property to the component, you need to improve your framework.
Another example is html5 history API, back in the old days people implemented link components in SPA with buttons (hilarious but it happened), only after History API is introduced there raised the need to manipulate the history properly, thus another rewrite issued.
before that, ES5 introduced `class`, proving yet another way to write js code, which in some situation make cleaner code than the plain old js functions.
everything in the web is moving, new nice things are introduced every month, if you want to create a modern and performant web application, you need to keep up with the new fancy things, frameworks are no exception for that.
What does this have to do with frontend work? Major version updates are common across any part of the stack. Just off the top of my head, SQLAlchemy has a seven step migration process[1] from 1.4 to 2.0, and it's absolutely not the kind of thing you could pull off in a few days if your code base has grown past a certain size.
[1]: https://docs.sqlalchemy.org/en/20/changelog/migration_20.htm...
> 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.
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).
It a software problem, not a frontend/backend problem. We've all been subjected this insanity in some way.
Its severity varies between ecosystems, though, and JavaScript is especially crazy in this regard. Frontend JS, doubly so.
That seems to be a problem that is getting worse with time though, with increasingly frequent "major" releases and fewer that consider backwards compatibility much at all. Also it used to be much more common to have published specs and standards that you could code to for a good chance to not have to rewrite your code next month.
Except usual time to upgrade to next version of .net is less than man day.
No one is forcing you to upgrade, Svelte 4 still works just fine? Svelte has had basically no major API changes since 2019, that's a better part of a decade. And with this new architecture change, they released a sophisticated codemod to do most of the work of updating for you.
Great until your dependency scanner picks up a vulnerability in the framework or a dependency that can't be upgraded without breaking v4, no exemptions can be given and the only updated version is 5. [1]
[1] https://endoflife.date/svelte
If it's already end of life you can fork it and upgrade the dependency. You'll miss nothing. This is only difficult if you need to maintain changes upstream, but that's not the case here.
Security support lifetimes make sense for a widely used language or runtime, but not really a frontend web framework on the most backwards compatible language you can have.
In fact, you can still use Svelte 4-style components with Svelte 5, even in the same project.
Honestly it’s exhausting seeing endless posts from people who don’t do frontend development saying “wow, looks awful!” having made zero effort to actually understand the scenario.
> They seem to have no respect for peoples time or any consideration for longtermism or even just the common decency of backwards compatibility
You mean Svelte 5, the backwards compatible framework that makes all of its new features an optional opt-in? That one?
> What are we at now, React 19?
Allow me to introduce you to the concept of semantic versioning, otherwise known as “a versioning system that has defined meaning”. Any breaking change means a new major version, which is why the numbers increment at a rate that is apparently terrifying. These breaking changes are often absolutely tiny and trivial to adapt to.
I don’t even like React but the upgrade path between major versions is rarely a big deal. You’re taking a non-semantic versioning mindset (new version number? Guess I have to rewrite everything!!) and applying it in a scenario where it doesn’t fit.
> Honestly it’s exhausting seeing endless posts from people who don’t do frontend development saying “wow, looks awful!” having made zero effort to actually understand the scenario.
Inevitably we will see it in every front-end related thread until the end of time.
> Honestly it’s exhausting seeing endless posts from people who don’t do frontend development saying “wow, looks awful!” having made zero effort to actually understand the scenario.
There's much bigger topics afoot in the world that also make me think humanity desperately needs better tools to defend & equip ourselves with broadscale collaborative efforts to shut down & reject-by-default negative-valence posts.
The hater-squad has the easiest job on the planet attracting some fellow people who also want to resist learning, change, or who want to feel more secure in their current position. The Dark Side is strong.
"What are we at now, Ubuntu 24?"
For what it's worth, between 2011 and 2016, React shipped versions 0.0.1 to 0.14.0. Then in 2016 they said "fuck it, we're stable now" and jumped immediately to 15.0.0 (they considered 0.14.0 to be mostly equal to 14.0.0).
Then they did 16 in 2017, 17 in 2020, 18 in 2022, and 19 finally in Dec 2024. I don't think 4 major versions in ~9 years is a world breaking amount of churn. I have my problems with the team's development of React, but I think they have a pretty sensible view of breaking changes and limiting churn.
> You're telling me you updated YOUR code to work with the latest framework release?
Next time I'll tell you how people used to update their code to use Python 3! Shocky-shocky.
That was also an obviously terrible idea, iirc to the point even python leadership aims to never do it again
And yet Scala did it next. And both were dramatically worse than what is happening here. Just frontend FUD
There is really no place where updating dependencies is dramatically better. Back end frameworks and even whole languages have this problem. On the front end, I mostly use React and it has been fairly backwards compatible. It's a tradeoff. If you never ever make breaking changes you can end up constrained by previous design decisions. If you make them all the time users won't be able to keep up.
> There is really no place where updating dependencies is dramatically better
This is absolutely untrue. There's a huge gap in how easy it is to upgrade some stacks vs. others.
Updating dependencies in a language with strong, static types and/or an expressive type system is incredibly easy, for example:
Step 1: update dependencies
Step 2: fix compiler errors
Upgrading major versions of .NET, for example, sometimes requires no work at all.
This is not true in JavaScript, Python, and some other languages where you're only going to discover issues during runtime.
TypeScript makes things a lot better, but you're relying on the authors of your dependencies either using TypeScript or keeping types up to date.
> There's a huge gap in how easy it is to upgrade some stacks vs. others.
This I can agree with.
> Updating dependencies in a language with strong, static types and/or an expressive type system is incredibly easy
Java would typically be regarded a pretty close to .NET in regards to its type system, yet I've seen plenty of issues with updating dependencies, whenever you have any sort of dynamic class loading or reflection going on: be it Lombok or MapStruct not liking a specific version of Java, or Spring Boot or one of its many integrations throwing errors during startup after a successful compile, sometimes even disliking specific annotations that worked previously.
A decent type system will help you make sure that the code compiles, sure (and I'm thankful for that), but with some styles of writing code and handling, for example, dependency injection, all bets are off. The same goes for any dependencies that make liberal use of those features. I'd have to dig around for specific examples, but I know for a fact that there are plenty of projects that are stuck on old versions of Spring for that very reason.
Or the fact that there are plenty of pre-.NET Core projects out there that won't be upgraded to anything new anytime soon for similar reasons.
In my experience, updates suck across the board, the only variable is how much. And that applies to everything not just dependencies in code (and runtimes): I've also had seemingly innocuous Debian updates break GRUB and prevent the OS from booting, or even upgrades making exim4 start up for some reason and taking up the port that my mail server needed, preventing it from starting.
I was a bit broad here. I am sure certain projects get things better than others. When I said no place I was more referring to whole categories of development like, front-end, back-end, embedded, data pipelines, ect...
I love types and advocate their use whenever possible. They help a lot but they are a spectrum. Thanks to static analysis tools like TypeScript or even eslint you can get a bit towards automated checks on front end code. Also even compiled languages can miss some things, different languages have type systems that give you different kinds of guarantees. For example, Java has NPEs that can't be caught at compile time.
Personally I've picked Vue over React like height years ago and it's been mostly great, never regretted it.
Also StimulusJS and htmx are good for simple cases as long as you don't need a global state IMHO.
React has been almost fully backwards compatible going back to version 1. If you have react code that worked 10 years ago it will almost certainly still work just fine right now. That's more than a lot of other platforms. Higher number doesn't mean less backwards compatible.
> What are we at now, Rails 8? Is it just a reason to keep people employed?
8 major releases over 20 years vs 19 over 10.
Yet react 19 is almost (except for some edge cases that only affect very specific stuff) fully compatible with version 1. Try running a rails 3 app on rails 8 or vice versa.
The React versioning is a bit silly, but React 15 was the first major version (in 2016) which makes it more like 4 major releases in 9 years. Not that different from 8 major releases over 20 years.
developers get what they pay for. When one values their time at zero, vendors also value it at zero.
Tailwind v4 just gave everyone who uses sass the middle finger. It's rampant in the front end to rewrite because it's actually a solved problem. They need to explain their salary by reinventing constantly..
[dead]
That's javascript ecosystem in general. A revolving door of breaking changes and yet another web framework. Not to mention many many many tiny libraries.
To give you a simple example.
"What's the best web framework these days for fullstack JS work?"
Ok, Hono, found that. Installed it, great, it even runs well with Bun. Holy shit, it seems like JS is catching up! But now how do I talk to my database? Hono has no such thing, you're on your own.
Ok, let's use Prisma but setting that up there is no one-true-way, it's all blog posts and praying you followed the right one. Also Prisma seems to now work with joins?
Migrations? You set that up manually.
Deploying is another story.
Very painful.
---
Compare to Laravel, Rails or Phoenix. All these things baked in, one blessed paved road to tackle the common things 99.9% of web apps need. We are blessed to have all this great work for free, right at our fingertips. People donated a lot of time and love into building them. I hope javascript one day reaches that level.
It's still cowboyitis out there.
I've never heard of any of these tools. Maybe you should be more critical of the answers you get?
I've been sitting here as a react developer, quite stagnent in my toolset, using the same React I've been writing since 2015. The 'newest' technology I picked up was Typescript back in 2019.
> Ok, Hono, found that.
Weird that you went with some framework I've never heard of, and that definitely does not come up when I google for best fullstack JS framework.
> Ok, let's use Prisma but setting that up there is no one-true-way
Maybe the docs? https://www.prisma.io/docs/getting-started
> Deploying is another story.
I mean deployment always brings some complexity, but for the majority of JS frameworks you can get started by building it, throwing it in a docker container, and hosting that somewhere. I don't see what's difficult about that
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.
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.
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).
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.)
SolidJS is what Svelte5 should have been
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?
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
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.
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.
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).
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.
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.
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.
Svelte compiles to Javascript. I don't think it's ever claimed to be Javascript. It's less weird and magical than React, IMHO.
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.
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 :)
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/98734433376e99909fb6...
[2] https://github.com/sveltejs/svelte/issues/11626
That's exactly why I disagree with frontend framework fanatics. Before long, something your app was using in a legitimate way is obsolete because of someone's opinion, and you have to modify your already working code if you want to get bug fixes. We are told that frameworks save time, but do they really? Web components are supposedly not good enough or too hard to write... really? Making a router and a good-enough renderer that uses template strings and passes down state in a functional way can be accomplished in a matter of hours, or a few days if you have other things to do.
The Svelte API shouldn't have changed, IMO. If you want what Runes do, then why not use React? Svelte will probably look like React in a few years, and maybe even like Backbone after that.
My only complaint about Svelte 5 is that its so new that the LLMs aren’t good at it yet.
>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.
I for one am just excited that a Nostr post has organically made it to HN front page!
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.
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".
At what point will they reach SQLite?
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?
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.
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.
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.
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?
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.
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.
> 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.
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.
>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.
Vue moved the exact opposite way, and in fact Svelte moved more towards Vue 3 and its composables/CompositionAPI.
why mithril.js was though ? it is still a solid choice.
People who use observables-based frameworks are asking for trouble.
Every single industrial scale project I saw was inevitably breaking apart on seams.
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.
[dead]