JavaScript
Article

JavaScript: 2016 in Review

By Craig Buckler

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!

  • gskema

    JavaScript 2016: Fast and Furious Deprecated? :D

  • Andres Vaquero

    Nice article, I’m out of frameworks altogether and build my own instead. I think the moment I started getting real value out of JavaScript is when I went through all the code I had written and removed jQuery / (other frameworks) from the equation. I instantly noticed how much cleaner and organised my code looked, but also how much I was abusing frameworks and technical debt for no compelling reason.

    • Craig Buckler

      I agree. I don’t use frameworks for ‘real’ work. They can help if you’re new to JavaScript or want to follow a working methodology – but be aware they’re an abstraction. You can run into problems when you need something which doesn’t quite fit … which, inevitably, is every project.

      Finally, it doesn’t matter what framework you use: it will be superseded by something better and support will disappear. That may affect your decisions for large-scale or long-term projects.

  • http://www.pvgr.eu/en/ Panayiotis “PVgr” Velisarakos

    Reasonable and unbiased as always Craig Buckler. “Don’t try to keep up” is the best advice one can give, to keep a fellow JavaScripter sane and healthy!

  • Sadha Moodley

    Very interesting read, thanks.

  • http://vitomd.com/blog vitomd

    What do you think is the best way to introduce new people to javascript? ES6 or ES5 ? ES6 has more features but could be a little difficult to setup for a beginner.

    • Andres Vaquero

      you can do anything with ES5 and no other library, less technical debt and more widespread support. Until ES6 is mature enough so that you don’t have to pull the whole world in to make it work I’d stick to ES5

    • Craig Buckler

      If you’re using Node 6+, then ES6 is fine. For browsers, I’d stick to ES5 for the moment.

      I suspect some ES6 concepts could be a little tricker to grasp. For example, would it be obvious that the => arrow is shorthand for `function`? Beginners would possibly appreciate writing it in full.

Recommended
Sponsors
Get the latest in JavaScript, once a week, for free.