Does non fancy vs fancy

[joelharkes]

In this case let's say, fancy is node 7+ async await pattern.

Would you really prefer to stay inside the callback world instead of having the amazing clean async and await code style. Or would you just call non performant/thread blocking sync code?

It still doesn't need any pre compilation, runs like a beast and the code is clean and understandable. The only drawback of this is to tell everyone to update to node 7.

I feel like staying in the es3 JavaScript is like saying: I'll style my website with tables, that way I'll be sure everyone can view it correctly instead of trying to learn how to use a flexbox.

This is the main issue i have with the readme. Everyone can have there own tools preference and that is fine. But why deliberately not use new language features?

[bendrucker]

The only drawback of this is to tell everyone to update to node 7.

I disagree. I see two big drawbacks:

• You need to transpile for the browser. Not light transpilation like const -> var. Not bundling. Transpiling flow control keywords produces output that's difficult to read/understand/debug. This guide is Node-focused but still acknowledges the need for a good tooling bridge to the browser.
• Upgrading to Node 7 is a big deal. Lots of companies and individuals insist on using the LTS release for daily work, myself included. Read this thread. I'm glad there's a cadence of LTS and semi-stable major releases. It helps the Node team gather feedback and work out the kinks. It lets me test my libraries in CI and catch deprecations/breakage. I just won't run my applications on a release that's not LTS. It's a headache I don't need.

I don't think tables to flexbox is a fair comparison for the current state of Node/JS. Flexbox is a transformative feature. Once browser support was particularly strong, it made UI developers a lot more productive. When flexbox was still immature, you needed a mess of hacks to ship a working application. Vendor prefixing is one thing, but having three different syntaxes to try to transpile/polyfill is another.

I feel like we're still at that awkward transition phase with promises/async. The difference is that layout in a browser is global, conflicting, and inherently hard to manage. To me a new box model for layout is a pure step forward. Promises are more a change of syntax. The only new behavior (combining expected and thrown errors) is a regression as far as I'm concerned.

My concern with JS language features is that I believe the productivity gains are rarely large enough to justify the severely disruptive workflow/style changes. I'll use Object.assign sometimes these days instead of require('xtend'). It's convenient and it's not really changing the way the code flows/runs. I apply the highest level of scrutiny to flow control features, especially async flow control. For my work async/await isn't worth it and won't be anytime soon.

[bendrucker]

One last thought: streams are super fancy in the sense that they have a huge, complex API and tons of quirks that take time to understand. I like them because they can elegantly control tricky async flow control patterns (e.g. backpressure, pipelining). My preference is to be fancy only when necessary. I'm taking the time I don't spend on big syntax/language changes and investing it in addressing the truly hard programming problems that come up.

[yoshuawuyts]

Hey there, thanks for the questions! I fully agree with the points @bendrucker's raised. async / await doesn't inherently bring anything new to the table or solve any particular problems better. I value stability and reliability a lot, and async / await isn't that.