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 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 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/

  • Michael Marks

    probably because its not well advertised. Well versed on the the present state of options and had never heard of donejs

  • BeatPoet67

    Nice article. Thanks.

  • S. B.

    “Vue.js is dependent on a single individual”

    People keep repeating that, but it is no longer true. Evan You himself said something along the lines that repeating this is disrespectful towards the Vue community in general. Well, I would not go *that* far, but I have to agree that Vue has passed the point where it really needs its creator. Even if he decides to leave the project, the community will keep Vue alive and in great shape.

    About the differences of the frameworks mentioned above. At our company we use both Vue and Angular. Angular is great for SPAs, I really like it, but I would never attempt to configure an Angular project without its CLI. Setting up a custom Vue build (in our case a build for a Symfony project where Vue components are just sprinkled in in some views) is okay-ish, even if Webpack is alien to you. That alone makes Vue valuable, if you ask me.

    Overall this was a great article, I enjoyed it. Thanks for the write-up :)

  • Avichay Eyal

    I think that there is a major missing piece in that article: how much will it cost me to migrate away from my choice when the next big thing comes? As of the current era every year trends change. Porting between frameworks costs a lot of money.
    I would add, then, the question: how closed world does the framework will enforce on my dev team?

  • It’s admittedly a difficult question to answer, though part 4 of the series, https://www.sitepen.com/blog/2017/07/06/web-frameworksfoundational-technologies/ , attempts to answer it in some ways by focusing on how aligned each framework reviewed is with various standards. The idea being if a framework aligns with standards wherever possible, then it should be easier to move away. Obviously standards are not the end all answer to the question, but one significant aspect of trying to answer such a question. The challenging part of trying to answer that question depends on how different the chosen framework is compared to what you move to next. Part 9, https://www.sitepen.com/blog/2017/10/03/web-frameworks-soundness/ , also touches on some of the relevant points that might answer this question as well.

  • herman willems

    Correct because today the VDOM is already oldfasioned. These days you have much faster render engines that dont use VDOM overhead and size and less memory. Like HyperHTML and Lit-HTML. These libraries everything is better than VDOM especially it shows fast and many SVG DOM updates which where not possible before.

    Feels also much more native to me. It works great together with native web components as a component system.

    So yes the future is more native because native is also evolving and learning from usecases.

    Soon: Bye bye slow VDOM(which was concidered to be fast lol)

  • Orvisky.sk

    From topic “Angular 2+”, why do you think this? “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.”. Do you have study on all “big” web applications and you have proof that no-one use Angular? Do you know that big part of Google Cloud Platform (and many other things) run on Angular ? I think you can’t say that these are focus on creating user interfaces. Common. Your opinion is strictly subjective from my perspective.

  • We do cover what leads up this to conclusion over the first ten parts of the series in case you missed it. Every perspective is somewhat subjective, but it’s also based on our experience in using a variety of frameworks on a wide variety of projects. I’ll let Kitson explain in more detail when he gets a chance.

  • Kitson P. Kelly

    All opinions are subjective. The intent of the series is to offer up some insight which the reader can take or leave.

    Angular 2+, by its own documentation (https://angular.io/guide/architecture), indicates that higher order application concerns are left to the user. Specifically I quote:

    > There is nothing specifically Angular about services. Angular has no definition of a service. There is no service base class, and no place to register a service.

    So by its own documentation, it does not address the larger concerns of building a web application. Its primary focus is a framework for authoring user interface components and bring those into a single page application. Someone looking to Angular 2+ to provide a structure or guidance of managing application state, interacting with back end services, etc. will have to bring those opinions themselves. That does not mean you cannot build complex web applications with Angular, just as much as you can build complex web applications with Vanilla JavaScript. That does not mean that that is their main focus.

    We tried our best to provide information from several different aspects throughout the whole series leveraging the information available from the frameworks themselves. We then tried to boil that down into several different areas and aspects which we covered in depth and summarised in this article. I am sorry you don’t agree with our conclusions, but of course you have every right to your opinion as well.

  • Kitson P. Kelly

    For the record, I didn’t come to those conclusions by repeating anything said by others. I came to those conclusions by looking at the commit history of the project at GitHub. While there are over 160 contributors to https://github.com/vuejs/vue/graphs/contributors, Evan accounts for 1,928 commits, 384,187 additions and 230,933 deletions. The next largest contributor has 37 commits, 1,939 commits and 344 deletions. Looking at the most recent commit history (https://github.com/vuejs/vue/commits/dev) only leads one to understand that. If Even were to leave the project, those are very large shoes to fill, and therefore I still think it is a legitimate consideration, not one I picked up from someone else.

  • nic

    “While there are not any out of the box Vue UX frameworks”
    I think you might wanna have a look at Vuetify and maybe reconsider that.

  • We do mention Vuetify and others in an earlier part of the series: https://www.sitepen.com/blog/2017/06/16/web-frameworks-user-interface-development/ . Out of the box means those officially provided by the project itself, rather than third-party options.

  • Mikhail Osher

    Neither React nor Redux can not be used in “web framework” context. They are simple libraries.

  • ninjin0

    Hello, why you allude Aurelia but say no word about $mol?

  • This 11-part look at frameworks is nearly 200 pages in length, and that is just by looking at six frameworks. The point of the series is how to make a more informed decision around choosing a framework, rather than just picking a winner based on a few criteria. Please take a look at part 1, https://www.sitepen.com/blog/2017/06/13/if-we-chose-our-javascript-framework-like-we-chose-our-music/ , if you haven’t already to see our introduction.

  • georgecombey

    Each framework has their own pros & cons. It sometimes depends on the skill level of the developers utilizing them.

  • Absolutely. We cover that a bit in https://www.sitepen.com/blog/2017/08/23/web-frameworks-using-and-developing/ (an earlier part of the series). In general, when choosing a framework now or in the future, looking at how well a framework aligns with your strengths and weaknesses is a key consideration. Ultimately you and your team need to successfully building applications with that framework.

  • Earlier parts of the series go into this in more detail, in that it is React, Redux, plus a number of other packages that together constitute a framework. Remember that a framework is fundamentally a way to encapsulate architectural consistency and best practices, so by that definition they constitute a framework, albeit a smaller one. Ignoring React and Redux in this context by saying they are not a framework would be shortsighted on our part given their widespread usage today as part of an approach for providing an architectural foundation for building web apps.

  • Julien Girault

    Skeptical… I wouldn’t come to a conclusion so fast. You’re missing specific attention to learning curve, performance, popularity, growth, developer experience, and ability to opt out of the freaking framework without shutting the business down.

  • This post was the final part of an 11 part series looking at frameworks in more depth. Most if not all of these points are covered in more depth in the earlier parts of the series:

    * Learning curve is covered throughout the series, but in https://www.sitepen.com/blog/2017/08/23/web-frameworks-using-and-developing/ and https://www.sitepen.com/blog/2017/10/31/web-frameworks-community/

    * Performance is honestly pretty comparable now for most typical performance metrics, so there’s not much of a differentiation until you look at specific types of apps

    * Popularity and growth is covered in our look at community under https://www.sitepen.com/blog/2017/10/31/web-frameworks-community/

    * Developer experience is covered in https://www.sitepen.com/blog/2017/10/03/web-frameworks-soundness/ , https://www.sitepen.com/blog/2017/08/10/web-frameworkscommon-usage/ and in other parts throughout the series

    * Opting out is covered somewhat in https://www.sitepen.com/blog/2017/07/06/web-frameworksfoundational-technologies/ , where we look at alignment with standards.

  • fag got

    My customer forced me to use dojo1 which is complete cancer :(

  • Julien Girault

    Thanks for replying.

    I think there’s more to say about opting-out of a framework in real life situations. I’d love to see a section talking about: “if for X reasons I have to rewrite the app with the newest better framework, how much of a struggle will it be?”

    Same for performance. I think saying performance is comparable nowadays is too narrow. Sure, benchmarks will show comparable ms. In many real life situations, performance often involves setting up SSR, and JS frameworks are not equal in that space. I’ve seen engineers choosing a cool framework, implementing a SPA, realizing initial payload and performance is terrible with slow network, and not being able to implement SSR with their stack.

    Thanks for doing these series. There’s a lot of good content and it can help people making a decision for their project. I’m curious to see what you will think of these frameworks (and conclusions) 3 years from now :)

  • Thanks for the follow-up!

    Indeed, one of the key points of the series was to ask and then answer a lot of questions, with the idea being that you should focus on the facets that matter most to you and your team and projects, and knowing that the questions and answers will change over time. Rather than the more common “Hey, I spent one day looking at two popular frameworks, and I like A better than B because of one reason that doesn’t really matter.” ;) It’s one of the main reasons that we did not declare a winner.

    I’m hoping to turn this series into something we’ll update over time, but we’ll see, it ended up taking quite a lot of time to write and edit.

    The challenge with opting-out is not having a crystal ball into what you are opting out to, but I think it’s safe to say that of the six in this series, React, Dojo 2, and Vue are probably easier to move away from, if only because they are less full featured and encompassing (purposefully). Because they don’t force you fully into a framework, they’re easier to leave, and often encourage such patterns.

    We did look briefly at SSR in the analysis, but in our experience, any of these frameworks (and many others) can result in apps that perform at a large scale, and also can perform quite poorly, and much of that depends on an engineer knowing how to write performant code, more than the framework itself. We’ve had countless projects over the years to help a team improve the performance of their applications. In many ways it has gotten easier as tools, browsers, and best practices have all improved in general, but there are still far too many easy ways to ruin performance, and frameworks cannot really save you from that. But you’re right in that some frameworks are better than others in helping with alternative workarounds like SSR.