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!
Websites today are still made the same way they were 20 years ago, with a cumbersome monolithic approach to building sites, storing data, and delivering content. It’s time for a new way to build the web. — GatsbyJS’s Founder Kyle Mathews
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
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 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 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
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.
- 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.
- Less boilerplate, as it’s written in near vanilla HTML, CSS, & JS syntax.
- Standard HTML, unlike JSX.
- Instead of using techniques like virtual DOM diffing, Svelte writes code that surgically updates the DOM when the state of your app changes.
- CSS is component scoped, which saves a lot of headache.
- 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.
If you liked this, you might also like:
