javascript vision thing

kai zhu kaizhu256 at
Wed Jul 25 11:35:50 UTC 2018

> 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.lee.theriot at>
> Classes are widely used on the web. See any modern web framework.
> On Wednesday, July 25, 2018, kai zhu <kaizhu256 at> wrote:
>> @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
>> kaizhu256 at
>>> On 24 Jul 2018, at 5:56 PM, T.J. Crowder <
tj.crowder at> wrote:
>>> On Tue, Jul 24, 2018 at 11:27 AM, kai zhu <kaizhu256 at> wrote:
>>>> tldr - tc39 should focus more on JSON-friendly
>>>> 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
>>>> 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
>>>> 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
>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list