Web Frameworks: Conclusions

By on November 10, 2017 3:22 pm

It has come time to read the liner notes and write some conclusions. When we started writing this blog series, we knew that JavaScript/web application frameworks were not easy to summarize. We have tried to answer the unanswerable: What framework should I use?

In this post we are going to draw some conclusions about each framework considered in this series, including what we think are their strengths and weaknesses. In addition, we will give you some parting thoughts to consider.

This is part of a series on web frameworks. If you’ve missed our previous posts, you may want to start with If we chose our JavaScript framework like we choose our music…

Do I need a framework?

It would be remiss of us not to try to answer this question. This has increasingly become a mantra of certain segments of the community. Arguing the web platform has advanced to the point where you don’t need additional APIs to make creating web applications easy. Like everything in this series, our response would be more it depends.

While going frameworkless can work, and does, it also comes at a cost. Those who advocate the benefits of frameworkless JS, those used to the, we would argue, Stockholm Syndrome of web technologies forget that there are multiple sets of rapidly evolving APIs with at least three different technologies with three radically different syntaxes. The specifications for the web platform identify over 12,000 APIs and the Venn diagram of what is actually in browsers shows there are significant gaps:

Venn Diagram of Web Platform APIs for Safari, Chrome, and Standards

Web Platform API overlap. Source: Microsoft API Catalogue

Going frameworkless is in part contracting to keep up with those platforms, to eschew teams of people, often working closely with the browser vendors, to have the hubris to say I can tame this wild beast.

But say you as an individual have the depth of experience and skills to honestly be able to go frameworkless. What about the rest of your team, or the person that comes after you, or are you locking yourself into being haunted by the decisions you make now forever? We have seen teams embark on a frameworkless adventure. They end up finding themselves creating a home grown framework which they must then maintain. The barrier to finding talent has been raised, because instead of knowing a framework, they have to find someone that has advanced skills in the web platform APIs, or they have someone who professes that experience, only to discover they lack the depth and experience to actually contribute effectively to the team.

We have to avoid the trap of false equivalence in our organizations. There are clearly companies where being innovative in the use and application of web technologies advances their market viability. Google, Facebook, and Netflix are good examples. Most organizations are not and should accept that.

Angular 2+

What are the strengths?

The biggest strength of Angular 2+ is its popularity. It could be argued that having the name Google associated with it has an impact on organizations considering it. Angular 1 rapidly gained in popularity because those coming from other interactive application environments found the familiar model view pattern for developing single page applications. By modernizing Angular 1 and rearchitecting certain portions of the framework, Angular 2+ has really burst onto the scene. The amount of training, both informal and informal, is impressive. There is a strong market for developers. It is also one of the few frameworks compared in this series that has an official set of rich components for building user interfaces.

What are the weaknesses and challenges?

We feel the Angular framework focuses on creating user interfaces in a single page application and does not address the larger concerns of a building a web application. This can lead to difficult to maintain projects if conventions are not established early. At a practical level, there is a lot of magic that occurs to provide run-time behavior that is not part of the core framework-provided technologies. This diminishes the value of TypeScript to the end-developer.

What does the future hold?

Angular 5 was just released and it appears that Angular has succeeded in increasing the release cadence to be aligned to a rapid release schedule. It is likely that Angular will continue to mature with continued support from Google.

Like any large organization, Google has multiple personalities. Externally there is an appearance of harmony between the Angular teams and those focused on browser standards. Our opinion is that harmony is really a thin veneer and that Angular hasn’t really addressed effective solutions to Web Components and Progressive Web Apps. It is our opinion that industry agreed standards will outlive some of the approaches in the Angular framework. The impact in how Angular applications are built and architected may be a medium/long term risk.

Why would I choose Angular 2+?

If you need to source skills in a framework at scale, where the skills are generally easily portable, or you need to train teams on a framework and have a level of confidence they will be productive in short order, you might consider Angular 2+. Be warned though Angular 1 (Angular.js) is a substantially different beast and applications, skills, and experience are not directly portable to Angular 2+ development.

If your web applications translate well into a model view pattern, then you might also consider Angular 2+.

If you are happy with the Google Material UX pattern, then Material for Angular is a quick, easy, and robust way to follow that pattern.

React + Redux

What are the strengths?

The biggest strengths of React and Redux are their relative simplicity and focus. Taking the mantra of do one thing and do it well it is hard to find fault that both libraries achieve very effectively what they set out to do. While for some a state container approach might be foreign, most developers can easily grasp the concepts and understand that benefits of a one way flow of data architecture and how they can simplify heavy user interface applications.

What are the weaknesses and challenges?

The biggest weakness of both React and Redux are not what they are, but what they are not. To build a feature-rich web application, you need many other features and once you get away from the core of React, Redux and a couple of other libraries, you will find a hugely fragmented community, with countless solutions and patterns which may or may not be easy to integrate together.

