As much as most developers eschew the idea of the rock star developer, some are definitely taken by it.
It turns out that there’s some academic backing to this original observation and it’s partly what is driving some really controversial organizational changes at larger software companies.
So of course I checked their new site, that was written with this architecture (https://www.hellofresh.com/shop/). Could they solve this problem?
They load React, ReactDom, Immutabble and Axios separately to avoid having them duplicated, which accounts to ~67KB.
So what are the 700KB doing?
219KB for a shop fragment
135KB for the header particle
96KB for the footer particle
The last 250KB is some API stuff called api_static and api_dynamic.
I can't really tell how sophisticated the shop is with its 219KB, but having a 96KB Footer and 135KB Header should raise some doubts, how is this possible? A React Footer should be 1KB or something. As I checked the source code I found mainly vendor code and as far as I can tell it's duplicated among the source files.
For me this shows me, that they couldn't solve the problems that arise with such an architecture and I doubt that there will be anything that solves these issues (without putting a lot of burden on the developers) in the near future.
Maybe I'm missing something, but what does this accomplish that code splitting / server side rendering doesn't? If there were performance gains, that would be interesting to know as well.
Why have multiple SPA frameworks on a single page? What happens when one fragment is built in React X.X and another in React Y.Y? It feels like you have to pull a bunch of different pieces together to form what would formerly be known as a "route" in more traditional webapps, and I'm not really seeing the upside here.
I hope we get a follow-up in 6-12 months about where this experiment goes.
You could have multiple SPAs in the same page but you don't actually do that in practice.
You do this not because this is simple, not to create a better user experience but so that you can have 100+ teams working on the site without them being stuck because every change needs to be carefully coordinated with everyone else.
I can’t imagine that this is a problem that requires a bleeding-edge front end web technology to solve. ML tech, some cool logistics methodology, an awesome menu/price algorithm etc are things that I would expect to see. But this seems a bit over the top?
This is also the same technique I have used at companies that need to present an "integrated" view.
For example, an internal HR web site that presents a single page of all things related to an employee benefits.
The information would come from multiple different services:
* ADP for payroll
* Fidelity for 401k
* An interval vacation tracker
Each service would be given their own iframe that they control. No needs to worry about anything outside the iframe.
This is a time-proven way to do an integrated presentation of independent systems.
To clean up the look and feel - use basic html transformations and inject the site css.
It may seem "hacky" - but it works well in many many real world circumstances.