…we would all be using justin-bieber.js. We as an organization have been working with JavaScript since 2000. We have seen frameworks rise and fall, including being responsible for some of them. We have seen trends come and go. We have seen browser dominance ebb and flow. We have seen winners and losers. We have seen JavaScript go from an obscure simplistic scripting language to the language of the internet. Through all of this, we have experienced and learned a lot. We would like to share some of that with you.

Probably the most common question we get asked as we get to know an organization is “What framework should I use?” No matter what some people would have you believe there is no straightforward answer. The answer though is founded in our typical response of “What are you trying to do?”

Through this series of blog posts, we are going to try our best to give you a framework for choosing a framework (how meta is that?) and along the way, we are going to try to provide some analysis of several of today’s leading frameworks. But first we need to establish some common language between us.

What is a web application?

This is one of the things that has changed dramatically over the last 20 years. In the nascent days of the web and web applications, this usually was a form which posted information back to the server. In many cases, the form was generated HTML from the server, with a little bit of JavaScript to make it interactive. The biggest problem was that it was extremely difficult to get a rich experience, like that of a thick client application. If you needed a rich experience, you would often have to incorporate things like Java applets, Flash, or Silverlight into your application. Many enterprise web frameworks were nothing more than a way to send thick clients over HTTP and display them in a browser.

Today though, there is virtually no limit to what can be done via JavaScript, a web browser, and related technologies. From virtual reality to real-time media, all tightly coupled to the hardware; all of this is available as part of the web platform. There has also been a significant shift on the desktop, where there’s a continued desire to leverage the same skills for development, enabling fully native desktop experiences. On mobile, we see an increasingly fuzzy line between native and web experiences, with a huge focus on making sure the web technologies deliver full interactive experiences that meet the performance expectations of the user, irrespective of the power of their device or the speed of their connection.

So what is a web application? In one of posts in this series, we will delve deeper into the common use cases we see and how the different frameworks work with them, but for now, let’s consider a web application anything that at run-time uses the three core web technologies of HTML, JavaScript, and CSS.

What is a framework?

As much as the web platform has changed over the last 20 years, so have the needs of tools we use to build the applications. For many interesting historical reasons, HTML, JavaScript, and CSS don’t actually fit together very well. Increasingly we are seeing synergies among the standards bodies that define these technologies, but that hasn’t always been the case. JavaScript was designed in two weeks originally as a lightweight scripting language, not a language to power the ubiquitous web of connected devices we now live in. It gained its throne, not on its merits, but by a quirk of fate.

For many interesting historical reasons, HTML, JavaScript, and CSS do not actually fit together very well.

Since JavaScript was delivered, people have been trying to fix JavaScript. If they were not trying to fix JavaScript, they were trying to make the APIs that allow access to the HTML better (the Document Object Model or DOM). These, of course, all come with someone’s opinion of the right way to build applications.

Early on, it was a wild west of browsers, with each browser trying to vie for slightly unique selling points (USPs) that they would hope would lead them to dominate the internet. This provided a set of unique challenges for those developing web applications, as each USP was a way in which your application would not work as expected in another browser, and for those who could not force a particular version of a browser on someone (which would be every customer-focused business entity in the world!), it was a landmine that would and could frustrate your users. So early on, the likes of Prototype, MooTools, Dojo 1, jQuery, and others really focused on trying to level the playing field, so that you could actually write code that worked in every browser.

As the web matured, web applications became more complex. It became far more than stringing together some web forms. User expectations started to increase towards richer UIs delivered over the web. At the same time, the browser market shifted away from Internet Explorer to the likes of Chrome, Firefox, and Safari. Some of the previous toolkits, like Dojo 1, grew into this rich UI space as well as the rise of commercial solutions like ExtJS. This continued to evolve over several years with the introduction of Backbone, Ember.js, and eventually Angular 1. Libraries that started as collections of browser patches and APIs became application framework platforms.

Over the past couple of years, we have seen the rise of the most mature set of frameworks. A virtual cornucopia of options. By and large, these all focus on creating extremely rich UI/UX experiences that work across the gamut of devices from desktop to mobile. Some frameworks provide highly structured ways to build applications and some focus on solving just a single problem, expecting to be incorporated into other frameworks to build a whole application.

