What To Expect From JavaScript In 2016 - Frameworks

This is the first part of a 3 part series on what to expect from JavaScript in 2016 taken from our whitepaper, "The Future of JavaScript: 2016 and Beyond". Part 2 covers JavaScript language enhancements and part 3 covers JavaScript in environments beyond the browser. Today's post focuses on the future of JavaScript frameworks.

JavaScript developers stand at the edge of a great divide. On one side are legacy browsers, differing standards, competing module systems and ES5, a language woefully inadequate for building modern applications. On the other side are evergreen standards compliant browsers and ES6, a monumental leap forward that brings JavaScript into the age of legitimate application development languages.

Many developers are already beginning to cross this chasm. The bridge over which they migrate is composed of JavaScript libraries and frameworks.

Libraries and Frameworks

Web developers have long relied on libraries and frameworks to supplement API's and functionality that browsers either don't provide, or don't implement consistently. The rise in popularity of the JavaScript language has resulted in what is sometimes referred to as a "Cambrian Explosion" of JavaScript libraries, frameworks and miscellaneous tools.

There has been some amount of debate surrounding this Cambrian Explosion in JavaScript. Is JavaScript really as popular as it appears to be? It turns out this is rather difficult to measure.

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.

Redmonk, which measures languages relative to one another on GitHub and StackOverflow ranks JavaScript just under Java as of June 2015.

GitHut, a site which ranks over 2 million active repositories on GitHub, ranks JavaScript as the language with the most active repositories and total pushes. Detection for languages in repos is done by the GitHub Linguist library.

It's this last GitHub statistic that pulls the curtain on the state of JavaScript frameworks and libraries. The situation is at critical mass.

Critical Mass

JavaScript developers are deluged with a simply astonishing amount of third party software. Even more interesting is the fact that almost all of these third party libraries are open source. The net result is an environment in which it is extremely difficult for companies to pick a set of JavaScript tools on which to build the digital portion of their business.

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.

Whether or not you find yourself a fan of jQuery, it cannot be denied that jQuery is still the most popular and widely used JavaScript library in the world. At the time of this writing, it is the most starred repository on GitHub.

jQuery is now a decade old. In the last year, it has weathered some rather heavy criticism claiming that jQuery is no longer necessary.

In his recent article, "jQuery's Relevancy: There And Back Again", Cody Lindley, author of "JavaScript Enlightenment", writes that "jQuery is as relevant today as it was when it was first written." Lindley goes on to explain that this is not because developers need jQuery to perform basic DOM manipulation or XHR operations, but because jQuery provides a much cleaner API than native DOM code.

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

jQuery Predictions For 2016

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.

We would be remiss if we started our discussion of popular JavaScript libraries and we didn't open with ReactJS. The hype that React has garnered in just the past 12 months is nothing short of astounding. Add to this the list of big companies that are using React, such as Netflix, and it cannot be denied that React has captured the hearts and minds of many developers.

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."

React Predictions For 2016

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

Developers can expect to see continued controversy around React's model of mixing markup with JavaScript, which will probably reach a peak point during 2016. While some developers like that the logic and markup for a component is all contained in the same place, many have pointed out that it violates separation of concerns, which has long been a fundamental tenet of programming in general.

I see a willingness of many frameworks or libraries to assist developers in abandoning the authoring of SOLID code. Decades of learning should be taken seriously into account when you create a framework. React is again an example of this. We've learned hard lessons about not mixing JavaScript into our HTML. So, why now the eagerness to embrace mixing HTML into our JavaScript?

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.

Angular Predictions For 2016

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.

Rob Eisenberg made internet headlines in April of 2014 when he announced plans to join the Angular core team, with the intention of merging Durandal into Angular 2. He made headlines again in November when he announced that he would be leaving the Angular team to work on a JavaScript framework of his own, called Aurelia.

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.

Aurelia Predications For 2016

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.

Aurelia has aggressive plans to be far more than a single-page app 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." said Eisenberg. This may mean that Aurelia has plans to provide a JavaScript Native approach for mobile apps, similar to NativeScript and React Native.

More large enterprises will adopt Aurelia based on the fact that it is a supported product. So far, larger entities whose core business proposition is not technology have been slow to adopt JavaScript frameworks since they are, for the most part, supported by the community. Aurelia's model of having a core team of developers and offering support will cause many enterprises to choose it in favor of alternatives, specifically for the business partnership that Aurelia offers.

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 Predictions For 2016

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 has long been a staple of the JavaScript framework ecosystem. Grown from the remnants of SproutCore, it is an industry standard framework with many notable implementations. Although popular sites such as Discourse, Groupon, Vine and even the Apple Music desktop application use Ember, it does not get the same amount of attention as frameworks such as React. This may be due in part to its age.

Ember also places a premium on future web standards. It has historically been an early adopter of many of the standards in future versions of JavaScript, such as promises. In addition, one of Ember's creators, Yehuda Katz, is on the TC39 committee, which is responsible for future versions of JavaScript.

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 Predictions For 2016

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.

Meteor is another library that can't really be compared to your standard application frameworks such as Angular, Ember or Aurelia. While the aforementioned all do Universal or Portable JavaScript (server-side rendering), Meteor takes the concept the rest of the way by providing both the server tier and database. It is a true application platform.

Meteor falls into the "Full Stack JavaScript" camp. It uses Node.js on the server-side, along with MongoDB. It uses an in-browser version of Mongo called MiniMongo to allow client-side code direct access to the data store. Developers are then free to choose if they want their code evaluated on the server, or the client.

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 Predictions For 2016

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.

Look for Meteor to make a big announcement in 2016 regarding the mobile web. Currently, mobile support in JavaScript frameworks is not quite what it is on the desktop. The mobile web is still a far cry performance-wise from native apps, and this is a gap that Meteor would like to close.

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.

Web Components

This wouldn't be a proper article without considering the implications on all of these frameworks when it comes to Web Components. Web Components are the technologies that are generally thought of as the emerging standards for creating interface components. However, web components can be used to create any piece of functionality that is possible with JavaScript, HTML and CSS.

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.

Web Components Predictions For 2016

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.

All JavaScript frameworks will begin to swap out their own technology for web component standards as those standards become widely supported.

"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.

Polymer Predictions For 2016

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.

Final Developer Predictions

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.

• Universal/Portable JavaScript will be big in 2016 seeing as how React, Angular 2, Meteor, Ember and Aurelia all support it.
• Developers will be expected to know ES6. Learn it.
• Browser compatibility will largely be a non-issue, based on the fact that fundamental pollyfilling has essentially been mastered.
• JavaScript frameworks will begin to target more than the web. This is already happening with React Native and NativeScript. Expect Ember and Aurelia to get in this game as well.