There’s been a lot of development in the frontend frameworks ecosystem over the last seven years. We’ve learned a lot about what it takes to build and maintain large applications. We’ve seen many new ideas emerge. Some of these new ideas changed how we build web applications, and others we discarded because they did not work.
In the process, we saw a lot of hype and conflicting opinions that made it difficult to choose a framework. This choice is especially difficult when you’re picking a framework for an organization that will be responsible for maintaining this application for a long time.
In this article, I would like to describe the evolution of our understanding of how to build modern web applications and suggest a way of thinking about which technology to choose.
Backbone’s Models represented data and business logic. They emitted change to Views. When a change event was triggered, the view was responsible for applying that change to the DOM. Backbone was template agnostic. It left it to the developer to manually update the DOM.
Around the time that Backbone 1.0 landed, Angular.js was released and started to grow in popularity. Instead of focusing on the Model like Backbone, it focused on making the view better.
Angular.js introduced the idea of compiling templates to make HTML dynamic. It allowed injecting behavior into HTML elements using Directives. You could bind a model to a view and the view would automatically update when the model changed.
The popularity of Angular.js grew because it was easy to add Angular.js to any project and easy to get started with. Many developers were attracted to Angular.js because it was built by Google which gave Angular.js automatic credibility.
At about the same time, Web Components specification promised to make it possible for developers to create reusable widgets that were isolated from their context and were easy to compose with other widgets.
The Web Components specification was four separate specifications that worked together.
- HTML Template — provides HTML markup for the component
- Custom Element — provides a mechanism to create a custom HTML element
- Shadow DOM — isolates the internals of the component from the context that rendered it
- HTML Import — makes it possible to load the Web Component into a page
A team at Google created a polyfill library that provided Web Components for all browsers at the time. This library was called Polymer and was open-sourced in November of 2013.
Polymer was the first library to make it possible to build an interactive application by composing components. Early adopters benefited from composability but found performance issues that needed to be addressed by the framework.
Simultaneously, a small group of developers were inspired by the ideology of Ruby on Rails and wanted to create a convention-based, community-driven, open-source framework for building large web applications.
They started with a fork of SproutCore 2.0, which was an MVC-based framework with clear separation between Model, Controllers, and the View. This new framework was called Ember.js.
The first challenge of creating a convention-based framework was finding the patterns that were common to large web applications. The Ember.js team looked at large Backbone applications to find similarities.
They identified the need to render nested views where some parts of the application were consistent while other parts changed from one part of the app to another. For Web development company check Vivid Designs
They also saw the URL as a key player in the architecture of web applications. They married the idea of nested views and the significance of the URL to create a routing system that served as the entry point into an application and controlled the initial view rendering.