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).
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.
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?
Ecosystem and ability to hire folks who are already competent. Sure it's not the most technically optimal framework but you can build great products with it.