Rax – A universal React-compatible render engine | Hacker News Reader

Rax – A universal React-compatible render engine

github.com

119 pointszthomas36 comments

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.

Interesting that they don't compare it to preact: https://github.com/developit/preact

I thought the same. Their targets are Inferno and Preact.

reading that, it seems pretty good. Are there performance costs to its diffing against the "real" DOM?

3kb for "React" is pretttttty tempting

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.

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

40kb is 40% of your budget if targeting mobile.

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.

Yeah for games it's not much of an issue.

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.

If you're loading libraries individually off a shared CDN, performance must not be much of a concern :P

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.

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).

I switched from React to react-lite for https://www.findlectures.com and it has worked great (haven't compared to Preact yet)

Is it faster than Inferno[1]?

[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

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.

[1] https://rawgit.com/krausest/js-framework-benchmark/master/we...

[2] https://github.com/krausest/js-framework-benchmark/issues/10...

Thanks, I was just wondering why the OP didn't compare Rax to Inferno.

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.

If you wanna read a lot more of our convo, head over to: https://www.reddit.com/r/javascript/comments/5m2u0s/infernoj...

Those microbenchmarks are meaningless. If you choose a framework because of their microbenchmark grades you are making a huge mistake.

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.

Am I the only one finding it weird that they call it a render engine?

No, and it's really confusing what it really does. The one example is a hello world text. I didn't bother downloading the rest.

You are definitely not the only one.

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

their repo is full of slightly adapted other packages. If they are 100% React compat, why would they need rax-redux? :-S

On the surface, the rax-redux implementation appears to be a lot simpler. For example, react-redux's connect spans all these files https://github.com/reactjs/react-redux/tree/75658dab18f7fe3e... and includes "connectAdvanced": https://github.com/reactjs/react-redux/blob/75658dab18f7fe3e...

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.

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.

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.

Good to see compatible implementations. Over time, we'll have something React-like as part of the web standards.

>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.

Fair enough and very true! I suppose web-components are 'react like' in a way though so maybe it's already happening.

It's the word "largely" in "largely React-compatible API" that scares me.

Looks okay but what does it offer more than other react clones

Does it support stateless function component?

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?

Reply on news.ycombinator.com