So while React and Redux are both very focused libraries, inexperienced teams can quite easily produce unmaintainable solutions, not being aware that the choices they are making are leading to bad or buggy performance. Even experienced developers can realize that a loose architecture or conventions can easily haunt them in the future.

It is easy to fool yourself into a false economy that organization-wide adoptions of React and Redux will mitigate inefficiency problems. Without extensive conventions and standardization of other libraries and patterns, standardizing on React + Redux is akin to saying we are adopting JavaScript to write our applications to increase efficiency.

What does the future hold?

Facebook and React are recently smarting from the plus Patents backlash, where they realized, like other projects have, that the wider community can and does raise its voice. I feel this has helped Facebook realize that they cannot take the we know better, trust us approach to forwarding their projects. Hopefully this will continue to flow through the features and technical direction of the projects.

It is hard to predict the future with React and Redux. Having focused libraries, though, does dramatically increase adaptability and most React + Redux patterns promote a decoupled architecture that allows for easy refactoring and iteration. Two years ago the flavor of the day was React + Flux, but the whole community embraced Redux quickly. It is likely that other major shifts in thinking or patterns could be easily adopted. This ability to pivot is likely to continue into the future.

Why would I choose React + Redux?

If you are in a situation where you need less hand holding and are looking more for good libraries than a comprehensive framework, then React + Redux might be right. You do need to be honest about the abilities of your team and organization, not only during your initial development, but throughout long term application maintenance.


What are the strengths?

The ability to incrementally adopt Vue.js is likely the biggest strength. Vue has a concise and rational architecture which makes it straightforward to understand and easy to build upon.

There is a robust community of passionate people and projects that add significant value to Vue.js, and it is fairly easy to pull together a comprehensive solution for a greenfield development project.

What are the weaknesses and challenges?

The desire to pivot between model view application and state container type applications can be confusing. It feels like there is a desire to remain relevant without fully embracing one application pattern over another. It feels to us that, at a minimum, it is confusing to those looking to Vue.js for a complete solution and could lead to inconsistent application patterns that are difficult to maintain.

One of the bigger challenges is Vue.js is dependent on a single individual. Obviously other projects can be dominated by one organization, but with Vue.js it feels more significant. While there is a robust community around Vue.js with many innovative additive projects, the core is essentially sitting on one person’s shoulders.

Our opinion is that it is great to see the approach of embracing emerging standards by Vue.js, but its sort of Web Component like pattern, but not Web Components, may be more of a liability than an asset.

What does the future hold?

While there is some fairly wide and diverse adoption of Vue.js, it is hard to predict how long it will last in the medium term. It is not directly supported by a commercial organization, thereby being largely dependent upon its maintainer’s viability and desire to continue to press forward.

It has shown a level of ability to adapt and pivot as certain patterns fall in and out of favor and continues to keep itself modern and up to date. There is no indication that Vue.js’s architecture wouldn’t be able to adapt in the future.

Why would I choose Vue.js?

If you have a legacy web application that needs a more robust and contained application layer, then Vue.js might be a good fit for you to adopt. It has clear patterns and even with inexperienced teams, there is a right way and a wrong way. While there are not any out of the box Vue UX frameworks, there are extensive sets of coherent frameworks built on Vue.js that might work for your project.

Dojo 2

What are the strengths?

Focusing on bringing more of a framework experience to the pattern of reactive components built on a state container architecture, Dojo 2 fills in a lot of blanks that are present with something like React + Redux.

Dojo 2 also acknowledges that it does not live in a world by itself. By embracing both the importing and exporting of Web Components, it realizes that different use cases need to be supported, but still provide the value of a structured and opinionated framework. There is also a focus on providing interoperability as a core foundation of Dojo 2.

Dojo 2 feels that it provides solutions to a lot of concerns and features that are important to full web applications that are not a focus of most other frameworks. Providing a system for internationalization and extensive patterns for accessibility are part of that story, but also providing a theming system and promoting patterns that ensure sound code development not only for TypeScript/JavaScript but also the management of resources like CSS.

Dojo 2 focuses on providing a structured, developer-ergonomic development environment. By its use of TypeScript and other patterns, it tries to provide guard rails to guide development without shackling those who know what they are doing. By focusing on making development more productive and safe, it aims to enable teams to deliver better web applications rapidly.

What are the weaknesses and challenges?

It is arguable that taking extended periods of time to release Dojo 2 as ready continues to hinder it. It will obviously continue to be in a crowded space, where other projects, because of their narrow focus or expanded resources, have been able to continue to develop and iterate at a quick pace.

