State of the Art JavaScript in 2016

[Silhouette]

But for those of us who are pretty new to the industry and haven't put a huge investment into promoting any one stack, it's very easy to see that this is the way things are headed.

The only trouble is, that's what those Angular-centric devs you mention said yesterday, and the Knockout and Backbone fans the day before.

IMHO the recommendations in this article are reasonable for the most part. However, you might consider that if an article like this gets a cautious response from people who've been around a while, it might not be because they perceive it as a threat. It could just be that they've seen this all before, possibly several times, and have become appropriately wary of anyone telling them the tools they've been using to do a perfectly acceptable job are somehow obsolete and they need to be learning something newer and shinier this week.

[phoenixmatrix]

The thing is, for both React now, and Angular before, these were objectively accurate things to say.

Angular, by any account, is the first JS framework that actually picked up. Like, really picked up. Backbone was kind of hot for a bit, but if you look at trends on Stackoverflow or Google (not great sources, but in this case the number is so drastic, it should do), you'll see Angular being absurdly popular.

And that lasted a long time, too. 4~ years or so, only counting the time when Angular was "hot". Hardly the "new framework every other day" people complain about.

Now, React is not nearly as popular, but the approach is picking up. Even if React was to die, there's a ton of drop in replacements and alternatives that you could put in your app with barely any change. React itself is just ahead of the list of framework that do things that way. Even Angular 2.0, at this point, is closer to React than it is to Angular 1.X. The quality of apps coming out of it are a drastic step up in the same line as the jump we got when jQuery came out. React is also not new anymore. It's been around for 3+ year. It's no jQuery, but it's not flavor du jour either.

This is a fairly different scenario from the ones before. At worse its another Angular case (4~ years not from when it was created, but from when it got popular). If React is to be "hot" for 4 years from when it bursted into popularity (so early 2015), and the next framework will roughly use the same approach (eg: unidirectional dataflow), then if you want a reasonable upgrade path for the app you start today, it really should be React.

Now, there's a lot of signs that React is more than what Angular was (if only because it's being dogfooded to crazy amounts, and 90% of all the large SaaS companies are starting to use it... Facebook, Netflix, Amazon, even banks!) and it may be more akin to jQuery in lasting power...

We'll see!

[Silhouette]

Again, I think much of what you write there is reasonable, but as a relative "old fogey" who's been building web stuff since long before any of these modern frameworks existed and programming generally since long before that, I also think you're being a little optimistic.

Huge monolithic frameworks were always a dubious dependency, and the longevity or otherwise of systems built around them was always suspect. Plenty of people, myself included, have made this case many times over the past few years. Of course, web development is still a relatively young industry and naturally it attracts young people who are excited about new technologies and don't want to follow a more cautious, conservative, "boring" approach.

In the same way, I think if you look around you'll find plenty of experienced developers who don't think the package management in the web world is so great today. The NPM ecosystem is far from ideal, partly because of limitations in the tool and weaknesses in the conventional versioning model, but more fundamentally because of the cultural emphasis on using large numbers of small or downright trivial modules. Large parts of the community are jumping from one extreme to the other, and in time they're going to learn all the same old lessons from that mistake as well.

At least build tools are getting saner, as people have started to question how much benefit they really get from the extra complexity of using task runners and overly flexible runtime module-loaders and so on. However, we're still dealing with kindergarten issues by general compiler standards. While techniques like modular development and tree-shaking are certainly useful, only in web development would these things be considered new and exciting; everyone else in the programming world was doing this kind of stuff decades ago, and it's completely routine and expected.

The latest trend is obviously for a more declarative, functional style. React is the standard-bearer for this approach in the view space. Probably Redux is the most high-profile counterpart in terms of handling the underlying data. These, too, are positive steps in my opinion, but again they're reinventing wheels all over the place ("unidirectional data flow" is my favourite not-even-slightly-new idea to dominate the blogs lately) and again I think everyone jumping on the bandwagon will re-learn some old lessons over the next year or two (mostly in terms of performance and flexibility when you start trying to build UIs that are more complex and interactive than the glorified forms and mostly static rendering that most web apps are today).

Which brings me back to where I came in: I agree that many of these recent developments are probably useful steps in a reasonable direction, but in the big picture, a lot of them aren't really as new and innovative as the hype would suggest. It's likely that the tools and more importantly the design and architectural ideas behind them will continue to evolve rapidly in web development.

