[lukevp]

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.

[quickthrower2]

But if it works this is one of those “chuck this in and see if you get a speedup” things, a bit like a platform upgrade for Java or .NET or moving to a new cloud SKU. Devs and managers love this kind of thing. No code just chuck it in and stuff goes faster (assuming that is how it works).

[paulddraper]

Yeah, memo() solves 98% of cases

[jitl]

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 percentile could be well worth it.

I’m not saying Million is that tool, just that such dismissal of the problem addressed rings a little hollow.

[paulddraper]

memo() does not require a team of experts.

[Existenceblinks]

I feel like this is all missing the points. The point is React is mid. Engineering metric is very strange these days. A guy has made your tool wicked fast, dismissed - fast enough .. wat?