faceyspacey
commented
6 years ago na. ...a while back (last august) the plan was to make Universal.render() which I think i quickly outlined to u. The idea being you can use a single function/module/file, but powered by 2 different webpack builds and the usage of resolveWeak + __webpack_require__ (ideally PRed to webpack as requireWeak) to render both the client + server seamlessly. You could think of your app as one hybrid codebase like in the good 'ol Meteor days.
Ultimately it's a lesser goal these days, and chose to table it. In Respond phase 2 we'll revisit it, possibly in conjunction with our own bundler. Ideally not tho, as we can ship this way faster.
So basically the plan is to see how everything else pans out, specifically with the new rudy-powered code-splitting capabilities and then revisit this. ..The thing is that all the fancy chunk transportation and re-hydration was largely a result of splitting at the component level. When doing it at route level, this stuff is far less magical and more straightforward and obvious in a good way. So if that turns out to be the case, it may turn out to be a bad thing to further elevate the user from low level ReactDOM.render via an additional abstraction. Also wince React Async may end up having SSR, the landscape will change. We'll likely want to take both evolutions of the React platform (Respond + React Async) into play before investing time in a simplified universal rendering abstraction (whose main focus would be making things already possible easier for learners/newcomers). For pro apps the unified abstraction gets in the way until its value is clear.
Respond is it’s own beast, that being said. Do we need this repo anymore?