Web Frameworks: Conclusions

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 framework-less can work, and does, it also comes at a cost. Those who advocate the benefits of framework-less 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:

Going framework-less 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 framework-less. 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 framework-less 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 formal 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 on 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.

Vue.js

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 continue 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 guardrails 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.

Ember

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 a 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 any time 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 are 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 are 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.

Aurelia

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. In many ways it still feels like a work in progress, even though it is 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!