It could also be a potential challenge that wanting to be flexible and interoperable might obviate the Dojo 2 raison d’être, leaving no specific reason to use Dojo 2.

What does the future hold?

It is all about the future with Dojo 2. It will continue to try to provide clear patterns and guidance for building web applications that scale. As standards continue to emerge, Dojo 2 will strive to adopt them and integrate them into their approach. Dojo 2 will continue to try to be open and interoperable, acknowledging that it is unlikely that any one solution will fit everyone’s use cases all the time.

Why would I choose Dojo 2?

If you want to adopt a flexible, modern, reactive web application architecture, but you want many intelligent defaults then Dojo 2 is a good choice. Instead of having to piece together a build pipeline and establish higher order conventions for your project, you can focus on developing your functionality and be confident that it is more likely to be production ready. Also if you appreciate the benefits of TypeScript, Dojo 2 leverages TypeScript in a highly disciplined manner to provide strong end developer ergonomics.


What are the strengths?

Ember.js is likely the most opinionated mainstream framework, and that is its biggest strength. Not only is there a right way to create an Ember.js application, there is usually only one way to create the application. Ember.js is more akin to a product or platform, where you would expect long term support and maintenance from a vendor. Ember.js provides comprehensive version management of their platform, upgrade tooling, and strong guidance and tooling on deprecation of APIs. Mature would be a good summary of Ember.js.

Ember.js had demonstrated over the years that it can maintain its framework and keep it aligned to modern standards while not abandoning legacy browsers prematurely.

Ember.js has a clear and rational architecture for comprehensively building web applications.

What are the weaknesses and challenges?

Ember.js is likely the most opinionated mainstream framework, and that is its biggest weakness. While the community is open and receptive to input, there is still a right way and going off piste can be challenging and problematic.

Having a rich third-party community can also be challenging. Because there is no out of the box set of UX components, using third-party sets is likely. You are likely to find though that those sets are not comprehensive and you will need to build or seek out other components. Because Ember.js doesn’t extend its opinions of how to interact and manage the DOM, you can find yourself with inconsistent components that don’t provide an easy to manage UI.

What does the future hold?

Major contributors to Ember.js are core participants in TC39, the standards committee for the JavaScript language. Ember.js has had more direct influence on the direction of JavaScript over the past few years than any other framework. Our opinion is that this will continue in the future, helping promote features and patterns in JavaScript. It also means that Ember.js will continue to keep itself closely aligned to the standards in the future.

It is unlikely that Ember.js will disappear anytime in the future, though their innovation is likely to come through other projects closely aligned to Ember.js, like Glimmer, which provides a new UI framework for Ember.js applications that is built on TypeScript.

Why would I choose Ember.js?

If you are looking for maturity in a framework, it is hard to go wrong with Ember.js. Also, because what Ember.js provides is understood and there is extensive official and officially sanctioned training, and the rigid constructs, finding talent that can build Ember.js based applications is possibly easier than with other frameworks. It is also quite possible to educate large teams on how to build applications and ensure a common dialog and understanding across the team.

If you want to place confidence in an organization to stay current and think critically about changes to their platform, then Ember.js would be a good consideration. You can spend less time worrying about keeping current with technology trends and focus more on creating applications.


What are the strengths?

There is a lot that Aurelia get right about the approach, structure, and thoughts about building web applications. There is a lot of technical excellence in the authoring of the framework. It is modern and uses modern technologies.

What are the weaknesses and challenges?

The biggest challenge in our estimate is momentum and lack of critical mass of core development. Our feeling is that many of the ideas and concepts are spot on and address critical concerns we have about other frameworks, but all of these aspirations feel not fully delivered. It feels as much as a work in progress as Dojo 2, but it being a released framework.

Large parts of Aurelia sit on a single individual’s shoulders, which could present a challenge if focus or availability of the individual were to change.

What does the future hold?

There is a lot of opportunity for Aurelia. If it were able to deliver on its vision, it would preserve the patterns established in Angular for building web applications, but deliver them in a more sound and standards-aligned way. We are unsure if Aurelia is going to be able to capitalize on that opportunity.

Why would I choose Aurelia?

If you are committed to the model view application pattern for the web, and you or your team have the desire to try to make something better, then Aurelia would be a consideration. It feels like a framework that is seeking a larger community to help power its development and evolution.

Final thoughts

Hopefully this series of posts have at the very least given you food for thought. You should walk away with the feeling that there is unlikely to be a provably correct decision. Also, hopefully you realize that there is really no universally incorrect decision. You should also be armed with a collection of questions and considerations to help you decide on your framework of choice.

