Classes are just sugar for a predominant pattern. On Wednesday, July 25, 2018, kai zhu <kaizhu...@gmail.com> wrote:
> > 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.ther...@gmail.com> > wrote: > > > > Classes are widely used on the web. See any modern web framework. > > > > > > On Wednesday, July 25, 2018, kai zhu <kaizhu...@gmail.com> 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 > >> kaizhu...@gmail.com > >> > >>> On 24 Jul 2018, at 5:56 PM, T.J. Crowder <tj.crowder@farsightsoftware. > com> wrote: > >>> > >>> On Tue, Jul 24, 2018 at 11:27 AM, kai zhu <kaizhu...@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 > >> > >> >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
