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.
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.
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.
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.
The shared component cloud
Bit is a scalable and collaborative way to build and reuse components. It's everything you need from local development…
Documentation * Tutorials * Quick start guide * Workflows * bit.dev components cloud * Video demo Bit is an open-source…
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.
Storybook: UI component explorer for frontend developers
Storybook is an open source tool for developing UI components in isolation for React, Vue, Angular, and more. It makes…
There needs to be an overarching framework to glue different components together. And I feel the following frameworks to be the best.
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.
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.
For fast and secure sites | Jamstack
Are you ready for blast-off into the Jamspace? Check out Jamstack Explorers! Get started today Comprehensive guide for…
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!
Welcome to the Svelte tutorial. This will teach you everything you need to know to build fast, small web applications…
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:
Ghost Pro - 20 Reasons that make it the best choice for bloggers in 2021
By the end of this post, I hope I will have convinced you to choose Ghost Pro for your blog.
15 reasons FAANG companies are worth the effort
Interviewing at FAANG is daunting, heck even getting an interview at one of them is difficult, and downright unfair…