Rax – A universal React-compatible render engine(github.com) |
Rax – A universal React-compatible render engine(github.com) |
3kb for "React" is pretttttty tempting
But I'm currently using Preact (server-rendered) for my personal site and loving the speed and byte size.
[1] Inferno seems to be the fastest React drop-in replacement at 9kb size at the moment: http://stefankrause.net/js-frameworks-benchmark4/webdriver-t... - full post to the comparison table before: http://www.stefankrause.net/wp/?p=316
We're working on improving them so they better reflect the difference in keyed vs non-keyed implementations [1][2]. When ready, Round 5 should be a much more realistic apples-to-apples comparison.
[1] https://rawgit.com/krausest/js-framework-benchmark/master/we...
[2] https://github.com/krausest/js-framework-benchmark/issues/10...
While the rax-redux equivalent seems to be contained in a single file:
https://github.com/alibaba/rax/blob/07e20908e4e17b182873db09...
The simpler implementation might indicate that the rax developers are trimming overcomplicated bloat, or culling features that don't align with specific needs of Alibaba. Or maybe they're just removing code they don't yet understand the necessity for. It's not immediately clear what tradeoffs each are making, but having rax audit what's really necessary could be a good thing for everyone.
In fact, it appears to be 98%-ish the same as React-Redux v4.4.6. They've added semicolons, swapped out the React imports for Rax imports, and shuffled the order of some of the methods, but the code is effectively identical.
It's cool and needed to cover all of the cases and edge cases, but it's easy to see how, if you don't need that stuff, it can be reimplemented in a fraction of the code.
Hell no. High-level APIs should remain in user space, they are too often optimized for short term thinking, prone to breakage, and inefficient.
Most of the current DOM specification has been around since 1998-2000, and the spec hasn't made a single breaking change. Standards committees have an obligation to not break the foundations of the web, framework authors can do whatever.
At the end of the day, there are numerous <= 15KB libs that come within 3%-15% of Inferno, so the perf and size difference is really becoming secondary to lib ergonomics and features.
If you wanna read a lot more of our convo, head over to: https://www.reddit.com/r/javascript/comments/5m2u0s/infernoj...
On mobile it's not just the file transfer that takes time: it's the JavaScript parsing and execution (on a single core) that hurts too. iPhones are massively faster than Android (especially cheaper Androids) at this, so many developers don't realize how much performance cost there is for a growing majority of their users.
Given how many different versions there are of popular libraries I'm personally skeptical that CDNs give you much of a chance if the asset being preloaded from another site. I'd love to see real numbers on this though.
It becomes more of an issue if you are doing a "business" app, where there's a lot of moving between pages and a lot of eventual page refreshes.
Another thing is that even if you're at 40kb gzipped, that's still at least 20ms for parsing JS. When you're trying to improve performance, chopping out 30kb is nice