DEV Community

Discussion on: Components are Pure Overhead

Collapse
 
ryansolid profile image
Ryan Carniato • Edited

I think the compiler could do most of the heavy lifting. The biggest limitation for Svelte would be structurally the SFC files themselves. They separate stuff too much to fully leverage what I'm talking about, but maybe that's fine. Like if you wanted to add state in an iteration of the {# each } helper in Svelte that would require breaking off to a separate file.

Not that this level of adoption is essential but just to illustrate my point. In Solid's JSX you could literally just create state inside the loop helper iteration. We can create state inside ref callbacks too. Things like Svelte Actions use: bindings can be inlined or not, because it's all the same thing. In Solid's case it's because the reactivity is runtime.

If a compiler had access to all the code you imported and the syntax well understood the way it is in .svelte files you could do this as a compiled approach. This doesn't just mean removing the overhead between component communication. But things like Svelte Stores would not be necessary as you could literally just write the let and $: operator anywhere. Svelte components more or less topologically sort and wire execution to imitate a typical runtime reactive library what if that extended beyond files you use for components. There would be opportunities to revisit Svelte's SFC format, but the fundamentals would stay the same.

I think the common assumption is this isn't possible. But some of the recent work we've been doing on Marko suggests otherwise. Still exploring the implications of this and I will share more as we uncover it. But that's what makes this exciting.