3 ms·

https://svelte.dev/docs/svelte/v5-migration-guide#Event-changes https://svelte.dev/docs/svelte/v5-migration-guide#Event-chan... Yes, what a completely frivolou

https://svelte.dev/docs/svelte/v5-migration-guide#Event-changes https://svelte.dev/docs/svelte/v5-migration-guide#Event-chan... Yes, what a completely frivolous change that will only cause headaches. Changes like this are why I dislike the mentality in the JS ecosystem. It was just cosmetic, and creates unnecessary churn. They seem to be addicted to changing things. They didn't like the old syntax? Though. What's done is done. Don't make frivolous changes in frameworks damn it.

danielscrubs 2y ago
Had the same feeling. Because of that I moved on to no-build Preact. I’ve been happy with it so far, and I hope that it will get me closer to ”work for the customers, not for the vims of framework developers”.
benmccann 2y ago
Snippets are far more powerful than slots and so the change is not merely cosmetic. Snippets give you a way to create reusable HTML fragments within a component.
- gedy 2y ago
  Sure, that is nice - though TBH that kind of feels like a workaround for Svelte's one file, one component design. React doesn't have this issue and can define as many components wherever you like.
- RadiozRadioz 2y ago
  I was commenting specifically about on:change
  - benmccann 2y ago
    I believe the reason for that was to enable event forwarding, which was a highly requested feature and makes a lot of things easier.
arichardsmith 2y ago
As someone who is in the midst of migrating from Svelte 4 to Svelte 5, I definitely feel the pain of syntax changes. However, I'd argue that `on:change` -> `onchange` isn't frivolous. A real world example: in Svelte 4, I had a custom input component that wrapped an <input> element. To be able to do `<MyInput on:change={callback} />` took a bunch of event forwarding boiler plate (or magic `on:change` syntax to forward that one event). When I wanted to also forward blur events I had to go through the same process. Now in Svelte 5 I can just use `const { foo, ...rest } = $props()` then spread with `<input {..rest}>` and I get all events forwarded for free. They could have kept the original `on:change` syntax, but that would have made property access more painful (who wants to call `rest['on:change']`?) and would have broken all my other components that I haven't migrated yet. The same goes for slots to snippets. Being able to pass snippets around like props has allowed me to simplify tons of components where slots were limiting. As a solo dev working part time on a Javascript project, I definitely hate some of the ecosystem churn, but this is one refactor I'm happy to do, and I'd say the same about most of the Svelte 5 changes.
- nhumrich 2y ago
  This is a really good perspective. I appreciate you sharing!

danielscrubs 2y ago

Had the same feeling. Because of that I moved on to no-build Preact. I’ve been happy with it so far, and I hope that it will get me closer to ”work for the customers, not for the vims of framework developers”.

benmccann 2y ago

Snippets are far more powerful than slots and so the change is not merely cosmetic. Snippets give you a way to create reusable HTML fragments within a component.

gedy 2y ago
Sure, that is nice - though TBH that kind of feels like a workaround for Svelte's one file, one component design. React doesn't have this issue and can define as many components wherever you like.
RadiozRadioz 2y ago
I was commenting specifically about on:change
- benmccann 2y ago
  I believe the reason for that was to enable event forwarding, which was a highly requested feature and makes a lot of things easier.

arichardsmith 2y ago

As someone who is in the midst of migrating from Svelte 4 to Svelte 5, I definitely feel the pain of syntax changes. However, I'd argue that `on:change` -> `onchange` isn't frivolous. A real world example: in Svelte 4, I had a custom input component that wrapped an <input> element. To be able to do `<MyInput on:change={callback} />` took a bunch of event forwarding boiler plate (or magic `on:change` syntax to forward that one event). When I wanted to also forward blur events I had to go through the same process. Now in Svelte 5 I can just use `const { foo, ...rest } = $props()` then spread with `<input {..rest}>` and I get all events forwarded for free. They could have kept the original `on:change` syntax, but that would have made property access more painful (who wants to call `rest['on:change']`?) and would have broken all my other components that I haven't migrated yet. The same goes for slots to snippets. Being able to pass snippets around like props has allowed me to simplify tons of components where slots were limiting. As a solo dev working part time on a Javascript project, I definitely hate some of the ecosystem churn, but this is one refactor I'm happy to do, and I'd say the same about most of the Svelte 5 changes.

nhumrich 2y ago
This is a really good perspective. I appreciate you sharing!