styleguide sanity-check for tc39 language-proposals to address javascript-fatigue

Alexander Jones alex at
Wed Oct 18 09:04:25 UTC 2017

The beauty of (coding) standards is that there are so many to choose from.

IMO it’s a false dichotomy though. A respected and credible group of
language contributors should pool some energy together and ratify some
opinionated best practices, a la the C++ Core Guidelines and PEP-8. No,
it’s not *necessary*—neither is the exponent operator—but it does have
clear benefits.

I believe most in the community would rather not have to sell things like
“const by default” to their team members, when it could be “official”
guidance instead. It’s energy we’d rather be spending on other things!


On Wed, 18 Oct 2017 at 06:59, Jordan Harband <ljharb at> wrote:

> These questions have consumed programmers in most languages since forever.
> It's not TC39's place to tell people how to write code - but there's plenty
> of style guides that have answers to these questions.
> On Tue, Oct 17, 2017 at 10:44 PM, kai zhu <kaizhu256 at> 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 at
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list