Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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.


This is a really good perspective. I appreciate you sharing!


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.


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.


I was commenting specifically about on:change


I believe the reason for that was to enable event forwarding, which was a highly requested feature and makes a lot of things easier.


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: