“Micro-libraries”: the future of front-end development?

Everybody has been talking a lot about JS frameworks over the last few years. There has been a large number of attempts to create the ultimate front-end framework but there is no clear winner.

While the high doses of innovation and the thrill of trying something new are great, the rapid change of technologies has become a critical risk.

Every six months, a hot new framework hits the mainstream, and our community explodes with excitement.


We can’t avoid making a decisions and answering questions like:

While we can try to back-up our choice…

Most technology decision makers use metrics like community size, popularity, and big company support to justify their choice of framework.

Choosing the wrong answer could lead us to undesired costs.

Some engineers dare to predict the future:

I believe Angular 2 is going to be amazing and Angular 2 will be what’s “so hot right now” in 2016.

What would be your choice if it was your call? What would you do if you realised that you picked the wrong option when the project is half way through its life cycle?

Maybe you are really excited about React right now or maybe you can’t wait for the release of Angular 2.0. Perhaps you are so excited that you have missed a small detail: The rise of micro-libraries.

The rise of micro-libraries #

We have observed that since the launch of React something changed. React was announced as a library, not a framework.

It may sound like an insignificant event but it is not the case. Angular 2.0 is also following this tendency and is going to be released as 3 independent components:

This is good news because we could end up with solutions that are much safer when it comes to change management. For example, if in a couple of years, the Angular 2.0 Router is not as good as we expected it could be replaced with a new library with ease and the same would apply for the DI Framework.

Aurelia is another popular framework and if you read its documentation you will be able to see that it is also composed of multiple independent libraries:

The same is happening with libraries like Flux, Redux, Reflux… we will be able to replace one approach with another if we have to.

We can imagine pieces of functionality like the component’s rendering engine being switched and upgraded as independent components. If some framework comes with a new idea like VirtualDOM we will be able to just replace the component’s rendering engine to one that uses VirtualDOM.

A new era is about to arrive. An era in which you will not pick one framework but your favourite parts of each of the available frameworks. Maybe you like the angular DI framework but you like the React components more than the Angular 2.0 components. That will not be a problem anymore!

The rise of web components #

We can also imagine something similar happening to UI frameworks like Bootstrap or Angular UI. In the future, we will download individual components instead of full UI frameworks.

Summary & references #

Maybe front-end applications are just going to follow the path of the server applications and move towards something like micro services. Web UI components will be implemented with the best set of technologies available for the problem that the component resolves.

Please feel free to let us know your thoughts about this article with us via @OweR_ReLoaDeD and @WolkSoftwareLtd.

Don’t forget to subscribe if you don’t want to miss it out future articles!

This post has been influenced by the following sources:

Thanks to Jakub Jedryszek for the information about Aurelia.


Now read this

Introducing InversifyJS

A lightweight inversion of control container for TypeScript & JavaScript apps # A few months ago I started to think about the possibility of creating a requireJS TypeScript fork in order to add dependency inversion (DI) support.... Continue →