First, it's important to recognize the fundamental way in which the model of open-source has changed.
Angular was the first open-source library to change this model. The Angular project is primarily built and controlled by Google. There is a team of developers, marketers and the like that are paid by Google to work on this project full time.
React became the second entry in this category of “Corporate Open-Source”. Initially created at Facebook, it is heavily promoted and marketed by Facebook who also pays a team of developers to work on React and React based tools and frameworks, such as React Native.
Despite this, both frameworks are truly open-source in the classical sense that they have enormous communities that surround and contribute to their success. The defining difference is that at the end of the day, large corporations pour millions of dollars into these projects and therefore ultimately own and make the decisions on these projects. Why they do it is the source of some debate, but it is always safe to assume that corporations invest in the future of their bottom line. Doing otherwise is counter to the health of the entity.
We opened last year's discussion of frameworks with React, but 2017 likely belongs to Angular, so we'll start there.
Last year we predicted that Angular 2 would be released in the first quarter of 2016.
A release candidate was announced in May at ng-conf, but there ended up being 5 release candidates and each was a large breaking change from the previous, which did continue the instability of Angular through to the middle of September when Angular 2 Final was released.
"What does "final" mean? Stability that's been validated across a wide range of use cases, and a framework that's been optimized for developer productivity, small payload size, and performance. With ahead-of-time compilation and built-in lazy-loading, we've made sure that you can deploy the fastest, smallest applications across the browser, desktop, and mobile environments. This release also represents huge improvements to developer productivity with the Angular CLI and styleguide. "
Jules Kremer – Angular Team
In addition to the core framework, the Angular team also released a command line interface tool to help with controlling the complexity of an Angular applications and scaffolding out commonly used boilerplate.
Given the amount of interest in Angular despite it's rough road to final release and dozens of breaking changes, it's clear that Angular enjoys a level of trust and adoption that virtually guarantee that Angular will be the dominate framework in 2017.
Angular has some concepts that make it remarkably unique, including module theory and it's complete de-coupling from the DOM. This makes frameworks such as NativeScript possible so that developers can build native mobile apps with the same knowledge that they use to build web applications.
The end of 2017 will see 2 major version releases of Angular. However, versioning for Angular is now semantic, so the major version changes will be taken in stride. However, each major version will be an opportunity for the team to introduce necessary breaking changes, but we will not see the API change drastically the way it did between versions 1 and 2.
React was an anomaly in 2015, and that trend continued with force in 2016. React is only a portion of the full front-end framework solution that most developers are looking for, which is the major difference between it and the other frameworks discussed here. That makes it very hard to draw a direct comparison.
In 2016, we predicted that React's popularity would continue to grow, especially with consumer facing applications. This turned out to be extremely accurate. While the enterprise seems to have been slower to adopt React, public facing applications are lining up with big names such as Airbnb, Dropbox, eBay, Expedia, and even internet behemoths such as Netflix.
We predicted that 2016 would be the year of the commercial React ecosystem. This turned out to be incorrect. While the open-source community is quite large, it is still very difficult to find complex, commercial grade React components from well-known vendors.
We predicted that enterprises would continue to watch React from a distance. This turned out to be largely true with the RC and Final releases of Angular completely overshadowing React in the enterprise. This list of companies that use React confirms this assumption.
Considering that React does the few things that it does so well, it's not likely that we will see a new or different version of React in 2017.
Given that Facebook weighed in on the React Starter Kit landscape by releasing the "Create React App" package, it's likely that we may see them release other official React components. It's easy to speculate that the React Router project may be merged into the official React repo at some point.
It's also somewhat likely that React will release its own UI component framework in 2017. This is because Facebook itself has a lot of standard UI and CSS components. Given the recent trend to package and open-source virtually everything they do, I would not be at all surprised to see a Facebook Bootstrap of sorts.
As of the time of this writing, Vue is trending on GitHub with 122 stars just today and over 35K all time. Compare that with Ember which has 17K stars and Angular with 53K. There is no denying that Vue is a contender.
Due to the intentional simplicity of Vue, its grass-roots success and the constant draw of web developers back to the core concepts of the browser, we predict that Vue will unseat React in 2017 as the light-weight front-end framework of choice for consumer facing applications.
That may seem like quite the statement, and is probably the wildest prediction of this article, but Vue contains all the elements of projects past that have taken the web by storm (see Bootstrap, jQuery), and unlike React and Angular, it is not built by a for profit corporation, which is more true to the basic tenants of the open web.
Enterprises will continue to favor Angular due to its strong corporate backing element.
In 2016, we didn't say much about Ember, other than that it was a "sleeper" framework and would continue to be just that. This is largely the case. Ember has a loyal cult following, but it tends to be like a musical act that everyone has heard of, but few people listen to. However, those that do will swear that it's the best band of all time.
We predicted that Ember would be the popular alternative to React for those consumer-facing applications, but it appears that honor has gone to Vue.
We don't have any predictions for Ember in 2017. Much like jQuery and Backbone, this is a framework that is mature and unapologetic in its implementation. The only prediction one could safely make is that none of this will change.
Aurelia made our list last year and we had several predictions for the somewhat niche front-end framework. Aurelia frequently shows up in requests from customers that we talk to. It shows up more often than any other framework in this article aside from Angular.
In 2016 we predicted that developers would adopt Aurelia in droves in 2016. While Aurelia seemed to hang on to its dedicated core, we did not see strong increase in the interest of Aurelia over 2015. The Google search trends show roughly the same sentiment over 2016.
We also predicted that Aurelia might see a native counterpart, such as NativeScript or ReactNative. This also did not turn out to be true, despite Aurelia's explicit goal to be more than just a web framework.
"We've always seen Aurelia as a platform and ecosystem for building rich interactive applications on every device. In 2016, you'll see the next phase of that vision realized as we move beyond Aurelia's v1 release and on to other things we're planning,"
Rob Eisenberg – Creator of Aurelia
Rob Eisenberg recently published an article on the future of Aurelia which makes it much easier for us to speculate on the future. Of note from his article was the intention to create UI components specifically for Aurelia.
While not a front-end framework like the rest of the items in this list, Kendo UI is a bit of an anomaly. It is first and foremost a UI library of widgets and components. However, the version of Kendo UI based on jQuery does contain portions of full stack framework features, such as two-way binding, routing and view management. This qualifies it for inclusion in the article.
In 2016, Kendo UI release Kendo UI For Angular 2 Beta, which was a complete re-write of Kendo UI to use Angular as the underlying framework for DOM manipulation, binding, routing and the like. This allows Kendo UI to leverage all the advantages of Angular, such as…
To be fair, we make Kendo UI so we know a bit about where it's going. To that end, expect a full release of Kendo UI for Angular, which includes all the widgets in the Kendo UI portfolio, by May of 2017.
We will also continue to work on Kendo UI For jQuery in 2017 as we don't see jQuery going anywhere and it's still the most popular way that our customers build their applications.
In addition to the UI framework itself, Kendo UI will release Kendo UI Builder, which is a visual tool for designing user interfaces composed of Kendo UI components. While currently limited to OpenEdge data sources, a mature Kendo UI Builder would connect to any data source to allow easy drag-and-drop composition and configuration of user interfaces with real time visual feedback.
We'd like to close out our section on frameworks by discussing what may be the most important technology that the web community has yet to adopt: Web Components. We've lumped Polymer in here as well because it is Google's polyfill library for Web Components which are largely unusable cross-browser without it.
Unfortunately, React inadvertently put the brakes on Web Components by creating a simple and elegant component model that worked across all browsers without polyfills or hacks. The rapid adoption of React meant that developers' interest in Web Components was negated by their frenzy for React, which offered a similar yet much slimmer solution. It also highlighted that web components in their current state are still not meeting developers where their needs are.
In 2016, we predicted that all major web browsers would support Web Components by 2016. This is simply not the case. The following chart shows the state of browser support for Web Components as of the time of this writing.
Basically, Chrome is still the only browser that fully supports Web Components. Firefox has put HTML imports on hold and Custom Elements and Shadow DOM are still behind flags. Safari has remained annoyingly silent on HTML Imports, but in a surprising pivot decided to ship an implementation of Shadow DOM. While Edge appears to be the holdout, they have announced intent to ship support for HTML Template elements. They have not, however, fully committed to Web Components, citing that they will instead ship support for features as they become stable pieces of the Web Components Standard.
"Following template support, and after completing the DOM rewrite, the next goal is to implement Shadow DOM, the second-hardest feature to polyfill, followed by Custom Elements. We plan to evaluate the rest of the first generation of Web Component specs after that. Naturally, as the specs continue to evolve and additional web component-related technologies rise in importance we may shuffle priorities along the way."
Travis Leithead and Arron Eicholz – Microsoft Edge And Web Components
However, Angular was designed from the beginning to support Web Components. They even ship their own Shadow DOM emulation. In other words, when Web Components are ready, only Angular is specifically designed to use them. This is another reason that we are building many of our own components on Angular’s infrastructure, so that when Web Components are ready, our own leap won't be nearly as far.
Other articles in this series: