Sign in

Micro-Frontend: The best Vaccine to React, Angular & Vue.js Pandemic

It’s high time we break the monolith architecture in the front-end, the way it’s broken in the back-end: stateless, componentized, tech-agnostic & separate!

After experiencing development using React & Angular, I have nothing but pure loathing for the current state of front-end web development.

Especially with the Agile and it’s weekly delivery mandate, the monolithic approach to front-end development is just a huge pain in the tushy. Requirements changes at the whim of the project manager, or at the last minute, due to misunderstood use case.

Front-end, a monolith, however remains inflexible unlike the micro-service based back-end.

While developing a back-end we strive to make it as stateless as possible, why not for the front-end. Why have a shared state at all, only to have it get unmanageable in the long run? What is a shared state, if not a glorified Global variable?

Then comes along the frameworks and their countless dependencies, verbosity, and hand holding opinions.

Sure there’s Storybook.js for those frameworks, to allow development of component in isolation, but the result still remains a monolith.

Defacto front-end frameworks, like React, Angular & Vue.js, aren’t even fast enough. On top of that they bloat the site with JavaScript. See: A RealWorld Comparison of Front-End Frameworks with Benchmarks.

Svelte already beats the Monoliths in their own game, however we can take it even further with Micro-Frontend approach.

This post is about taking the front-end to the next level. Breaking the site and building the individual pieces the way back-end development is done.

Pros & Cons

Cons of Monolithic Frontend

  • During inception, the architecture might be solid, but the volley of adjustments made to the system turns the code base into a a big ball of mud, a casual, haphazardly structured system.
  • A version change to any library breaks the whole application, instead of just one component, and we have to fix the issue for each of the component individually in a go.
  • Tiny changes require full deployment.
  • Eventually things get tightly coupled, due to lack of foresight of new requirements streaming in. Components can’t function independently once plucked from their location as the same component gets reused in multiple pages, with varying requirements in UI.
  • Everyone in the front end must use the same library, and won’t be able to choose best tool for the job.
  • Struggle to scale is real.
  • Teams keep stepping on each other’s toes.
  • While the backend is nicely segregated, the front-end remains a large monolith, which requires knowledge about the whole backend.
  • Development blues like: Inability to find the file on which to work on, because we can’t see which component the ui view belongs to.
  • Things become stateful, which gets unwieldy eventually.
  • Component discovery suffers and so does reusability.
  • Incremental upgrades are risky, & slow.

Pros of Micro-Frontend

  • This design is resilient to drawbacks of requirement changes.
  • Version change of any library won’t require every component to be updated to get the site running. Each component can do it independently.
  • Tiny changes won’t require full deployment.
  • Things can never get tightly coupled, as each component are independent and must be able to function without the rest.
  • Everyone’s free to choose best tool for the job.
  • Scaling is on par with a Microservice architecture.
  • Teams can’t keep stepping on each other’s toes, if everything is nicely split.
  • Front end is split, mirroring the back end.
  • Easy to find file on which to work on, as we can clearly see from Bit.dev site. (Try hovering over each component on that site!)
  • Components remain stateless through and through, as they solely interact via their respective public API.
  • Component discovery is easy.
  • Incremental upgrades are easy.

Tools

The following tools are what can help you with Micro-Frontend development. Both of the tools, when combined together, can make one master of webdev.

1. Bit.dev

Share Code Components — Bit.dev — YouTube

Bit is an open-source cli tool for collaborating on isolated components across projects and repositories.

Instead of building the whole project in one build process, the component-driven CI from Bit.dev splits the build process so that it only runs on the components that actually changed, and propagates the changes, to build every impacted component, on every page, in every app.

So instead of messing with cumbersome iframes or finding alternative solutions, we can rely on build-time integrations that do not couple release processes together.

Since components are decoupled, we can easily add, replace, hotfix, or even rollback a single component or feature.

On top of that, features such as visual component documentation, a smart component search, and even live simulations all help to make all the components discoverable so that we don’t have to maintain any additional documentation websites, registries or tools.

See: How We Build Micro Frontends blog post by Bit.dev.

2. Storybook

Storybook for Front-End Development — YouTube

Storybook is an open source tool for developing UI components in isolation. It makes building stunning UIs organized and efficient.

Checkout how Airbnb react date picker Storybook is organized.

It helps with documentation, mocking hard to reproduce use case, build in isolation, and do visual testing on components.

However Storybook solves half of the equation.

Storybook excels in the visual development of standalone components locally, Bit handles the full lifecycle of components already created. It completes Storybook from the point a component lives in your project, and beyond.

See: How is bit.dev different from Storybook? blog by Bit.dev.

Frameworks

There needs to be an overarching framework to glue different components together. And I feel the following frameworks to be the best.

1. Handlebars

Handlebars Tutorial — YouTube

Handlebars is a simple templating language. It uses a template and an input object to generate HTML or other text formats. Handlebars templates look like regular text with embedded Handlebars expressions.

It’s great for readonly content, for instance this blog is made using Handlebars. Try turning off the javascript, and the site will still work as the template have been rendered in the server.

However it’s not good for fast (incremental) updates of the DOM, event-handling, frontend-backend communication. — See: When not to use Handlebars?

As for when to use it, checkout Jamstack.

2. Svelte

Rich Harris — Rethinking Reactivity — YouTube

Svelte takes Handlebars further, by facilitating updates of the DOM, event-handling, frontend-backend communication.

It’s actually not a framework but a compiler with a templating language like Handlebars.js! (i.e. with single curly braces instead of double)

Svelte being a compiler and templating language is what makes it so powerful.

  1. Unlike React, Vue or Angular, that do the bulk of their work in the browser at runtime, Svelte shifts that work into a compile step which results in a framework free vanilla js code.
  2. Less boilerplate, as it’s written in near vanilla HTML, CSS, & JS syntax.
  3. Standard HTML, unlike JSX.
  4. Instead of using techniques like virtual DOM diffing, Svelte writes code that surgically updates the DOM when the state of your app changes.
  5. CSS is component scoped, which saves a lot of headache.
  6. Supports universal rendering & static site gen with Sapper. So no compromise on SEO, and one step closer to Jamstack!

Conclusion

Sure, lots of JS comes out every minute. Not every one of them is worthy of our attention. However Svelte does something no other framework does, and that deserves everyone’s attention. Combine that with Micro-Frontend architecture, and we are golden.

What do you think, let me know in the comments below.

Leave a Comment →

If you’re someone, just starting out in the industry or looking to better yourself or trying to find your way in life. You have come to the right place!

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store