6 ms·

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'

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...

yewenjie 3y ago
Svelte 4 was just a maintenance release (also after a couple of years of Svelte 3) to smooth-out the way to Svelte 5.
- lolinder 3y ago
  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?
  - lol768 3y ago
    Because major version bumps are 'sexy' nowadays. 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!
    - tmpz22 3y ago
      Do Major version bump contributions count more towards promotions at those companies?
      - azemetre 3y ago
        IDK about promotions but apparently it was a thing for the TypeScript project to get funding at Microsoft: https://github.com/microsoft/TypeScript/issues/14116#issuecomment-280592571 https://github.com/microsoft/TypeScript/issues/14116#issueco...
    - sdeframond 3y ago
      There is a major difference: user-facing applications don't need to maintain backward compatibility. For a library or a language, developers like to use Semantic Versioning: a major update will break client code.
      - lol768 3y ago
        > 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!
        sdeframond 3y ago
        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.
  - rich_harris 3y ago
    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.
    - xboxnolifes 3y ago
      Exactly. A library update that requires 1 minute of code writing to fix breaking changes is still a breaking change.
    - lolinder 3y ago
      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.
      - rich_harris 3y ago
        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.
        lolinder 3y ago
crackinmalackin 3y ago
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.
- teddyh 3y ago
  <https://en.wikipedia.org/w/index.php?title=Osborne_effect&oldid=1162915650 https://en.wikipedia.org/w/index.php?title=Osborne_effect&ol...>
- lolinder 3y ago
  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.
  - ttfkam 3y ago
    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.
putnambr 3y ago
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.
- alserio 3y ago
  If I may, you are a major behind, and not much has changed from 3. 4 to 5 seems that will be more "radical" but right now is still in development
- khromov 3y ago
  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 https://svelte.dev/docs/v4-migration-guide
- azemetre 3y ago
  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.
swyx 3y ago
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.
- azemetre 3y ago
  The Node foundation puts out maintenance cycles on their site: https://nodejs.dev/en/about/releases/ https://nodejs.dev/en/about/releases/ 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.
  - swyx 3y ago
    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.
    - azemetre 3y ago
      I understand, thank you for the apology. 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.
kansface 3y ago
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.
- csjh 3y ago
  Isn't that just SolidJS?
ttfkam 3y ago
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.).

yewenjie 3y ago

Svelte 4 was just a maintenance release (also after a couple of years of Svelte 3) to smooth-out the way to Svelte 5.

lolinder 3y ago
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?
- lol768 3y ago
  Because major version bumps are 'sexy' nowadays. 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!
  - tmpz22 3y ago
    Do Major version bump contributions count more towards promotions at those companies?
    - azemetre 3y ago
      IDK about promotions but apparently it was a thing for the TypeScript project to get funding at Microsoft: https://github.com/microsoft/TypeScript/issues/14116#issuecomment-280592571 https://github.com/microsoft/TypeScript/issues/14116#issueco...
  - sdeframond 3y ago
    There is a major difference: user-facing applications don't need to maintain backward compatibility. For a library or a language, developers like to use Semantic Versioning: a major update will break client code.
    - lol768 3y ago
      > 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!
      - sdeframond 3y ago
        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.
- rich_harris 3y ago
  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.
  - xboxnolifes 3y ago
    Exactly. A library update that requires 1 minute of code writing to fix breaking changes is still a breaking change.
  - lolinder 3y ago
    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.
    - rich_harris 3y ago
      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.
      - lolinder 3y ago

crackinmalackin 3y ago

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.

teddyh 3y ago
<https://en.wikipedia.org/w/index.php?title=Osborne_effect&oldid=1162915650 https://en.wikipedia.org/w/index.php?title=Osborne_effect&ol...>
lolinder 3y ago
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.
- ttfkam 3y ago
  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.

putnambr 3y ago

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.

alserio 3y ago
If I may, you are a major behind, and not much has changed from 3. 4 to 5 seems that will be more "radical" but right now is still in development
khromov 3y ago
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 https://svelte.dev/docs/v4-migration-guide
azemetre 3y ago
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.

swyx 3y ago

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.

azemetre 3y ago
The Node foundation puts out maintenance cycles on their site: https://nodejs.dev/en/about/releases/ https://nodejs.dev/en/about/releases/ 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.
- swyx 3y ago
  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.
  - azemetre 3y ago
    I understand, thank you for the apology. 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.

kansface 3y ago

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.

csjh 3y ago
Isn't that just SolidJS?

ttfkam 3y ago

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.).