4 ms·

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 b

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.
Raed667 3y ago
I don't want to dismiss Svelete entierly but this code `<button on:click={handleClick}>` smells like old bad ideas instead of fresh air. It is yet another custom templating language with its unique limits [0]. If I have an option i'll stick with JSX. [0] https://github.com/sveltejs/svelte/issues/5112# https://github.com/sveltejs/svelte/issues/5112#
- ttfkam 3y ago
  > If I have an option i'll stick with JSX. "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.
- deleted 3y ago
  [deleted]

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.

Raed667 3y ago

I don't want to dismiss Svelete entierly but this code `<button on:click={handleClick}>` smells like old bad ideas instead of fresh air. It is yet another custom templating language with its unique limits [0]. If I have an option i'll stick with JSX. [0] https://github.com/sveltejs/svelte/issues/5112# https://github.com/sveltejs/svelte/issues/5112#

ttfkam 3y ago
> If I have an option i'll stick with JSX. "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.
deleted 3y ago
[deleted]