So, for this series of blog posts, we are going to consider a framework as any significant solution that, at run-time, uses idiomatic JavaScript and the other technologies of HTML and CSS. While it is impossible to have an exhaustive set, we are going to focus on the following:


  • Angular 2+

  • React + Redux

  • Vue.js

  • Dojo 2

  • Ember.js

  • Aurelia

What should I look for?

We will start that answer with a question: “What do you need?” While we are going to dig into as many aspects of these frameworks as we can, our analysis will not be exhaustive. Part of what drives this plethora of choice is the wide variety of different needs. We would even say that it might be folly for any large enterprise to enforce a one size fits all mandate when it comes to frameworks. While there are synergies that come from sharing code and having similar skills among development teams, most businesses these days have a variety of needs, from consumer-facing websites to inward facing business applications. No framework works best in every use case.

Your job, as the reader, is to come up with the checklist of your needs, which should be driven by what you want to accomplish. Some questions to consider about what you need which can provide context as you go through this series:

  • What type of web application do I need to build? Is it a consumer-facing website? Is the web application a consumer product? Is the application a business application which will be used by an expert user who knows a lot about the macro business process? Will the application be displaying a lot of data and need to visualize it in an actionable way?
  • What environments will this run in? Will it run on mobile? Do I need a native experience on mobile? Will I be able to control the browser set on which my application is run?
  • What sort of user interactions will I need to deliver? Will I be comfortable with off the shelf user elements or are the user interactions actually a key component of the value that my application provides? Is my application just part of a larger federated set of web applications, where I need to have a seamless user experience?
  • How much of my application will be client-side? Will my business logic reside within the web application or will I need to interface to server-side systems which will drive the application? How much service integration and orchestration will I need to do within my web application?
  • What is my development environment going to be like? How integrated will my front-end team be with my server-side team? Is it full stack development? What will be the workflow between the product owners, the UI/UX designers, and the software engineers? What other technologies will I need to integrate into my application?
  • How am I going to know my application will work as expected? How do I want to test it? What is the ongoing lifecycle of the application? Will it be handed over to a support team or will the original engineers continue to maintain the application in perpetuity?
  • How much do I expect this application to take from the open source community and am I prepared to give back to the community? Will I have the right level of skills and experience to deal with issues when they occur? Who will I turn to when we get stuck?

Major Areas

Now that you have some of the questions you need to answer, we want to take you through a journey of looking at the aspects of the above frameworks through several different lenses. We plan to cover the following areas in this series:

  • User Interface Development – The foundation for most web applications is, of course, the user interface and we will discuss several aspects of user interface development for the selected frameworks.
  • User Experience Design – A web application is a lot more than just a bunch of user interface elements plopped on a web page. Web applications need to fit the user ergonomics of your target user. How do you achieve those with your web application is an important consideration.
  • Foundation Technologies – It is important to understand the core of the framework. How are the frameworks built, what do they try to accomplish as far as ensuring web applications built with them work properly in different environments? How forward-looking are these frameworks as well, to help ensure it will not be outdated too quickly.
  • Applications – Once you have a user interface, you need business logic to drive it. How do the frameworks provide this and how rigid and flexible are those concepts?
  • Usage – Be it mobile first, expert-user business systems, consumer applications, or content management, all the frameworks deliver on these use cases in different ways and have varied strengths. Understanding where the frameworks excel (and maybe where they do not) will help in deciding what is best for you.
  • Integration – It is unlikely your web application will be fully self-contained. It will need to interface with different systems. The approach each framework takes to this is an important consideration.
  • Testing – How do each of the frameworks approach testing as well as what is a good testing approach?
  • Soundness – How well does the framework promote patterns and use technologies that help ensure well designed and behaving applications.
  • Building – What does the tooling and build pipeline look like for each of the frameworks?
  • Community – What is the community around each framework? Are those skills available on the market? Who do you turn to when you need help?

Let’s go

Popularity is not a good barometer for web application frameworks. This is because they all meet different needs in different ways. Having a good understanding of what you need will help you determine which framework is right for your particular application. So hopefully you are strapped in and ready to embark on this adventure together as we strive to explore the depths of web applications frameworks!