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.
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.
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.
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.
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.
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.
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]
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.
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.
> 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.
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 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.
> 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...
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?
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.
> 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.
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).
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.
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.
Readit News
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.
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.
I don’t even think it would be possible to "move to a new framework" without starting from near scratch.
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.
Deleted Comment
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?
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.
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.
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
Out of curiosity, could you elaborate on this a little?
Here's a discussion on it, with the first post from Rich Harris himself with some reasoning: https://news.ycombinator.com/item?id=35891259
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.
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.
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 Comment
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.
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.
Astro + Svelte seems nice enough if you need it but for most of what I do, plain Svelte 5 is great.
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.
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.
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.
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...
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.
- 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)
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!".
Deleted Comment
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.
Sorry there was hostility when you were around. We try hard to keep hostility out and keep everyone civil now a days
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.
[0] https://jcuenod.github.io/bibletech/2025/02/16/beyond-typesc...
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.
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.
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.