ReactDOM - The cost of extra 900 bytes

[prasannavl]

ReactDOM and React are good separation of concerns. However, except for special cases, React applications almost always require the ReactDOM as well. The special cases can obviously have their own builds which can remove the unnecessary dependency. But React officially should serve a single library which includes the ReactDOM as a single resource. It absolutely makes no sense for an extra network request for a library that's 900 bytes gzipped.

This cost is even multiplied, since the official CDNs seem to already have a redirection in place. At the moment of filing this issue, a request to https://fb.me/react-0.14.7.min.js ends up with 301 to https://fbcdn-dragon-a.akamaihd.net/hphotos-ak-xfa1/t39.3284-6/12624086_185960608428874_474870377_n.js

And similar redirects for ReactDOM. That's 4 requests in place of what could be a 2. 2 requests, for a mere 900 bytes. In other words, taking the overhead of TCP/IP and HTTP, an overhead of nearly half a kilobyte with about 600ms of latency (in my geographic location) for a mere 900 bytes. Now, add to the fact that the gzip would probably nullify that 900 bytes almost entirely if its included as a part of the other 70kb file, due to binary compression.

I'm honestly quite surprised why it was even decided to separate them (Not as libraries, but in terms of deployment).

[gaearon]

It absolutely makes no sense for an extra network request for a library that's 900 bytes gzipped.

It’s only 900 bytes because it aims to keep the post-split compatibility in 0.14 for a version. Since before 0.14, ReactDOM.render() was React.render() and we still support this in 0.14 with a warning, the standalone React build had to include ReactDOM to avoid breaking people who haven’t updated their code yet. Since we don’t want to duplicate the code, we use this trick with re-exporting a hidden export of React from ReactDOM so that both old and new code works.

However, in the next versions we don’t have to support the old React.render() anymore, as it has been deprecated. There is an ongoing work on really splitting the two packages which you can track in #5974. After the split, it won’t be 900 bytes anymore.

[jimfb]

@gaearon True, but even if we move the code around, you are still eating a second round trip for no apparent reason. In the common case, a user will want react.js IFF they're using react-dom.js so it makes sense for the default to be that they are packaged together. There are notable counterexamples (like react-art), but most of those people are using commonjs anyway (which will deduplicate). It's easy to make the argument that they should be bundled by default.

[prasannavl]

Thanks for the explanation. It does however seems a little harsh that 4 requests. I could divide this into 2 scenarios:

1. Present (The time of this discussion): Where the separation in terms of deployments make no sense. It could have just as well remained in the same library, just being exported separately.
2. Future: Now, for user scenarios, pretty much almost always on the browser, both the libraries are going to taken in. Now, even including the redirects that take place, the cost that I mention above will no longer be relevant. However, it does seem more prudent to have a deployment option to just include a single unit.

[gaearon]

@jimfb @prasannavl

Yeah, definitely seeing your points. On the other hand it feels like having different packaging for CommonJS and UMD might get really confusing: #5413 (comment).

[jimfb]

Yeah, but we could maintain that same API by having react-dom.js export both React and ReactDOM, as mentioned in that thread. I'm going to close this thread in favor of reopening #5413.