41–50 of 56 posts
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.
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.…
OP lied about benchmarks in the past: https://www.reddit.com/r/javascript/comments/x2iwim/askjs_mi...
Lying is a deliberate action. The thread you link to seems rather to expose accidental bad benchmarking and poor communication/explanation of results, probably in good faith and due to inexperience.
Earlier quoted context omitted.
> 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.
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.…
Yeah, memo() solves 98% of cases
I’m not saying Million is that tool, just that such dismissal of the problem addressed rings a little hollow.
Earlier quoted context omitted.
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…
It’s weird how functional fans always tell you something, and then the moment you start calling them on it, they say “no you!”
According to functional programmers, all optimization is premature optimization, unless your program is “noticeably slow”. What is “noticeably slow” you might ask, and the answer is: nobody knows!
Being able to type faster than VSCode registers your keystrokes is not “noticeably slow”. This counts as “fast enough”.
Processing 10,000 lines of data in 5 minutes is fast enough. Just make it a task and toss it on a highly parallel cluster, then you won’t notice that this should take milliseconds, move on to the next thing.
While you’re contemplating what “noticeably slow” means, let’s also toss up some articles claiming Haskell is faster than C, but not providing any evidence for said claim, contrary to the countless measurements demonstrating the falseness of this claim.
>it’s not significant compared to
Is that really what our counter argument is? That by the time your ill-conceived images download on a clean browser cache, your garbage code may have finished generating the DOM? You regularly build apps that you expect people to use once and fill said apps with large images?
Earlier quoted context omitted.
Yeah, memo() solves 98% of cases
To me this kind of assessment can read like a C dev saying something like “snprintf solves 98% of buffer overflows” or something. Yes, every React application can be performant if coded carefully by a small team of experts, and every C program can be secure if coded by a small team of experts, but often applications are built by a large team of median engineers, so tooling to make median code automatically 90th perce…
OP lied about benchmarks in the past: https://www.reddit.com/r/javascript/comments/x2iwim/askjs_mi...
> OP lied Lying is a deliberate action. The thread you link to seems rather to expose accidental bad benchmarking and poor communication/explanation of results, probably in good faith and due to inexperience.
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…
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.
Can you expand on that? I've never hit perf issues with react but I've been curious how it commonly happens.