Show HN: I made Million – It's a Virtual DOM made for the future
My name is Aiden Bai and I'm really interested in HCI research, particularly within user interface (UI) and web development. At the time of writing this, I'm a student at Camas High School.
In July 2021, Million.js began as an experiment with Virtual DOM because I was curious with how UI libraries worked. I was frustrated with the lack of a modern, fast, and modular Virtual DOM library for JavaScript. Virtual DOM had been around for almost a decade, yet many Virtual DOM libraries still struggle with render speed compared to newer methods of rendering.
Today, Million.js is the first effort to bring Virtual DOM into the future after hundreds of hours of experimenting. Traditional Virtual DOM libraries have yet to leverage new technological paradigms in the new age of compiled Transitional UI Libraries. Million.js leverages the compiler to create predefined paths, instead of executing all the work in the browser.
Hope this serves as an interesting example of how older technologies (relative to JavaScript time) can evolve to modern time (similar to how Solid took Knockout's fine-grained strategy and applied modern techniques)
10 comments
[ 6.4 ms ] story [ 35.0 ms ] threadThis is in contrast to the DOM, or the native rendering method for JavaScript, which requires developers to specify imperative steps to "construct" the user interface.
Virtual DOM is useful because it makes it much easier to create user interfaces, but comes at the cost of rendering performance. Million aims to make close the gap between DOM (native) and Virtual DOM performance through compilation, or optimizing certain "predefined routes" to native code, allowing for optimal rendering speed.
You can read more about virtual DOM here: https://millionjs.org/blog/virtual-dom
See, I had always thought that virtual DOM was one or two things: the building of the underlying structure as a separate list of nodes from what is displayed, and separately, a sort of buffered visual rendering on the (presumably more powerful) server that was used to determine exactly which elements needed to be rendered for the given view, then passing the associated DOM tree nodes to the browser for actual rendering. Kinda like double buffering and depth culling I guess?
Is there some thing that does this and I've just been getting ideas confused all this time?
This is how the Virtual Node tree is constructed. One case could be a React.createElement call that creates a virtual div node. You can visualize it by going to this page (Scroll down to the REPL section): https://millionjs.org/docs/api/basics/m
> a sort of buffered visual rendering on the (presumably more powerful) server that was used to determine exactly which elements needed to be rendered for the given view, then passing the associated DOM tree nodes to the browser for actual rendering
This is called hydration: https://en.wikipedia.org/wiki/Hydration_(web_development)
I’d really like to be able to declare my UI in a “draw” or “render” loop, like how I would do a UI with immediate mode rendering. This way I don’t need to deal with any subscription handlers, actions, etc. I just update the state object and the UI just renders. Would it be practical to use million.js in this fashion?