Echo JS 0.11.0

I did a project in ng2 using babel and some of the flow transforms, which worked okay, you definitely need something to handle the decorator syntax as without it, it's *really* not nice to build ng2.  I don't think it was bad, though I did go through growing pains with the router, and even then, it changed again since I had handed off that app around 8 months ago.  Wiring up redux with the router was particularly painful (twice) but syncing the two is really important if you're going to use a redux store at the core of your app state.

From my relatively light exposure, it's really worth digging into Redux for state management, it will make the logic in growing an app much more consistent.  It's not easier than flying by the seat of your pants, but the pain you pay upfront is more than made up for as an app grows.  Beyond this, that workflow can be used with different rendering options from ng2 to react and others...  The ecosystem isn't finished growing and a trend towards web components will probably continue.  Working with unidirectional state management workflows, however is unlikely to go away as it just makes more sense in medium to large complexity apps.  And works well enough in lower to medium complexity.

(my comment, copied from tfa's comments secion)

As much as I like bluebird, there's really no need to polyfill Promises in Node 4+.  Bluebird may well be slightly more well performing in some cases, I don't see that it adds much value, especially since most cases, it will be io bound anyway.  Also, use the mz package and mz/fs for an already async file-system layer.

Also, I'd just assume run my code through babel using one of the modern presets with stage 2 and the decorators transform.  This way I get all the goodies, including async functions with await syntax.  Much cleaner than some of the promise clutter overall.

I agree, tentatively... MY first thought was something decorator based for establishing the class/prototype for validation would be useful.  Though TS specifically wouldn't be necessary, it might be helpful beyond what Babel would offer here, especially wrt child properties as class instances.

Interesting, but a *lot* of boilerplate...  it's worth noting that if you want typescript wit React, you could get even more benefits...

Nice usage of newer APIs to check for the font...

That said, I really appreciate the work that went into react-icons, to take several open icon libraries (including FontAwesome's) and normalize them into SVGs and wrap them in a React library.  This way if you only use 5 icons, you don't load the whole font, and don't have to setup a custom font builder toolchain.

If I get a chance to get my new blog tooling finished... Though, I guess I could write something up on Medium in the interim.

Although it touches on it... it's a bad example... I tend to prefer early return wherever possible, and putting the shortest conditional group higher.  I feel that "else" is usually a code smell.

Likewise, I will sometimes use continue to avoid additional logic vs. a larger nested conditional block.

I find that the flatter the code the better, and that being able to see everything you need to see on screen, where practical is very important... shorter methods, etc.

One more minor disadvantage is that fetch can't make synchronous requests, which means it can't be used to implement, for example SCORM directly on the server... though you could create a caching interface that did use fetch.

LOL at the reference to npm being "oh, like Bower" which is funny because you need node+npm to install Bower... something I always found incredibly amusing.  and the biggest knock against Bower in the first place.

The rest of the rant is a little funny, but seriously... for the use case, jQuery would probably be fine...  I'd probably use babel with the polyfills, and run through that.

No, React is still better...  React + Redux + redux-thunk + fetch (with webpack/babel) is a pretty hard combo to beat.