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

Isiah Meadows isiahmeadows at
Thu Oct 19 23:54:24 UTC 2017

In general, it's not the TC39 who should be dictating how code is
written - in particular, even they have their stylistic disagreements
(like with ASI and `let` vs `const`), and active TC39 representative
maintain both JSHint (opinionated) and ESLint (unopinionated).
Additionally, JSLint (the predecessor to JSHint) was created by a
formerly active TC39 representative. If you want to see more of these
broad stylistic disagreements, check out [their meeting notes][1]. A
few things that come to mind are decorators, cancellation, recent
class additions, and [BigInt][2].

Instead, if you have your own strong opinions on everything, try
introducing [ESLint][3] to your projects. They have numerous presets
and rules built-in, and you can create your own custom presets, rules,
and plugins. If you want to ban `null`, write a custom rule for it. If
you want to ban anything not ES5, write a rule that catches every
expression that isn't ES5. If you want to define local rules, use
[eslint-plugin-local][4]. In my case, I decided I didn't want to use
default exports, so I wrote a local rule banning all default exports.
Not that I have a problem with those who use it - I don't. I just feel
it's easier for me to wrap my head around named exports without
introducing the cognitive overhead of default exports.


Isiah Meadows
me at

Looking for web consulting? Or a new website?
Send me an email and we can get started.

On Wed, Oct 18, 2017 at 6:37 AM, Naveen Chawla <naveen.chwl at> wrote:
> I disagree that the language contributors should be involved in best
> practice guidance. Patterns evolve over usage and experience with the
> constructs. I bet the implementors of `&&` and `||` didn't necessarily
> expect them to be used so effectively for non-boolean logic e.g. `car &&
>` instead of `if(car!==undefined)` or whatever... Or
> maybe they did. But the point is language usage is often a matter of opinion
> and preference, and not something that should be set as a tide against a
> possibly justifiable opposition. As a response to the original question, I
> gave my opinion and reason in brackets. If the reader prefers a different
> way for their own reasons, fine - I would just expect them to give their own
> reasons for superseding my reasons...
> On Wed, 18 Oct 2017 at 14:34 Alexander Jones <alex at> wrote:
>> 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!
>> Alex
>> 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
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list