IEEE Spectrum ranks Java as the most popular language, with C as a close second. This measure is a combination of GitHub stats, CareerBuilder postings and their own IEEE Xplore library. This measurement appears to be more of a “market value” of language proficiency.
There is also very strong sentiment behind each of the numerous frameworks. The rhetoric around which framework or library is the single “right way” to build applications makes it even more difficult to find the signal in the noise. Furthermore, creators of frameworks and those that adopt those frameworks are hesitant to honestly critique their choice.
I think there’s a huge collective anxiety – a sort of sunk-cost fallacy – at play with web developers. We invest deeply in some tool, and so we’re eager to justify, to ourselves and others, why the decision to use one tool over was rational. I think this makes it hard to have a good dialog about how tools compare.
Brian Ford – Angular Team
For this article, we asked several key developers in the community to help us gauge the future of some of the most popular third party libraries and frameworks available. Some of these developers are the very authors of these frameworks, and some are implementers with a lot of experience on real world projects.
jQuery is now a decade old. In the last year, it has weathered some rather heavy criticism claiming that jQuery is no longer necessary.
jQuery is simply a helpful library that you can optionally use when scripting HTML elements. And the fact is, most developers choose to use it when scripting the DOM because the API helps them get more things done with less code.
Cody Lindley: jQuery’s Relevancy – There and Back Again
The BuiltWith site shows a steadily growing usage of jQuery. There is no indication that the use of jQuery is in decline. There is one jump in the top 1 million sites during the month of October, but the overall picture is of a steady rise. Over 70% of the top 10K sites still use jQuery.
By all indications, jQuery usage will continue to rise during 2016. Evidence to suggest otherwise is anecdotal at best.
The level of hype around jQuery will continue to die, but the actual utility of the library will remain intact. Even newer frameworks and libraries offer some level of DOM abstraction. For instance, Angular 1.x uses jqLite, which is essentially the DOM selection and manipulation subset of jQuery. The API is almost identical to the actual jQuery library.
ReactJS is a far simpler library than its larger brothers and sisters such as Angular or Ember. However, it also does far less.
React is meant to be the just the V in any MV* implementation. That means that React is primarily concerned with how visual components are built and rendered, and doesn’t deal with the flow of data or the actual physical structure of the application. In order to achieve that, a full framework such as Flux or Redux must be added to the React equation.
The main features of React are the virtual DOM, and the way that it treats every UI component as just that – a component. However, the appeal to developers is the number of large, high load applications that are already running on React. These would be applications like Facebook and Instagram. The appeal then becomes, “If it’s good enough for Facebook, it should be good enough for my project too.”
Expect the adoption of React to remain strong among large consumer applications. As developer Elijah Manor pointed out, React was picked for the Dave Ramsey Every Dollar project based on its existing use in large, well known applications.
One compelling reason, and the reason we started using [React], is that we were launching a new product called EveryDollar. We were expecting a lot of load initially […]. We wanted something that would scale well. React was really new, but it came out by Facebook and Instagram, and obviously those are two applications that scale really well.
Elijah Manor – Polymorphic Podcast
Rob Eisenberg – Creator of Aurelia
2016 will also be the year of commercial React components. While the React ecosystem is quite large, it is fragmented and is quickly going the way of jQuery plugins. Developers will begin to look for comprehensive solutions backed by a partner.
Enterprises will continue to watch React from a distance in 2016. The fact that React is such a small part of the overall application solution leaves developers to stitch together data access, routing and all of the other components needed for a full application stack. This will keep larger more conservative shops from adopting React, in light of the lack of a complete story out of the box.
Developers should make it a point to learn React in 2016. It’s likely that the component model React has introduced will begin to bleed into other libraries and frameworks.
Note: The React team did not return a request for input on this article.
The rapid rise of Angular during 2014 was remarkable to watch because it was one of the rare times that the enterprise sector has so completely adopted an open source library. Angular seemed to answer so many outstanding questions for developers coming from more structured languages, such as Java or C#.
Angular has received some amount of criticism for its documentation and performance. Some feel that Angular is over-engineered and too complicated when compared with other frameworks. However, that has not stopped its adoption and legions of adoring fans.
The Angular ecosystem also grew drastically. Currently, there are 132,639 questions on StackOverflow that are tagged with Angular. Compare that with 6,969 for ReactJS, and 19,031 for Backbone. There are several commercial UI libraries for Angular, including Kendo UI from Telerik.
With the recent announcement the Angular 2 beta release, developers can safely expect to see the full release of Angular 2 in the first quarter of 2016. Brian Ford from the Angular team explained the intentions behind Angular 2, and what was accomplished in 2015.
Our main motivation for Angular 2 is to do the things in Angular 1 that were impossible without significant breaking changes in Angular 1 apps. Mostly, we wanted to improve speed and robustness. We spent most of 2015 getting the core concepts in Angular 2 right. We took everything we learned from Angular 1, and from other open source projects in the same space (React, Ember, etc.). We’re using a benchmark-driven approach. We’re already as much as 10x faster than AngularJS 1, and we’re only improving.
Brian Ford – Angular Team
The Angular documentation and tooling will also improve significantly in 2015. The Angular team will spend a non-trivial amount of time on helping developers migrate from Angular 1 to Angular 2. “If you try to get started with Angular 2, you’ll probably notice it has a lot of rough edges. We’re working hard to make the experience as productive and enjoyable as possible.” says Ford, “a huge part of that [improving tooling, documentation and ecosystem] is going to be making migration a good experience, which will involve writing guides, building tools, and making improvements to AngularJS 1.x to support migration.”
It’s unlikely that swaths developers will abandon Angular 1 for 2 in 2016, even if a smooth migration path is forged. Angular 1 will have a long tail, especially in the enterprise, where we will likely continue to see Angular 1 continue to thrive in 2016.
Special thanks to Brian Ford from the Angular team for his input on this article.
Aurelia tries to embrace existing/emerging standards to provide a full application framework. It relies heavily on ES6, a standards-based module loader and a component model that is compatible with the web components standard.
Rather than invent non-standard tech, or even buck against the web itself like some libraries do, we’ve chosen to embrace the web platform itself and to help developers use it to build future-compatible apps.
Rob Eisenberg – Creator of Aurelia
The most interesting thing about Aurelia, is that it’s possible to build applications using mainly ES6 classes, and not referencing the Aurelia framework at all. This goes a long way to make sure that applications are “future proof”. When the next emerging standard arrives, or a different framework is used in the future, code written in Aurelia can be directly ported since it is primarily just ES6 classes.
Developers will begin to adopt ES6 in droves starting in 2016. This will cause Aurelia to gain significant momentum, specifically in the .NET community and developers who are familiar with Eisenberg’s previous work, such as Caliburn.Micro.
Special thanks to Rob Eisenberg from the Aurelia team for his input on this article.
Kendo UI was launched in November of 2011, strictly as a set of jQuery based user interface components. At the time, developers were struggling with drastically different browser versions and feature support, as well as a wilderness of jQuery plugins that made it hard to assemble a cohesive application. Kendo UI was built on the premise that a developer could leverage a single set of UI components that would be guaranteed to work across all browsers, all the way back to IE 7.
While Kendo UI started as a UI library, it grew to include binding, routing, views, models and everything else developers needed for a full application solution. Despite offering those capabilities, developers continued to gravitate towards community standard frameworks, such as Angular, Ember and Durandal. However, they still wanted to the robust widgets that Kendo UI offered.
Today Kendo UI is the largest open source jQuery-based UI library available. It is also a very successful commercial library, specifically in the areas of data grids, schedulers, data visualization and document processing.
Kendo UI will begin to decouple itself from its own binding framework in 2016 to provide better integration with Angular, React, Ember, Aurelia and any other framework that developers prefer to use. Kendo UI will focus on being a set of UI components, and offer abstractions for the various larger frameworks so that it can be plugged in anywhere.
There are too many frameworks and not enough libraries. We need reusable, functional blocks that play well together.
Tsvetomir Tsonev – Kendo UI Team Lead
Kendo UI will continue to invest heavily into complex UI widgets, such as the Grid, PivotGrid, and Spreadsheets widgets. This will entail adding new features and continuing to refine these components. Also look for Kendo UI to ship additional widgets, such as an Interactive Timeline.
Kendo UI will also deliver more sample applications for other noteable frameworks, such as Angular, Angular 2 and React.
Special thanks to Tsvetomir Tsonev from the Kendo UI team for his input on this article.
Ember also tries to help developers write better code. This is done via the use of a rigid and opinionated framework which seeks to guide developers into best practices, so that they fall into the “pit of success”.
Ember will continue to be a “sleeper” framework. While it won’t be getting near as much air time as its React and Angular peers, it will be the choice for many large applications that need to service users at a massive scale. Look for other large sites to choose Ember for their next releases.
Ember will serve as the diametric comparison for React in terms of separating logic from markup. More and more developers will begin to draw this comparison in their own minds before deciding if they want to blend all of their component logic together as React prescribes, or separate it out as much as possible the way Ember dictates.
Note: The Ember team did not respond to a request for input on this article.
The ecosystem around Meteor is currently centered around a Meteor proprietary package management system called, Atmosphere. Developers can add the necessary meta data to their libraries so that they are compatible with the Atmosphere format. These libraries can then be pulled into any project with a simple command.
Meteor will begin to announce large scale applications that currently use Meteor. This will be the first time that many developers are aware of Meteor as they learn of some very high profile sites that are built on the technology.
Meteor will offer a free tier on its hosting platform called Galaxy. Right now the cheapest package for Galaxy subscribers is a non-trivial $495 per month.
I believe that the biggest [gaps in existing frameworks] is true mobile support. We are still not there. There are many paths for [closing that gap] but it is still not a better experience than native apps
Uri Goldshtein – Meteor Team
Special thanks to Uri Goldsein from the Meteor team for his input on this article.
In his article, “Why Web Components Aren’t Ready For Production…Yet“, TJ VanToll describes several of the major drawbacks to web components that have so far kept them from being adopted by developers. The main hang-up so far has been browser support.
The obvious reason to avoid web components is browser support. Although web components landed in Chrome 36, they only have partial support in Firefox, and they are not present in Safari or IE. Because cross-browser support won’t be possible for a very long time, if it happens at all, a polyfill is a long-term necessity for developers that want to use web components outside of Chrome.
TJ VanToll – Why Web Components Aren’t Ready For Production…Yet
At one point, despite agreement from both Microsoft and Mozilla, Apple removed Shadow DOM from Safari altogether. Unfortunately, since users have no choice of browsers on iOS, Mobile Safari currently holds the rest of the web hostage. If a technology is not supported in Mobile Safari, it’s likely that it will not be used by developers, especially if it’s as hard to pollyfil as web components are.
All major browsers will support web components by the second half of 2016. This prediction is based on the recent addition of Shadow DOM to WebKit.
“Web components” is an umbrella term for a bunch of upcoming APIs, and there’s more than one way to break apart your app into smaller parts. The general idea is for Angular to pragmatically adopt new browser features as they become more available.
Brian Ford – Angular Team
The Polymer project from Google is often mistaken for, and used interchangeably with web components. Polymer is an application framework that is built on the concept of web components, and attempts to pollyfill certain web components APIs (such as Shadow DOM) for browsers where those APIs don’t exist.
Despite Google throwing what appears to be the entirety of their influence into the web components arena, Polymer has not yet garnered mainstream support. This is most likely due to the same browser compatibility issues that web components suffer from.
Google has created an impressive list of components for Polymer that encompass UI, animation and even seamless integration with Google’s own APIs. Developers looking to adopt Polymer will find virtually everything they need for their applications, especially if they are interested in doing Material Design.
At the 2015 Chrome Dev Summit, Google announced that there are now 1 million sites running on Polymer. These include some big name companies, such as GE. It also includes many of Google’s own internal properties, such as Google Play Music.
Expect to see Google transition the majority of its applications over to Polymer in 2016. Google obviously sees web components as a strategic advantage. Given that it has little developer adoption, it is clear that Google will continue to push web components and Polymer by adopting it internally.
Google will release application framework, routing and internationalization components for Polymer in 2016. These are already on the roadmap.
Web Components will begin to take hold in the development community during the second half of 2016. This will cause an identity crisis for web developers who have been coding to frameworks for so long.
Expect to see the first batch of commercial web components by the later months in 2016.
Note: The Polymer team did not respond to a request for input on this article.
Lastly, here are some generic predictions for developers that I gathered based on my own research and conversations with those who provided input for this article.