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.
Show HN: Million 3 – Optimizing compiler for React
31–40 of 56 posts
Re: Show HN: Million 3 – Optimizing compiler for React
#32> 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"?
Re: Show HN: Million 3 – Optimizing compiler for React
#33OP lied about benchmarks in the past: https://www.reddit.com/r/javascript/comments/x2iwim/askjs_mi...
People make mistakes, and should hopefully learn from them, but it's not right to comment with nothing but dug up dirt, especially with such a negative accusation of malice, while they try and move on.
The GP said the OP misrepresented their benchmarks before. It's good context and the rest of the Reddit thread is also informative.
"Lie" is a bit edgey but I think adults should be able to stomach a little sourness instead of, ironically, accusing people of dirt and malice.
Re: Show HN: Million 3 – Optimizing compiler for React
#34Aiden seems to have hopped on the AI hype train, too.
Re: Show HN: Million 3 – Optimizing compiler for React
#35I'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.
And the file has a very, very faint gradient background with heavy dithering, so lossless compression won't actually help that much (ECT was only able to shave 13% of the file after minutes). In fact it is one of the worst imaginable cases for raster image formats.
Re: Show HN: Million 3 – Optimizing compiler for React
#36Earlier quoted context omitted.
It doesn't need one, probably less than 1% of React apps make use of this tool. Its an optimization that would be premature for most apps unless they've got large amounts of dynamic onscreen components.
It has absolutely needed significant performance improvements for years. Vanilla JS is somewhere in the ballpark of 30x (x not percent) faster than react. If that’s not calling for significant performance optimization necessity, I don’t know what is. Nobody has ever complained about their app feeling better to use because it performs better. Users do not sit there like “man, I really wish the web was SLOWER”. Additio…
The one order of magnitude difference is on some todo app benchmark with mass-updates and the like, it is not really representative of most real world applications, and you might as well just do an escape hatch in plain js for certain parts of your site if you expect/measure significant slowdown from react itself.
It is absolutely not significant compared to site load, images, initial DOM layouting, etc. Plus your FP paragraph is straight up uninformed flame-bait.
Re: Show HN: Million 3 – Optimizing compiler for React
#37Ignore the haters. Million is a great project, and def provides a great solution to speeding up react.
Re: Show HN: Million 3 – Optimizing compiler for React
#38Earlier quoted context omitted.
It doesn't need one, probably less than 1% of React apps make use of this tool. Its an optimization that would be premature for most apps unless they've got large amounts of dynamic onscreen components.
It has absolutely needed significant performance improvements for years. Vanilla JS is somewhere in the ballpark of 30x (x not percent) faster than react. If that’s not calling for significant performance optimization necessity, I don’t know what is. Nobody has ever complained about their app feeling better to use because it performs better. Users do not sit there like “man, I really wish the web was SLOWER”. Additio…
> in the ballpark of 30x (x not percent) faster than react
In real world apps or theoretical benchmarks?
Re: Show HN: Million 3 – Optimizing compiler for React
#39> 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"?
It means you compile-in a direct reference to the node that needs to be updated when some property changes, so instead of searching the tree of n nodes to find it, you already have the reference.
Re: Show HN: Million 3 – Optimizing compiler for React
#40I'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.
18 MB may be odd, but most pages now have multiple images making each page 10s of MB. That makes all discussions about some framework few hundred kb smaller funny.