Virtual DOM architecture's bottleneck is the diffing, hence why Million attempts to solve this with "compiler-augmented" API.
This is where I don't follow.
From what I can figure, anything that uses virtual DOM and performs diffing has to do, in principle, the same amount of essential work. I don't see how having an API with a different shape, internally, is going to make any difference in terms of performance?
Many of the existing libraries are almost definitely already near their theoretical performance limits - many of the "fast" virtual DOM libraries are competing for very narrow marginals.
If you have motivations besides performance for building this library, maybe it's time to drum up some of those? 🙂
Either way, if we're going to need a compiler, my (annoying, sorry) question is always this: if we're going to compile anyway, why not compile to something with better performance limits? We're already close to those limits with virtual DOM diffing - and there are plenty of libraries that can do this without a compile step. There's even a few that can do precise updates without a compiler. What is the complexity and overhead of a compiler going to buy us?
Yeah, I completely agree on the runtime performance peaking -- but the limit can be broken with precompilation. For instance, runtime operations can be optimized via Million deltas, which are essentially ways to tell million to run imperative runtime operations instead of diffing, or compiler flags, which give million clues on a vnode and vnode's children so it can significantly reduce diffing, not to mention tangential optimizations like better static hoisting and smart key assignment that can be created in the compiler.
Million.js has a really composable API, which is also another selling point. If there is one thing that other Virtual DOM libraries should allow the developer to compose logic together, including nested compositions.
Idealistically, compiling to imperative operations and having some sort of fine grained architecture over it may be a better, more performant implementation. I avoid to claim whichever architecture is better in a certain aspect because I personally don't know which is better. However, the React + Virtual DOM friends are trending towards this new ecosystem with build steps (React w/ Next.js), and the fact that these Virtual DOM-based libraries aren't leveraging this built step to further optimize (further than prerendering and trivial optimizations) the runtime Virtual DOM is a gap for further optimizations like Million.js + compiler.
I see, so you have these flags that lets a compiler essentially disable tree traversals or skip other parts of the usual virtual DOM diffing process.
That's interesting. If I had to describe this, it would be something along the lines of "virtual DOM with opt-outs". This could definitely improve things over the brute force unconditional tree updates performed by traditional virtual DOM diffing.
I don't expect this will put you quite in the same category as libraries that do precise updates, but maybe close? You still have to diff the props - I wonder if there could be some way to distinguish "permanent" from "dynamic" props? Generally, dynamic props have a function associated with them anyhow, whereas permanent props can be just an expression.
I don't know if it's really still virtual DOM? In some sense it is, but as someone else pointed out, it's perhaps a closer relative to something like Glimmer.
Just an observation, but something like Sinuous or Solid also does diffing - but it's opt-in, whereas your library makes unnecessary work opt-out. Generally, opt-outs require more if-statements, whereas unconditionally requesting the operation you want is generally simpler at that level. But I am curious to see how this pans out - you're controlling some of the complexity at a different layer of abstraction, so maybe that pays off in terms of simplicity in a compiler's output. This will be interesting to see for sure 🙂
Million.js doesn't intend to be for precise update libraries, it just attempts to optimize parts of the virtual DOM that can be optimized. Props diffing is up to the library developer, Virtual DOM by default is "just pass the props down and we'll figure out the UI" (like React), vs precise update libraries which is "we'll diff the props then construct the UI."
It still fundamentally is a virtual DOM, you can use it like a Virtual DOM, in fact, you can use it without a compiler. However, it can be "augmented" by a compiler to achieve better performance. I'm not sure about glimmer but I'll do a bit of research into that.
I think Sinuous and Solid are more on the precise update libraries (I don't know specifically, just glazing over the readmes). Virtual DOM and precise update libraries are two different architectures, and diffing is done at a different level. The opt-outs can be conditionally calculated at compile-time, meaning that conditional statements would be unnecessary (just inserting flags into the runtime function).
Thanks for the encouragement, I'll do more research and see how I can improve Million further
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is where I don't follow.
From what I can figure, anything that uses virtual DOM and performs diffing has to do, in principle, the same amount of essential work. I don't see how having an API with a different shape, internally, is going to make any difference in terms of performance?
Many of the existing libraries are almost definitely already near their theoretical performance limits - many of the "fast" virtual DOM libraries are competing for very narrow marginals.
If you have motivations besides performance for building this library, maybe it's time to drum up some of those? 🙂
Either way, if we're going to need a compiler, my (annoying, sorry) question is always this: if we're going to compile anyway, why not compile to something with better performance limits? We're already close to those limits with virtual DOM diffing - and there are plenty of libraries that can do this without a compile step. There's even a few that can do precise updates without a compiler. What is the complexity and overhead of a compiler going to buy us?
Yeah, I completely agree on the runtime performance peaking -- but the limit can be broken with precompilation. For instance, runtime operations can be optimized via Million deltas, which are essentially ways to tell million to run imperative runtime operations instead of diffing, or compiler flags, which give million clues on a vnode and vnode's children so it can significantly reduce diffing, not to mention tangential optimizations like better static hoisting and smart key assignment that can be created in the compiler.
Million.js has a really composable API, which is also another selling point. If there is one thing that other Virtual DOM libraries should allow the developer to compose logic together, including nested compositions.
Idealistically, compiling to imperative operations and having some sort of fine grained architecture over it may be a better, more performant implementation. I avoid to claim whichever architecture is better in a certain aspect because I personally don't know which is better. However, the React + Virtual DOM friends are trending towards this new ecosystem with build steps (React w/ Next.js), and the fact that these Virtual DOM-based libraries aren't leveraging this built step to further optimize (further than prerendering and trivial optimizations) the runtime Virtual DOM is a gap for further optimizations like Million.js + compiler.
I see, so you have these flags that lets a compiler essentially disable tree traversals or skip other parts of the usual virtual DOM diffing process.
That's interesting. If I had to describe this, it would be something along the lines of "virtual DOM with opt-outs". This could definitely improve things over the brute force unconditional tree updates performed by traditional virtual DOM diffing.
I don't expect this will put you quite in the same category as libraries that do precise updates, but maybe close? You still have to diff the props - I wonder if there could be some way to distinguish "permanent" from "dynamic" props? Generally, dynamic props have a function associated with them anyhow, whereas permanent props can be just an expression.
I don't know if it's really still virtual DOM? In some sense it is, but as someone else pointed out, it's perhaps a closer relative to something like Glimmer.
Just an observation, but something like Sinuous or Solid also does diffing - but it's opt-in, whereas your library makes unnecessary work opt-out. Generally, opt-outs require more if-statements, whereas unconditionally requesting the operation you want is generally simpler at that level. But I am curious to see how this pans out - you're controlling some of the complexity at a different layer of abstraction, so maybe that pays off in terms of simplicity in a compiler's output. This will be interesting to see for sure 🙂
I agree with your description.
Million.js doesn't intend to be for precise update libraries, it just attempts to optimize parts of the virtual DOM that can be optimized. Props diffing is up to the library developer, Virtual DOM by default is "just pass the props down and we'll figure out the UI" (like React), vs precise update libraries which is "we'll diff the props then construct the UI."
It still fundamentally is a virtual DOM, you can use it like a Virtual DOM, in fact, you can use it without a compiler. However, it can be "augmented" by a compiler to achieve better performance. I'm not sure about glimmer but I'll do a bit of research into that.
I think Sinuous and Solid are more on the precise update libraries (I don't know specifically, just glazing over the readmes). Virtual DOM and precise update libraries are two different architectures, and diffing is done at a different level. The opt-outs can be conditionally calculated at compile-time, meaning that conditional statements would be unnecessary (just inserting flags into the runtime function).
Thanks for the encouragement, I'll do more research and see how I can improve Million further