Echo JS 0.11.0

Mistake towards the top, in the second code segment...

    someModule(param, (result, error) => {

should be

    someModule(param, (error, result) => {

Node-style CJS async methods should *always* have error first in the response... those few API interfaces that don't cause issues with other libraries.

One point of contention in these articles... TypeScript is not an advantage or disadvantage... you can use it with React too if you really want to.

I'll often use both, but not in the same places... async functions when called return a promise... you can await anything that returns a promise.

I'll often refactor some pieces that make sense as functions that return a straight promise (especially if using callback code.

    const foo = () => new Promise((res,rej) => {
      someCbFunction((err, result) => err ? rej(err) : res(result);
    });

There are times it's just easier to think imperatively... A great example is a promise that will retry N times on rejection before raising the rejection... try this with promises alone and you'll drive yourself bonkers.

The only thing I'm unclear on, is in the example, what is `module`, is it the default export (`import module from 'url'`), or is it the full exports like (`import * as module from 'url'`)

Interesting idea, aside from MaxArt's points.

Regarding the original framework, I'm starting to feel like there are a lot of "me too" JSX frameworks popping up, and while I appreciate a more purely functional approach, I'm not sure that it's necessarily strictly better over static render components.

Back on topic, I've similarly wanted to see a more formal guild form around software development, but it just seems like a huge undertaking.

I keep thinking it would be nice if TS was an extension to Babel, so it could work with other presets/tooling in that space.  Avoiding the double-ast cost when going through TS + Babel, just so you can get async functions and a handful of other goodies.

One of my experiences was pretty similar... I've been happy with React (w/ redux/thunks/fetch), and would recommend it whole heartedly over ng2... as a migration, ng1 to ng2 is even more painful than a planned rewrite path.

Most of my biggest complaints on ng2 have been addressed (although after rc1), and even then, it just feels weird in a day when we have a lot of tooling around npm, the stuff baked into ng2 just feels like too much, and too difficult to really use.

I've done a couple of ng2 apps, and I think I could do more with it... that said, I still feel that React + Redux + redux-thunk and fetch gets you most of the way there, with material-ui or react-bootstrap being a great starting point... yeah the tooling isn't as flushed out, and there's some boilerplate... that said, jumping into an app is so much easier than ng2. (and imho ng1 as well).

I've talked a few people out of going with ng2 for new projects... it just isn't worth the trouble.

As for DI (from gp), what's wrong with require/import and testing using proxyquire?

I'd love to see babel and webpack more closely integrated... I mean a lot of the heavy lifting on one end is already handled by babel, if the bundling could be done as an extension to that tool, it would be great imho.

Interesting approach, but I think it's coming up on too much magic, which in the end will make things too hard for someone new coming into the project.