EcmaScript 2015 / ES6 or how backend developers lost JavaScript...

Feb 28, 2016, 10:22:21 AM

tl;dr; A humble point of view of an average backend/"full stack" developer on JavaScript. How it evolved, how backend devs stayed in JavaScript 2010 and how the gap between jQuery-JS and ES6-JS became an abyss.


Let's wrap up some terms that I'll use further:

  • Backend developer - a person who writes PHP/Ruby/Python/etc. server-side code.
  • Frontend developer - a person who writes complex JS/CSS/HTML.

It is about specialization. Of course all web devs are a little bit "full-stack", but only a super guru are really "full-stack".

Once upon a time...

I remember the times 15 years ago when JS world was a total mess.
For me, as a beginner home-made web developer, it was a black magic.
It was hard.

I was making some PHP sites, generated everything at backend side. Sometime I needed some "bells and whistles". You could copy-paste some "pretty gallery or dropdown menu" from some "JS libs site". And you were lucky if it worked for you. If not - there was literally no way to get "what is happening there" and the JS code was just ugly mess (at least how I saw the situation at that moment).
It was hard.

Year 2006 blown web dev world ... jQuery.
Anyone could make some easy JS trick really easy with jQuery. And more over it had such a cool plugins system. You just add some "pretty gallery plugin" and attach that gallery with simple selector. There were clear "entry points" for customization.
Then AJAX epoch. And again jQuery made it as simple as $.ajax. All that things made JS world easier, simpler to backend developer (actually we were more like full-stack in that time).
It became easy.

But "the world has changed...". SPA and cross-platform JS mobile apps appeared. First it was "ugly-toys", but then it appeared to be serious. jQuery is not enough to make SPA or a big JS app.
Backbone came to the rescue. It was hard to get some things, but it was so "jQueryish". It literally added some app structure, but allowed us to use the same old-known things we had before (that was actually the key to adoption).
It was kinda easy too.

Dark times...

One day it just exploded: Node.js, Phonegap, Konckout, jQuery Mobile (*trollface*), thousands of Backbone-based frameworks, Marionette, Angular...

Some backend devs tried to follow, but honestly - for example it is too hard to follow your PHP news and keep yourself up-to-date with every JS framework. Someone took Node.js and became happy, someone chose Backbone-based things and decided to dive in there.

JS Tools

Quickly things became even worse. Besides frameworks there was another fatal flaw - lack of dynamic require and modularity in JS.

Now developer need to know the difference and choose between npm/bower, AMD/CommonJS, Require.js/Browserify/WebPack, Brunch/Grunt/Gulp. All these tools could be used in different roles and combinations, some of them overlap their responsibilities. I think you are already impressed ? :)

Let's add there some crazy CoffeeScript, that also requires pre-compiltaion and blows non-prepared minds.

Whatever tool you take - you are always behind, always "outdated".

Each new step, new framework or library - tries to solve some complex issue. But the solutions are so complicated by themselves, that it makes situation even worse in total.

So how did Backend developers survived that rush ? The answer is simple - most of them just didn't follow. They were still using old good jQuery, spectated what Frontend devs were doing and thought "ok, that's complex, but if needed I will be able to dive in... it is just JavaScript, a lot of complicated JS, but I know where to start...".

I am not blaming ES6

Personally I consider it is a great step forward and glad to use it. But I consider ES6 kind a milestone in 2 dimensions: JS language by itself (ES6 extend syntax a lot, it could look like completely new lang) and JS eco-system (a lot of very different approaches appears).

To use a ES6 now you need to pre-compile it (using some of those WebPack, Browserify or SystemJS). And in some years all browsers will support all ES6 features without pre-compilation in ES5.

But life of Frontend developer will always stay an endless rush with pre-compilation. Because now we should start considering ES7. That's an endless story.

Diving deeper. More nice words - Angular 2.0, React, Virtual DOM, Flux, Redux, Immutable structures, reducers, Elm (my mind blows here)...

We have forgot about CoffeeScript, thanks to ES6, but born NativeScript - thanks to Angular 2.0 all Frontend developers will need to learn it.

React with Redux - proposed completely non intuitive development model (as for "imperative" developers point of view). You can't just understand "how it works" without tons of manuals.

Modern JS web app written in ES6 plus "strange" HTML/CSS (due to Web Components, custom HTML elements, binding directives etc.) is very different from those "jQueryish" world that all Backend devs know now.

That's why I think somewhere at "ES6" point in time and space we can consider that average Backend dev is unable to dive quickly in modern JS apps world. Due to the set of circumstances - unknown overcomplicated Tools, new Frameworks with unknown data flow and "new" language (ES6 or NativeScript). If previously you could just ignore it and keep making some "dirty fixes on frontend", now it seems almost impossible.

Full-stack is dead ?

I can't say that, but it seems to me barely possible to keep real full-stack knowledge for a Backend dev. You can be in touch with all that stuff, but never on the frontier. And who knows, maybe it is not so bad to have real separation of Web development concerns.

comments powered by Disqus
Kuzminov "iJackUA"
Web Team Lead
at MobiDev (Kharkiv, Ukraine)
Code in Ruby and Elixir, but still love PHP. Explore ES6 and Vue.js. Explore databases, use Ubuntu and MacOS, think about IT people and management


Skaffold tool that facilitates continuous development for Kubernetes-native applications. Continuously deploys to your local or remote Kubernetes cluster.

DoItLive is a tool for live presentations in the terminal. It reads a file of shell commands and replays the commands in a fake terminal session as you type random characters.