Re: javascript vision thing

[kai zhu]

tldr - tc39 should focus more on JSON-friendly javascript-language-features instead of wasting-time on hard-to-serialize classes/meta-programming.

have you ever wondered why javascript is so popular? why you decided to become a nodejs/backend-javascript programmer?

javascript’s popularity is not because of any engineering/technical merits.  its entirely a derivative of the fact that browsers have taken over the world, and many new software-jobs are either frontend-related, or some [glorified] form of backend-support for the frontend.  the business-proposition for why your employer hired you as a nodejs-developer (vs. php, etc…), is likely because they thought using the same language as their frontend-developer, would allow you to better *support* the needs of the frontend.  and if you can’t do a better job at supporting the frontend than a cheaper php/etc… developer, then you honestly should be *fired* (or “promoted” to management).

my problem with tc39, is that they “claim” javascript is a general-purpose language (and try to design it as such), when industry-wise, its really not.  if javascript was not a browser-language, most employers could not justify hiring developers to create software with it.  if tc39 is sincerely interested in keeping javascript a dominant/relevant language in industry, they should focus on *practical* (vs *academic*) features that help it maintain its edge as a frontend/web-integration language over its competitors.

and the primary-edge javascript has over its competitors (in an industry dominated by web-programming), is that it can transparently manipulate-and-serialize JSON data-structures between frontend <-> backend systems, while competitors like java depend on clumsy, error-prone, class-constructors and custom-serializers.

kai zhu

kaiz...@gmail.com

[kai zhu]

@tj, would you or i care about nodejs/javascript if the language did not exist in browsers?  in fact would anyone on tc39 give a damn about javascript (aside from its creator) in that scenario?  as i've said before [ad nauseam], the only drive most of us [non-frontend-developers] have in javascript is making our backend-programs accessible to the masses via browsers/webviews.  javascript’s dominance/relevance in industry is as a *web-integration* language.  and its aided by its special-ability to directly serialize JSON data-structures (an underrated, and very useful web-integration feature), while most of its competitors have to rely on clumsy, hard-to-serialize classes.

there is no foreseeable future where javascript will be a better tool than java/c++/python/etc. for non web-related projects.  there is no foreseeable future where employers would hire nodejs-developers to work on non web-related projects.  so why does tc39 insist on pushing distracting language-features (clumsy java-like classes, non-integration-friendly meta-programming, static module-loading, etc.) for an unrealistic future-scenario that’s not going to happen?

kai zhu

kaiz...@gmail.com

On 24 Jul 2018, at 5:56 PM, T.J. Crowder <tj.cr...@farsightsoftware.com> wrote:

On Tue, Jul 24, 2018 at 11:27 AM, kai zhu <kaiz...@gmail.com> wrote:

tldr - tc39 should focus more on JSON-friendly javascript-language-features
instead of wasting-time on hard-to-serialize classes/meta-programming.

This is a false dichotomy (the fallacy of the either/or choice). I'd
agree we're approaching, or at, the need for the next thing after
JSON, and that some focus on that would be a good thing. That doesn't
mean stopping work on other good things. Perhaps you could take the
lead on addressing the issues you run into. I'm sure constructive
input would be welcomed.

my problem with tc39, is that they “claim” javascript is a general-purpose
language (and try to design it as such), when industry-wise, its really not.

Yes, it is. Just because you don't see it that way doesn't mean others
don't. And others have been telling you they see it differently
repeatedly over a long period of time on this list.

if tc39 is sincerely
interested in keeping javascript a dominant/relevant language in industry,
they should focus on *practical* (vs *academic*) features

`class` notation is practical (simplifying a common pattern and making
it less error-prone). (I know you don't use that pattern. That's fine.
But lots of people do, so it's practical for them whether you like the
pattern or not.) Promises are practical (simplifying and standardizing
callbacks, making them composable; again making them less
error-prone). `async`/`await` is HUGELY practical, massively
simplifying writing asynchronous code. Arrow functions, rest and
spread, default parameter values -- all practical. (NOT trying to put
words in your mouth, but if you were going to reply "Yes, but those
problems could already be solved in others ways.", then: Sure, and we
could all write assembly code, too. But it's *useful* to address these
in the language.)

