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. [1]: https://esdiscuss.org/notes [2]: https://esdiscuss.org/notes/2017-01-25#15iv-progress-report-and-request-for-comments-on-64-bit-int-support [3]: https://eslint.org/ [4]: https://github.com/taskworld/eslint-plugin-local ----- Isiah Meadows m...@isiahmeadows.com Looking for web consulting? Or a new website? Send me an email and we can get started. www.isiahmeadows.com On Wed, Oct 18, 2017 at 6:37 AM, Naveen Chawla <naveen.c...@gmail.com> 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 && > car.drive()` instead of `if(car!==undefined) car.drive()` 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 <a...@weej.com> 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 <ljh...@gmail.com> 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 <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 >> >> _______________________________________________ >> 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 > _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