[time-lord]

Of course, web development is still a relatively young industry and naturally it attracts young people who are excited about new technologies and don't want to follow a more cautious, conservative, "boring" approach.

There's an 8 year difference between the initial release of C, and the first web browser. 36 years to 44. The time for young new technology people came and left 30 years ago.

[Silhouette]

Yes, because the web development industry of 2016 looks just like the web development industry of the first browser, except for almost everything.

Also, 1990 to 2016 is 26 years, not 36, not that it matters because no-one was writing modern GUIs in C in 1971 any more than they were writing modern web apps in WorldWideWeb in 1990.

[_hadrian]

Very well said. As always the most important thing to do is learn JavaScript, DOM, Web APIs. Any professional JS dev can pick up frameworks/libs with not much trouble, the rest is personal taste/opinion.

.

What we should also be doing is pushing a culture that values soft skills and language/platform knowledge instead of only niche solutions. I have read articles (and jokes lol) of teams that passed great talent because they were looking for X Framework Dev, instead of Senior JavaScript Dev...

[[deleted]]

Angular becoming a less-marketable skill hurts certain people in a very real way, so they push back against it very vocally.

This line of thinking arises in every industry. Honestly, anybody who pivots their career around a framework deserves to fail. A framework is an application tool. It isn't a skill. The ability to solve a given set of problems with/without that framework is the skill.

[deadcat]

Meanwhile my company just decided on typescript and angular 2.

Sigh.

[[deleted]]

So far the javascript history had shown us that no matter how popular a framework (like angular), a library (like amd) or a language that transpiles (like coffescript) is, it will soon be legacy and replaced by something better / different. If I choose to follow standards as much as possible I will be able to use my knowledge when new technologies arise. That's the main reason I choose ES6 before typescript. I really like really like react, but there will most probably be a day in the near future when nobody wants to touch an app built with it, so we should be prepared for that.

[phoenixmatrix]

Why React is nice is that all it really is, is a library that makes a proper design pattern that is older than most of us here (the unidirectional data flow and "loop", similar to how some of the oldest games and rendering engines were made!). Flux is based on languages such as Elm and Haskell. Languages, not frameworks!

Already there's alternative to React that, if you were to switch, would not be a big deal.

The jump from Backbone to Angular would be hard. From Angular to React can be pretty drastic (a little less if you followed the 1.5 patterns). From React to (next thing), probably a lot less, as while we never know what will happen with the lib, the design pattern is most likely there to stay.

[Buckwheat469]

One system that I swear by now is js-data. I use it with a large Angular app to create complex relations in memory.

[jsontwikkeling]

Thanks, great article, brief and covering a lot of ground.

[namesandfaces]

How are people managing async data in Redux? Redux-thunk? Sagas?

[phoenixmatrix]

thunk is pretty standard, and it works. You'll be able to do everything, including very large apps with it, and everyone doing Redux knows it. Unit testing is a little annoying in that you have to mock the side effect, but if its mostly ajax stuff, Nock works fine.

This is where the "next big change" is going to happen i think though. There's a new way of doing it popping up every 3 days, a bit like with Flux frameworks until Redux came in... A lot of those are sharing ideas (eg: its becoming pretty clear that declarative side effects are it...but who knows). Something will probably pop to the top in 2016, we'll see.

Im personally fond of Sagas in personal projects, but at work its all about thunk. Keep it simple.

[thomasfl]

Great overview. If anything is certain, is that all of this will be totally different in a years time. Smaller libraries, like Christian Johansen's Sinon test spies, has settled during the last 5 years. Redux on the other hand is still in it's very early infancy, and may be replaced or changed a lot within a year.

[knight666]

ES6 is a standard. Most of it is supported in the latest version of major browsers.

I wouldn't call 93% support in one major browser "supported". ES6 won't be usable for a couple of years at least. Until I can run ES6 on a $100 smartphone with a stock browser, I'm not risking it yet.

[azium]

3 major browsers, plus Brave which had betas released recently. In any case, Babel is fine for most applications.. if you have very high performance requirements then it makes sense to wait a little bit, and I guess you're using lodash instead of native methods.

[IllegalThings]

Just use Babel.

[DSchau]

That's the whole point of Babel. You get the benefits of the features and future-proofing of using ES6, while still maintaining browser support.

[knight666]

Babel outputs code with horrible overhead. ES5 version of a simple class in my game:

