Funny story behind the line of Chinese React clones: the original goal of development was to make react work with ie6-9 (pirated winxp still is the "Default OS" here), but it came out that most of Chinese React forks are even less ie friendly than the original.
Preact doesn't offer a full synthetic events system so handling e.g. touch events cross-browser may cause you a little more headache than it would in React.
But I'm currently using Preact (server-rendered) for my personal site and loving the speed and byte size.
FWIW, there is actually no code in React to normalize touch events between browsers. For touch events react and preact are basically the same (aside from React creating a lot of pooled objects for their synthetic event system, and preact not using delegation).
Forget about file size, 40kb vs 8kb doesn't really matter in the modern era. If anything, using an obscure library may cost you more because it's less likely to be a CDN cache hit for the user.
Start testing on a mid range Android device on 3G and tell me you still believe that.
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.
I build games where the player is supposed to play for hours. Am I wrong thinking that file size matters less for me? It adds 1% to the loading screen.
we package our JS into one bundle, so just one CDN to hit (ours).
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
You mean, in America... in a metropolitan area.... with a nice newer device... with an unlimited data plan. A 40kb vs 8kb savings can mean quite a bit to those in other conditions.
Inferno is definitely fast, but these benchmarks are highly misleading.
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.
Inferno is gonna be really tough to beat, at least for non-keyed implementations. We don't have a keyed implementation from them, so it's hard to say exactly how they do there, but i dont doubt that it'll be at or near the top. For now kivi is likely the fastest possible but the way you have to write your code with kivi is rather unpleasent. However, the whole point of kivi was to push the perf boundaries, not to be useable directly.
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.
Yup, though the Rax benchmarks are especially bad. Calling a function with unchanging arguments in a loop with a constant number of iterations is going to trigger about the least real-world performance characteristics you could ask for, haha. I'm happy to see more people getting into the VDOM space, but it sucks to have to explain all the pitfalls every time a new broken benchmark comes out.
Well, I see it only a smaller project created by people in the Weex community who prefer React syntax. They did not even talk much about it on Weex Conf. https://atf.alibaba.com/weex
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.
Looks like the Rax version is based on React-Redux 4.x, which was was primarily a single file and kept most of the logic in a React component. React-Redux v5 is a complete internal rewrite that pushes the logic out into memoized selector functions.
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.
react-redux is definitely super bloated right now. It's packed full with method overloads (that are super confusing if you read their definitions in the doc as opposed to looking at examples), and performance optimizations that involve looking at the function arguments, memorization, etc.
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.
>something React-like as part of the web standards.
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.
Noticed they added Facebook to the LICENSE. Facebook was notorious at one point for some unpopular language in their open source licenses. Does their inclusion in the LICENSE file mean a developer needs to be aware of how Facebook is currently (or in future) licensing React, as well as how Rax is licensed?
