Jacob Ebey and I created the first “server-side rendering” technique for Federated Applications almost a year ago. We went with the tried and true POST-request-based network communication to load HTML, convert it into react, then replace the children in the newly minted “react” code.
This approach technically worked. But as with everything, it seems userland vs. server land required drastically different paths. The intricate network stitching, to some degree, takes the shine of the awesomeness of Module Federation. Great in the browser, but hard to do on the server.
While still in beta, I believe that I’m near ready for a release candidate. From my perspective, this is the most significant leap forwards for Module Federation since its inception.
Give a warm welcome to Software Streaming.
Software Streaming is part of our patent-pending "Federated Multiplexing" software substrate. (credit to Tyson Midboe)
Node loads code off disk; eventually, it'll have URL import support like Deno — that'll reduce work on Webpack Runtime, but these native loading strategies are helpful, but a quick glimpse at these native mechanisms is not a silver bullet. A huge misconception I see constantly is ESM makes Module Federation somewhat redundant. That's not true — at best, it lets us use more native capabilities to download strings. Less work for webpack, not a replacement of webpack.
Maybe web standards will have matured enough in the next 5–7 years. You might not need webpack, or want it, makes sense. These other bundlers don’t have a flexible enough API surface area for what I want to do. Module Federation is one thing, maybe other bundlers can get something similar and compatible, but it’s always missing some feature. It seems easier to write plugins for other bundlers, but Module Federation is just one plugin. There are deep integrations…