All of them are useful beyond the web. All are also useful in web programming.

I have no problem with skepticism of specific proposals. What I would
find useful, though, would be a focus on the proposal's merits, rather
than constant re-raising of this claim that JavaScript is a web-only
language. You've made that claim, ad nauseum. My view is that it's
been rejected by the list membership and by TC39, but whether that's
true or I'm mistaken, please stop spamming the list with it. We all
know how you feel about it.

But again: I'm sure constructive, research-based input on how to deal
with JSON issues related to (for instance) BigInt would be welcome in
that BigInt thread and, ideally, eventually a proposal. There's no
need for some big conceptual argument over the course of the language
-- that *is* a waste of time.

-- T.J. Crowder

[Zlatko]

Hello,

This sounds very damning, can you elaborate a bit? Specifically: what specific feature or features regarding JSON support would you like to see?

As for some other things, I'm not sure I agree. While yes, practical reasons for certain things exist, I think we need to add the features in a meaningful way, not just because it's practical. E.g. extending JSON support significantly may bring temporary advantage - but what when JSON falls out of favor? Let's say something more performant like protobuf? I believe if we added generic tools (like we are doing - things like object rest and spread simplified a lot of code we write), then proper libs will always pop up for handling some specific protocols or formats, e.g. JSON.

Another point you make is that competitors like Java depend on clumsy, error-prone class constructors and custom serializers. Can you name some specific problems that competitors like Java or, say, Rails, have with JSON serialization?

Please take this merely as a critical look at your statement here. I'm really interested in your further thoughts on this.

Zlatko

[kai zhu]

> Classes are widely used on the web. See any modern web framework.

indeed, and i conjecture in doing so, developers have caused more harm than good for their employers in getting their web-projects shipped, when JSON-serialization web-integration problems arise.

On Jul 25, 2018 17:44, "Michael Theriot" <michael.l...@gmail.com> wrote:
>
> Classes are widely used on the web. See any modern web framework.

[kai zhu]

This sounds very damning, can you elaborate a bit? Specifically: what specific feature or features regarding JSON support would you like to see?

my opinion on BigInt is that it should have default JSON.stringify to the [string] literal-form, e.g.

```js

JSON.stringify({ aa: 1234n }); // { "aa": "1234n" }

```

essentially any new meaningful data-type should have some default JSON.stringify form, instead of throwing an error like they did with BigInt.  JSON.parse is left alone (its up to user to figure out how revive BigInt from JSON).  this would 1) give sorely needed guidance on JSON-serializing these new data-types to help web-integration, while 2) keep JSON-spec unchanged, since we don’t do anything with JSON.parse.

but what when JSON falls out of favor? Let's say something more performant like protobuf? 

i've worked with node-implementation of grpc/protobuf [1], and its a blackbox for most frontend-developers to debug when things go wrong (the microservice-architecture at time insisted on using grpc for the “frontend” api-gateway, with a thin, http-to-grpc proxy).  frontend hires/contractors couldn’t make any sense of grpc validation-errors/timeouts when making JSON api-calls to the frontend-proxy.  i ended up adding a “stealth” swagger frontend-gateway on the proxy to insulate frontend-devs from that insanity, with additional integration/qa work to ensure swagger properly translated grpc validation errors to the JSON api-calls made by frontend-devs.  in hindsight, grpc was unnecessary and ended up being a technical-debt.

here's some more rants by me against protobuf [2].

Another point you make is that competitors like Java depend on clumsy, error-prone class constructors and custom serializers. Can you name some specific problems that competitors like Java or, say, Rails, have with JSON serialization?

the reason why i'm hostile to javascript-classes can be summarized in the original post on this thread [3]

[1] npm grpc library

https://www.npmjs.com/package/grpc

[2] quora-answer to: How do protocol buffers compare to the JSON API spec?

https://www.quora.com/How-do-protocol-buffers-compare-to-the-JSON-API-spec-and-are-there-specific-situations-where-one-is-preferable-to-the-other/answer/Kai-Zhu-9

