Svelte 5 Released
npmjs.com
npmjs.com
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.
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
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 :)
...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.
The reason React is "embraced" by the industry is that it is widely used, not because it's the best choice. This lowers the risk for companies that can replace its developers with another easily. I'm not saying it's as bad as beeing stuck with a stale IE (yet), but there are surely good alternatives out there.
"Nobody has been fired for choosing IBM", was a saying that applies to React today
It has reached the "IBM" point where it's so widely used, that it has become the most rational choice for enterprise.
We have to wait for a few years while smaller businesses who don't have (or care about) the same risks uses better alternatives until they reach the point where you are not blamed for choosing something outside the box
That looks like tautology to me. What point are you trying to make with this?
Comparing IE6 and React is _hardly_ a fair comparison. One was a Trojan horse injected by corporate policies and ACLs, while React gets explicitly chosen by teams. And... Yes, there _is_ a reason why nobody gets fired for choosing React: it's not a bad choice! Is Svelte a better choice? Not universally. Unfortunately—like with many things in our field—it comes with trade offs and the answer boils down to "it depends" again.
React has its quirks, but "hating" on a library because it was part of a dumpster fire project doesn't mean the library is bad, just that people using it weren't competent with it (not necessarily incompetent in general).
Vue, Svelte, Leptos, Solid, Elm. I've seen all of them used as dumpster fire fuel, and it was hardly the library's fault.
> That looks like tautology to me. What point are you trying to make with this?
React is in a place now, where it is the "safe" default choice for Enterprises. It's not necessarily a bad choice, but I argue that risk management is often an important part of deciding which tech to use.
It got to this point by being backed by Meta and was a genuinely good alternative to other frameworks at the time. But it is my view that enterprises prefer React not because it is the best, but because it is good enough and easy to find workers with experience. This is a self reinforcing feedback loop.
I worked in a sales driven startup some years ago and got to shape the technology as the first hire and only developer for a few months. I chose React because it was easier to recruit for and time to market was important. If I had already a team of developers with experience with another framework, I would have chosen that one even if it had been a less popular framework due. Time to market was our main focus.
More established companies don't have the same time constraints and are often more concerned about scaling up with multiple teams. A less popular framework is a bigger risk. It is "easy" to hire 10 people for any framework, but what about 100?
Meanwhile, React is basically pure TS and the only bugs I run into are the occasional limitations of TSC.
>Its type checker and build toolchain are so abysmally bad and bug-riddled that I run into new bugs and limitations on the daily.
This seems like a setup issue.
Mine catches everything just fine. Both in-editor (I use neovim) and with a make step (just calls vue-tsc) + a precommit hook as a sanity check.
>React is basically pure TS and the only bugs I run into are the occasional limitations of TSC.
React is obscene. It always seemed to me the Java of the FE world, made worse in recent years. By that I mean grotesquely verbose and full of ceremonious value passing through multiple functions just for the tiniest of things. I've had to work with React codebases and these days I outright refuse to do that/turn down jobs with that requirement. I'd rather use angular.
Svelte and Vue are ergonomic and straightforward and they sanely default to SFCs instead of that woeful chimera of languages called JSX/TSX - you can still use it if you so desire though.
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.
Interestingly, people chose React over Angular, because it gave you the freedom to not use anything.
I disagree. A "web stack" is outdated quickly, but the language remains mostly the same, as does my data. React lets me express most things naturally as forward data transformations, without entangling me too much to peculiar toolchain that will become obsolete and break absolutely everything.
> 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.
Sure, you'll have an easier time making decisions if someone else makes them for you.
You're comparing two tools that are both at the top of a very tall stack of pre-made decisions.
React is definitely one of the long beards though, and thats’s because declarative programming is a win for UIs IMO. So much so it had a massive knock on effect in popularizing this approach (what’s old is new again… and again) across languages and problem sets.
In my post I was actually speaking about learning CSS and HTML alongside the "real programming language" that is JS/TS.
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.
> some relevant docs
Read the docs. All of them. React isn't that big.
I have an extensive post called "A (Mostly) Complete Guide to React Rendering Behavior) that covers the concepts and nuances in detail:
- https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...
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.
> But the React API, for some areas, feels complex and boilerplatey
That's also why in local dev mode, you'll see the render cycle executed twice so that you can spot any undesired side effects due to this design choice.
So a lot of the complexity is to deal with this specific design choice to determine when code inside of the component function needs to be re-executed. In React, you need to explicitly opt-out of reactivity while in nearly every other framework, you are opting-in to reactivity.
For me, I've always seen this as the weirdest footgun because it's antithetical to the underlying language and runtime behavior so developers need to be explicitly aware of this behavior.
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.
Is there some mysterious force of nature that binds front-end frameworks to bad decision making?
Maybe you don’t need that. Seems like a bunch of the Svelte community did. I wouldn’t frame that as a bad decision.
Furthermore <slot /> had limitations in terms of children which made it difficult to build UI libraries.
Svelte 5 now is actually simpler to learn for new comers despite higher verbosity.
I love it!
huggingface https://huggingface.co/pydio https://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 .
I’ve used it as a reference for a NestJS+SvelteKit app in the past, they did a pretty good job.
EDIT: Also, not OSS, but https://search.brave.com seems to be built with Svelte
Another notable example is Yahoo Finance, which is written in Svelte
Ollama's OpenWebUI https://github.com/open-webui/open-webui
Cannot edit my previous answer i mentioned wrong page. , updated proper links
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).
I've rarely used React, are you talking about React-specific libraries? I find it hard to believe that there are more maintained React libraries than vanilla JS libraries.
It basically singlehandedly convinced me that the ecosystem was worth going with react when I started my project, despite really enjoying svelte.
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)
Vue gets unfairly overlooked imo. I worked with it for 12 months and it was mostly a joy
They reverted from the `on` syntax while adding in signals like Vue's `ref`. The way the props pass down is more akin to React than Vue, but the overall reactivity system feels the same as Vue.
I'm not sure I'd pick it over either Vue or 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:
- 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!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
If I need to hit a certain performance because the business has concluded that it matters, and React can’t get us there, then I’m likely switching to Svelte or whatnot.
If none of my tools can do the job, I’m going to the store and buying a new tool and learning how to use it. I don’t feel ideologically attached to my palm sander. I’ll buy a belt sander if the palm doesn’t make sense for a task.
Though the desire to improve without external pressure could be considered ideological
As a seasoned React dev of 10 years (aka a heavily biased person) I would claim 99% of this issue is better explained by: - React is the most popular choice => used in all kinds of places by all kinds of people - with varying skill - under all kinds of business pressure to deliver features => a lot of slow apps in React
I'm not saying a case for specific areas where React is slow can not be made, these anecdotes just don't do it for me.
We do have the synthetic framework benchmark, where React is indeed one of the slower candidates. I have yet to build an app with functionality akin to adding 10s of millions of rows, so it has not been an instructive decision driver for technology choice. The project I have been working on (also in Vue, Svelte, SwiftUI) had their bottlenecks in other places.
The non-synthetic argument in favor of React passing the performance test is billions of people using FB, Insta, Netflix, MS Office (to name some of the big React apps), about which I have not much in terms of complaints.\ This is usually where the second big React critique kicks in: it being a Fortune-500 framework. That has not been my non-fortune-ate experience.
I think a residual argument can still survive this: I/my org has not been able to write performant React. I'd be curious to read someone go into the details of where it broke down and how switching view layers solved for that specific situation (I hope that does not read cynical, I'd really be curious).
reddit switch from reactjs to lit for performance reasons
https://www.reddit.com/r/reactjs/comments/12yxva6/whats_you_...
nothing is wrong with react, performance is obviously depending on how optimization is done
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.
I have always found state management easier in React if I keep it out of React.
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
For DB and user logins, you might have to run in SSR mode to be able to do server-side stuff, but you can certainly build API routes, server middleware and interact with cookies for user token stuff.
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.
Lately I’ve also been wondering about the relationship and correlation between software writing skills and writing skills.
-- Edsger W.Dijkstra https://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498...
Writing code and writing literature are curiously similar. It begins with thinking, both structured and creatively. Breaking a story down into pieces while keeping the bigger picture, and making a plan for how to approach it. Then comes the difficult metamorphosis where abstract ideas/concepts are turned into concrete words/code.
Good literature/code is concise, expressive, even beautiful. It doesn't come about easily, but takes time. The author reshapes and refactors the text until it meets some standard that the author aspires to, often revisiting it days later to read it with fresh eyes. Then it's committed for review, and may still have to be reworked a bit.
I agree with those who say that coding is more art than engineering. At least if you're really good at it.
> Svelte 5's reactivity is powered by signals, which are essentially what Knockout was doing in 2010. More recently, signals have been popularised by Solid and adopted by a multitude of other frameworks.
> We're doing things a bit differently though. In Svelte 5, signals are an under-the-hood implementation detail rather than something you interact with directly.
The big issue for me was the lack of support for nested observables in Svelte, which caused no end of trouble; plus a lack of portals (though maybe the new snippets fix that?).
But it feels awkward for real SPAs - internal applications that have no need for server side rendering.
I get that hydrations value is mainly in SEO and a tiny improvement in initial draw speed, but why would you want it disabled, specifically?
It's pretty much what you already wrote though.
You'll only need the fallback page and can omit the +layout prerender configuration. It's documented on that page
SSR means your web server needs to scale with load on your front page, versus static bundles that can be served almost at infinite scale from a $15/month VPS.
However, when your app is larger or needs to be faster, you want a dedicated backend for your API. Then, you can choose a more secure and more scalable language like C#, Go or Kotlin.
Regarding performance, many SSR advocates (don't forget there's a huge business behind this stuff) don't do the math correctly. It's faster (or as fast) to host a SPA on a CDN and get the data from your backend close to your DB. Let me explain assuming the page containing personal data from the user:
1. The user never visited the site. Getting the SPA from the CDN is very fast. Even if you need to get the JS via a second round trip. Then to get the user data is a much slower second roundtrip to the backend server. With SSR, you also have a first much slower roundtrip to the backend to get your SSR site (maybe even another one for hydration!). Then there's a second slower roundtrip to the server to get the user data. This request is slower than getting the data from a fast API backend in the SPA case. So, if the user never visited the site, you need basically two requests anyway: One for the app another for the data. How else should the backend know, what data to return. With an SPA on a CDN the first request is much faster. I must mention that rendering the SPA is an issue on slow devices. But this is a much smaller problem with Svelte than with React. SEO is probably better with SSR, but no as much as the crawlers are nowadays fast to run the JS.
2. The user has visited the site: The SPA is cached in the browser. Or an eTag validation request goes to the CDN. Very fast. Then, the first relevant request with user auth token goes to the backend to get the user data. With SSR, you get everything with one request. No real world difference there. Both approaches one relevant request. One can argue: Rendering the JS on the client device vs on the Node server. C# or Go backend faster than Next or Sveltekit. But those are not the big numbers.
Now, the big disadvantages of SSR is that you need to run a comparatively slow and not very scalable Node backend. If your app is small, then go for Sveltekit or Next with SSR as the DX is awesome. There's no simpler way to create a fullstack app then Sveltekit. It you have a more complex scenario, most of the time SPA is the way to go.
I get that you've got opinions and like to voice them, but the parent comment didn't say they didn't want to use the node backend whatsoever initially. they only asked how to disable hydration.
IMHO, you'd be better of using Angular or plain svelte for this usecase, as almost all value you get from svelteKIT is the tight backend/frontend integration.
If you don't want that, you're using the wrong tool. But hey, the definition of a hacker is basically "a person that uses a tool for an unintended usecase" (literally: someone that uses an axe to build furniture), and this is called hackernews. To each their own.
With that said, unfortunately when using Kit in "SPA mode" you're not getting the full experience, but it's still the best thing out there. You could try Routify as well.
There's a great talk from last years Svelte Summit that was about Svelte(Kit) in "SPA mode".
https://www.youtube.com/watch?v=uIZOeBS-3cI
TL;DR: Lean into load functions and monkey-patch fetch (if possible)
At the end of that process you'll have the background to reevaluate your decisions.
That said, if you truly want to learn, MDN is the reference, and they have a pretty good curriculum too: https://developer.mozilla.org/en-US/curriculum/
Also, ignore the dizzying amount of frameworks. Learn web technologies, and then React. There are millions of back-end tools as well, but in practice, you only use a limited set. Front-end is the same.
If you don’t like anything – no worries! Classic SSR with templates and stuff is a thing too, as another commenter pointed out.
Edit: no matter what, make sure you write good HTML first and foremost. Use proper semantic tags, don’t add dozens of nested divs, use native controls when possible etc. Make sure to check accessibility, but it should be OK if you don’t do any weird stuff. MDN is a great starting point.
Svelte is pretty niche. I'm not saying you shouldn't learn it, but that you should focus on the common tools first. This is just like you might tell a friend learning programming to learn Java/Python/Go etc. before getting into Lisp/Haskell/Prolog.
All are useful and have their place, but one set of languages is definitely more likely to be used in a workplace (unless you're lucky!).
If you want my opinion on a cool/trendy framework to use, I really like Astro [0], but, again, I doubt anyone will hire you unless you also have experience in React/similar.
[0]: https://astro.build/
I'm not sure if I understand well its use case. It's not for cases when there's complex backend logic, right? What other technologies can be replaced by Astro, to have an example?
> What other technologies can be replaced by Astro, to have an example?
As I mentioned above, and you hit on this too, I think Astro can replace static site generators. It wouldn't replace React (or your favorite framework), but it would use those frameworks to reduce your overall reliance on JavaScript and let most of your site be static HTML.
Astro has "island" pattern which allows you to selectively use JS frameworks on portions of pages where interactivity is required. You can use React, Vue, Svelte, etc.
The big benefit of islands is that the majority of your site is static HTML and only the bits of each page that actually need JS rely on it vs React where your entire site would use JS.
I haven't used this feature but I have heard that people really like it.
I think Claude/ChatGPT works exceptionally well with React code.
I tried to learn Svelte but React/Tailwind plus a language model is just incredible.
Much React hate I think is the way I view the band Metallica. They were way cooler in my head when they were not as popular.
If you use "if !browser" with sveltes browser object, the things inside that branch will only run on the server.
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.
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.
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.
Has anyone had similar experiences/confusions when learning SvelteKit?
The universal load function specifically not only injects the data on the server before serving the page but then also runs on the client once the page is loaded.
In my specific case the client side version hit a different api, hosted in a different region. There are different use cases for this though.
Similar kind of thing happens in zig during comptime execution.
This is what I would call "magic" or implicit behavior. It seems very nice to have that at first but in reality after significant use of something there will come a point at which one wants to fully understand how it works. The magic then needs to be demystified.
(edit) Sorry, for previous users the preview site might be better: https://svelte-5-preview.vercel.app/docs/introduction
Any idea of when the new tutorial will be complete? I might go back and refresh some stuff.
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:
let counter = 0;
// ...
<div>{counter}</div>
With the `$store` rune, the way you make reactive stores inside and outside components is the same, but it only works in .svelte.js/ts. The unification is great – but why not just use `let` in .svelte.js, too?
// 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>
But again – really good work and I hope to try it out on my next project!
No shadow dom and a better template directives? Maybe, not sure.
The runes are still optional, I think, and you can still use the old syntax. Not sure if that will be true in Svelte 6 though!
import whisper
model = whisper.load_model("turbo")
result = model.transcribe("audio.mp3")
print(result["text"])
import eng_to_ipa as ipa
def get_homophones(word):
words_that_sound_the_same = []
the_way_this_word_looks = word
the_way_this_word_sounds = ipa.convert(word)
words_that_contain_that_sound =
ipa.contains(the_way_this_word_sounds)
for every_word in words_that_contain_that_sound:
the_way_that_word_looks = every_word[0]
the_way_that_word_sounds = every_word[1]
if the_way_this_word_sounds == the_way_that_word_sounds:
if the_way_that_word_looks != the_way_this_word_looks:
words_that_sound_the_same.append(every_word)
return words_that_sound_the_same
get_homophones('their') #[['there', 'ðɛr'], ["they're", 'ðɛr']]
Chef's kiss. I hate code that overcomplicates.
Blah blah 'making stuff explicit'... I don't think that it's impossible to make things explicit while also making it ergonomic, and humane to use.
Anyway, programming as a whole is an old paradigm, sigh, might as well make the new thing myself.
Runes are a pretty slick addition, as someone who comes from React, this feels like home.
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!
Nope, but it does have routing!
I won't choose React for my own projects again.
Seems like the number of companies using Svelte in production is growing but still not super high.
I like the direction Svelte going in, the old syntax was ok but not great.
I wonder how this new Svelte compares with some of the other new kids on the block like solid.js and alpine.js.
You're talking about SvelteKit. Svelte does not have a router.
Performance might be the only reason IMO, but once Vue Vapor is release that will most likely not be an advantage.
The Vue3 and Svelte 5 API are almost the exact same, but Vue can be used in TS/JS and Svelte 5 can't.
I do think SvelteKit is better than Nuxt by a lot. Maybe that's a big advantage.
I found the mental model behind managing state in Vue a little difficult. There was a lot of syntax I had to learn/understand before I could work with it. OTH when I first worked with a svelte working with the code base was extremely straightforward, and that was my very first time touching JS.
I think the main reason for Svelte5 to exist was that state can now be shared beyond the boundaries of a .svelte file. They needed a reactive stateful primitive which is the $state addition.
I recently tried to start building something in NextJS, I worked with react a little bit and thought it really isn't going to be that hard. I honestly didn't get far, I really needed to understand a bunch of concepts before I could just start working. This isn't something I experienced when I started working with Dart&Flutter.
I appreciate all of the work other authors have put in to make UI in plain JS and not bend the language to their whims, but I don't think UIs can be built ergonomically without that. Historically UIs have always been best expressed in languages built around that fact. HTML, CSS and Vanilla JS pushed the envelope for UI development but with what's expected from UIs in this age of browser based computing, that model just doesn't age as well given the complexity it adds.
It's why I reckon people won't give up on making UI frameworks in Rust, because it's macro system allows the authors to build supports around a language that really could not get far on just it's own.
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.
I made my first website a few months ago (I'm an ML engineer). I tried in both Svelte and React.
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.
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.
It seems that my opinion that React is horrendously and hideously overcomplicated is at least somewhat objective! Svelte has been quite pleasant.
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.
Now granted I’d never use a reducer, and imo a decent state library is the biggest win if you are using React.
Every time I try out something other than React (Vue, Svelte, etc), I have to learn some new syntax, understand the runtime magic, and add a syntax/LSP to my editor. But React is just JS/TS, which is straightforward.
Being disappointed by a library/framework because your LLM of choice can't produce decent code doesn't really tell me very much about the library, other than it's usage is varied.
The syntax is maybe the only good part of react. And I still think the way it uses JSX is not great. Conditionals and .map seem... weird.
But yes, judged from syntax only, react is ok.
just came back to svelte after using version 3 previously, and I'm still finding my footing;
CLI tool: https://github.com/sveltejs/cli
Edit: added the link to the CLI tool
Why makes you think SvelteKit could be dead? What a weird a pessimistic phrasing.
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.
For those of us who do not like to code complex logic and state in javascript, I can recommed htmx https://htmx.org/. Also, I am more comfortable writing backend code and this just fits my style better.
I really like the way that Svelte has a single file that encapsulates the HTML, CSS and JS for a page and it does so as three seperate chunks of the svelte file. This means I just need to look at say blogPost.svelte to see everything I need and I don't need to think about namespaceing or BEM or anything else for the CSS.
Its this way of working with Svelte that I really like and rarely see from other frameworks. I find astro to be good for this too.
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.
I’d recommend another solution for experienced devs.
Shouldn't this be a more general programming language, not tied to the web?
people would be better off just using the real thing, Solid
https://www.skeleton.dev/ and https://flowbite-svelte.com/ are another couple of popular ones.
There's a big list at https://www.sveltesociety.dev/packages?category=design-syste...
I really liked having HTML/CSS/Js all in one place.
But then tailwind became popular, and I realised I could get this same UX with React + Tailwind.
Now I prefer React + Tailwind to Svelte.
No Svelte jobs, weird compiler magic. Hated SvelteKit