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: <a href="https://meoweler.com" rel="nofollow">https://meoweler.com</a>
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)
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.<p>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.
From the changlog on Github:<p>The new version brings:<p><pre><code> - 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!</code></pre>
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.<p>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.<p>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.
I <i>love</i> 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).<p>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: <a href="https://github.com/sveltejs/svelte/issues">https://github.com/sveltejs/svelte/issues</a><p>As for my latest personal project, upgrading right now so I can help find more of those edge cases :D
Svelte 5 is <i>almost</i> heaven, I thought. But it's <i>full</i> heaven.<p>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).<p>Now, where I struggled (using Svelte 5 on a business logic heavy SPA since RC in April):<p>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.<p>With React: Everything is a value. Unidirectional data flows. It's very easy to follow the flow of the data.<p>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.<p>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.<p>Why is Svelte still <i>full</i> 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).<p>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.<p>I'm happy.<p>Big thanks and respect to the Svelte team.
We use Svelte 4.0 in production and it performs beautifully; it rarely is the cause of our frustrations. Excited to try the new version.<p>Lately I’ve also been wondering about the relationship and correlation between software writing skills and writing skills.
Someone on Twitter claimed that Svelte 5's runes are basically a nicer (custom) syntax for Solid.js -- is that true? I find the way Solid.js decouples signals from components to be a huge step up from React's state management in terms of abstraction capability and composability.
Exciting, I love Svelte! Does anybody have experience with both Vue and Svelte? It's been a while since I used Vue but it seems like both frameworks have converged quite a bit over the years. With this release I'm particularly curious now: why would somebody pick one over the other?
What's the preffered way to make simple SPAs using Svelte now? I'm using this +layout.ts with sveltekit:
> export const ssr = false;
export const prerender = false;<p>But it feels awkward for real SPAs - internal applications that have no need for server side rendering.
Full v5.x changelog:
<a href="https://github.com/sveltejs/svelte/blob/main/packages/svelte/CHANGELOG.md">https://github.com/sveltejs/svelte/blob/main/packages/svelte...</a>
This really made my day. I decided to convert a pretty large project over to v5 a couple of months ago because the new APIs were so much nicer. I rolled the dice a bit because I wasn't sure if I was going to hit weird edge cases, but everything went smoothly. Congrats to the Svelte team and major kudos for coming up with runes!
Where would one even start learning more about front-end development in today's world? Ignoring the dizzying amount of frameworks, how could I become knowledgeable enough to connect my back-end experience to design the "full stack?"
When I recently looked at SvelteKit, what confused me the most was the universal load function.<p>If you use "if !browser" with sveltes browser object, the things inside that branch will only run on the server.<p>But because svelte is compiled, these functions get compiled to two different versions, one for the server and one for the client, in which that if statement has been completely compiled out. That in itself isn't bad but it's weird that normal code and control flow influences compilation. In other languages this would be a macro or something that clearly expresses that it's metaprogramming.<p>Then there are some other weird things like props being merged and potentially overwriting each other in a deep level. But that is by design and can be reasoned about.<p>What also felt weird to me is that there is no recommended way to do initialization logic such as reading in a config, reading from the environment and preparing something for the rest of the lifetime of the application.<p>Has anyone had similar experiences/confusions when learning SvelteKit?
Good work! I’m not really sold on the runes stuff though (tldr: <a href="https://svelte.dev/blog/runes" rel="nofollow">https://svelte.dev/blog/runes</a>)<p>The old way is a bit “magical” in a sense that it does some stuff under the hood to implement the intention behind your code, but it reads really straightforward:<p><pre><code> let counter = 0;
// ...
<div>{counter}</div>
</code></pre>
`let` in a .svelte compoment makes a variable reactive. If your state is outside a component, you use stores.<p>With the `$store` rune, the way you make reactive stores inside and outside components is the same, <i>but</i> it only works in .svelte.js/ts. The unification is great – but why not just use `let` in .svelte.js, too?<p><pre><code> // counter.svelte.js
export function createCounter() {
let count = 0;
return {
get count() { return count },
increment: () => count += 1
};
}
// App.svelte
<script>
import { createCounter } from './counter.svelte.js';
const counter = createCounter();
</script>
<button on:click={counter.increment}>
clicks: {counter.count}
</button>
</code></pre>
I understand it can be really tricky – e.g. you might want to use let for things that are not modified in runtime and do not need reactivity, but it should be possible to determine in compile time. (Actually after writing this all up I think I know why Svelte went with runes instead, haha!)<p>But again – really good work and I hope to try it out on my next project!
Blog post will be published on Monday:<p><a href="https://x.com/Rich_Harris/status/1847682508822913359" rel="nofollow">https://x.com/Rich_Harris/status/1847682508822913359</a>
From listening to webdev podcast #1, Syntax.fm, the gist I get is that a lot of what used to be invisible compiler magic is now more visible & explicit.<p>The compiler user to rewrite property access to make reactivity happen. Now you can kind of see yourself updating & reading/reacting as you sprinkle runes in. Implicit to explicit magic, with Runes as the headline demonstration of that. Other examples very welcome!
If you like Svelte, Yuzu Health is hiring developers to work in Svelte in New York City. <a href="https://yuzu.health/careers/senior-software-engineer" rel="nofollow">https://yuzu.health/careers/senior-software-engineer</a><p>Seems like the number of companies using Svelte in production is growing but still not super high.
I learned Svelte 3 over a year ago and I found it very pleasant. Unlike React, Svelte is an integrated framework, no "pick your router" nonsense, I don't want to be picking a router.<p>I like the direction Svelte going in, the old syntax was ok but not great.<p>I wonder how this new Svelte compares with some of the other new kids on the block like solid.js and alpine.js.
Why should someone use Svelte 5 over Vue 3?<p>Performance might be the only reason IMO, but once Vue Vapor is release that will most likely not be an advantage.<p>The Vue3 and Svelte 5 API are almost the exact same, but Vue can be used in TS/JS and Svelte 5 can't.<p>I do think SvelteKit is better than Nuxt by a lot. Maybe that's a big advantage.
Congrats. I discovered Svelte through the 5 RC and immediately fell in love.<p>I’m in the process of porting an HTML audio and Spotify Web Playback music player to Svelte5 and it feels so clean and productive.<p><a href="https://github.com/nzoschke/jukelab">https://github.com/nzoschke/jukelab</a>
This is fantastic news. Between the Svelte 5 RC and Deno 2, I’ve been really enjoying working with the JS/TS ecosystem for the first time in a long time — it’s just been vaguely difficult keeping up with the (minor) tweaks in the RCs along the way. Congratulations to the team :).
An interesting datapoint:<p>I made my first website a few months ago (I'm an ML engineer). I tried in both Svelte and React.<p>I used Sonnet as a copilot the whole time and expected Svelte to be more difficult because there are orders of magnitude less training data on it.<p>To the contrary! The LLM tied itself in knots very quickly with React but mostly did ok with Svelte/Sveltekit. Also, the Svelte stuff it makes is usually snappier. However it does have a wider range of UI widgets it can grasp with React.<p>It seems that my opinion that React is horrendously and hideously overcomplicated is at least somewhat objective! Svelte has been quite pleasant.<p>To any devs out there that have to work with React, you have my sympathies. Compared to Svelte it's just flaming hot putrid garbage.
can I do async derived stores by default yet? It was kinda tricky to get working in svelte 4 and even Square/svelte-store wasn't super ergonomic. Would be super nice if it was built in
Do they still operate with very little backwards compatibility policy? They killed the sapper project and replaced it with sveltekit. Is sveltekit still alive?
Been using Svelte for about 8 months and have fallen in love with it, using it in production for both personal and company projects.<p>My only gripe is it doesn't support <template> tags or class list arrays out the box, meaning I've had to use preprocessors instead, the latter for me makes it far nicer to mentally visualise components when using dynamic tailwind classes.
Svelte vs React is discussion that will never end.<p>For those of us who do not like to code complex logic and state in javascript, I can recommed htmx <a href="https://htmx.org/" rel="nofollow">https://htmx.org/</a>. Also, I am more comfortable writing backend code and this just fits my style better.
I love Vue. Svelte is great! Unfortunately nothing beats react especially if one plans to develop for mobile. Despite how ugly the nuances in react are compared to those two, it’s still more mature making the other two trying to catch up and feel outdated in terms of features.
I'm curious what users of Svelte think about <a href="https://qwik.dev" rel="nofollow">https://qwik.dev</a>, have many of you been tempted by it? There are a lot of similarities and both are great at keeping file sizes down with a great DX.
The blog post is up: <a href="https://svelte.dev/blog/svelte-5-is-alive" rel="nofollow">https://svelte.dev/blog/svelte-5-is-alive</a>
Svelte noob here: can someone more experienced explain why runes are getting people excited? My untrained eye starting reading the Svelte runes documentation and it just made me go "well I guess Svelte is getting React Hooks?"
My first web project was with svelte.<p>Lack of a debugger for the server sided JavaScript seems just as silly to me as server sided JavaScript. I would consider that alone a non-starter.<p>I’d recommend another solution for experienced devs.
Doesn't the philosophy behind Svelte justify a broader scope than just Web apps?<p>Shouldn't this be a more general programming language, not tied to the web?
all the big frameworks bar react are switching to the solid model of signals and fine-grained reactivity<p>people would be better off just using the real thing, Solid
nice and everything, but it still has plenty of performance issues and crashes with the tsserver. Using solid start because of that, tooling is not there yet.
Svelte. Interesting framework, I dipped into React then tried Svelte and loved it initially - very noob friendly.<p>I really liked having HTML/CSS/Js all in one place.<p>But then tailwind became popular, and I realised I could get this same UX with React + Tailwind.<p>Now I prefer React + Tailwind to Svelte.<p>No Svelte jobs, weird compiler magic. Hated SvelteKit