Should React opt for compile time instead of Virtual DOM?

#react #svelte #javascript #discuss

I am front-end developer who loves working with React. I am really impressed with Svelte's approach for reactivity and I just wanted community's input on my thoughts.

React drastically changed the way we develop frontend apps, but Svelte definitely redefined reactivity with it's approach to compile time optimizations vs Virtual DOM.

Why

Everyone talks about switching from one framework to another but if React could ditch Virtual DOM, and start adopting compile time optimizations, that would be best of both worlds.

React is already very much mature, has lots of tooling available and lots of community support. Developers will be able to continue using the existing tools with much more improved React.

How

I am just putting my thoughts here. There are lots frameworks which are using React internally like Next JS, Gatsby etc. All the frameworks and tools will definitely be affected as well if React changes it's underlaying architecture.

But may be React can do an opt-in phase like how it did during React 16. This will allow a slow transition into a new React.

What are your thoughts?

Let me know what you guys think about this. Is it possible? or is it unnecessary?

Top comments (5)

Ryan Carniato • Oct 20 '20

Author of Solid here. There are challenges of attempting to take the React model and making it precompiled.

RE:DOM removes the VDOM abstraction but also removes a large part of the abstraction in general. Updates are helper wrappers on DOM operations. You are no longer dealing with state change propagation. The render resembles a VDOM abstraction but the updates are granular. Closer projects to this goal that started with some excitement then fizzled out are: github.com/sokra/rawact and github.com/mohebifar/vidact. React also tried their own experiments with Prepact. Which showed some promise but ultimately was shelfed.

So the challenge is preserving the render model. React's whole update model is based on the fact it renders top-down and repeatedly. You can't be creating actual DOM nodes this way it would be so unperformant. The solution that people have been working on is separating the create path from the update path using a compiler.

This is similar to Svelte. But there are some challenges here because now your core component renders once, and you need to split the update behavior out accordingly. See Svelte or a reactive system already has semantics for this like $:. You might think ok I can use Hooks. However the code outside of the hooks in the component body always re-runs. Mimicking React's closure behavior actually becomes a bit of a challenge. React hooks are sort of the inverse of Reactive primitives. They don't update unless told and the world around them updates. In reactive system only the "hooks" update.

Now I don't think this is impossible but just takes a lot of work and you end up sort of modelling a more complicated system anyway. In Solid I solved this by throwing React's update semantics out the window, but it's also why I don't have React compat. Ironically I actually didn't intend to be so close to React. I was already working fine with Solid but when React introduced the Tuples in the Hook APIs I jumped on them since they solved a long time trouble I had.

It goes to show that it doesn't take very much API change to adopt a more granular update model (the key to removing the VDOM). But it does mean that React itself cannot go down that particular path and is stuck coming up with a different solution if this is the way they want to go.

Sandeep • Oct 22 '20

Wow! Thanks for such an amazing response :)
I am still trying to figure out lots of details you shared here, but could understand that it's a whole underlaying modal change for them which is not very straightforward.

Thanks a lot for sharing your thoughts, and thanks for creating Solid 🙌