Yeah I actually wrote about this in a different article. https://medium.com/better-programming/the-real-cost-of-ui-components-6d2da4aba205
I was thinking the same thing. But I’m less familiar with bundlers for sure. Even bundlers like rollup individually transform modules before the bundling step. I didn’t see a straightforward way to achieve this. I tried to see if I could run babel later, but bundling step does the tree shaking so you want to have done the transformation before then. I basically realized I’d have to do everything from scratch more or less to achieve what I was going for. So yes Solid just uses babel transformation. To my knowledge no existing library uses tricks like this.
I know a lot of people like this sort of simple syntax. Vue popularized hiding reactivity in the same way. I firmly think it’s a trap. You always get to a point you need to break down the abstraction and it actually happens pretty quickly. The more you try to hide reactivity the more localized you become (although this could be solved somewhat by above but even code splitting becomes another hurdle). Hidden side effects of mutations is probably the most dangerous part. Maybe if we got to a point where processing wasn’t a concern and we had a language with no holes in the abstraction, but I don’t think we are particularly near there.
That being said probably not much of a discussion to be had with me on that point. On this I’m adamant. I actually talk about this in several of my articles.
As for pooling, are you talking about reactive pooling? I completely transform JSX into something that doesn’t resemble JSX. Basically what is turned out at the end is a static template of DOM nodes I clone, and a short code execution that adds bindings. Everytime the template is created it just clones and attaches reactive bindings. And from there it updates as needed. I see some advantage to pooling reactive computations to save creation costs but haven’t gone their yet. Most of my focus has been on initial creation since that is classically where reactive libraries are slow. We are fast on updates, and even smaller later creations are usually decent. Some people have played around with DOM node recycling but that is pretty dangerous since DOM nodes tend to carry state.
What I’ve been looking at is loosening the granularity and combining expressions with minimal diffs, even cross-component. This can improve creation cost greatly with a minimal update overhead as long as you do it smartly. I do this currently in Solid at a template level only breaking out inserts, so more expensive structural computations are handled separately. In Solid this granularity of updates means most things are lazily evaluated. So in the condition example it only generates the path that matches the condition. And only runs that code once until the condition changes and then renders the other side. All libraries including Svelte still do all the heavy lifting at runtime, we can just optimize the code path so we don’t need to ask what we are dealing with all the time. We know which attributes we need to update and which are static.. But it all boils down to the similar imperative code. Solid just does a particular good job creating those instructions and wrapping with computations to update.
