My opinions: For existing code, just transition when encountering code, for convenience (no need to transition everything in a go).
For new code, always use await async where possible (very manageable vs callbacks) For new code, always use const (for references you don't expect to change) and let (for references you expect to change), and ditch var altogether (reason: var lets you accidentally override any global variables) For new code, always use fat arrow EXCEPT when using a library that relies on the use of "this" inside a function, where the "this" is different than the outer "this" (reason: more terse, and lets you access the outer "this"). Destructuring: as per your convenience. Pipeline: never unless they allow await in a pipeline (reason: could lead to inconsistency), otherwise always (instead of () for calling functions). However, pipeline operator is not yet accepted in the language. On Wed, 18 Oct 2017 at 11:14 kai zhu <kaizhu...@gmail.com> wrote: > there are several factors for the current javascript-fatigue. one factor > which tc39 could help mitigate is to provide a narrative on how to > consistently apply proposed language-features (over existing-practices and > interfacing with legacy-code). > > i feel too many new and old javascript-programmers alike are unable to > adopt a consistent programming-style for post-es5 features in > production-code. style-issues which are problematic when a project has to > deal with legacy libraries include: > > - when is it appropriate to use callback vs promise vs async-generator vs > async/await, when interfacing with legacy-code (aka context-switching-hell > or baton-passing-hell)? > - when is it appropriate to use var vs let, when interfacing with > legacy-code? > - when is it appropriate to use function vs fat-arrow, when interfacing > with legacy-code? > - how can we apply destructuring in a consistent and readable manner? > - when is it appropriate to use (proposed) pipeline-operator, and when is > it not? > > es6/es7/es8 introduces hundreds of these kinds of questions which distract > us from actual coding and shipping features. > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