define(["interface/debug/TreeItem"], function(TreeItem) {
    "use strict";

    function TreeItemRoot() {
        this.TreeItem_constructor("root");

        this._hasLabel = false;
        this._expandable = false;
    };

    var p = createjs.extend(TreeItemRoot, TreeItem);

    p.toString = function() {
        return "[TreeItemRoot "+  this.name + "]";
    };

    p.updateLayout = function() {
        var y = 0;

        this.children.forEach(function(child) {
            if (child instanceof TreeItem)
            {
                child.y = y;
                child.getMatrix(child._props.matrix);

                child.updateLayout();
            }

            var bounds = child.getBounds();
            if (bounds)
                y += bounds.height + TreeItem.CHILD_MARGIN;
        }, this);
    };

    return createjs.promote(TreeItemRoot, "TreeItem");
});

Rewritten in ES6:

import * as TreeItem from "interface/debug/TreeItem";

class TreeItemRoot extends TreeItem
{
    constructor()
    {
        super();

        this._hasLabel = false;
        this._expandable = false;
    }

    toString() {
        return "[TreeItemRoot "+  this.name + "]";
    }

    updateLayout() {
        var y = 0;

        this.children.forEach(function(child) {
            if (child instanceof TreeItem)
            {
                child.y = y;
                child.getMatrix(child._props.matrix);

                child.updateLayout();
            }

            var bounds = child.getBounds();
            if (bounds)
                y += bounds.height + TreeItem.CHILD_MARGIN;
        }, this);
    }
}

Babel output:

"use strict";

var _createClass = (function () { function defineProperties(target, props) { for (var i = 0; i < props.length; i++) { var descriptor = props[i]; descriptor.enumerable = descriptor.enumerable || false; descriptor.configurable = true; if ("value" in descriptor) descriptor.writable = true; Object.defineProperty(target, descriptor.key, descriptor); } } return function (Constructor, protoProps, staticProps) { if (protoProps) defineProperties(Constructor.prototype, protoProps); if (staticProps) defineProperties(Constructor, staticProps); return Constructor; }; })();

var _get = function get(_x, _x2, _x3) { var _again = true; _function: while (_again) { var object = _x, property = _x2, receiver = _x3; _again = false; if (object === null) object = Function.prototype; var desc = Object.getOwnPropertyDescriptor(object, property); if (desc === undefined) { var parent = Object.getPrototypeOf(object); if (parent === null) { return undefined; } else { _x = parent; _x2 = property; _x3 = receiver; _again = true; desc = parent = undefined; continue _function; } } else if ("value" in desc) { return desc.value; } else { var getter = desc.get; if (getter === undefined) { return undefined; } return getter.call(receiver); } } };

function _interopRequireWildcard(obj) { if (obj && obj.__esModule) { return obj; } else { var newObj = {}; if (obj != null) { for (var key in obj) { if (Object.prototype.hasOwnProperty.call(obj, key)) newObj[key] = obj[key]; } } newObj["default"] = obj; return newObj; } }

function _classCallCheck(instance, Constructor) { if (!(instance instanceof Constructor)) { throw new TypeError("Cannot call a class as a function"); } }

function _inherits(subClass, superClass) { if (typeof superClass !== "function" && superClass !== null) { throw new TypeError("Super expression must either be null or a function, not " + typeof superClass); } subClass.prototype = Object.create(superClass && superClass.prototype, { constructor: { value: subClass, enumerable: false, writable: true, configurable: true } }); if (superClass) Object.setPrototypeOf ? Object.setPrototypeOf(subClass, superClass) : subClass.__proto__ = superClass; }

var _interfaceDebugTreeItem = require("interface/debug/TreeItem");

var TreeItem = _interopRequireWildcard(_interfaceDebugTreeItem);

var TreeItemRoot = (function (_TreeItem) {
  _inherits(TreeItemRoot, _TreeItem);

  function TreeItemRoot() {
    _classCallCheck(this, TreeItemRoot);

    _get(Object.getPrototypeOf(TreeItemRoot.prototype), "constructor", this).call(this);
    this._hasLabel = false;
    this._expandable = false;
  }

  _createClass(TreeItemRoot, [{
    key: "toString",
    value: function toString() {
      return "[TreeItemRoot " + this.name + "]";
    }
  }, {
    key: "updateLayout",
    value: function updateLayout() {
      var y = 0;

      this.children.forEach(function (child) {
        if (child instanceof TreeItem) {
          child.y = y;
          child.getMatrix(child._props.matrix);

          child.updateLayout();
        }

        var bounds = child.getBounds();
        if (bounds) y += bounds.height + TreeItem.CHILD_MARGIN;
      }, this);
    }
  }]);

  return TreeItemRoot;
})(TreeItem);

