Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Million 3 – Optimizing compiler for React

million.dev

Post reply on HN
Print view View original

21–30 of 56 posts

Re: Show HN: Million 3 – Optimizing compiler for React

#21

Post by wredue »

chrisco255 wrote: post #5
spyke112 wrote: post #4

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.

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”.

Additionally, assuming this lives up to the claims, or even lives up to a quarter of the claims, then the optimization is, by definition, NOT premature. Premature optimization is the act of optimizing before you even know if something is slow, or before you measure.

I suppose you are probably working under the Functional Programming definition of “premature optimization” where they tell you to never measure (because it just makes FP look bad).

Re: Show HN: Million 3 – Optimizing compiler for React

#22

Post by aidenyb »

Hrun0 wrote: post #11

OP lied about benchmarks in the past: https://www.reddit.com/r/javascript/comments/x2iwim/askjs_mi...

hi, this is aiden

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...

Re: Show HN: Million 3 – Optimizing compiler for React

#23

Post by ricardobeat »

gothink wrote: post #17

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.

Ouch. It’s also downloaded twice (in Safari at least), putting the total page weight at almost 40MB.

Re: Show HN: Million 3 – Optimizing compiler for React

#24

Post by ricardobeat »

RyanHamilton wrote: post #16

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?

React is still doing reconciliation for your full element tree, even if you minimize updates. The approaches are not really comparable.

Re: Show HN: Million 3 – Optimizing compiler for React

#25

Post by c-smile »

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.

Re: Show HN: Million 3 – Optimizing compiler for React

#26

Post by cnasc »

gothink wrote: post #17

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.

https://idlewords.com/talks/website_obesity.htm

Re: Show HN: Million 3 – Optimizing compiler for React

#27

Post by brailsafe »

Hrun0 wrote: post #11

OP 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.

Re: Show HN: Million 3 – Optimizing compiler for React

#28

Post by acdha »

c-smile wrote: post #25

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 br…

> On most of UI changes nothing stops React to update only local portions of the tree - elements that have their state changed.

In practice, it still re-renders a lot. It’s easy to get a significant performance increase by not using React (usually at least one order of magnitude) - browsers have improved a lot and what looked like an optimization for IE6 is largely overhead now.

Re: Show HN: Million 3 – Optimizing compiler for React

#29

Post by c-smile »

acdha wrote: post #28
c-smile wrote: post #25

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 br…

> On most of UI changes nothing stops React to update only local portions of the tree - elements that have their state changed. In practice, it still re-renders a lot. It’s easy to get a significant performance increase by not using React (usually at least one order of magnitude) - browsers have improved a lot and what looked like an optimization for IE6 is largely overhead now.

> In practice, it still re-renders a lot.

Neither framework will fix programmer's errors.

This

   for(let child of container)
      child.innerHTML = getHtmlFor(i++);
will always be slower than this:

   for(let i = 0; i
N transactions versus 1 transaction.

I mean that compiling separate N "small" DOM access calls is not always faster than one integral update.

Re: Show HN: Million 3 – Optimizing compiler for React

#30

Post by zackify »

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.

Post reply on HN