7 ms·

Rax – A universal React-compatible render engine

119 points by zthomas 10y ago

deleted 10y ago
[deleted]
swrobel 10y ago
Interesting that they don't compare it to preact: https://github.com/developit/preact https://github.com/developit/preact
- t1amat 10y ago
  I thought the same. Their targets are Inferno and Preact.
- deleted 10y ago
  [deleted]
- rtpg 10y ago
  reading that, it seems pretty good. Are there performance costs to its diffing against the "real" DOM? 3kb for "React" is pretttttty tempting
  - Etheryte 10y ago
    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.
    - rtpg 10y ago
      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
    - Touche 10y ago
      40kb is 40% of your budget if targeting mobile.
    - simonw 10y ago
      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.
      - Kiro 10y ago
        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.
        rtpg 10y ago
        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.
    - developit 10y ago
      If you're loading libraries individually off a shared CDN, performance must not be much of a concern :P
    - nobleach 10y ago
      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.
  - bjacobel 10y ago
    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.
    - developit 10y ago
      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).
- garysieling 10y ago
  I switched from React to react-lite for https://www.findlectures.com https://www.findlectures.com and it has worked great (haven't compared to Preact yet)
baybal2 10y ago
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.
jiyinyiyong 10y ago
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 https://atf.alibaba.com/weex
wmertens 10y ago
their repo is full of slightly adapted other packages. If they are 100% React compat, why would they need rax-redux? :-S
- secoif 10y ago
  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/75658dab18f7fe3e62ea0c3d97fcf513bf176e10/src/connect https://github.com/reactjs/react-redux/tree/75658dab18f7fe3e... and includes "connectAdvanced": https://github.com/reactjs/react-redux/blob/75658dab18f7fe3e62ea0c3d97fcf513bf176e10/src/components/connectAdvanced.js 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/07e20908e4e17b182873db0997729cb6c03ab690/packages/rax-redux/src/components/connect.js 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.
  - shados 10y ago
    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.
  - acemarke 10y ago
    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.
greenspot 10y ago
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-ts/table.html http://stefankrause.net/js-frameworks-benchmark4/webdriver-t... - full post to the comparison table before: http://www.stefankrause.net/wp/?p=316 http://www.stefankrause.net/wp/?p=316
- leeoniya 10y ago
  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/webdriver-ts/table.html https://rawgit.com/krausest/js-framework-benchmark/master/we... [2] https://github.com/krausest/js-framework-benchmark/issues/104 https://github.com/krausest/js-framework-benchmark/issues/10...
  - greenspot 10y ago
    Thanks, I was just wondering why the OP didn't compare Rax to Inferno.
    - leeoniya 10y ago
      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/infernojs_10_release/ https://www.reddit.com/r/javascript/comments/5m2u0s/infernoj...
- 10y ago
janvidar 10y ago
Am I the only one finding it weird that they call it a render engine?
- kowdermeister 10y ago
  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.
- FlorianRappl 10y ago
  You are definitely not the only one.
deleted 10y ago
[deleted]
deleted 10y ago
[deleted]
andrewvijay 10y ago
Looks okay but what does it offer more than other react clones
deleted 10y ago
[deleted]
xuan 10y ago
Does it support stateless function component?
ceejay 10y ago
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?
kozak 10y ago
Good to see compatible implementations. Over time, we'll have something React-like as part of the web standards.
- sapeien 10y ago
  >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.
  - place1 10y ago
    Fair enough and very true! I suppose web-components are 'react like' in a way though so maybe it's already happening.
- aforty 10y ago
  It's the word "largely" in "largely React-compatible API" that scares me.

119 points by zthomas 10y ago

deleted 10y ago

[deleted]

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

t1amat 10y ago
I thought the same. Their targets are Inferno and Preact.
deleted 10y ago
[deleted]
rtpg 10y ago
reading that, it seems pretty good. Are there performance costs to its diffing against the "real" DOM? 3kb for "React" is pretttttty tempting
- Etheryte 10y ago
  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.
  - rtpg 10y ago
    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
  - Touche 10y ago
    40kb is 40% of your budget if targeting mobile.
  - simonw 10y ago
    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.
    - Kiro 10y ago
      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.
      - rtpg 10y ago
        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.
  - developit 10y ago
    If you're loading libraries individually off a shared CDN, performance must not be much of a concern :P
  - nobleach 10y ago
    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.
- bjacobel 10y ago
  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.
  - developit 10y ago
    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).
garysieling 10y ago
I switched from React to react-lite for https://www.findlectures.com https://www.findlectures.com and it has worked great (haven't compared to Preact yet)

baybal2 10y ago

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.

jiyinyiyong 10y ago

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 https://atf.alibaba.com/weex

wmertens 10y ago

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

secoif 10y ago
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/75658dab18f7fe3e62ea0c3d97fcf513bf176e10/src/connect https://github.com/reactjs/react-redux/tree/75658dab18f7fe3e... and includes "connectAdvanced": https://github.com/reactjs/react-redux/blob/75658dab18f7fe3e62ea0c3d97fcf513bf176e10/src/components/connectAdvanced.js 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/07e20908e4e17b182873db0997729cb6c03ab690/packages/rax-redux/src/components/connect.js 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.
- shados 10y ago
  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.
- acemarke 10y ago
  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.

greenspot 10y ago

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-ts/table.html http://stefankrause.net/js-frameworks-benchmark4/webdriver-t... - full post to the comparison table before: http://www.stefankrause.net/wp/?p=316 http://www.stefankrause.net/wp/?p=316

leeoniya 10y ago
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/webdriver-ts/table.html https://rawgit.com/krausest/js-framework-benchmark/master/we... [2] https://github.com/krausest/js-framework-benchmark/issues/104 https://github.com/krausest/js-framework-benchmark/issues/10...
- greenspot 10y ago
  Thanks, I was just wondering why the OP didn't compare Rax to Inferno.
  - leeoniya 10y ago
    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/infernojs_10_release/ https://www.reddit.com/r/javascript/comments/5m2u0s/infernoj...
10y ago

janvidar 10y ago

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

kowdermeister 10y ago
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.
FlorianRappl 10y ago
You are definitely not the only one.

deleted 10y ago

[deleted]

deleted 10y ago

[deleted]

andrewvijay 10y ago

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

deleted 10y ago

[deleted]

xuan 10y ago

Does it support stateless function component?

ceejay 10y ago

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?

kozak 10y ago

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

sapeien 10y ago
>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.
- place1 10y ago
  Fair enough and very true! I suppose web-components are 'react like' in a way though so maybe it's already happening.
aforty 10y ago
It's the word "largely" in "largely React-compatible API" that scares me.