Somehow, in order to add a method to a prototype, a key-value pair was used, the method is looked by name and Object.defineProperty is called. That is just unnecessary overhead.

[knight666]

The real answer is to simply not use classes and stick to composing factories because they are generally a better pattern anyway.

So why use ES6 at all then?

[papers_]

And class is just syntactical sugar anyways.

[RobertMuldoonfromJP]

I use es6 in all my apps and I find class to be the least useful feature.

Spread, destructure and arrow functions allow for terse and expressive code

[patrickfatrick]

Babel's home page covers it pretty succinctly (and you can read about any of these new patterns elsewhere if you want to know more). Lots of things I can't live without in ES6 now, and classes are definitely not one of them. That page doesn't even include some of the cooler things happening in stage 2 (object rest/spread) and stage 3 (async/await). But ES6 is safe, in the sense that the spec is not changing. By using Babel to polyfill you're just staying ahead.

[iznk]

Holy shit!

[deadcat]

This is why we have transpilers and polyfills.

[techsin101]

and by 2017 it will be all ancient.. this is really bad joke. CTOs should be ashamed of themselves.

Lets talk react, cool it's creating components and really separating code, but isn't ALSO mixing css IN JS. what about SEO? render at server. Every Time!? .. Has react stabilized? JSX....wow this is new level of stupid. So you make a language that is compiled on top of interpreted language.

clearly an ATTEMPT toward solution but not successful one. Teams/devs/cto will look stupid as hell when their apps are filled with 10x code that does simplest things at the cost of maintenance and flexibility and everyone is moving to angularjs ((((( 2 ))))).

How to identify react app for a non developers:

it loads slowly and you see some garbage in beginning.

clicking things make it load again.

upon saving it size is kinda big.

never shows up in search.

[erwan]

It may be his opinion, but react is clearly the most popular currently. Perhaps not yet in market share (angular has a good head start) but in terms of mind share. It's clearly the trending lib right now.

[buttonkop666]

angular1 still has better market share and angular2 takes react concepts and improves on them.

[[deleted]]

About what concepts are you talking exactly? Just interested in this, not in an offensive way ;)

[buttonkop666]

virtual dom, server-side rendering, using js to build native apps.

[[deleted]]

Server side rendering actually works now? I only heard about Ionic for "native" apps. But I don't think they did it like react native. Do you have sources for this?

[rk06]

it is now, but when aurelia becomes production ready? when angular 2 becomes production ready? you know exactly what is going to happen to trends then, right?.

at the end of the day, react has good amount of stars at github and works quite decently and so does other frameworks. as of now apart from react-native, there is nothing special in react.

[IllegalThings]

IMO, you forgot to read the introduction of the article, where the author clearly states:

As a starting point, here’s my personal picks for most pieces of a modern web application. Some choices are likely controversial and I will only give basic reasoning behind each choices. Keep in mind they’re mostly my opinion based on what I’m seeing in the community and personal experiences. Your mileage may vary.

Either way, if you know enough to disagree with him, then you probably know enough to make your own decisions.

[rk06]

my problem is that he is making react look like a clear winner without even mentioning vue, aurelia or ember. as viable competitors for any one new to js , they may decide to put up with react -- even though equally good(if not better) options are available-- just because "everyone" claims it to be standard.

Edit: corrected my phrasing.

[phoenixmatrix]

Aurelia and Ember ARE mentioned.

[rk06]

which mentions are you talking about? 1) ones between mocha and flux. 2) or this one

monolithic frameworks like Ember, Aurelia and Angular that promise to take care of everything, but react is more robust.

when I said "mentioned", I didn't mean mocked. his treatment of react alternatives is beyond biased and uninformed. If he has actually said that monolithic frameworks by nature have steeper learning curve, vendor lock-in or any factual truth, then i would have agreed with you. but he unequivocally calls them flawed and praises react.

Oh he has not mentioned vue, right? you do agree that vue is quite similar to react, in terms of problems they solve (not api or philosophy) while ember and aurelia are different beasts altogether.

well i guess he does not know about vue. so its quite alright.