JavaScript: 2016 in Review

Craig Buckler
Share

JavaScript in review, 2016

This article was peer reviewed by Joan Yin, Scott Molinari and Julian Motz. Thanks to all of SitePoint’s peer reviewers for making SitePoint content the best it can be!

2016 has been a monumental, bizarre, and somewhat jubilant/terrifying year depending on your outlook. To concentrate on JavaScript alone may seem inconsequential compared to other events, but it’s a huge part of every web developer’s working life.

JavaScript popularity continues to explode. Not everyone loves the language, but you rarely hear the derisive comments of a decade ago. Personally, I’ve always loved JavaScript — even in the early, frustrating years. Those approaching it from a C++, Java or PHP direction can be confused at first: JavaScript looks familiar, but isn’t. Overcome your presumptions and you’ll appreciate its simple elegance, practicality and flexibility. (That said, date handling is still a nightmare!)

JavaScript celebrated its 21st birthday in May, so let’s look back at its first year of adult maturity …

ECMAScript Evolution

ES6/2015 was the most significant update to the language since its birth. The specification took seven years to complete, but browsers and runtimes are finally starting to support arrow functions, let, const, proxies and more delights. The ES6 compatibility table is turning a glorious shade of green.

Perhaps it’s a little early to fully switch to ES6 if you’re supporting older browsers. By older, I mean anything released more than a year ago. You can use an ES6-to-ES5 compiler such as Babel, but development is complicated enough without introducing an additional build step.

ES7/2016 is more evolution than revolution. One exciting new feature is async, which allows asynchronous code to be written in a synchronous manner without the syntactical complexities of callbacks or Promises (which continue to confuse me).

Progressive Web Apps

My favorite JavaScript-based technology of 2016 is awarded to Progressive Web Apps. PWAs were announced in Google’s 2015 Chrome Dev Summit, but stable technologies and tools finally arrived in Chrome 52 in July. PWAs permit offline-first functionality and supersede flaky AppCache methods. Web apps can finally compete with native apps and offer the benefits of:

  • a home screen icon
  • fast launching and custom splash screens
  • snappy execution
  • offline functionality without an internet connection
  • URLs, linking and bookmarking
  • full-screen or themed interfaces
  • sandboxed execution
  • local and/or cloud-based storage with synchronization
  • fewer device space and processing resources
  • better security (HTTPS is a prerequisite)
  • easy discovery from any search engine
  • try before you install
  • simpler deployment: it’s just a web app
  • no AppStore nonsense: your app can contain whatever nudity and swearing you desire without someone demanding 30% of your profits!

Best of all: any website or application can be transformed into a PWA within a few hours. The steps:

  1. Enable HTTPS on your server.
  2. Create an application manifest — a JSON file in your application root which defines the name, colors, icons and display options.
  3. Create a Service Worker — a JavaScript file in your root which intercepts network calls and can return cached or live data as necessary.

It’s early days, and examples are rare, but PWAs offer an amazing opportunity to “mobilify” your web applications. Admittedly, there’s no guarantee Apple will implement the technology, but it shouldn’t matter: your app will still work in Safari, it just won’t benefit from offline execution. I have a feeling Apple will be encouraged to support PWAs once the web experiences becomes noticeably superior on Android.

For more information, see Dev.Opera’s Progressive Web Apps: The definitive collection of resources and Google’s PWA Guides.

Framework Fixation

It’s difficult to make an unbiased judgement, but React seems to have received the most attention this year. You may disagree; it depends on what you’re using, where you’ve been browsing and who you’ve spoken with!

Vue.js has increased in popularity, and version 2.0 was released in September.

AngularJS has possibly lost some of the momentum it gained in 2015, but that could change following the release of Angular 2 in September. The new version is a complete rewrite; it’s not backward-compatible with v1.0.

New frameworks and libraries are exciting, but the decade-old jQuery is still going strong. Version 3.0 was released on June 9 and v3.1 subsequently appeared on July 7. The library now runs in strict mode, supports Promises, and has various fixes applied. (View the upgrade guide for the full list of changes.)

jQuery is adopted on 96.4% of websites that use JavaScript. Compare that to Angular — the most-used modern framework — with a 0.5% share. jQuery 1.x is the most popular version, accounting for 93.5% of installations. Version 2.x follows with 6.0% and version 3.x with 0.5%.

I’ve been critical of developers using jQuery by default for every project. It can be over-used when a more appropriate option or a little vanilla JavaScript would suffice. However, it offers a shallower learning curve and is more flexible than most. It will take many years for another framework or library to unseat jQuery.

API Abuse

Ahh, the Battery Status API. It seemed so useful when I wrote about it in 2013; what could be better than responsibly minimizing network requests and processing when your app detects the user’s phone is about to die?

Unfortunately, Mozilla estimates around 6% of sites use the API, but the majority was advertisers detecting the (fairly) unique battery status and tracking users as they navigate different domains. There was also the possibility of certain services raising prices when they knew a user was more desperate …

While this is not a JavaScript or API issue per se, Mozilla has taken the unprecedented step of removing the Battery Status API from Firefox 53 for privacy reasons. It’s unlikely to appear in iOS devices; and other APIs at risk for similar reasons include the Proximity Sensor and Bluetooth. That’s a shame: these APIs have practical benefits, and I hope privacy issues can be addressed in future editions.

New Nodes

The twice-yearly Node.js schedule gave us version 6.0 in April and version 7.0 in October.

The platform is on an upward trend, although W3Techs report Node.js server usage of just 0.2% compared to 82.3% for PHP. The figures may be slightly misleading, since Node.js does not necessarily identify itself even when it’s installed.

No server-side runtime is likely to catch PHP: it’s had a long head start, and remains the most practical option for hosts to offer. However, Node.js is carving its own path, and is widely used by developers of all language faiths.

The Yarn of Yarn

I like npm, and consider it one of the primary reasons for the explosion of Node.js tools. I’ve never experienced too many problems, but I’m not working on projects as sizable as Facebook.

Facebook’s engineers released Yarn in October. It’s a new Node.js package manager designed to be faster and more stable than npm. It relies on the npm registry, so should remain fully-compatible.

Tim Severien’s Yarn vs npm: Everything You Need to Know describes the benefits Yarn offers. I agree with his conclusion:

Although Yarn isn’t a fork, it improves several flaws npm has. Wouldn’t it be cool if npm learned from this and asked Facebook, Google and the other Yarn contributors to help improve npm instead?

Tired of Fatigue

The I-can’t-take-this-any-more article of 2016 goes to Jose Aguinaga’s How it Feels to Learn JavaScript in 2016. The runner up: dayssincelastjavascriptframework.com.

These may be humorous takes on the current state of JavaScript, but it’s increasingly difficult to keep pace with the latest trends, frameworks and recommendations. Developers struggle when faced with a plethora of options to evaluate.

My advice: don’t try to keep up. It’s impossible. Whatever system you bet on today will be superseded by something better tomorrow. Pick an option for your project and stick with it unless work becomes untenable.

There’s only one absolute certainty: JavaScript itself. Learn the language first and keep building on your knowledge. Your experience will help you understand how each framework operates so you can make an informed choice. That choice may be to forego frameworks altogether.

Happy New Year!