[3] original post on "javascript vision thing”

https://esdiscuss.org/topic/javascript-vision-thing#content-0

kai zhu

kaiz...@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+un...@googlegroups.com.
To post to this group, send email to nod...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/43acfe41-8642-4346-ac45-64badec4bda1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[kai zhu]

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

kaiz...@gmail.com

[Siegfried Bilstein]

Do you have examples of the patterns and es6 features you describe? 

Siggy

--
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+un...@googlegroups.com.
To post to this group, send email to nod...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/0BBA242B-D57D-4260-BC24-7983923B43A7%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Sent from Gmail Mobile

[kai zhu]

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

kaiz...@gmail.com

To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/CAOd5ZkpWCKLTk9TR%2BeE%2Bg9upuezAf_EQVKnpaOhFNk1SgYiZJA%40mail.gmail.com.

[Michael J. Ryan]

Considering how many js devs fail to answer "what values evaluate to false in JavaScript". It isn't the new features that are the problem.

There's a combination of problems.  People believing they're better developers than they are.  People who look down on js and front end development.  And those ahead to learn new things.

JS isn't really evolving any more than Java, C#, go, python and others as a whole in the past 20 years.  And having to fight uphill to use newer features is a pain.  I'm not on the younger side of this (I'm 42)... But I've managed to keep up.

_______________________________________________
es-discuss mailing list
es-di...@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

[Zlatko Đurić]

Hi all,

I don't know why I can't resist this troll. I've just spent half an hour writing an elaborate answer on how the whole premise is wrong, knowing that this is a known troll account. Well, I've deleted it all and will not fall for his trolling again.

 (Btw I thought this list is moderated, how come his same-all troll ramblings always pass the mods?)

Zlatko 

--

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 a topic in the Google Groups "nodejs" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nodejs/p81p-_FqS-s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to nodejs+un...@googlegroups.com.

To post to this group, send email to nod...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/CA%2BpgmMoRmv-P-8a%2B6JCj8szBcJ_32fPULL3DqrZp%2B3SgMZLTDw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Zlatko

[Forrest Norvell]

On Sat, Sep 22, 2018 at 3:43 PM Zlatko Đurić <zlad...@gmail.com> wrote:

 (Btw I thought this list is moderated, how come his same-all troll ramblings always pass the mods?)

Hi! I don't post to this group much anymore, but to answer your question, it's because as much as I disagree with Kai Zhu, his posts are neither harassment not trollish. I believe he's perfectly sincere. If things get too heated, I'll step in to calm them down, but for now, the situation seems to be taking care of itself.

👋

Forrest Norvell, group moderator

[kai zhu]

this is not a troll-account, and I’m a live-person with realistic (albeit uncomfortable) views on limitations of javascript product-development in industry.

es6 seems to adopt java’s philosophy that with careful-planning, you can create semi-permanent, well-abstracted code during the design-phase that will last throughout the product-development cycle.  my experience with numerous web-projects, both successful and failed, indicates this approach as flawed.  and i believe most people in industry who have been burned by failed web-projects in the past (due to over-encumbered/engineered initial-designs that couldn’t cope with realities of product integration/qa) are wary of hiring unproven java-turned-js devs who still hold these brittle design-philosophies.

there's no such thing as “permanent” javascript-code in product-development.  everything eventually gets rewritten, when the inevitable business-critical ux feature-request comes in that you must accommodate, even though it breaks your current integration-workflow.  when this common scenario plays out in industry:

a) the [inexperienced] unqualified js-dev likely dithers, unwilling/unable to unwind the complicated initial-design they architected to accommodate the feature-request, while

b) the [experienced] qualified js-dev would have anticipated this, and simply rewrites their initial expendable-code with new expendable-code to accommodate the feature-request (with expectation it will be rewritten again-and-again in the future).

its difficult for employers to discern whether js-devs will exhibit trait a) or trait b) through technical-interview alone.  and es6 skews this with design-patterns biased towards trait a), further confusing employers seeking qualified js-devs.

kai zhu

kaiz...@gmail.com