This week i want to highlight two articles: one about Fate-sharing and micro-frontends, and another, about the future of web frameworks and how they fit into the distributed frontends solution space.

Fate-sharing is an interesting concept that i didn’t knew about, however it’s pretty common to see its effects in large frontend applications:

”Fate-sharing is an engineering design philosophy where related parts of a system are yoked together, so that they either fail together or not at all “
Wikipedia

The concept of fate-sharing is a major problem in large, complex frontend applications. A single mistake by a team member can cause a major performance regression or even downtime, which is especially concerning due to the slow release cycles often seen in monolithic applications. This has led to increased interest in release independence and isolation between subsystems of large frontend applications.

Risks associated with fate-sharing create a pressure to enable distinct parts of the application to be deployed independently. We’ve seen this happen in the backend space before, which has already mostly moved from monolithic servers to microservice architecture for modern large-scale development.
https://igor.dev/posts/fate-sharing-and-micro-frontends/

The future of frontend architectures needs to put in its horizon the capability for “distributed, carefully decomposed architectures that enable scalability and avoid fate-sharing through independent releases”. However, most solutions today solve fate-sharing at the cost of continuously increasing payload sizes, or by increasing coupling and sharing dependencies. This can either lead to performance degradation or frequent functional failures.

Frameworks

There are interesting new developments in the what’s becoming known as the html-first framework space with concepts like islands architecture and resumability. They both seem to start by tackling the hydration issues commonly seen in todays frameworks:

In web development, hydration or rehydration is a technique in which client-side JavaScript converts a static HTML web page, delivered either through static hosting or server-side rendering, into a dynamic web page by attaching event handlers to the HTML elements.

This results in the client re-executing code that the server already ran during server-side rendering (SSR). This has led to this concept being referred to as "pure overhead".

Islands

The islands architecture starts to address these issues by introducing the concept of multiple embedded applications. These applications can be hydrated using scheduling approaches (e.g. requestIdleCallback) or take into account additional factors such as viewport visibility and interactions. Each part of the page is an isolated unit, so a performance issue in one unit won't affect the others.

The main frameworks in this space would be:

• https://fresh.deno.dev

• https://astro.build

Resumability

The concept of resumability is being pioneered by Qwik. This architecture is about taking the concept of islands further by skipping the hydration process.
In the islands architecture the concept of hydration is still present, the main difference is that it’s scoped into smaller parts and done on demand. Qwik adresses this by serializing listeners, internal data structures, and application state into HTML during the server-browser handoff, allowing the client to resume execution where the server left-off.
The framework also provides primitives for implementing the islands architecture style with containers. The main advantage of this strategy would be that due to the resumability properties these islands can have a much better TTI (time to interactive).

O(1) Frameworks

One of the main benefits that comes with the islands concept is that the Javascript that needs to be downloaded is not proportional to the size of the application. Instead it is related to the parts of the application that are interacted with.
Regarding the duplication of components and the growing size of payloads associated with microfrontends, this could potentially make a difference. For example, you may have multiple fragments that all contain a complex datepicker. However, if the user only interacts with one of them, only one copy of the datepicker code needs to be downloaded and executed. There is still a case to be made about the consistency of the UI and managing different versions of components, but this appears to be a step in the right direction.

Future

Imagine a future where your server is only 9ms away from your average client, while your client-side device takes hundreds of milliseconds to parse, evaluate, and execute your ever-increasing Gen 2-based Web application. Rather than trying to squeeze more performance from your client, you'd start thinking about how to offload more of the logic to the server-side. That future is coming. And it's coming faster than most of us expect. https://igor.dev/posts/experiences-web-frameworks-future-me/#return-to-server

In a future where frontend applications are ever increasing in size responsibility and complexity. Where with the advent of edge networks the server is only miliseconds away, its not feasible to have ever increasing payloads that the user’s device will take hundreds of milliseconds to parse, evaluate, and execute. Building distributed applications that can become immediatly interactive seems to be a step in the right direction that needs further exploration in the microfrontends space.

Resources

Qwik: A no-hydration instant-on personalized web applications

Islands architecture
https://jasonformat.com/islands-architecture/
https://www.patterns.dev/posts/islands-architecture/

Hydration is pure overhead
https://www.builder.io/blog/hydration-is-pure-overhead