It wasn't my decision, but it is a choice I agree with. I would generally avoid Svelte for the same reason I'd avoid Coffeescript; a compile-to-JS language had better bring some radically useful semantics with it to justify a new syntax. Elm and Clojure meet that criteria. Svelte doesn't.
I like Svelte, actually. I think it's quite powerful and comes with a nifty toolkit. I just don't enjoy working with frameworks that view the DOM as a hostile environment from which devs need protecting.
I believe the opposite
The further a superset moves away from the base language, the more difficult it becomes to integrate with the ecosystem
This is why TypeScript won, because it adds only the minimum necessary to accomplish a specific goal
Among the syntaxes that unite js and html out there, I think svelte is the one that tries the hardest to maintain the separation between what is the base language and what is an addition
And tries to add as little as possible to achieve its goal
In the sense that Svelte, like React, you must either code within the walls of the framework, or be good enough with the DOM as a platform that the framework is just perpetually in the way. JavaScript (and Typescript) and the DOM are powerful enough; don't obscure them with tooling.
as someone who primarily builds UI for the web, the semantics of Svelte (and Svelte 5 in particular) are incredibly useful to me, especially when you consider that most big apps in 2025 are already compiling typescript anyway
Trying this now and I'm very torn.
- Losing react-aria is huge. It's a gold standard for accessible UI, and Svelte doesn't come close. Melt UI and shoelace don't fit the same
- There are definitely "rules of runes"
- Lang tools are a bit wonky. Hit out-of-date imports and unexpected load times
"Rules of runes" and lang tools being wonky is on point. I love Svelte and have used 5 since pre-release. These pain points don't get nearly enough attention for how painful they are lol.
I'm also doing a client only app. React has react router, which makes SPAs easy to DIY. Svelte only has SvelteKit, which really, *really* wants you to SSR. Even following the instructions to enter SPA mode, you still need `if (browser)` checks for loaders or global exports
What’s your primary motivation behind the desire to switch? FWIW Solid has the same perf benefits, comparable UI libraries (Kobalte), and a great client-only router. And if you’re primarily concerned with Svelte’s syntax niceties, Solid Labels has you covered there too:
Hopefully some day Svelte will have a headless UI library comparable to React Aria or Kobalte, that’s the biggest thing that keeps me from using it too. Well, that and a standalone router, but I hear (🤫) the Remix team is cooking up something universal and exciting as part of Reverb.
lol I know, Dave says I need to talk about it more often, but surely folks are tired of hearing “you know, Ember already does this…” about every new feature added to a JS framework ><
More like making a first party router that's used _within_ Kit. The direction of travel is chipping away at the Kit machinery until it's a thin wrapper built from swappable parts. To do that we need certain primitives to exist, and when I say 'working on it' those are mostly what I'm referring to
HTML is accessible by default, having a React components library just for this purpose is in my opinion, a not good indicator. Wrote ton of accessible React components without needing any extra layer of packages.
Which means… Svelte is also accessible, you only need to put a little effort.
I understand this principle, and I still work this way. But...
- building an accessible tab view takes a week+ of reading the w3c spec. I did this at a previous job
- building accessible tooltip interactivity can take more effort
Popover and dialog give me hope that plain HTML can solve these problems natively. But there are so many nuances in app-like UIs that are hard to master, and will take years to see in browsers. I've solved these problems by hand for years, and I want to leave them to the open source community now
I thought it too. Until I realised that problem is in business (“more features, less A11Y or tests”) and in developers that are lazy (“they don’t care at the beginning”).
Adding accessibility to big scale enterprise app may take months… only because nobody planned and cared beforehand.
I feel you there. But there are a number of libraries that ONLY have the react flavor. Ex: Really bummed to lose react-aria. It's a gold standard for accessible UI and has a war chest of components. Melt UI is really behind, and shoelace just feels weird to use. I'm type casting everything
React Native is the best of the best for mobile. Native feel and native gestures are very important to get right (for my quality bar), and that just isn't possible with webviews. And when React Native fails you, you can drop down to native Swift or Kotlin code per-component
*yes, you might end up with React Native on mobile and React web on desktop. They're not interchangeable, but the mental models are at least. Svelte on desktop and React native on mobile requires a deeper mindset change
Eh, I wouldn't for mobile:
- Webviews lock you out of full-native UI + gestures. Especially noticeable on iOS. React Native gets closer to native feel and has an escape hatch to just write Swift
- Tauri is... rough. I used it for a few months, and the poor docs + rust compile times were painful
Comments
The further a superset moves away from the base language, the more difficult it becomes to integrate with the ecosystem
This is why TypeScript won, because it adds only the minimum necessary to accomplish a specific goal
And tries to add as little as possible to achieve its goal
https://youtu.be/1sIyNE6WNXY
- Losing react-aria is huge. It's a gold standard for accessible UI, and Svelte doesn't come close. Melt UI and shoelace don't fit the same
- There are definitely "rules of runes"
- Lang tools are a bit wonky. Hit out-of-date imports and unexpected load times
https://github.com/mjackson/remix-the-web
Excited to see what you all come up with!
Which means… Svelte is also accessible, you only need to put a little effort.
- building an accessible tab view takes a week+ of reading the w3c spec. I did this at a previous job
- building accessible tooltip interactivity can take more effort
Adding accessibility to big scale enterprise app may take months… only because nobody planned and cared beforehand.
Hope that AI will help with this at least on code level.
It's mostly pressing delete
+ true
- component function boilerplate
- memo
- useMemo
- useCallback
- dependency arrays
- CSS-in-JS lib
- context provider components
- Framer Motion
- babel bullshit (mandatory for react compiler)
- class component (mandatory for error boundaries)
- fragment
- lazy
- state management lib
That's without me adding the APIs that simply have simpler equivalents
- Webviews lock you out of full-native UI + gestures. Especially noticeable on iOS. React Native gets closer to native feel and has an escape hatch to just write Swift
- Tauri is... rough. I used it for a few months, and the poor docs + rust compile times were painful