Alright, since HN is doing its tedious grumpy-old-man thing, let me just spell this out: Your old Svelte components will continue to work. There'll be some 'breaking changes' in the persnickety semantic versioning sense, but migration will be smooth. It's a big priority for us.
But the thing you'll be able to easily and incrementally migrate _to_? It's radical.
Big thanks for all the work you've done: I've been using SvelteKit mainly for experimentation & one-offs.
Svelte v3 -> v4 migrations have so far been a breeze for me: An entry update to package.json and an 'npm update' is all I need to do to migrate, and I've been doing basic CRUD & SSR/CSR SVG renders in my test projects.
I have no clue what kind of esoteric state management / render manipulations everyone else has been doing to make Svelte angry.
Thanks for the re-assurance. We've been migrating a huge app to svelte over the last 6 months and it's nice to hear it won't be become legacy on arrival ;)
Looking forward to the easy & incremental paradigm shift whatever it is.
I'm hoping there could be some improvements to composability and slot edge-case usage possibly?
As swyx said, it's probably not a priority for us. You can basically get the same benefits by using Incremental Static Regeneration, which is turnkey if you're using Vercel (not through any tight framework<->platform integration, but rather because the platform offers the feature and the Vercel adapter exposes it — any other platform could do the same thing): https://kit.svelte.dev/docs/adapter-vercel#incremental-stati...
(am not rich, just giving thoughts on why i disagree with the premise of the question) incremental build is a static site concern and i think its pretty clear the industry has more or less given up on that as a scaling strategy for websites in favor of serverless/edge rendering (which you can blend with static generation to get almost the same thing as incremental builds)
Svelte 4 was recently released (like 2 months ago), and Svelte 5 is already being primed.
I wonder if these types of messaging/marketing hurt adoption? If you're looking for something stable and you see large version changes, why would you adopt it?
You'd think with all the react misfires over the last year (telling the community common of useEffect is wrong, server components landing flat, poor performance) that the community would be open for adopting something new like solid, svelte, vue, or hell even htmx; but react still climbs in usage rates.
If you're working on an average crud app and just need something to handle an SPA why would you choose svelte? In less than a year there's breaking changes, now add another potential one. I want to say this hurts optics more than it helps, because I know my coworkers at boring enterprise company will just say it's unstable. It doesn't matter how performant it is, it doesn't matter how similar to react/vanillaJS it is; all they see is a library with massive changes that breaks compatibility and fractures what little 3rd party libraries there are, doesn't matter if this argument is right that's the perception.
So we decide to do another project in react and the world continues turning.
I think I'm understanding why htmx is becoming popular...
I don't see how it can hurt adoption? Svelte/Sveltekit are already stable. This is simply an update from the Svelte team about how performance is getting even better. If anything, this inspires confidence from me about how the team is constantly looking to improve the product. Svelte 3 to Svelte 4 was pretty much a painless transition too.
A lot of panic in here about how people think this is a Angular v1 to v2 transition all over again. Svelte version updates are largely behind the scenes so there's really not much to upgrade if your app is already built in Sveltekit.
People who haven't tried Svelte/Sveltekit yet are seriously missing out. It's a breath of fresh air in today's UI landscape. The constant performance gains are the cherry on top.
Svelte doesn't exist in a vacuum, and developers have been burned by major version bumps over and over again (Angular, every PHP upgrade, Python 3, etc). If Svelte is stable, they can signal that by keeping the version numbers stable.
People who are still considering adoption don't know enough yet to read release notes and understand what are breaking changes and what are not.
If you introduce a breaking change no matter how trivial or edge case it's considered WITHOUT bumping the major version number, I guarantee folks will be very bitter indeed.
Trust is hard-earned but easily lost. Best not to use a semver number blithely as a marketing tool.
Backward compatibility is best, but if you have to break things, make it 100% clear to folks downstream. This is what Svelte 4 did. The changes were mostly esoteric and changed a couple of defaults due to experience/lessons learned, but they were breaking changes made for good reasons. Leave semver considerations out of the marketing and concentrate on the problems you're trying to solve and how well the tool helps solve them for you.
"I don't like the way the garnish looks they put on my ribeye, so I'm just gonna head over to McDonalds."
JSX doesn't even parse the same as HTML5; it matches XHTML from decades ago. Again, the source doesn't match what the target uses (browsers). It's close, but not the same.
A Big Mac is close to a good burger, but it's not a good burger.
Node.js is now on version 20, and Node 16 was stil active as of this time last year. Is it unstable?
literally spending 2 seconds reading the Svelte 4 release makes it clear that its a maintenance release. you could've done that instead of typing all this.
v16 had maintenance + development for 2+ years. Seems pretty good for an ecosystem that has a reputation of breaking changes across minor npm packages.
I use svelte for some side projects, I want to adopt it where I've worked in the past but it's very hard to win mindshare against arguments about stability and support. And honestly? Those arguments are very valid, that's why I asked if these types of hype posts actually hurt adoption. It was a question, this is a forum.
---
As an aside I'm very disappointed with your reply attacking my education level.
You don't remember me but I met you at React Boston 2018 and complimented your talk. If this is how you talk to people online that are nobodies, I don't know what to say... except thanks for showing me your true colors.
Hopefully you're just having a moment of stinginess and this isn't who you actually are.
thanks for remembering me, and no i didnt attack your education level, i was just very tired of people having lazy superficial reactions to version changes and making up a non-story. i shouldve also pointed out that the active version of React went from React 16->17->18 in the span of 2 years without people raising this kind of comment so its basically a double standard. anyway i see where you're coming from so I apologize.
I wasn't trying to diss Svelte at all with my comment, my question is very sincere. I use Svelte for a few local apps on my home network (board game and a music playlist selectors) but I have a very hard time convincing people starting new projects to consider it. That's why I tried to pose it as a question because I don't really know how to argue against it.
Svelte 3 was released 4 years ago. Svelte 4 had VERY few breaking changes, and those were in obscure corner cases.
Four years in the JavaScript ecosystem denotes a very stable API. 99.9% of all Svelte 3 projects would likely need no code changes at all moving to v4, at least that's been my experience.
Enterprises love Angular… which is now on version 16. Speaking from personal experience, the level of breakage between Angular versions (specifically v13 to something newer) is far greater than what was found in Svelte 3-to-4.
Svelte is substantially similar to plain HTML, CSS, and JS than any other framework out there except for htmx, and htmx gets there by actively avoiding any JS (punting to AlpineJS, which will have its own major version change issues) and therefore limiting the scope of problems htmx can tackle on its own.
htmx is great for what it is, and I love that it is helping people understand the inherent power of HTML before JS even joins the chat. However, it's not a complete web development solution like Svelte (or React, Angular, Vue, Solid, etc.).
But why did Svelte 4's maintenance changes need to be a major version bump? Why not make the changes as minor version changes to Svelte 3, then bundle all breaking changes into Svelte 4?
Because of a little thing called semantic versioning. A change can be 'minor' in the sense that it doesn't really affect how the vast majority of users use your package, but still have changes that are technically breaking.
I'm aware of that. I'm asking why the tiny breaking changes couldn't just wait for the next major release, because OP is correct that frequent version number bumps scare off potential adopters.
Used carefully, semantic versioning shouldn't just describe the development choices you made, it should encourage you to make more conservative choices to avoid unnecessary breaking changes, small or large.
Svelte 4 was a complete structural overhaul of the `sveltejs/svelte` repo — turning it into a monorepo, converting all the `.ts` modules into typechecked `.js` files, etc, modernising our dependencies and our workflows, dropping CJS and so on.
Svelte 5 is a complete internal rewrite of the code itself.
Could we have achieved both in a single release? With perfect planning and foresight (at a time when we didn't yet know what Svelte 5 would entail) then maybe, yes. But more likely, it would have just jeopardised both things, and made it near-impossible to ship bugfixes for the current stable version. That's why we opted for this approach, and carefully communicated it (through our own dev vlog, our release notes, our blog posts, our podcast appearances and so on).
Managing an open source project beyond a certain level of complexity and usage is _hard_. These are the sorts of choices that are sometimes necessary. I'm very confident that we made the right one.
FWIW, I didn't intend either of my comments to be a personal attack. I understand how complicated running an open source project as large as yours can be, and I don't envy your task. I was just agreeing with the original poster about how these things look to those outside the community. Your explanation for how that happened makes a lot of sense.
Similar approach seems to have worked well for Java. There are long term releases like versions 8,11,17 and everything in between are kind of catch up releases with short term support cycle. Enterprises typically adopt LTS releases while enthusiasts/startups/developers would tinker with other short-term releases and give valuable feedback back to the community.
Have you seen the insane abuse that the Chrome (and later, Firefox) teams have subjected their version numbers to?
In the first ten years Firefox existed, it went from version 0.1 to version 5. They're completely meaningless concepts now. It is ludicrous we are now on major version >100 for both browsers!
> There is a major difference: user-facing applications don't need to maintain backward compatibility.
Of course they do. Users still use extensions and web-pages that they expect to work. Firefox moving from e.g. XUL/XPCOM to WebExtensions could've been a major version bump, for example. Ditto Manifest v3 for Chrome.
I wish people would stop assuming users are too stupid to understand basic information about the software they use!
I feel that when an application stops supporting some old, unused file format that nobody cares about anymore (for example some old version of .doc files), then it should not be a major version bump. That would be giving too much visibility to a change that has little to no impact for most users.
Extension APIs on the other hand should have their own version number. Especially since an application may ship with both v1.x and v2.x for some time while v1 is being phased out. The app may even display some warning: "you are using extensions X, Y and Z that are using the API v1. This API will be removed in next release, causing these extensions not to work anymore".
The target audience of those version numbers is different from the app's main version number.
it simplifies versioning. there is no more major and minor versions. there is just version. how is firefox 108 any different from 10.8? it just feeds the argument when to make a major version bump if you don't just do it when you reach the 9.
it's something the linux kernel could have adopted too. because the difference between 5.19 and 6.0 is just as incremental as all the other versions.
the only benefit with the kernel versioning is that the first number gives you a rough indicator how old a system is. are you still on 4.x? you should probably upgrade. but actually the same can be done with current browser versions. your browser version is in the 80s? you should probably upgrade.
in the kernel case it would have been interesting to increase the major version exactly every 5 years to help with the age estimate.
as it is, the kernel settled on the version number being base 20
> it simplifies versioning. there is no more major and minor versions. there is just version.
Yep. For developers that build software its very easy. Fixed a bug - version++, improved performance - version++, changed API - yes version++, rewrite program in another language, broke all compatibility, remove 2/3 of all supported features, yep, version++.
By your logic difference between bugfix in programming language and change of syntax should be indicated with the same version++?
no, i only don't see the need to distinguish between major and minor feature releases.
there are feature releases and bugfix releases. this is what the linux kernel, browsers and even some linux distributions are doing.
for most apps but also for the linux kernel and for programming languages incompatible changes should not even happen. a browser should support old websites, so there is never an excuse to break compatibility. hence no need for versioning that. i am not talking about libraries and interfaces.
the main problem with major.minor versions is that it is never clear what should be a major version change and what should not. emacs solved the problem by simply dropping the major version. a few other applications did too.
the pike programming language switched from 0.6 to 7, avoiding calling it 1.0 as the language had already been stable for some time by then. then they slowly increased the minor version to 7.8 in 2008, but where afraid to go to 8.0. i remarked that if they didn't switch to 8 soon, they never would. eventually they switched to 8.0, 5 years later, and are now at 8.0.1738. (but there is a 9.0.0 version in the development branch since end of last year).
sbcl switched from 1.5.9 to 2.0.0 without any major changes. since then they release a new version every month and the version number is basically decade.year.month. there is no distinction between major and minor versions. the current version (looking at the calendar) should be 2.3.7. what does that tell me about the difference to 2.2.11? absolutely nothing. if they used a single linear increasing version it would not make a difference.
which in my eyes is actually correct for both examples because a programming language should not have major changes. the python2->3 transition was a big headache. it should not have been necessary.
in most examples that i can find the distinction between major and minor is meaningless. a more sensible distinction is: feature.bugfix, that's enough. and for many apps i would not even bother with bugfix releases unless the bugs are damaging to the users.
I've got a side project still on Svelte 3, I feel this. I got the implementation into a good state a few months ago and haven't needed to touch it, soon it will be two major versions behind. No regrets, no other framework was as easy to work with for a primarily SSR app.
I was feeling this with Quarkus too, but they finally set one of their recent versions as LTS. Setting an LTS and migration guides between LTSs is a practice I'd like to see more in front-end tech.
There's about a 99% chance you can update from Svelte 3 to 4 without any code changes. Some code changes are performed automatically by the migration script: https://svelte.dev/docs/v4-migration-guide
Yeah I have a little personal Svelte app from the v3 days too, basically a simple form site that I use to choose boardgames during dinner parties.
It still works locally, been meaning to update it which I think will be painless as well because it's a dead simple site. No regrets either, I really like Svelte and tried to convert some data visualization apps with it but couldn't win mindshare at the time in these companies.
I haven't look into too much, but what made react easy to adopt was that Facebook would put out codemods to help migration during major transitions. It was easy to justify these version bumps when there was tooling that made these transitions somewhat painless.
Yeah, I’d agree that React development has been a major disappointment starting with hooks. I’d like to move on, but to what? I want a framework that fulfills the promise of React: efficient DOM updates derived from state paired with something that is just JS under the hood - no templating language/DSL.
When building nontrivial applications, I don't want my UI framework to be radical from version to version. Performance improvements are great and all but if radical means substantial change to the design, an upgrade amounts to a rewrite.
Which one do you use? All of them went through breaking changes.
Also, I'm pretty sure "radical" was referring to the performance improvements, not API/syntax change. Svelte has very simple syntax, there isn't much you can change.
No kidding. I'm literally back to just generic server-rendered templates wherever I can get away with it. I don't want to fix UI code, ever, whenever I can help it.
There's no ignoring svelte despite a lot of devs pushing back against it due to years in React and "existing resources and community". The performance is superior and that will drive adoption. It's a much better development experience. Sort of feels fun again.
Performance is never what drives adoption of general solutions like front end frameworks, developer productivity is way above that as a metric and yeah: React having a massive ecosystem is it’s killer feature.
Trust me, I wish we could move one from React for something more reasonable like Solid or Svelte, but no amount of benchmark will change the trend.
Feels like Twitter is living in a parallel universe.
I’ve just started learning Svelte for a side project, but I think you can make an argument for developer productivity with it too. React doesn’t have a monopoly on that.
What if you don't need a massive ecosystem? For example, the project I am currently working on has (checks package.json) react-router, react bindings for redux, and react-spring (the latter could easily be dropped; it is almost not used). Plus Storybook, but that's not even react-specific. That's all.
The ecosystem is more than the libraries. Do you use the VS Code or WebStorm integrations? Do you use one of the many options we have for bundlers and dev servers? Do you use the browser dev tools?
Svelte has to recreate plugins for all of these things and more. I haven't yet tried Svelte (I'm waiting for Svelte 5), but the tooling needs to be at least comparable to Vue's if I'm going to consider adopting it.
It doesn't need wrappers to the same extent React, Angular, et al do. Svelte works quite well with vanilla JS libraries without having to implement a wrapper most of the time.
> The performance is superior and that will drive adoption
This has never been true. Nobody adopts React in 2023 because it's the fastest (as in performance) option. Other frameworks have been far faster for the better part of a decade. Why would shaving a handful of milliseconds here and there change the game now?
People choose React because you could have gone from 0.15 to 18.0 with maybe a week of effort, often less. It has escape hatches where they're needed. Almost every tool you could need works with React. There's essentially nothing that you can't accomplish with React as the foundation. Nobody has gotten fired for choosing React.
> People choose React because you could have gone from 0.15 to 18.0 with maybe a week of effort, often less.
That's only if you are not using other libraries, otherwise it will take much more time than that and the upgrade would very likely require you to rewrite your components as functions which will be a massive undertaking, specially for larger codebases which already made extensive use of OOP patterns to keep code modular. It's even worse if you consider that React is unusable for most projects without a lot of associated tooling that also faces breaking changes often (i.e. your build tooling, your CD/CI environment and deploy workflow, etc.).
In reality React is anything but stable, it has in 10 years faced multiple paradigm shifts in terms of development experience, had most of its codebase changed or refactored multiple times, etc.
> Nobody has gotten fired for choosing React.
This is an (unfortunately) very true piece of wisdom which I have to agree with.
I spent a couple of days trying to migrate a react app at v17 bootstrapped with create-react-app to v18 and Vite, but eventually gave up because all the tooling and libraries and deployment processes needed attention along that migration path.
I'd be very surprised if 0.15 to 18.0 could be as seamless as you claim, for a real production application with hundreds of components and a few dozen dependencies
While yes, Svelte is faster out of the box than React, that's not its main draw in my opinion. When you learn React, you learn React's idioms, its methodology, the common component libraries, etc. You learn its API and patterns.
Svelte follows the patterns established by HTML and CSS, and builds upon them. If you know how to write static HTML, you will already be familiar with the structure of a Svelte component. If you know CSS, the <style> tag in Svelte is natural to you (except that CSS styles are scoped to component by default, so it's actually easier than plain CSS).
For the JS, you don't have to research to find out what the hot client state management tool of the week for React is. You don't have to worry about useState vs useEffect vs useMemo. You don't have to worry about how to integrate with a reactive library like rxjs. You just write what looks like plain JS + things like "$:" and "$store", and you're done.
Developer performance is what matters most here. React has an advantage for now due to a decade of inertia, but folks coming up who don't already know React or folks who are feeling burned out by React due to huge transitions like classes-to-functions? They're the target audience who's gonna try Svelte and realize they've been living with Stockholm Syndrome for a while now.
Things like useMemo(…) are abstraction leaks. They are mental overhead and boilerplate over and above the actual problems people are trying to solve.
Gimme someone with HTML/CSS knowledge and basic JavaScript skills, and I'll deliver a viable Svelte developer in a day or two. That's something React cannot match and will never match.
Will React disappear? Of course not. Even COBOL is still in use. No one's dumping React and a large codebase on a whim. But when more folks realize they can use GridJS and ChartJS and other vanilla JS libraries out of the box with Svelte without an elaborate stack of bespoke wrappers to make them work, React's ecosystem will not seem quite so rich in comparison.
Folks writing for greenfield are gonna think twice about React.
I think the future is frameworks like Astro that allow you to use any library you want. That'll make the most sense until someone comes up with a new paradigm all together.
SolidJS is currently faster at runtime. Not sure it could beat Svelte at developer time. And with the reported speed improvements in Svelte 5 (waiting to see how those bear out in the real world), the difference isn't going to be how fast in runs in your browser; it'll be how fast you can go from a blank IDE text window to a user's browser.
let features = 0;
let people = 1;
$: featuresPerPerson = features / people;
function addPerson() {
people++;
}
function addFeature() {
features++;
}
Folks might consider it magic, but it's a lot closer to our mental model of the problem than anything SolidJS can give. As for "magic", we're working with sand we shot with lightning to make it think. If you don't like magic, you're in the wrong vocation. The only question is whether or not the magic is useful, predictable, and reliable. I consider Svelte to be that right kind of magic.
I get the flex. But for the kind of application I'm building professionally, updating thousands of rows is hardly a concern. I spend most of my time thinking about state and data lifecycle.
It has been a while since a framework actually slowed me down enough for me or my users to notice.
Putting perf aside for a moment, I think the way svelte components are defined is a superpower, and more compile-time ergonomics like that could really differentiate Svelte.
Learning Svelte 4 is no different than learning Svelte 3, the changes are almost entirely behind the curtains. Apparently Svelte 5 will also be very minimal breaking changes, so any knowledge will pass over trivially.
In other words, invest all your time in learning svelte :>
Not sure I agree about Svelte's bundle size being a problem, but v4 already improved tooling quite a bit by switching to JSDoc and judicious type export limits. Intellisense for library functions, the ability to drill down seamlessly from your code to library code, and helping IDEs choose the correct import have all greatly improved.
Yes, I would think a framework that cares about performance would include optimizations that are too difficult or tedious to perform by hand. It should be faster than vanilla js.
No change between a v4 and v5 should be “radical”.
Sure make changes, even breaking changes but “radical” does not inspire confidence that the migration will be straightforward or that the people running the project have any respect for what users have already built.
I hope this is just Rebase style hype and that in reality the changes are more measured than implied here.
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes <-- You are Here
MINOR version when you add functionality in a backward compatible manner
PATCH version when you make backward compatible bug fixes
Radical implies Angular v1 to v2 types changes, which was disastrous for a lot of people who had built large complex apps on v1 that then had to be maintained for years because a v2 rewrite was too big.
But the thing you'll be able to easily and incrementally migrate _to_? It's radical.
I'll get off your lawn now.