around 2 yrs ago, i messed up benchmarks in the past with million v1. i'm sorry about putting out false information. once the reddit post came out i stopped working/advertising million entirely. i then spent 3 months redesigning the entire library. i tried my best to make it as fast as possible and accurate. benchmarks are real now, see here: https://krausest.github.io/js-framework-benchmark/current.ht...
Million was originally created as a Virtual DOM -- and still ships as a Virtual DOM. More recently, Million added an optional react compat library in order to make it easier for users to learn about Million.
I'm open to different ways to market Million if there is a specific tagline you have in mind
Ah, this is important new information for me! I just visited the website, and looked for a virtual DOM API that I can use inside of my library. Unfortunately, when I read the actual "getting started", it showed me how to import react libraries for hooks, and use JSX, and so I concluded that:
(a) This is actually a React replacement, like Preact, not just a virtual dom.
(b) The homepage marketing is misleading! The project lost a bit of integrity for me at that point, and I started trusting it less.
If the homepage marketing is declaring it to be a virtual dom, then I want to see how to use the virtual dom API so that I can verify what it is! If it then on top of that has a React Compatibility layer, that's just awesome and makes me really excited to understand it, and I'll probably want to look at that layer so that I can see what React is beyond a virtual dom.
Anyway, do you have a pointer to how to use it as a plain old virtual dom? I happen to be in the market for one, right now!
you're definitely the most qualified to do a js-framework-benchmark implementation. it's pretty odd that this hasnt been done given how much the marketing leans on performance claims.
"do your own benchmarks" is too handwavy a dismissal, imo. btw, my own framework is in this list, and has been for a long time, to keep me honest.
That's a fair point, seems like the current issue owner is inactive on the task, I'll go in myself and start work on a benchmark. Million started out as only a virtual dom (and therefore was never added to the js-framework-benchmark). Only recent was the React compat added, which is when we were comfortable to start working on benches.
My intention wasn't to dismiss your point at all btw. My intention was if there wasn't any 3rd party benchmark for a library (like js-framework-benchmark), you shouldn't take claims at face value unless you've done due diligence. It's great to hear that you're keeping yourself accountable, hopefully Million will also sometime soon :)
It is an old idea with reactive graph created at runtime and direct bindings (knockout.js, etc), but as always, implementation is way more important than some abstract idea, and ~6 years ago Adam showed that it is actually possible to implement this idea quite efficiently (S.js+Surplus). Then Ryan started working on Solid.js and it became one of the most popular implementation of this idea.
There are a lot of things that I don't like in Solid.js implementation, like it seems that he still don't care about performance in general and only focuses on getting high score in js-framework-benchmark (optimizing library for two cases: DOM template cloning and one/many-to-one reactive bindings). But I believe that it is not something that is inherently wrong with an idea and there are a lot of room for improvements in implementations.
I guess the main tradeoff with such idea is that it has a slightly higher learning curve than something like React with its top-down recompute/rerender approach (as long as we don't care about performance). But when we start to add reactive systems to react/svelte/etc to improve performance, at that point it becomes more complex than just using UI library specifically designed for reactive system.
Right now I am trying some experiments with new algorithms and datastructures for reactive system, that I specifically designed for UI problem space, to actually beat vdom implementations in microbenchmarks that were heavily biased towards vdom-like libraries (reimplementing top-down dataflow+diffing in reactive system with derived computations, it is super useful when building something like https://lexical.dev/ )
EDIT: Also, in such libraries it becomes quite hard to implement features like reparenting or DOM subtree recycling. But it seems that nobody cares about reparenting in web UI libraries (Flutter supports reparenting). DOM subtree recycling is quite useful in use cases with occlusion culling (virtual lists), but it should be optional with different strategies to reclaim memory (not how it is done in Imba library).
