Micro frontends

The evolution of Javascript, a little bit of history

When we talk about frontend, it is much wider than just Javascript, but for this article, we are going to be mainly centered on it.

Javascript has walked a long and thorny road, and over the years have had may identity issues, was born in 1995 as Netscape’s Mocha and many big companies have tried to supplant or dominate JS, first Sun, then Microsoft (VBScript), then Adobe, then Microsoft again (Silverlight), then Google, and then, arguably with TypeScript, Microsoft.

At the beginning was created as an intention of a “glue language” for designers with a developer soul, with no standards at all and yet, here we are now with a standardized and improved language, which is now the most used for web development. And if you have a look at its progress you will see that any step that Backend does, Frontend does it as well some years later. In this case, in 2005 Micro-web-services was proposed for the first time and some years later in 2016 Micro Frontend was mentioned for the first time.

So… what’s a Micro FrontEnd?

If you have been searching for Micro FrontEnd you will find this image pretty much in all the sites, so I don’t want to be the exception

We have been migrating from Monoliths applications to small chunks of code, making it easier for big teams to specialize in functionalities, maintain, and deploy applications.

If teams are more specialized, they are going to work only on one task, so they can improve in a better and faster way a specific functionality of an app. Also, they are responsible for the end-to-end life cycle, this means each team will be accountable for the design, architecture, front-end, back-end, database, deployment, and any other matter that comes up in the TECH life.

Having this separation allows companies, to be much more flexible in technologies, this means, that a project becomes language/technology/framework agnostic, each team can decide what is going to use, while everything fits in the corresponding spot.

The principles of a Micro FrontEnd are:

• Agnostic to technology as mentioned before
• Isolated code
• Every team should be prefixed, for all, CSS, events, stores
• Resilient Site, this means that every functionality should work even if JS failed or was not executed completely

Why this need was born?

With time, TECH teams have realized that life is not easy when you need to work with many other teams in a monolith application, a change from one team, can put the application down and make loose time to other teams.

When Single Page Applications became popular in companies environments, this pain grew as well as the FrontEnd code, creating huge monoliths of HTML, CSS and JS increasing the complexity of maintaining, debugging it and deploying the application, also was difficult to manage the teams since all are working in the same “work area” and teams were stepping over others work.

So as said before, FrontEnd took the same step as Back-End, move to microservices, so TECH teams could be much more comfortable working and avoiding to crash on other team’s work. Growing the application started feeling more natural since Micro FrontEnd apps grow in a horizontal way.

Here comes the twist / Conclusion

Based on what I have read doing my research for this article I think all the TECH world is just thinking about what’s more optimal for TECH teams, leaving the most important part outside the equation... The Final User. In most of the solutions I that the final outcome code is even bigger than the monoliths we wanted to defeat in the first place.

Of course, this code is easier to maintain, deploy, etc etc, but having in the same page load, more that one Framework or two or three times the CSS because projects are independent is not fair for the users, the wait times are going up, also for the processing of the code.

I agree with the evolution of the Front-End like Back-End, but I feel we, as developers need to lose some of this Micro FrontEnd freedom, and try to strike a happy medium where we can work comfortably in our codebases and users can have better response times.

What do you think? Are we losing our focus over the final user?