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

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

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

kai zhu
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Jordan Harband
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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Naveen Chawla
In reply to this post by kai zhu
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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

T.J. Crowder-2
In reply to this post by kai zhu
On Wed, Oct 18, 2017 at 6:44 AM, kai zhu
<[hidden email]> wrote:
>
> there are several factors for the current javascript-fatigue.

I don't believe any such thing exists.

> es6/es7/es8 introduces hundreds of these kinds of questions
> which distract us from actual coding and shipping features.

I've certainly never been distracted by these things, other than in the usual way ("Hmmm, in our house style are we always going to use () with arrow functions even if there's only one parameter, like we always use curly braces with `if`?"), which isn't significant and is certainly a *very* small price to pay for the added utility of these features.

Including libraries? Fine, use the API they provide (callbacks or promises) or wrap that API if you don't like it but need the lib anyway, and certainly don't worry about the *style* the library uses in its code. No distraction.

Frankly, this just seems like you're trying once again to push your "JavaScript should have frozen in time as of ES3 or maybe ES5" agenda, which I don't think anyone else on this list shares.

-- T.J. Crowder

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

kai zhu

> Frankly, this just seems like you're trying once again to push your "JavaScript should have frozen in time as of ES3 or maybe ES5" agenda, which I don't think anyone else on this list shares.

its a legitimate agenda from someone who cares deeply about javascript and believes es6 was a mistake and a step in the wrong-direction for javascript and frontend-development.

-kai

On Oct 18, 2017 3:02 PM, "T.J. Crowder" <[hidden email]> wrote:
>
> On Wed, Oct 18, 2017 at 6:44 AM, kai zhu
> <[hidden email]> wrote:
> >
> > there are several factors for the current javascript-fatigue.
>
> I don't believe any such thing exists.
>
> > es6/es7/es8 introduces hundreds of these kinds of questions
> > which distract us from actual coding and shipping features.
>
> I've certainly never been distracted by these things, other than in the usual way ("Hmmm, in our house style are we always going to use () with arrow functions even if there's only one parameter, like we always use curly braces with `if`?"), which isn't significant and is certainly a *very* small price to pay for the added utility of these features.
>
> Including libraries? Fine, use the API they provide (callbacks or promises) or wrap that API if you don't like it but need the lib anyway, and certainly don't worry about the *style* the library uses in its code. No distraction.
>
> Frankly, this just seems like you're trying once again to push your "JavaScript should have frozen in time as of ES3 or maybe ES5" agenda, which I don't think anyone else on this list shares.
>
> -- T.J. Crowder


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

T.J. Crowder-2
On Wed, Oct 18, 2017 at 8:18 AM, kai zhu
>
> its a legitimate agenda from someone who cares deeply about
> javascript and believes es6 was a mistake and a step in the
> wrong-direction for javascript and frontend-development.

I won't get into an argument with you about ES2015+ except to say I vehemently disagree with your conclusion, and challenge your characterization that there's some kind of "fatigue." I'm constantly meeting programmers who are thrilled with the new features -- three real standouts are arrow functions, `class` syntax, and `async`/`await`. I show `async`/`await` to people and they go crazy for it. "Whoo hoo, no more callback hell!"

But the point is: The ship has sailed. Re-litigating decisions that have been made is pointless and tiresome. When new proposals are made, it's perfectly valid to raise issues with *them* if you think there are issues (and perhaps cite **concrete** issues that have arisen from similar past work to support that argument -- with data, not innuendo), but complaining about arrow functions, `let`, Promises, etc., in October 2017 is not useful. Those decisions were finalized years ago.

-- T.J. Crowder

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Alexander Jones
In reply to this post by Jordan Harband
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Naveen Chawla
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Isiah Meadows-2
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
[hidden email]

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>> [hidden email]
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> [hidden email]
>>> https://mail.mozilla.org/listinfo/es-discuss
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Alexander Jones
I used the term 'language contributors' rather than TC39 as an intentionally vague way of describing people like us.

The ISO C++ Committee also lacks a consensus on everything, but that doesn't mean those people and the people around them can't debate and establish a consensus on *something*. Hence, C++ Core Guidelines.

I think the reality is that people are averse to this because they don't want their pet practices at work being discouraged by anything resembling official guidance — having to justify a decision to use `var` instead of `const` by default is *effort*, right? But they're perhaps not always considering the benefits that an improvement in (not necessarily total) uniformity can bring.

I claim that the majority in the Python community would say that PEP-8 has been a net benefit. (Yes I break its rules from time to time. That's what rules are for. ;) )

On 20 October 2017 at 00:54, Isiah Meadows <[hidden email]> wrote:
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
[hidden email]

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>> [hidden email]
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> [hidden email]
>>> https://mail.mozilla.org/listinfo/es-discuss
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Michał Wadas
Though, PEP-8 was created in 2001 and in significant part codified already used conventions. And JavaScript does not have such widely followed conventions - except camelCase for functions and PascalCase for classes.

On Fri, Oct 20, 2017 at 10:19 AM, Alexander Jones <[hidden email]> wrote:
I used the term 'language contributors' rather than TC39 as an intentionally vague way of describing people like us.

The ISO C++ Committee also lacks a consensus on everything, but that doesn't mean those people and the people around them can't debate and establish a consensus on *something*. Hence, C++ Core Guidelines.

I think the reality is that people are averse to this because they don't want their pet practices at work being discouraged by anything resembling official guidance — having to justify a decision to use `var` instead of `const` by default is *effort*, right? But they're perhaps not always considering the benefits that an improvement in (not necessarily total) uniformity can bring.

I claim that the majority in the Python community would say that PEP-8 has been a net benefit. (Yes I break its rules from time to time. That's what rules are for. ;) )

On 20 October 2017 at 00:54, Isiah Meadows <[hidden email]> wrote:
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
[hidden email]

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>> [hidden email]
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> [hidden email]
>>> https://mail.mozilla.org/listinfo/es-discuss
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss