by underwater on 12/12/16, 8:51 PM
I've spent a lot of time optimizing the startup time of large React codebases. In my experience the size of the React bundle is irrelevant; it will be quickly dwarfed by the product code for any meaningful application. The real problems in startup speed are twofold:
Browsers are stuck optimizing an outdated model - parsing and compiling JavaScript on the critical path is madness. The only benefit of that model is that a web developer can right click and view source to see some unreadable minified JavaScript code. The cost is that every web user has to wait hundreds or milliseconds or multiple seconds for the browser to do busy work. Even advancements like Service Workers don't do anything to mitigate this problem.
The second problem is that browser vendors are locked in a arms race chasing artificial metrics. This started years ago when the Chrome team introduced V8 with a huge PR push to sell the benefits of their JIT. It looks awesome to say that your browser tops SunSpider but those metrics don't necessarily correlate to how sites use JavaScript. Firefox has a heavily optimized JIT that kicks in when a function is run 1,000 times. When loading Facebook the hottest codepath is run 900 times.
by wje on 12/12/16, 7:26 PM
by slezakattack on 12/12/16, 8:26 PM
You'll have to excuse my ignorance as I just like to lightly follow the JS web dev community and am no way a JS expert, but what is the reasoning behind the React spin-offs? There's Inferno, Preact, ivi, and possibly more, but are all of these so different that they require their own repository? Is it out of the question to simply contribute to the other existing open source projects? I imagine there are some backwards compatible breaking changes but it feels a bit weird to have so many React-like spinoffs. Could anyone shed a light on this? I'm genuinely curious.
by mmanfrin on 12/12/16, 7:47 PM
I misunderstood the title and was very confused as to why Dan Brown would have things to say about Javascript perf.
by igl on 12/12/16, 10:40 PM
React's event system is one of its strong points. Like with many alternatives, I stopped looking into them when i read "no event system" in the README. Perf is not the single most high priority in a framework.
by s2d2 on 12/13/16, 4:40 AM
I love it. When it comes to PCs I am a speed junkie. Maybe because the first thing I started to learn as a kid was 3D graphics dev.
Anyway most websites are incredibly slow and clunky. With 20+ scripts and everything pops up or moves while loading.
On the speed of pure JS. I recently developed a JS game just for fun. Optimizing in a language with GC sucks.
by findjashua on 12/12/16, 9:29 PM
the big motivation for small size seems to be shaving the time spent on parsing the js. Is there any reason this can't be parceled off to a background worker, and using the main thread only for rendering?
by marknadal on 12/12/16, 8:59 PM
Pro tip: function calls (especially anonymous ones) are the biggest performance bottleneck. I've done pretty extensive research on this:
http://youtu.be/BEqH-oZ4UXI .