A framework is nothing more than an embodiment of some patterns, integration of some technologies, and source code to help make our web applications easier to build and maintain. If you are an individual developer, the best advice we can offer is to spend some time with as many frameworks you might think would work for you. If you are a business manager or architect trying to make a decision, remember that a feature list is just one aspect of a decision, and sometimes more is not better. Challenge yourself or your team to take a holistic look at a framework, but first, start with a list of what is important to you and your organization, especially those things that transcend technical features.

Finally, we are here to help. We have tried to demonstrate to you over these eleven posts. While I (Kit) have authored the majority of this series, it was hugely supported by the rest of the team here at SitePen, doing research, adding content, providing experience, and reviewing. We are a company motivated by enabling other companies to achieve their business objectives by solving hard problems. Feel free to get in touch with us to see how we might be able to help you!

Other posts in the series


  • A lot of pro sites still seem to use jquery, often with backbone.js, sometimes pairing it with boostrap or jqueryui. The conerns about conflicting moving parts don’t seem to apply to combos like that. Are those also frameworks in the sense indicated by the article? They don’t provide a technology to optimize a set of simulataneous DOM updates for a single page app. Is there a preferred lib that would use jquery only for DOM reading and perform batch DOM writes more efficiently? This article on YallaJS made it sound like a candidate for that role:

    Thoughts and comments appreciated…

  • Not the author but just my 2 cents about the jquery vs modern framework discussion.

    I don’t believe the problem with the jquery vs a framework paradigm relates to DOM efficiency and might just be a small factor. Perhaps the view layer “frameworks/libs” like React perform better in some DOM update use cases but is not why you use them. The real reason comes down to maintenance and developer productivity and efficiency. I have 5+ years in doing JS development using vanilla/jquery route w/ backbone and now 3+ years w/ React and 1+ using redux in production. The debugging level of effort for frameworks tends to significantly less. Tracking and understanding origins of bugs is far simpler in an opinionated framework. e.g, If your loading indicator or data seems incorrect in a redux app it will probably be an error in the reducers.

    If there was as much due diligence into strict conventions in a jquery based app perhaps one of the newer frameworks is an unnecessary venture. Anecdotally in the jquery based code bases I was apart of there was never any clear conventions or structure.

  • You really should give DoneJS some love. https://donejs.com/

    Best of all worlds – more maintainable, great support, easy to learn.

  • The series would have been 2000 pages rather than 200 if we had compared every framework that we find interesting, so we had to draw the line somewhere. We agree that the team working on DoneJS do good work.

  • VDOM frameworks streamline all of your DOM operations into a single consistent set of operations. So your code for mapping business logic and data into the UI gets streamlined, and you find yourself doing more configuration rather than a series of one-off DOM operations and bindings between data and DOM. So it just leads to fewer places to introduce errors and performance problems.

    jQuery’s biggest strength is that it is easy. It’s biggest weakness is that ease prevents most people from establishing solid architecture patterns when they try to scale it up to build larger applications. It’s certainly possible to do so, but out of the box it lacks much in the way of architectural opinion on its own (which is why people started looking at things like Backbone, Knockout and others back in that era).

  • Yup definitely agree with that.

  • Thanks to both of the replies above for the informative points of view. It sounds like the gist of the answer to my actual question was this: the parent article focused on comparing VDOM frameworks because VDOM frameworks provide improved modularity and data encapsulation and performance for single page apps. So performance is only 1 part of that issue, and not the most important in the majority of use cases.

  • Martyn Janes

    As author of the UniteJS http://unitejs.com/ web development tool which tries to provide a level playing field for all the different frameworks I would like to think I have a good understanding of the different frameworks Angular/Aurelia/Polymer/Preact/React/Vue. Removing the FUD around the development tools by using UniteJS means you can concentrate on the actual coding which is what most development teams want.

    Out of all the frameworks we chose Aurelia for our web site. This decision was based partly on the fact that we like the separation of concerns with code/view/style, in addition during coding for the most part you don’t see much Aurelia specific syntax, but when it is used it always feels very intuitive. The adherence to web standards where possible also means that as the web evolves parts of the framework will possibly disappear but your code will remain largely unchanged.

  • It baffles me how DoneJS (or more generally CanJS) isn’t more popular. It’s been around for a long time. It’s well supported and is used by several big names. Marketing is truly more important than technology.

  • Keep in mind, the point of the series was not to tell you which framework is universally the best or pick a winner, because frankly that answer does not exist as the answer is “it depends”. Instead, we wanted to explain the process we go through in evaluating frameworks with our customers. So really what’s more important I think is the questions rather than the frameworks we chose to compare. If there’s anything I would love to do differently with the series, it would be to find a couple of frameworks with radically different approaches than those we compared, to provide a bit more contrast as some areas really don’t have much variation when compared. We cover this point a bit in the first post in the series, https://www.sitepen.com/blog/2017/06/13/if-we-chose-our-javascript-framework-like-we-chose-our-music/