Angular may go away, ES6 is here to stay

Recently, frontend developers seem to get exhausted, confronted with a churn of frameworks that come and go at a pace more tearing than ever. AngularJS is written off, React could be the new thing. No, wait! May Riot 2 become the new React-killer? Granted, React and Riot are not frameworks in the sense of “I can do it all” like AngularJS, but they also don’t feel like simple libraries (think for example: jQuery). They require you to learn a custom DSL, do pre-compilation, amass a significant amount of extra knowledge that is hardly usable outside their very own ecosystem and probably obsolete before long.

To be clear: this is how frontend development works. This is our job. It should not be a big issue. If a team decides to go for a certain technology, every member of that team has to learn it, thoroughly. In my opinion, the actual problem lies in how much weight these technologies get assigned to, a few years ago mostly by non-technical people (project management), these days apparently also by developers. More and more, a deep dependency and obedience towards frameworks seem to unfold amongst many web developers. As soon as jQuery ceased to be in vogue, they sought the next one-and-only framework/library to cling to. AngularJS seemed like the solution, the one to stay. But, just as the bulk of developers has put all their eggs in this one basket, it blew up!

For my share, I really hope that the time of chasing after big frameworks is finally over. It’s more important to learn the concepts of browser applications instead of a specific implementation of these concepts. I mean, what is a SPA? All frameworks/libraries try to tackle at least one of the three unchanged major concerns of a typical frontend application:

  • Routing and navigation
  • Server communication
  • DOM manipulation

This is a SPA:

<!DOCTYPE html>

<div id="view"></div>


var pages = {
'/': '<p>Welcome to the home page</p><p><a href="/page2">Go to page 2</a></p>',
'/page2': '<p>You are now on page 2</p>'

function renderCurrentPage() {
document.getElementById('view').innerHTML = pages[location.pathname] || '<p>not found</p>';

document.body.addEventListener('click', function (event) {
if ( === 'A' && RegExp('^' + location.origin))) {
history.pushState(null, null,

window.addEventListener('popstate', renderCurrentPage);



OK, it’s needless to say that one would not use this for production code! Also, for simplicity’s sake I omitted server communication, but it’s sufficient to make my point: this represents the tiny nucleus of a SPA. Of course one would separate intermingled concerns into their own code units and give them an abstract programming interface, broad enough to cover each requirement, small enough to stay as simple as it is. And of course, it would be madness to re-invent the wheel. For each concern there is an armada of libraries out there; libraries that do one thing, and only one thing, but the one thing they do, they do very well. There are excellent libraries that manage routing/dispatching, there are excellent libraries for AJAX, and there are a lot of UI libraries covering all thinkable flavours of working with the DOM. And most of these libraries distinguish themselves from big frameworks in the fact, that they expose a public API that consists of not more than one to three functions! They are easy to learn, and it’s easy to replace them with another one. Naturally, replacing a UI library takes more effort than replacing an AJAX library. But still, they are not a complete buy-in. Also a feature of small libraries: they usually do not come with any magic inside. If you know JavaScript properly, and if you know how browsers work, there should be little to no surprises popping up while using them. Also, they’re usually very fast and come with only a small network payload. Take a look at and discover what is out there!

As a disclaimer: I do not want to promote that it would be a good idea to create patchwork applications out of 20 different libraries. Each external dependency is a burdon on an application, and it should be evaluated thoroughly if it’s worth adding that burdon. Each application has different requirements. Building an enterprise data entry wizard? You probably want routing, data-binding, thorough input validation and powerful REST capabilities, as well as intelligent error handling and logging. Building a multimedia application? You probably care very little about the aforementioned subjects, but you will need libraries that help you tackling audio and video.

But framework X gives applications structure!

Yes and no. My learnings are that this argument is heavily overrated. Have you ever seen a big AngularJS application? You’re on your own giving it good structure. Wouldn’t you always try to give your application good structure? It doesn’t come for free.

But framework X is backed by {{ put your favorite big tech company here }}...

.. and is therefore automatically a good piece of engineering and has a long lifetime and yada yada… Seriously? We should know better.

So, which framework/library should I learn next?

The one that helps you best solving your next problem. But there is a much more important question:

Are you already proficient in ECMAScript 6?

You’ll want to keep yourself hireable for many years to come. The framework du jour probably won’t help you in this matter. If you have not started already, start today! It’s a lot of fun. I have put together a small boilerplate project that you can use to start coding immediately. As always in web development, all you need is a browser and a text editor (OK, and local server)…