by lukevp on 2/2/24, 11:52 PM
I met Aiden (the < 20 yo who started Million) a year or so ago. He presented about Million in front of a room full of 40+ grizzled JS devs. I don't personally see any reason to use Million JS, React is fast enough as it is if you memoize and use selectors correctly. Aiden said some similar things at the time (a solution in search of a problem, that got unexpectedly popular) but I gotta say, he's a hype man for sure. I wish him luck, I think if he made a more compelling library, it would be a rocket ship with his marketing. I do think he should take some hints from the other post regarding the deceptive benchmarks and make sure he can back up his marketing materials, but 14k stars on GitHub for something that (to me) seems pretty useless is truly bananas skill.
by zackify on 2/3/24, 2:56 AM
Or people could structure their react components efficiently and be fine as is.
I’m sure I’ll get a lot of downvotes for that.
But after 10 years of using react. Most performance issues were really just poor state management in the wrong locations and not the virtual dom holding it back.
by agluszak on 2/3/24, 5:31 AM
> Instead of traversing every node, Million uses a compiler to directly update dynamic nodes, resulting in O(1) time complexity.
This sounds very hand-wavy. What does it mean to "use a compiler to directly update dynamic nodes"?
by Hrun0 on 2/2/24, 10:26 PM
by 698969 on 2/3/24, 3:25 AM
Million's optimizations are only relevant if you're rendering a large number of identical stateless components (exactly like JS Framework Benchmark).
Real world applications are mostly deep trees of stateful components.
by c-smile on 2/3/24, 1:50 AM
How does M3 stand with SvelteJS?
Seems like these are two conceptually similar things.
> React traverses the virtual DOM tree to update the UI, resulting in O(n) time complexity.
That's the worst case, on initial load. On most of UI changes nothing stops React to update only local portions of the tree - elements that have their state changed.
Educated guess: In Million and React.JS cases major bottleneck is inside browser re-layout mechanism, not on JS side I think.
by RyanHamilton on 2/2/24, 11:21 PM
I've built a real time updating app using react and I'm struggling to see the benefit here. For the very core parts I'm already avoiding the react overhead by using useref to maintain the same object. This reduces "hydration " and traversing to nil cost with no new concepts to learn. Why would I use million?
by frfl on 2/2/24, 10:17 PM
I haven't used React in a while and never used SolidJS, but would SolidJS not basically be a optimizing compiler as well for "React". Technically SolidJS is a separate framework and I don't know if it's a 100% drop in replacement like this make be.
Edit: My comment is probably not accurate. Please ignore what I said.
by photon_collider on 2/2/24, 8:32 PM
This looks really cool! It's interesting that this compiler provides performance optimizations by looking for data diffs rather than diffs in the Virtual DOM. Is this intended to be an alternative to React Forget (still in development)?
by ggregoire on 2/2/24, 9:38 PM
Never heard of this, sounds super cool! Gratz on the milestone!
Theoretically, could this be merged in the main React project or would this break something?
by agluszak on 2/3/24, 5:34 AM
by voat on 2/3/24, 6:33 AM
Ignore the haters. Million is a great project, and def provides a great solution to speeding up react.
by tibbydudeza on 2/2/24, 8:30 PM
Interesting - tried it but it did not like me using decorators.
by quickthrower2 on 2/5/24, 10:06 AM
Anyone knows how this compares with Svelte’s approach?
by gothink on 2/2/24, 11:31 PM
I'm not a React dev, so I can't comment on the project itself. Something I noticed on the blog post, though:
The image at the top of the page is served uncompressed at a whopping 18.5MB (9751px * 6132px)! Seems a bit extreme for what amounts to a simple logo and some text.
by spyke112 on 2/2/24, 9:11 PM
Kudos to the team, but why on earth should i choose React when we’ve now reached a point where it needs an optimization compiler, seems silly to be honest.