4 ms·

I loved svelte. But svelte5 seems to be a bit of turn off. It's not even the runes. Slots was hands down the best feature of svelte. And they deprecated it I s

I loved svelte. But svelte5 seems to be a bit of turn off. It's not even the runes. Slots was hands down the best feature of svelte. And they deprecated it I still can't for the life of me figure out how the new way is supposed to work. The migration docs are very limited. And it's super weird that the parent has to intentionally render children instead of a slots? Also, why deprecate the on:event syntax?

RadiozRadioz 2y ago
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!
gedy 2y ago
I'm in agreement, really loved Svelte 1, 2, and 3, but the v5 changes feel like a needle scratch unfortunately. I love Rich Harris' work and appreciate what he gives to the community, but man he loves to rethink things.
jerojero 2y ago
You have a child and a parent component. The snippet is declared on the parent and rendered on the child. So, you will have the snippet where you want it to be rendered on the child: ```child.svelte <script> let { myFirstSnippet, mySecondSnipper } = $props(); </script> <div id="Your first snippet goes here"> {@render myFirstSnippet()} </div> <div id="Your second snippet goes here"> {@render mySecondSnippet()} </div> ``` Here we are declaring that this child takes 2 snippets called `myFirstSnippet` and `mySecondSnippet` and we place them wherever they might go. And then on the parent we need to actually build those snippets: ```parent.svelte <script> import Child from ... </script> {#snippet myFirstSnippet()} <span>Hello from firstSnippet!</span> {/snippet} <Child {myFirstSnippet}> {#snippet mySecondSnippet()} <span>Hello from secondSnippet!</span> {/snippet} </Child> ``` Here we are taking that `Child` component and rendering the two snippets that will go into it, as you see, you can either pass the snippet as a named prop or you can declare it inside the child component with the same name as the prop the child gets. The end result of this will be a `Child` component that's rendered on the `Parent` with the two snippets inside this child component. I hope that clears things up.

RadiozRadioz 2y ago

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!

gedy 2y ago

I'm in agreement, really loved Svelte 1, 2, and 3, but the v5 changes feel like a needle scratch unfortunately. I love Rich Harris' work and appreciate what he gives to the community, but man he loves to rethink things.

jerojero 2y ago

You have a child and a parent component. The snippet is declared on the parent and rendered on the child. So, you will have the snippet where you want it to be rendered on the child: ```child.svelte <script> let { myFirstSnippet, mySecondSnipper } = $props(); </script> <div id="Your first snippet goes here"> {@render myFirstSnippet()} </div> <div id="Your second snippet goes here"> {@render mySecondSnippet()} </div> ``` Here we are declaring that this child takes 2 snippets called `myFirstSnippet` and `mySecondSnippet` and we place them wherever they might go. And then on the parent we need to actually build those snippets: ```parent.svelte <script> import Child from ... </script> {#snippet myFirstSnippet()} <span>Hello from firstSnippet!</span> {/snippet} <Child {myFirstSnippet}> {#snippet mySecondSnippet()} <span>Hello from secondSnippet!</span> {/snippet} </Child> ``` Here we are taking that `Child` component and rendering the two snippets that will go into it, as you see, you can either pass the snippet as a named prop or you can declare it inside the child component with the same name as the prop the child gets. The end result of this will be a `Child` component that's rendered on the `Parent` with the two snippets inside this child component. I hope that clears things up.