You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After upgrading to Svelte 5, I’ve had this lingering thought about the implementation of Snippets that feels a bit odd.
Snippets are powerful, and I understand they are the successor to Slots. I didn’t have this feeling during the Slot era because Slots were relatively simple in functionality—too limited to make me overthink things (once again, kudos to the team for their amazing work).
Back to the main point: when using Snippets, their flexibility often makes me wonder—isn’t this just an anonymous Component?
Take the following code as an example:
{@renderview({ name: "hello" })}
Why not replace it with this form:
<viewname="hello"/>
From my perspective, a Snippet that accepts an object as its argument is structurally consistent with a regular Component. It feels similar to the difference between arrow functions and regular functions in JavaScript—I believe the two could share the same design. This way, Snippets would gain Component-like features such as richer parameter passing, better control over reactivity, type safety, and more.
We could also introduce a new syntax for Snippets to make them visually identical to Components:
This would then be compiled into an anonymous Component and bundled with the parent Component.
I think this approach could significantly reduce the number of Component files—for example, scrollbar-root.svelte, scrollbar-handler.svelte, scrollbar-tracker.svelte, etc., could all be consolidated into a single .svelte file!
They could even detect closures to automatically generate certain reactive bindings, reducing boilerplate code when developing "large components" (cases where multiple components are used together) for passing contextual information.
Additionally, if the above proposal could be implemented, I believe the following idea would naturally follow:
Namely, allowing Snippets to be embedded directly into JavaScript.
Consider the role of JavaScript’s let/const keywords and {@const ...} in our framework—where let/const are the prototypes, and {@const ...} serves as a supplement to achieve similar functionality in HTML.
Ultimately, I think Snippets will follow the same path—where $snippet(...) in JavaScript becomes the primary form, and {#snippet} in HTML acts as a supplement.
If this could be realized, we would achieve first-class language-level Component facilities within the Svelte framework. This would completely overturn previous debates about defining multiple script blocks in a single file and eliminate React’s biggest advantage over Svelte—the syntactic consistency and closure-like behavior enabled by JSX.
Of course, my understanding of Svelte may not be deep enough, and my arguments might not hold water. But in any case, this is my personal perspective—one that might guide Svelte toward a more elegant and powerful future.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
After upgrading to Svelte 5, I’ve had this lingering thought about the implementation of Snippets that feels a bit odd.
Snippets are powerful, and I understand they are the successor to Slots. I didn’t have this feeling during the Slot era because Slots were relatively simple in functionality—too limited to make me overthink things (once again, kudos to the team for their amazing work).
Back to the main point: when using Snippets, their flexibility often makes me wonder—isn’t this just an anonymous Component?
Take the following code as an example:
Why not replace it with this form:
From my perspective, a Snippet that accepts an object as its argument is structurally consistent with a regular Component. It feels similar to the difference between arrow functions and regular functions in JavaScript—I believe the two could share the same design. This way, Snippets would gain Component-like features such as richer parameter passing, better control over reactivity, type safety, and more.
We could also introduce a new syntax for Snippets to make them visually identical to Components:
This would then be compiled into an anonymous Component and bundled with the parent Component.
I think this approach could significantly reduce the number of Component files—for example,
scrollbar-root.svelte
,scrollbar-handler.svelte
,scrollbar-tracker.svelte
, etc., could all be consolidated into a single.svelte
file!They could even detect closures to automatically generate certain reactive bindings, reducing boilerplate code when developing "large components" (cases where multiple components are used together) for passing contextual information.
Additionally, if the above proposal could be implemented, I believe the following idea would naturally follow:
Namely, allowing Snippets to be embedded directly into JavaScript.
Consider the role of JavaScript’s
let/const
keywords and{@const ...}
in our framework—wherelet/const
are the prototypes, and{@const ...}
serves as a supplement to achieve similar functionality in HTML.Ultimately, I think Snippets will follow the same path—where
$snippet(...)
in JavaScript becomes the primary form, and{#snippet}
in HTML acts as a supplement.If this could be realized, we would achieve first-class language-level Component facilities within the Svelte framework. This would completely overturn previous debates about defining multiple script blocks in a single file and eliminate React’s biggest advantage over Svelte—the syntactic consistency and closure-like behavior enabled by JSX.
Of course, my understanding of Svelte may not be deep enough, and my arguments might not hold water. But in any case, this is my personal perspective—one that might guide Svelte toward a more elegant and powerful future.
Beta Was this translation helpful? Give feedback.
All reactions