I can wholeheartedly recommend Svelte. As someone who can only do vanilla HTML/CSS/JS, it lets me build projects quickly and efficiently without having to learn something complex like React. Case in point this silly side project made in Svelte over a weekend: https://meoweler.com
I went with Svelte when I built out the website for my canvas library a few years back[1]. It's proved to be easy to maintain the site, and I particularly like that it supported my vanilla JS library (which I use on the site's landing page) with minimal fuss.
At some point I want to update the site to use Sveltekit, which I'd been experimenting with in personal projects. But then the team announced Svelte 5 and these things called "runes" and ... I don't know. Having just passed my 60th birthday I'm getting to a stage in my life when keeping up with all the New Shiny makes me wonder if it's worth the effort, or if I should be doing more interesting stuff like creating new content for the site instead.
It's funny because very early on the key selling point of Svelte was that you just mutate objects and it compiles to the observable pattern, unlike React's clunky setState syntax. Now, somehow magic symbols in the code is supposed to be an improvement? It doesn't seem that different from React's magic hooks these days.
Is there some mysterious force of nature that binds front-end frameworks to bad decision making?
This is also why I chose SvelteKit as my first framework. I was actually pretty fluent in vanilla since my first real web project was a full stack chrome extension, but when it came time to choose a framework for my first true web app, I chose Svelte because it was the only framework I could immediately understand.
Svelte reminded me of how I got my start with coding. I love it. Refusing to learn React has cost me job opportunities but Svelte is just so much more pleasant to use and easy to grok.
I’m currently building a social network with SvelteKit and I couldn’t be happier. Excellent DX.
That website is actually a great way to compare options, thanks for sharing! I did find that it gives a 500 error for Birmingham, AL specifically, if you’re still working on it.
...but that's what Svelte is not. The techniques you adopt won't transfer over to vanilla HTML/CSS/JS without the magic Svelte compiler. These habits will become crutch when Svelte inevitably goes the way of every Javascript frontend framework.
> something complex like React
React is not that complex, certainly not more so than Svelte. It's hard to wrap your head around some behaviors, but at the end of the day, it is really just Javascript/Typescript. It is programming. As a programmer, I want to spend most of my time programming in a programming language, not so much of it configuring the Rube-Goldberg machine that is HTML/CSS. Your mileage may vary, of course.
> this silly side project made in Svelte over a weekend
> As a programmer, I want to spend most of my time programming in a programming language
If your work requires you to use a web stack, this attitude will not serve you well in the long run. If you make the effort to learn these technologies, you'll soon find them to be simple and predictable, but admittedly not without some historical baggage. You may even have an easier time with Svelte, since it has everything working out of the box, unlike React, which requires you to figure out a build toolchain and a separate solution for styling.
I swear every time I use React, every couple of years, I wind up thinking "okay fine, but... why?"
I love JSX. But the React API, for some areas, feels complex and boilerplatey. I dunno why you have to explicitly memoize some stuff. Svelte just magics that shit away.
> It's hard to wrap your head around some behaviors
I've got a React maintenance and development project coming up in a few weeks. I'd love if you'd expand a bit on these points and maybe point to some relevant docs. You could potentially save me days or more of tail chasing. Thanks.
Svelte 5 has been very nice to work with over the past few months. Yes, runes require you to think more carefully about lifecycles and updates. And you may end up writing a little more code initially than with svelte 4. But it serves you better in the long run with complex apps. I found a process for gradually turning a simple app into a more complex one that works for me. I iteratively move $state() runes out of .svelte files and into .svelte.ts files where I build a more abstract data-oriented structure for my app from a series of mutually linked classes. Then those runes can be re-imported into the .svelte files, or used and updated wherever you need. If you plan it right, I think it avoids the need for heavy redux-like state management. (at least I think so. I haven't worked with redux much myself)
Just my personal opinion: I love svelte for small projects but the whole runes rewrite just feels so much less ergonomic. A step in the direction away from the simplicity that drew me to svelte in the first place.
That said, there is backwards compatibility with the older syntax, so this isn’t a dealbreaker, and the team does a good job of explaining the reasons behind their selected design patterns.
(Interestingly, I’ve felt the opposite with react lately - they’ve been making the dx simpler).
This is more or less where I’ve landed lately. There are some things I really like in Svelte and Solid but not enough to overcome the massive ecosystem advantage React has.
Do you know of any large OSS software built with Svelte? I'd like to see how it turns out in the long run, because I'm reticent of all frontend frameworks nowadays through what I perceive as gateways to uncontrollable accidental complexity and abstractions.
> I iteratively move $state() runes out of .svelte files and into .svelte.ts files where I build a more abstract data-oriented structure for my app from a series of mutually linked classes. Then those runes can be re-imported into the .svelte files, or used and updated wherever you need.
I don’t know exactly how you do this, but it sounds like you are dangling on the global state of the runes. This is DANGEROUS in Svelte and can definitely ruin your day.
Hope it starts to chip into React’s usershare and more companies adopt it, but I know that’s a slow process especially for the big companies.
I got out of front end development for most of the years Angular and React have dominated and it looked like a mess, but Svelte and even Astro make sense, maybe I’m just old school. I would totally go back to the frontend with these new frameworks.
React is cargo cult at the moment and has been for years already. People will just use react because everybody is using react, no matter if it makes sense or not.
If Vue hasn't made a dent, I don't ever expect Svelte to. Angular was the only high-level competitor and I haven't heard that one in a long time already.
For a framework to eat into React's usage, it needs a strong evangelist (like Facebook has been for React)
But didn’t Vue come before React? And it’s mostly the same from what I understand, it’s not totally different like Svelte. I think it can change, if more people put it on their resumes and LinkedIn and if those that know React say can do things in 1/3 the time with Svelte and mention that in interviews as well. That is a slow way of evangelism for Svelte that can spread.
I was very amused this summer, hearing a company that I had worked at six years ago is switching from React to Angular. I had thought angular was dead.
I gave React a handful of year to get popular and mature. I tried to approach it an immediately ran into basically endless arguments and bitching about how to manage state. There was no clear winner so I dropped it. Everywhere I landed trying to find advice or best practices just led to more questions. Like WTF?
Svelt, Vue3 or hell...Angular, and it's off to the races. I just need to know how to accomplish all the things being demanded by Product.
- even better performance,
- a more granular reactivity system with runes,
- more expressive template syntax with snippets and event attributes,
- native TypeScript support,
- and backwards compatibility with the previous syntax!
I've been using Svelte since v3 was released almost daily. I've been using v5 for the past couple of weeks and it's fantastic.
The biggest improvement IMO is that you can now write reactive logic intuitively outside your components and it just works without needing to use complex machinery or patterns like Mobx, Redux, or Vuex.
I've been doing frontend since the 90s and used everything under the sun. Svelte 5 is the most pragmatic and elegant solution I've ever used.
Have you ever looked at all the code that it needs to do that? Plus an integration lib like mobx-react. And even then the performance doesn't compare to Svelte 5, Solid, etc.
You can use reactivity outside components in Vue without Vuex, I don't find it to be much less intuitive than Svelte (which is also nice, don't get me wrong).
You can but it's nowhere near as elegant and natural.
Vue exposes ref(), .value, etc which personally I find to be just cognitive overhead.
With Svelte 5 you just use $state and don't need to care about the implementation details. Furthermore, thanks to the compiler approach, your Svelte code is not coupled with an internal API anymore.
I can’t speak for the majority, but for my team it’s because it’s not worth the distraction. We’ve got years of experience and tooling and “tradition” with one approach. Why do we want a second?
It’s also just not an interesting issue. In my experience, the actual coding (and later maintenance) of a web application is the least challenging, least interesting part of the project. At that stage, all the interesting problems have generally been solved in workflow, process, data structure design and general de-risking. Classes? Hooks? Binding style? Tabs or spaces? I really couldn’t care less. Just be consistent so you can all build and develop skills together.
I admit that when I was younger this kind of thing seemed to matter to me. I dunno if it’s because I’m now more focused on big picture or if I’m just tired and don’t care anymore. Maybe both!
I really like this anecdote, and I very much think you're speaking for a lot of people here. Tech is tooling. Some people make a hobby out of the tooling, others merely use the tools to build something.
It's totally valid to make a hobby out of tools (e.g. motorcycles), but it's easy to end up with all sorts of highfalutin' opinions about how the tools must or must not be used, that hinge on minute distinctions that fundamentally don't matter to someone looking to merely use them as tools.
From users' point of view, they only care about the performance really
Some e-commerce apps use React in WebView on Android and the apps will become unresponsive after visiting several product pages (more than 10 probably). They have to be force closed and opened to be used again
This sounds familiar. We know React, and while I’d dearly love more automatic performance, it’s not worth introducing a whole bunch of new complexity to do that.
I'm building a React app from scratch and since I have control this time, I'm following a strict pattern: all data manipulation (∆) happens outside of React components, and the components themselves are as lightweight as possible.
I feel like this change suddenly makes everything about the React paradigm make sense - it can be just a view layer, and when used that way, it works great.
But I can't say I've ever worked on a React app that followed this this pattern before. Perhaps this is React's fault, or perhaps it would be the same with every framework once an app gets big enough (in my limited experience with Vue and Angular, those didn't seem any different from React in this regard).
(∆) By data, I mean the data that is fed into the app from the database. There's a certain amount of data generated internally by components, I write small functional functions at the top level or in the same folder as the components to handle that, but not placed inside the component itself, which is common practice but ends up creating these huge hard to parse components.*
> all data manipulation (∆) happens outside of React components,
I do something similar. State and its management lives outside the React components, which only consume this state via hooks. Keeping the state in chunks, and outside the tree lets me access a chunk of state only in the components that need it.
This results into minimum amount of re-rendering of components. Component code also looks cleaner and easier to read.
My React fomula is React + MobX, keep the hook use to minimum, single state object per component (the classic React way), do not bother with server components at this point, you should be fine.
Haha, reminds me of 20 years ago when someone said they are building a PHP app from scratch and this time they won't have HTML, business logic and SQL all in one .php file. We learn as we go ;)
This is why I think react is still the best: In react you only deal with plain values. You never have to worry about wrapping a value in an observable or calling it in a function with a tracking context. Or .valueing it or whatever.
It looks like Svelte 5 is trying to make signals "disappear" but they still leak through. Reading the docs about shallow $state.raw vs deep proxying the default $state rune in svelte 5 makes me really appreciate the plain value and simpleness of react.
The react compiler will make the biggest headache of react go away, that being useMemo, memo, and useCallback.
React has the biggest and highest quality ecosystem. It has the smartest and brightest people in this space working either on react directly or in the immediate surrounding ecosystem. React has by far the most $ backing it.
Looking ahead I think react makes the best immediate AI target. Long term AI will go past react but while we still want to vet the code with humans react will probably be the best target.
Thought of another important reason why I love react:
- It has the best TypeScript support of any framework. Partly because MS is so invested in react the typescript team is very incentivized to have good support for them.
Oh yeah and this one is imporant:
- React Native with expo is the best way to make cross platform mobile apps. Yes its better than Flutter.
Having used both a fair bit I much prefer Flutter. RN always felt like fragile pile of hacks to me with extremely brittle builds. Flutter feels like a stack engineered for purpose from the ground up and the tooling, ecosystem and performance have been consistently great.
There was a sweet spot in the past when React was actually simple and clean.
I really do want to escape it these days but quite frankly every frontend framework is the same and they are just shitty in different ways, not really better than React.
I love Svelte and use it for all my personal projects and all company projects (except strictly static sites are still built with just 11ty but I hate it and want to move off it).
But I'm going to wait a bit on v5 for the company, scanning all the issue headlines, it looks like there are a still a lot of unresolved edge cases: https://github.com/sveltejs/svelte/issues
As for my latest personal project, upgrading right now so I can help find more of those edge cases :D
For what it's worth, I've upgraded three pretty beefy projects to v5 over the past 6 months or so (making sure to stay on top of latest releases), and I haven't seen any weirdness. That being said, I'm not using any of the transition APIs and only one of the projects uses the "runes outside of a Svelte file" thing (i.e. svelte.js files), so YMMV. I was so excited about runes that I couldn't wait. The only thing that bit me initially was `$state` runes converting objects into Proxy instances, so if you want to send data using `postMessage` or IPC in Electron, you need to serialize it first. I really love the new APIs. The Svelte team did an awesome job of addressing most of the gripes I had with v4.
I've used 11ty on and off since pre-1.0. The documentation remains awfully confusing and doesn't cover common use-cases. The system has been pulled together but not thought out as a whole.
Lume (from Deno) is my preferred 11ty alternative.
I adore 11ty. It’s not inherently component driven, but it’s super straightforward and endlessly customizable. It allows you to really experiment with organization, too. I like it a lot.
Svelte 5 is almost heaven, I thought. But it's full heaven.
To keep it short: The Svelte team did a remarkable job improving every aspect but preseriving the characteristics and distinctive features (fast, small, easy, elegant).
Now, where I struggled (using Svelte 5 on a business logic heavy SPA since RC in April):
Signal in general are extremly easy to use, but quite hard to track. You have to "know" or "find out" if something is reactive. Vue makes it easy with their .value API, but also not 100% foolproof.
With React: Everything is a value. Unidirectional data flows. It's very easy to follow the flow of the data.
With Angular: Data pipelines are built using RxJS. Hard to learn, but extremely powerful. You can follow the data flow quite well. Not as easy as with React, but once you are good with RxJS, still easy enough.
With Svelte 5: Runes look like values. This mental model is good enough most of the time. It's especially great in small contexts where you exactly know where your variable comes from or where everything is reactive. But Runes also behave like signals and proxies. So, you sometimes need to know exactly what is in your bag. Is it a value? A signal ($state with value or $state.raw with object or array)? A proxy ($state with array or object)? In larger contexts it gets really hard to track.
Why is Svelte still full heaven to me: I realized that Runes are just the basic building blocks. They are the common basic toolkit. I don't have to use them in large business logic areas of my apps. I can create (nominal typed, using TS of course) custom wrapper classes, e.g. to only allow signals, not proxies. This wrapper classes could disallow mutation. Passing those around makes it type safe. If I see a value, it is a value. If I see a type of my reactive wrapper class, it is reactive. Or, I can use RxJS and Svelte 5. Or I can mimic Vue's or Solid's APIs (as Rich showcased).
There's a spot in the new docs (wip) where the Svelte team is going to explain Runes. I think they're also (as other Signal experts - I hope Prof. Signal Carniato solves this for all of us :-)) working on better debugging tools.
It’s interesting to watch this carcinization of reactivity in all major frameworks. They all started out differently, but seem to settle around the same general concepts. These days, you could sit a React guy in front of a modern Vue app, and they could probably figure out how to work with it relatively fast.
Readit News
At some point I want to update the site to use Sveltekit, which I'd been experimenting with in personal projects. But then the team announced Svelte 5 and these things called "runes" and ... I don't know. Having just passed my 60th birthday I'm getting to a stage in my life when keeping up with all the New Shiny makes me wonder if it's worth the effort, or if I should be doing more interesting stuff like creating new content for the site instead.
[1] - https://scrawl-v8.rikweb.org.uk/
Is there some mysterious force of nature that binds front-end frameworks to bad decision making?
This is also why I chose SvelteKit as my first framework. I was actually pretty fluent in vanilla since my first real web project was a full stack chrome extension, but when it came time to choose a framework for my first true web app, I chose Svelte because it was the only framework I could immediately understand.
Svelte reminded me of how I got my start with coding. I love it. Refusing to learn React has cost me job opportunities but Svelte is just so much more pleasant to use and easy to grok.
I’m currently building a social network with SvelteKit and I couldn’t be happier. Excellent DX.
> easy to grok got me :)
Deleted Comment
...but that's what Svelte is not. The techniques you adopt won't transfer over to vanilla HTML/CSS/JS without the magic Svelte compiler. These habits will become crutch when Svelte inevitably goes the way of every Javascript frontend framework.
> something complex like React
React is not that complex, certainly not more so than Svelte. It's hard to wrap your head around some behaviors, but at the end of the day, it is really just Javascript/Typescript. It is programming. As a programmer, I want to spend most of my time programming in a programming language, not so much of it configuring the Rube-Goldberg machine that is HTML/CSS. Your mileage may vary, of course.
> this silly side project made in Svelte over a weekend
I will admit, that's what Svelte excels at.
If your work requires you to use a web stack, this attitude will not serve you well in the long run. If you make the effort to learn these technologies, you'll soon find them to be simple and predictable, but admittedly not without some historical baggage. You may even have an easier time with Svelte, since it has everything working out of the box, unlike React, which requires you to figure out a build toolchain and a separate solution for styling.
I swear every time I use React, every couple of years, I wind up thinking "okay fine, but... why?"
I love JSX. But the React API, for some areas, feels complex and boilerplatey. I dunno why you have to explicitly memoize some stuff. Svelte just magics that shit away.
I've got a React maintenance and development project coming up in a few weeks. I'd love if you'd expand a bit on these points and maybe point to some relevant docs. You could potentially save me days or more of tail chasing. Thanks.
Few things, for me the domain name is difficult to remember
The page doesn’t fully scroll down for me and the discord button is not accessible on mobile
Other than that the site it nice
Dead Comment
That said, there is backwards compatibility with the older syntax, so this isn’t a dealbreaker, and the team does a good job of explaining the reasons behind their selected design patterns.
(Interestingly, I’ve felt the opposite with react lately - they’ve been making the dx simpler).
EDIT: Also, not OSS, but https://search.brave.com seems to be built with Svelte
I’ve used it as a reference for a NestJS+SvelteKit app in the past, they did a pretty good job.
huggingface https://huggingface.co/pydiohttps://huggingface.co/docs/chat-ui Ollma webui https://github.com/open-webui
These are just a few of them that I quickly search and look at their popularity .
Ollama's OpenWebUI https://github.com/open-webui/open-webui
Cannot edit my previous answer i mentioned wrong page. , updated proper links
Gradio: https://github.com/gradio-app/gradio
I don’t know exactly how you do this, but it sounds like you are dangling on the global state of the runes. This is DANGEROUS in Svelte and can definitely ruin your day.
I got out of front end development for most of the years Angular and React have dominated and it looked like a mess, but Svelte and even Astro make sense, maybe I’m just old school. I would totally go back to the frontend with these new frameworks.
For a framework to eat into React's usage, it needs a strong evangelist (like Facebook has been for React)
Svelt, Vue3 or hell...Angular, and it's off to the races. I just need to know how to accomplish all the things being demanded by Product.
The new version brings:
Probably a better link for this post?
Edit: I'm not so sure that's up to date actually. Lots of "Coming soon" sections
The biggest improvement IMO is that you can now write reactive logic intuitively outside your components and it just works without needing to use complex machinery or patterns like Mobx, Redux, or Vuex.
I've been doing frontend since the 90s and used everything under the sun. Svelte 5 is the most pragmatic and elegant solution I've ever used.
Vue exposes ref(), .value, etc which personally I find to be just cognitive overhead.
With Svelte 5 you just use $state and don't need to care about the implementation details. Furthermore, thanks to the compiler approach, your Svelte code is not coupled with an internal API anymore.
It’s also just not an interesting issue. In my experience, the actual coding (and later maintenance) of a web application is the least challenging, least interesting part of the project. At that stage, all the interesting problems have generally been solved in workflow, process, data structure design and general de-risking. Classes? Hooks? Binding style? Tabs or spaces? I really couldn’t care less. Just be consistent so you can all build and develop skills together.
I admit that when I was younger this kind of thing seemed to matter to me. I dunno if it’s because I’m now more focused on big picture or if I’m just tired and don’t care anymore. Maybe both!
It's totally valid to make a hobby out of tools (e.g. motorcycles), but it's easy to end up with all sorts of highfalutin' opinions about how the tools must or must not be used, that hinge on minute distinctions that fundamentally don't matter to someone looking to merely use them as tools.
Some e-commerce apps use React in WebView on Android and the apps will become unresponsive after visiting several product pages (more than 10 probably). They have to be force closed and opened to be used again
I feel like this change suddenly makes everything about the React paradigm make sense - it can be just a view layer, and when used that way, it works great.
But I can't say I've ever worked on a React app that followed this this pattern before. Perhaps this is React's fault, or perhaps it would be the same with every framework once an app gets big enough (in my limited experience with Vue and Angular, those didn't seem any different from React in this regard).
(∆) By data, I mean the data that is fed into the app from the database. There's a certain amount of data generated internally by components, I write small functional functions at the top level or in the same folder as the components to handle that, but not placed inside the component itself, which is common practice but ends up creating these huge hard to parse components.*
I do something similar. State and its management lives outside the React components, which only consume this state via hooks. Keeping the state in chunks, and outside the tree lets me access a chunk of state only in the components that need it.
This results into minimum amount of re-rendering of components. Component code also looks cleaner and easier to read.
It looks like Svelte 5 is trying to make signals "disappear" but they still leak through. Reading the docs about shallow $state.raw vs deep proxying the default $state rune in svelte 5 makes me really appreciate the plain value and simpleness of react.
The react compiler will make the biggest headache of react go away, that being useMemo, memo, and useCallback.
React has the biggest and highest quality ecosystem. It has the smartest and brightest people in this space working either on react directly or in the immediate surrounding ecosystem. React has by far the most $ backing it.
Looking ahead I think react makes the best immediate AI target. Long term AI will go past react but while we still want to vet the code with humans react will probably be the best target.
Thought of another important reason why I love react:
- It has the best TypeScript support of any framework. Partly because MS is so invested in react the typescript team is very incentivized to have good support for them.
Oh yeah and this one is imporant:
- React Native with expo is the best way to make cross platform mobile apps. Yes its better than Flutter.
Also RN has no real desktop app story.
Everyone at the company knows a little React already. We are not good at it and we don't like it, but I guess for them it's a safe bet.
I really do want to escape it these days but quite frankly every frontend framework is the same and they are just shitty in different ways, not really better than React.
But I'm going to wait a bit on v5 for the company, scanning all the issue headlines, it looks like there are a still a lot of unresolved edge cases: https://github.com/sveltejs/svelte/issues
As for my latest personal project, upgrading right now so I can help find more of those edge cases :D
I saw they have Svelte 5 support, and maybe this would make runes a killer app if we can inject the runes into Astro, (or even React) components?!
Lume (from Deno) is my preferred 11ty alternative.
To keep it short: The Svelte team did a remarkable job improving every aspect but preseriving the characteristics and distinctive features (fast, small, easy, elegant).
Now, where I struggled (using Svelte 5 on a business logic heavy SPA since RC in April):
Signal in general are extremly easy to use, but quite hard to track. You have to "know" or "find out" if something is reactive. Vue makes it easy with their .value API, but also not 100% foolproof.
With React: Everything is a value. Unidirectional data flows. It's very easy to follow the flow of the data.
With Angular: Data pipelines are built using RxJS. Hard to learn, but extremely powerful. You can follow the data flow quite well. Not as easy as with React, but once you are good with RxJS, still easy enough.
With Svelte 5: Runes look like values. This mental model is good enough most of the time. It's especially great in small contexts where you exactly know where your variable comes from or where everything is reactive. But Runes also behave like signals and proxies. So, you sometimes need to know exactly what is in your bag. Is it a value? A signal ($state with value or $state.raw with object or array)? A proxy ($state with array or object)? In larger contexts it gets really hard to track.
Why is Svelte still full heaven to me: I realized that Runes are just the basic building blocks. They are the common basic toolkit. I don't have to use them in large business logic areas of my apps. I can create (nominal typed, using TS of course) custom wrapper classes, e.g. to only allow signals, not proxies. This wrapper classes could disallow mutation. Passing those around makes it type safe. If I see a value, it is a value. If I see a type of my reactive wrapper class, it is reactive. Or, I can use RxJS and Svelte 5. Or I can mimic Vue's or Solid's APIs (as Rich showcased).
There's a spot in the new docs (wip) where the Svelte team is going to explain Runes. I think they're also (as other Signal experts - I hope Prof. Signal Carniato solves this for all of us :-)) working on better debugging tools.
I'm happy.
Big thanks and respect to the Svelte team.