React compiling down to raw application code

[scottmas]

Ahead of Time compiling is becoming a thing in the ever evolving Javascript world. At the end of the day, web frameworks simply have to change (virtual) DOM nodes at the appropriate time. Framework specific logic, like change detection, re-rendering and diffing, etc, are simply ways of letting developers be able to reason about when they expect a change to occur in the DOM.

If a compile step can intimately understand all the code paths a certain application can take, web applications don't have to incur the overhead of implementing the entire framework logic.

Angular is doing it in a limited way and a recent library svelte is requiring AOT compilation.

I'm not sure if this is the right location for this discussion, but I think this is something that the React community seriously needs to begin considering.

[blainekasten]

This has been on my mind here and there. I think there are 2 sides to this coin.

1. The code you write is not the code you debug.
2. The weight of the code is dramatically increased by the need for framework and ceremony.

Frameworks like svelte seem promising, though it is early to know if the appeal is worth it. I personally have concerns about the code being hard to debug. But I think this is a very interesting concept and have tried to think about if it's possible to extract out enough logic into simple and concise code that the framework is unnecessary beyond development conveniences.

[styfle]

@blainekasten What makes you say this?

The code you write is not the code you debug

Today, I debug ES6 code that has been compiled and running as ES5 code in the browser. Just include the source maps. Is there a reason you think source maps would not work for AOT compiling?

[scottmas]

I'm also skeptical source maps will work in the AoT world, except in a very rudimentary form.

Source mapping was invented to solve a problem that is equivalent to translating Australian English (ES6) to American English (ES5). You'll need to change a couple idoms here and there (i.e. change var declarations), but it's pretty straightforward.

However, translating English (React) to Chinese (AoT compiled code) becomes orders of magnitude more complex. The "meaning" remains the same, but nearly all the implementation details are different.

This said, I think this is an acceptable tradeoff if the benefits are significant enough. Particularly since developers will still be able to perform development in React proper, not the AoT version.

It's unclear at this point how large the potential benefits could be, but for example Svelte was able to decrease code size about 12x for TodoMVC (4kb vs 45kb), be about 1.3x faster, and be probably significantly faster on initial boot time since there's far less code to parse. But it's unclear if these benefits scale to complex real world applications.

[scottmas]

@gaearon @sebmarkbage @acdlite @trueadm @developit and other people working on the future of React (e.g. React Fiber) have opinions?

[gaearon]

We might explore a limited version of this in the future. I don't think we'll ever go "full AOT" like Svelte because some things are inherently dynamic (e.g. diffing lists), and inlining that logic into components while preserving full React power would produce bloated bundles.

I'm not very familiar with Angular so can't comment on that comparison but just wanted to note React doesn't have a "template compilation" step in the first place.

[gaearon]

You might be interested in these issues: https://github.com/facebook/react/labels/Component%3A%20Optimizing%20Compiler

[acdlite]

Yeah, I think the tl;dr version is that we will likely compile to code that modifies React internal data structures (fibers), but not the DOM directly. Will always need a runtime.

[scottmas]

Interesting. So just so I can clarify this in my mind... Right now there are three major code pieces that need to be loaded to run a react app: (1) react, (2) react-dom, and (3) the application itself.

So are you saying devs could create a compiled version of the application (3), but that (1) and (2) would remain the same?

[gaearon]

Yes. To clarify, we're working on making the bundles smaller. However in our experience the size of React or ReactDOM is not the bottleneck—it's the application code. So we're interested in optimizing that for bigger and scalable wins.

[sophiebits]

It might be the case that we could cut out some parts of react or react-dom if all components were AOT compiled, but it is a non-goal to have no runtime – just like in Babel it makes sense to have a shared helper for creating classes instead of writing out all of the logic every time.

[developit]

FWIW I agree about the runtime being a likely necessity, implementing AOT compilation of compositional components without a runtime seems like it would be either impossible or end up being N copies of a microframework for dealing with that case, which puts you in the same situation as babel helpers as mentioned.

[blainekasten]

However in our experience the size of React or ReactDOM is not the bottleneck—it's the application code

True, though it is semi-related to the way React application code is written. Trivial example here:

// React application code
import React from 'react';

class HideableDiv extends React.Component {
  state = {
    hidden: false,
  };
  
  toggleHide() {
    this.setState({hidden: !this.state.hidden});
  }

  render() {
    return (
      <div
        onClick={() => this.toggleHide()}
        style={{display: this.state.hidden ? 'none' : 'block'}}
      >Click To Hide Me!</div>
    );
  }
}

Now implemented in traditional JS:

const div = document.createElement('div');
div.innerHTML = 'Click to Hide Me!';
let hidden = false;

div.addEventListener('click', () => {
  hidden = !hidden;
  div.style.display = hidden;
});

The compared nature here is 17LOC to 7LOC. So the bottleneck may not be React or ReactDOM libraries, but may be the requirements of those libraries.

FWIW, I agree with almost ever sentiment here. Although I would be very interested to see this as a community project to gauge the viability of transforming stateful react application code into imperative runtime code while successfully source mapping back. If possible, that'd be pretty huge.

[gaearon]

To be honest I find this particular example a bit of a straw man. This is not representative of most React components I worked with, which have more complex updates, lifecycles, and render child components depending on state.

As I mentioned earlier, you can find our thinking about this here: https://github.com/facebook/react/labels/Component%3A%20Optimizing%20Compiler. For example, "component folding" would inline trivial components into bigger components, reducing the output size.

[developit]

Having looked into svelte et al a little bit, I think the complexity comes in child and composition diffing, not attribute/prop diffing. Diffing a large list of components based on keys via AOT would produce fairly verbose output and likely not optimize as well.

[trueadm]

@developit I was under the impression that @Rich-Harris added in shared helpers into Svelte to help deal with those cases?