[nodejs] Re: javascript vision thing

Ben Wiley therealbenwiley at gmail.com
Sun Sep 23 05:03:56 UTC 2018


I find the general tone of the preceding thread condescending toward
developers who have dealt with real problems recent ES additions have
addressed. Though I don't think I totally follow your argument that
continuing to increase API surface area decreases the surface area for
bugs. Perhaps for the developer, but certainly not for the core platform
which browsers have to implement. Also as there's a trend toward demand for
more and more language-inherent ways to accomplish the same thing, I think
we're beginning to overload newcomers to the language with grammar to learn.

Ben

Le dim. 23 sept. 2018 00 h 51, Henrique Barcelos <rick.hjpbarcelos at gmail.com>
a écrit :

> > 1. es6 generators and modules are the top 2 notorious things that come
> to mind as being difficult to debug/integrate in product-development.
>
> How exactly are generators and modules difficult to integrate or debug?
> Difficult compared to what?
>
> How are ES modules more complicated for the developer than CommonJS or UMD?
>
> How come generators be more complex than handling a sequence of
> asynchronous code using a user-land event-based API?
>
> How difficult would it be for Javascript engines to optimize user-land
> code?
>
> To me, it's far better to have something in the language's standard lib
> that a user-land implementation, specially for beginners.
>
> > 2. classes (and typescript, though not directly es6-related), tend to
> create lots of unnecessary structure that becomes a PITA when you need to
> rewrite everything, which occurs often in product-development. there are
> lots of newly minted js-devs entering industry, who lack experience in
> understanding the risks of javascript over-engineering (and that nothing
> you write is permanent). they write lots of semi-permanent, es6
> infrastructure-code during the initial design-phase, which is a general
> no-no for many veterans, who understand most of that stuff is going to get
> tossed out the window and rewritten during integration-phase (and again
> everytime a ux feature-request comes in that breaks the existing
> integration-workflow).
>
> What exactly is this related to classes? While I myself am not a fan of
> the whole classical syntactic sugar on top of prototypal chains, it's not
> the language's fault that its features are frequently abused and misused.
>
> What you're saying about over-engineering is not intrinsic to the
> Javascript community, it's a software engineering problem.
>
> Maybe it's because we work in a new field, with roughly 50 years (although
> programming itself has changed a lot since the 60's). Maybe it's because
> we're forming bad developers. Maybe it's because software development is a
> really complex subject.
>
> One thing we can know for sure is that the tools are not the problem. We
> are. You can use a knife to cook a delicious meal, by you can also use it
> to kill someone.
>
> > 3. let and const declarations. most code you debug/write in javascript
> is ux-related integration-code dealing with async-io, which relies heavily
> on function-scoped closures to pass variables across process-ticks.
> block-level scoping is an unnecessary design-pattern that leads to
> confusion over the former.
>
> This is an odd complaint, because variable hoisting was one of the more
> convoluted features of Javascript, simply because it was different from any
> other language I've heard of.
>
> I don't think you could even call block-level scoping a "design pattern",
> because it is a de facto standard for modern languages.
>
> > 4. fat-arrow. it has garden-path issues, making it difficult to write
> efficient javascript-parsers that can differentiate the following [valid]
> javascript-code:
> >```js
> (aa = 1, bb = 2, cc = 3);
> // vs
> (aa = 1, bb = 2, cc = 3) => aa + bb;
> ```
> >this leads to fundamental performance-issues with
> tooling/minification/test-coverage-instrumenters. jslint for
> efficiency-reasons, simply cheats and assumes both of the above are
> fat-arrows, and raises fat-arrow warnings for both (and halts further
> parsing) [1].
>
> I have never written or seen code like `(aa = 1, bb = 2, cc = 3)`. If you
> code like that, you're the problem, not JavaScript. Even though it's a
> valid construct, for compatibility sake, it doesn't mean that modern tools
> should support or endorse this.
>
> "Oh, but performance...". Yeah, you can also write a perfectly valid code
> that hurts performance as well. You can even create an infinite loop with
> valid constructs. It doesn't mean you should.
>
> ---
>
> Summarizing what I'm trying to say: your criticism has nothing to do with
> the language or its evolution pace. They are universal problems around
> software engineering and will continue to be even if we slowed down.
>
> I've been writing Javascript code since ES3 and my life got significantly
> better with ES6+.
>
> The existence of TC39 guarantees that a feature will only make it into the
> language after a very thorough public scrutiny process.
>
> I don't believe we need to go slower. In fact, I wish we could move even
> faster.
>
>
> Em dom, 23 de set de 2018 01:32, Henrique Barcelos <
> rick.hjpbarcelos at gmail.com> escreveu:
>
>> > 1. es6 generators and modules are the top 2 notorious things that come
>> to mind as being difficult to debug/integrate in product-development.
>>
>> How exactly are generators and modules difficult to integrate or debug?
>> Difficult compared to what?
>>
>> How are ES modules more complicated for the developer than CommonJS or
>> UMD?
>>
>> How come generators be more complex than handling a sequence of
>> asynchronous code using a user-land event-based API?
>>
>> How difficult would it be for Javascript engines to optimize user-land
>> code?
>>
>> > 2. classes (and typescript, though not directly es6-related), tend to
>> create lots of unnecessary structure that becomes a PITA when you need to
>> rewrite everything, which occurs often in product-development. there are
>> lots of newly minted js-devs entering industry, who lack experience in
>> understanding the risks of javascript over-engineering (and that nothing
>> you write is permanent). they write lots of semi-permanent, es6
>> infrastructure-code during the initial design-phase, which is a general
>> no-no for many veterans, who understand most of that stuff is going to get
>> tossed out the window and rewritten during integration-phase (and again
>> everytime a ux feature-request comes in that breaks the existing
>> integration-workflow).
>>
>> What exactly is this related to classes? While I myself am not a fan of
>> the whole classical syntactic sugar on top of prototypal chains, it's not
>> the language's fault that its features are frequently abused and misused.
>>
>> What you're saying about over-engineering is not intrinsic to the
>> Javascript community, it's a software engineering problem.
>>
>> Maybe it's because we work in a new field, with roughly 50 years
>> (although programming itself has changed a lot since the 60's). Maybe it's
>> because we're forming bad developers. Maybe it's because software
>> development is a really complex subject.
>>
>> One thing we can know for sure is that the tools are not the problem. We
>> are. You can use a knife to cook a delicious meal, by you can also use it
>> to kill someone.
>>
>> > 3. let and const declarations. most code you debug/write in javascript
>> is ux-related integration-code dealing with async-io, which relies heavily
>> on function-scoped closures to pass variables across process-ticks.
>> block-level scoping is an unnecessary design-pattern that leads to
>> confusion over the former.
>>
>> This is an odd complaint, because variable hoisting was one of the more
>> convoluted features of Javascript, simply because it was different from any
>> other language I've heard of.
>>
>> I don't think you could even call block-level scoping a "design pattern",
>> because it is a de facto standard for modern languages.
>>
>> Em sáb, 22 de set de 2018 04:42, kai zhu <kaizhu256 at gmail.com> escreveu:
>>
>>> yes, in order of severity:
>>>
>>> 1. es6 generators and modules are the top 2 notorious things that come
>>> to mind as being difficult to debug/integrate in product-development.
>>>
>>> 2. classes (and typescript, though not directly es6-related), tend to
>>> create lots of unnecessary structure that becomes a PITA when you need to
>>> rewrite everything, which occurs often in product-development.  there are
>>> lots of newly minted js-devs entering industry, who lack experience in
>>> understanding the risks of javascript over-engineering (and that nothing
>>> you write is permanent).  they write lots of semi-permanent, es6
>>> infrastructure-code during the initial design-phase, which is a general
>>> no-no for many veterans, who understand most of that stuff is going to get
>>> tossed out the window and rewritten during integration-phase (and again
>>> everytime a ux feature-request comes in that breaks the existing
>>> integration-workflow).
>>>
>>> 3. let and const declarations.  most code you debug/write in javascript
>>> is ux-related integration-code dealing with async-io, which relies heavily
>>> on function-scoped closures to pass variables across process-ticks.
>>>  block-level scoping is an unnecessary design-pattern that leads to
>>> confusion over the former.
>>>
>>> 4. fat-arrow.  it has garden-path issues, making it difficult to write
>>> efficient javascript-parsers that can differentiate the following [valid]
>>> javascript-code:
>>> ```js
>>> (aa = 1, bb = 2, cc = 3);
>>> // vs
>>> (aa = 1, bb = 2, cc = 3) => aa + bb;
>>> ```
>>> this leads to fundamental performance-issues with
>>> tooling/minification/test-coverage-instrumenters.  jslint for
>>> efficiency-reasons, simply cheats and assumes both of the above are
>>> fat-arrows, and raises fat-arrow warnings for both (and halts further
>>> parsing) [1].
>>>
>>> [1] jslint managing garden-path complexity of fat-arrow, with a single
>>> lookahead, that can turn out wrong, so it halts parsing.
>>>
>>> https://github.com/douglascrockford/JSLint/blob/36adbc73ef0275df7d3fac9c3ef0844ac506136b/jslint.js#L2914
>>>
>>> kai zhu
>>> kaizhu256 at gmail.com
>>>
>>>
>>>
>>> On 22 Sep 2018, at 12:04 PM, Siegfried Bilstein <sbilstein at gmail.com>
>>> wrote:
>>>
>>> Do you have examples of the patterns and es6 features you describe?
>>>
>>> Siggy
>>>
>>> On Sat, Sep 22, 2018 at 01:02 kai zhu <kaizhu256 at gmail.com> wrote:
>>>
>>>> a problem i've observed in industry is that many es6 language-features
>>>> have the unintended-consequence of incentivising incompetent
>>>> javascript-developers at the expense of competent-ones.  its generally
>>>> difficult for many employers (even those knowledgeable in general-purpose
>>>> programming), to discern between:
>>>>
>>>> a) a competent javascript employee/contractor who can get things done
>>>> and ship products (albeit with legitimate delays), and
>>>> b) an incompetent-one who can easily hide themselves in non-productive
>>>> es6 busywork, and continually pushback product-integration (again with
>>>> “legitimate” delays, until its too late).
>>>>
>>>> its gotten bad enough that many industry-employers no longer trust
>>>> general-purpose-programming technical-interviews when recruiting js-devs,
>>>> and rely almost exclusively on either a) an applicant's reputation /
>>>> word-of-mouth for getting things done, or b) their ability to complete a
>>>> time-consuming tech-challenge, where they must demonstrate ability to ship
>>>> a mini-product.  both methods are not scalable to meet the demand in
>>>> industry for qualified js-devs in product-development.
>>>>
>>>> the only solution i can think of to this industry-problem is to
>>>> hold-back on introducing new disruptive/unproven javascript
>>>> design-patterns, and figuring out how to educate the industry with
>>>> tightened javascript style-guides and existing design-patterns proven to
>>>> work (more is less); generally, ways to enhance the current, woefully
>>>> inadequate “bullsh*t detector” of employers so they can better identify and
>>>> mentor/train/weed-out unqualified js-devs.
>>>>
>>>> kai zhu
>>>> kaizhu256 at gmail.com
>>>>
>>>>
>>>> --
>>>> Job board: http://jobs.nodejs.org/
>>>> New group rules:
>>>> https://gist.github.com/othiym23/9886289#file-moderation-policy-md
>>>> Old group rules:
>>>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
>>>> ---
>>>> You received this message because you are subscribed to the Google
>>>> Groups "nodejs" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to nodejs+unsubscribe at googlegroups.com.
>>>> To post to this group, send email to nodejs at googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/nodejs/0BBA242B-D57D-4260-BC24-7983923B43A7%40gmail.com
>>>> <https://groups.google.com/d/msgid/nodejs/0BBA242B-D57D-4260-BC24-7983923B43A7%40gmail.com?utm_medium=email&utm_source=footer>
>>>> .
>>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>>> --
>>> Sent from Gmail Mobile
>>>
>>> --
>>> Job board: http://jobs.nodejs.org/
>>> New group rules:
>>> https://gist.github.com/othiym23/9886289#file-moderation-policy-md
>>> Old group rules:
>>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "nodejs" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to nodejs+unsubscribe at googlegroups.com.
>>> To post to this group, send email to nodejs at googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/nodejs/CAOd5ZkpWCKLTk9TR%2BeE%2Bg9upuezAf_EQVKnpaOhFNk1SgYiZJA%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/nodejs/CAOd5ZkpWCKLTk9TR%2BeE%2Bg9upuezAf_EQVKnpaOhFNk1SgYiZJA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> --
>>
>> Henrique
>>
> --
>
> Henrique
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180923/16f43b11/attachment-0001.html>


More information about the es-discuss mailing list