Node.js was first written in 2009, and has since skyrocketed in popularity. The list of companies using Node.js is enormous, and the recently formed Node.js Foundation includes the likes of IBM, Intel, PayPal, and Microsoft. The Node.js package manager, npm, became the biggest package manager in the software world in 2014, and now contains nearly twice as many modules as similar package managers from the Java and Ruby worlds.
Growth of npm as a package manager. Image from modulecounts.com/.
However, the success of Node.js hasn’t come without growing pains. In late 2014 a group of developers forked the popular framework, citing the lack of active and new contributors and the lack of releases. This new framework, io.js, quickly gained followers and community support, leaving many to fear a long-term fragmentation in the Node.js world. Thankfully those fears were averted when Node.js and io.js merged in June of 2015.
Part of the merger involved the formation of an LTS, or a Long-Term Support plan for Node.js releases. Under the plan, Node.js will designate one release per year an LTS release, and will actively support that release for a full 18 months.
The development cycle is aimed to appease both developers that want to stay on the cutting edge and large companies that need a stable release they can count on for years to come. The development cycle also has major implications for the future of Node.js. When I asked Mikeal Rogers from the Node Foundation what the biggest change coming for Node.js in 2016 he had this to say:
“The new development cycle is going to be the biggest change. We’ll have 2 major releases each year, with only one of those releases receiving Long Term Support. That’s significantly more than before and we’ve never truly had LTS before so this is all a big change for developers and a new opportunity for enterprise to expand adoption as well.” Mikeal Rogers, Node Foundation
In 2016 expect to see further adoption of Node.js and its package manager npm. The continued adoption of Node from large companies — Microsoft, IBM, Intel, Progress Software, etc. — as well as enterprise-friendly features such as long-term support plans, may signal a growth in Node.js adoption in the enterprise, replacing typical enterprise solutions like .NET and Java.
“A few years back I quantified the growth rate of npm and created a predictive graph. At the time people thought it was insane, because it said that in a little over a year we’d have over 100K modules and that the rate of growth wouldn’t level out. We hit 100K modules within a few days of what it predicted which even I was shocked by.
If you dive deep into npm’s growth you’ll see that what is pushing it forward is that npm is an ecosystem of ecosystems. It’s the best place to build sub-platforms for a variety of use cases. Parts of that ecosystem are leveling off but they keep getting replaced by new rapidly growing ecosystems.” Mikeal Rogers, Node Foundation
Over the years Cordova has defended itself against a perception of bad performance, with the most notorious complaint coming from one of technology’s most influential people in 2012.
“When I’m introspective about the last few years I think the biggest mistake that we made, as a company, is betting too much on HTML5 as opposed to native… because it just wasn’t there.” Mark Zuckerberg, Facebook
Since 2012, a number of companies have stepped in to attack this performance problem. This includes performance-minded UI frameworks like Ionic, Onsen, and Kendo UI Mobile, tooling improvements from Telerik and the PhoneGap team, new web views such as those provided by Crosswalk, and high-quality plugins, such as those found in the Telerik Verified Plugins Marketplace.
The Telerik Verified Plugins Marketplace
In addition to company-provided performance aids, new features provided by mobile OS makers, such as Android’s auto-updating web views and iOS’s new WKWebView API, have greatly improved the Cordova performance situation. With that in mind, I asked Brian LeRoux, formerly of Adobe’s PhoneGap team, about what’s next for Cordova.
“Cordova has grown very deliberately stable. We strive to keep things simple, push the features out to the plugins interface, and stay on top of platform upgrades like Android M and iOS 9 as much as possible. It took a few years of thrashing but ‘small modules’ mindset is beginning to take hold which makes me happy. The end dev audience won’t see this unless they extend Cordova with their own distribution.” Brian LeRoux
Although Cordova continues to grow in popularity, its development approach is being challenged from two different angles. The first is from Google, who is pushing the concept of progressive apps, which are true web apps with native-like features such as splash screens, home screen placement, and offline access. Progressive apps are still in their early days, and their features are still only offered on Chrome for Android, however, expect Google to continue pushing the concept of progressive apps in 2016.
I asked Christopher Chedeau (aka Vjeux) from the React Native team and Valio Stoychev, NativeScript’s product manager, about what’s coming for their frameworks in 2016, and both echoed this focus on stability.
“For React Native, we exited the phase where it was a crazy idea/prototype and now enter the phase where we need to make it solid. You should see a lot of work being done on performance tooling/optimizations, improvement of all the core APIs, better error messages, fix edge cases… This way engineers at Facebook and outside can build the high quality mobile apps they want to.” Christopher Chedeau (Vjeux), Facebook
“As our user base rapidly grows, we need to make sure our users have a robust framework they can count on for building real-world applications. Therefore we intend to continue working on things like performance and debug tooling to improve the NativeScript developer experience. Our other major focus is our work with the Angular 2 team, which we anticipate will continue throughout 2016.” Valio Stoychev, Telerik
NW.js was developed at Intel, and released back in 2011
NW.js packages up a web application in a native shell, while providing access to native desktop APIs, such as the file picker, window menus, and so forth. The combination lets you write Windows, OS X, and Linux desktop applications using standards-based web technologies.
Fast forward a few years and NW.js is not the only framework using such an architecture. In April of 2015 GitHub announced Electron, a similar framework for building cross-platform desktop apps.
GitHub’s Electron was released in April 2015
Electron was developed as the shell for Atom, GitHub’s web-based text editor, and has since been decoupled to make it easier to use in any project. With GitHub’s backing, Electron has surged in popularity, and now has over 20,000 stars on GitHub (quickly catching up with NW.js’s 25,000+ stars).
Electron also made headlines in 2015 as the engine behind Microsoft’s new cross-platform Visual Studio Code IDE, and a quick look through a list of community-created Electron resources shows just how popular Electron has become in the development community.
. What happens is that there is a massive waste of effort as each ecosystem have the same tools such as package manager, IDE, core libraries, knowledge base…
To give a concrete example, at Facebook, we need to implement the exact same feature 3 times: for Web, iOS and Android. Even worse, because it’s so hard for one engineer to get ramped up in those ecosystems, we usually have 3 people implementing that feature. This is sad.
With that in mind I’ll let Brendan Eich’s famous quote stand as the last word in this article: “Always bet on JS.”