javascript vision thing

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

Re: javascript vision thing

Ben Wiley
Please refrain from jokes about domestic violence. It distracted from the rest of your email, which I decided not to read.

Ben

Le mar. 24 juill. 2018 11 h 09, Carsten Bormann <[hidden email]> a écrit :
On Jul 24, 2018, at 16:31, Anders Rundgren <[hidden email]> wrote:
>
> JSON isn’t really a topic for tc39 only but since the IETF consider JSON "done", an open question is where possible future developments should take place,

What is the best place where I should beat my wife?
No, that is not the question.

> including dealing with new data types like BigInt.

That, indeed, is a question for JavaScript.  It has nothing to do with “developing” JSON; JSON can already represent BigInt just fine.

> Personally I think the JSON WG should be rebooted but apparently I’m rather alone with that idea.

Indeed.

Frankly, JSON, together with the JavaScript-induced limitations in its ecosystem as documented in RFC 7493, is not a very brilliant data interchange format.  It is popular because it is extremely simple (at least on the surface), it is already familiar to users of most dynamic programming languages, and it hasn’t changed since 2002.  “Changing” JSON simply means no longer having JSON.

(And there are quite a few much better data interchange formats; maybe JavaScript can start to support some of them out of the box.)

> Obvious extensions include comments and dropping the "" requirement on keys that are JS compliant.

*Shudder*.   These are *not* needed for data interchange.  For configuration files and other data input by humans, DO NOT USE JSON.  If you need YAML(*) (which also has been fully stable for more than a decade, by the way), you know where to find it.  YAML also *is* the extended JSON that so many people are wishing for.

Grüße, Carsten

(*) and of course YAML supports graphs, binary (byte string) data, human-friendly input, etc.  It is approximately what any other effort to “humanize” JSON and fill in its shortcomings will arrive at eventually, just with some microdecisions you and I may not like but that are not relevant in the big picture.

_______________________________________________
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: javascript vision thing

Michael Theriot
In reply to this post by kai zhu
Native JSON streaming would be nice in my opinion.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: javascript vision thing

Anders Rundgren-2
In reply to this post by Carsten Bormann
On 2018-07-24 17:09, Carsten Bormann wrote:
> On Jul 24, 2018, at 16:31, Anders Rundgren <[hidden email]> wrote:
>>
>> JSON isn’t really a topic for tc39 only but since the IETF consider JSON "done", an open question is where possible future developments should take place,
>
> No, that is not the question.
>
>> including dealing with new data types like BigInt.
>
> That, indeed, is a question for JavaScript.  It has nothing to do with “developing” JSON; JSON can already represent BigInt just fine.

Serializing BigInt as JSON Number is the solution then?

There are a few argument against that:

- This would typically require low-level parsers to always rely on a BigNumber type.  Oracle's JSON-B does exactly that.  Currently there is no BigNumber type in JS or .NET.

- There is quite a bunch of IETF standards defining JSON structures. As far as I know none of them exploit JSON outside of its original, JS-induced limitations.

- Although BigInt is a very welcome addition to JS, usages are few and typically confined to specific things like crypto or money.  Creating backward incompatibility for that is IMO counterproductive.

- Serializing BigInts as a string does not break anything.


>> Personally I think the JSON WG should be rebooted but apparently I’m rather alone with that idea.
>
> Indeed.

That might be the case but it doesn't solve the problem.


>
> Frankly, JSON, together with the JavaScript-induced limitations in its ecosystem as documented in RFC 7493, is not a very brilliant data interchange format.

It seems to work well in spite of not being brilliant.

Even "the impossible", JSON Canonicalization actually works as described if you stick to the same limitations existing IETF-defined JSON objects do: https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01

I'm not going into the the rest of the mail because supporting another interchange format is another question.

Yes, CBOR is great https://tools.ietf.org/html/rfc7049 :-)

cheers,
Anders

>  It is popular because it is extremely simple (at least on the surface), it is already
> familiar to users of most dynamic programming languages, and it hasn’t changed since 2002.  “Changing” JSON simply means no longer having JSON.
>
> (And there are quite a few much better data interchange formats; maybe JavaScript can start to support some of them out of the box.)
>
>> Obvious extensions include comments and dropping the "" requirement on keys that are JS compliant.
>
> *Shudder*.   These are *not* needed for data interchange.  For configuration files and other data input by humans, DO NOT USE JSON.  If you need YAML(*) (which also has been fully stable for more than a decade, by the way), you know where to find it.  YAML also *is* the extended JSON that so many people are wishing for.
>
> Grüße, Carsten
>
> (*) and of course YAML supports graphs, binary (byte string) data, human-friendly input, etc.  It is approximately what any other effort to “humanize” JSON and fill in its shortcomings will arrive at eventually, just with some microdecisions you and I may not like but that are not relevant in the big picture.
>

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

Re: javascript vision thing

Carsten Bormann
On Jul 24, 2018, at 18:29, Anders Rundgren <[hidden email]> wrote:

>
> On 2018-07-24 17:09, Carsten Bormann wrote:
>> On Jul 24, 2018, at 16:31, Anders Rundgren <[hidden email]> wrote:
>>>
>>> JSON isn’t really a topic for tc39 only but since the IETF consider JSON "done", an open question is where possible future developments should take place,
>> No, that is not the question.
>>> including dealing with new data types like BigInt.
>> That, indeed, is a question for JavaScript.  It has nothing to do with “developing” JSON; JSON can already represent BigInt just fine.
>
> Serializing BigInt as JSON Number is the solution then?

For applications that make good use of BigInt, I would say so.
So you wouldn’t use JSON.parse, but a new interface that preserves integers beyond 2**53 as BigInt (or possibly even all integers; I don’t want to design this on a napkin)

> There are a few argument against that:
>
> - This would typically require low-level parsers to always rely on a BigNumber type.  Oracle's JSON-B does exactly that.  Currently there is no BigNumber type in JS or .NET.

There is no need for the above interface to handle floating point numbers (NR2/NR3).

> - There is quite a bunch of IETF standards defining JSON structures. As far as I know none of them exploit JSON outside of its original, JS-induced limitations.

Maybe the IETF was smart enough to stay in the confines of I-JSON…

But really, JSON never had that particular limitation.  A JSON-based ecosystem that wants to enable the use of JavaScript JSON.parse does, as Twitter found out when they were sending their perfectly valid JSON to JavaScript applications.

> - Although BigInt is a very welcome addition to JS, usages are few and typically confined to specific things like crypto or money.  Creating backward incompatibility for that is IMO counterproductive.

Right, so maybe the motivation for touching JSON really isn’t that massive.

> - Serializing BigInts as a string does not break anything.

After JSON.parse, they are text strings then, not BigInts.
Generally, there is the expectation that, for an interesting set of x, JSON.parse(JSON.stringify(x)) == x
Hence the exception when you pass BigInt to JSON.stringify today.

>>> Personally I think the JSON WG should be rebooted but apparently I’m rather alone with that idea.
>> Indeed.
>
> That might be the case but it doesn’t solve the problem.

It also doesn’t create the problem of damaging JSON by instability.

>> Frankly, JSON, together with the JavaScript-induced limitations in its ecosystem as documented in RFC 7493, is not a very brilliant data interchange format.
>
> It seems to work well in spite of not being brilliant.

Right.  As do bicycles.  Until you need to transport a sofa or cross the Atlantic.
JSON is the right tool for a large number of jobs.

> Yes, CBOR is great https://tools.ietf.org/html/rfc7049 :-)

Can’t disagree here :-)

Grüße, Carsten

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

Re: javascript vision thing

Isiah Meadows-2
IMHO, I'd like to see four things:

- Native JSON multi-object support
- Binary data support that doesn't require delimiters
- Native JSON property streaming support
- Spec-level binary JSON support

Apart from that, I don't really see anything JSON lacks.

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com

On Tue, Jul 24, 2018 at 12:43 PM, Carsten Bormann <[hidden email]> wrote:

>
> On Jul 24, 2018, at 18:29, Anders Rundgren <[hidden email]> wrote:
> >
> > On 2018-07-24 17:09, Carsten Bormann wrote:
> >> On Jul 24, 2018, at 16:31, Anders Rundgren <[hidden email]> wrote:
> >>>
> >>> JSON isn’t really a topic for tc39 only but since the IETF consider JSON "done", an open question is where possible future developments should take place,
> >> No, that is not the question.
> >>> including dealing with new data types like BigInt.
> >> That, indeed, is a question for JavaScript.  It has nothing to do with “developing” JSON; JSON can already represent BigInt just fine.
> >
> > Serializing BigInt as JSON Number is the solution then?
>
> For applications that make good use of BigInt, I would say so.
> So you wouldn’t use JSON.parse, but a new interface that preserves integers beyond 2**53 as BigInt (or possibly even all integers; I don’t want to design this on a napkin)
>
> > There are a few argument against that:
> >
> > - This would typically require low-level parsers to always rely on a BigNumber type.  Oracle's JSON-B does exactly that.  Currently there is no BigNumber type in JS or .NET.
>
> There is no need for the above interface to handle floating point numbers (NR2/NR3).
>
> > - There is quite a bunch of IETF standards defining JSON structures. As far as I know none of them exploit JSON outside of its original, JS-induced limitations.
>
> Maybe the IETF was smart enough to stay in the confines of I-JSON…
>
> But really, JSON never had that particular limitation.  A JSON-based ecosystem that wants to enable the use of JavaScript JSON.parse does, as Twitter found out when they were sending their perfectly valid JSON to JavaScript applications.
>
> > - Although BigInt is a very welcome addition to JS, usages are few and typically confined to specific things like crypto or money.  Creating backward incompatibility for that is IMO counterproductive.
>
> Right, so maybe the motivation for touching JSON really isn’t that massive.
>
> > - Serializing BigInts as a string does not break anything.
>
> After JSON.parse, they are text strings then, not BigInts.
> Generally, there is the expectation that, for an interesting set of x, JSON.parse(JSON.stringify(x)) == x
> Hence the exception when you pass BigInt to JSON.stringify today.
>
> >>> Personally I think the JSON WG should be rebooted but apparently I’m rather alone with that idea.
> >> Indeed.
> >
> > That might be the case but it doesn’t solve the problem.
>
> It also doesn’t create the problem of damaging JSON by instability.
>
> >> Frankly, JSON, together with the JavaScript-induced limitations in its ecosystem as documented in RFC 7493, is not a very brilliant data interchange format.
> >
> > It seems to work well in spite of not being brilliant.
>
> Right.  As do bicycles.  Until you need to transport a sofa or cross the Atlantic.
> JSON is the right tool for a large number of jobs.
>
> > Yes, CBOR is great https://tools.ietf.org/html/rfc7049 :-)
>
> Can’t disagree here :-)
>
> Grüße, Carsten
>
> _______________________________________________
> 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: javascript vision thing

Mark Volkmann
For me the biggest thing JSON lacks is the ability to add comments.

---
R. Mark Volkmann
Object Computing, Inc.

> On Jul 25, 2018, at 4:26 AM, Isiah Meadows <[hidden email]> wrote:
>
> IMHO, I'd like to see four things:
>
> - Native JSON multi-object support
> - Binary data support that doesn't require delimiters
> - Native JSON property streaming support
> - Spec-level binary JSON support
>
> Apart from that, I don't really see anything JSON lacks.
>
> -----
>
> Isiah Meadows
> [hidden email]
> www.isiahmeadows.com
>
>> On Tue, Jul 24, 2018 at 12:43 PM, Carsten Bormann <[hidden email]> wrote:
>>
>>> On Jul 24, 2018, at 18:29, Anders Rundgren <[hidden email]> wrote:
>>>
>>>> On 2018-07-24 17:09, Carsten Bormann wrote:
>>>>> On Jul 24, 2018, at 16:31, Anders Rundgren <[hidden email]> wrote:
>>>>>
>>>>> JSON isn’t really a topic for tc39 only but since the IETF consider JSON "done", an open question is where possible future developments should take place,
>>>> No, that is not the question.
>>>>> including dealing with new data types like BigInt.
>>>> That, indeed, is a question for JavaScript.  It has nothing to do with “developing” JSON; JSON can already represent BigInt just fine.
>>>
>>> Serializing BigInt as JSON Number is the solution then?
>>
>> For applications that make good use of BigInt, I would say so.
>> So you wouldn’t use JSON.parse, but a new interface that preserves integers beyond 2**53 as BigInt (or possibly even all integers; I don’t want to design this on a napkin)
>>
>>> There are a few argument against that:
>>>
>>> - This would typically require low-level parsers to always rely on a BigNumber type.  Oracle's JSON-B does exactly that.  Currently there is no BigNumber type in JS or .NET.
>>
>> There is no need for the above interface to handle floating point numbers (NR2/NR3).
>>
>>> - There is quite a bunch of IETF standards defining JSON structures. As far as I know none of them exploit JSON outside of its original, JS-induced limitations.
>>
>> Maybe the IETF was smart enough to stay in the confines of I-JSON…
>>
>> But really, JSON never had that particular limitation.  A JSON-based ecosystem that wants to enable the use of JavaScript JSON.parse does, as Twitter found out when they were sending their perfectly valid JSON to JavaScript applications.
>>
>>> - Although BigInt is a very welcome addition to JS, usages are few and typically confined to specific things like crypto or money.  Creating backward incompatibility for that is IMO counterproductive.
>>
>> Right, so maybe the motivation for touching JSON really isn’t that massive.
>>
>>> - Serializing BigInts as a string does not break anything.
>>
>> After JSON.parse, they are text strings then, not BigInts.
>> Generally, there is the expectation that, for an interesting set of x, JSON.parse(JSON.stringify(x)) == x
>> Hence the exception when you pass BigInt to JSON.stringify today.
>>
>>>>> Personally I think the JSON WG should be rebooted but apparently I’m rather alone with that idea.
>>>> Indeed.
>>>
>>> That might be the case but it doesn’t solve the problem.
>>
>> It also doesn’t create the problem of damaging JSON by instability.
>>
>>>> Frankly, JSON, together with the JavaScript-induced limitations in its ecosystem as documented in RFC 7493, is not a very brilliant data interchange format.
>>>
>>> It seems to work well in spite of not being brilliant.
>>
>> Right.  As do bicycles.  Until you need to transport a sofa or cross the Atlantic.
>> JSON is the right tool for a large number of jobs.
>>
>>> Yes, CBOR is great https://tools.ietf.org/html/rfc7049 :-)
>>
>> Can’t disagree here :-)
>>
>> Grüße, Carsten
>>
>> _______________________________________________
>> 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: javascript vision thing

kai zhu
In reply to this post by T.J. Crowder-2
@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?


On 24 Jul 2018, at 5:56 PM, T.J. Crowder <[hidden email]> wrote:

On Tue, Jul 24, 2018 at 11:27 AM, kai zhu <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: javascript vision thing

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

On Wednesday, July 25, 2018, kai zhu <[hidden email]> 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?


On 24 Jul 2018, at 5:56 PM, T.J. Crowder <[hidden email]> wrote:

On Tue, Jul 24, 2018 at 11:27 AM, kai zhu <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: javascript vision thing

T.J. Crowder-2
In reply to this post by kai zhu
Lurkers: If I'm alone in this, please say so. If I'm **not** alone, please say so (publicly this time). Either way, I'm done as of this message other than linking back to it.

On Wed, Jul 25, 2018 at 11:33 AM, kai zhu
> 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

This is where we differ (well, one place we differ), as I've said many times before, and others have said many times before. That future is now.

How we got here is irrelevant. Where we **are** is that JavaScript is a general-purpose programming language good for a lot more than just web-related work. And "web" technologies are used for a lot more than just the web, witness all those mobile app frameworks using HTML/CSS/JavaScript, Windows store apps, Electron, etc. It's also a good language for writing *nix shell scripts and command-line utilities, particularly now that it has `async`/`await`. There are at least a dozen JavaScript engines for doing embedded device work, completely removed from the web environment. And so on.

Separately, the idea that web projects don't benefit from features like `class`, `async`/`await`, and meta-programming features and such is flatly contradicted by the evidence.

But leave all that aside. We all know you don't agree with that. You've told us, ad nauseum. It's not that we haven't heard what you're saying, it's that we disagree with it. (I say "we" because I've had private messages from people supporting my pushback on this. I wish they'd be made publicly.) Taking every vague opportunity to push your view of JavaScript as a niche, limited language is not constructive at this point. Robustly-expressed differing views are an essential part of consensus-building, but there comes a point where one has to accept that one's view has not been successful *and move on*. I think frankly we're well past that point on this topic, and have been for a while. Specific input on proposals is great, including raising specific concerns with serialization etc. (ideally with a proposed solution, but sometimes just raising a concern is useful). Putting forward constructive, specific proposals for things you think TC39 should be acting on is great. Constantly trying to push a view clearly at odds with the consensus of the community here is just not useful, and gets in the way of useful conversations we could be having, including about the things you care about getting done. Please, please move on.

And again: I think you're right that issues around JSON interop with new features like BigInt need focus (here, in the proposal itself, in some JSON working group, somewhere), and there seems to be interest in doing so. So if that's an area of interest for you, please contribute to that effort, rather than spending time beating this dead horse.

I'm not going to keep writing these replies, I'll just refer to this one from now on.

And again, lurkers, please weigh in.

-- 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: javascript vision thing

kai zhu
In reply to this post by Michael Theriot

> 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" <[hidden email]> wrote:
>
> Classes are widely used on the web. See any modern web framework.
>
>
> On Wednesday, July 25, 2018, kai zhu <[hidden email]> 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
>> [hidden email]
>>
>>> On 24 Jul 2018, at 5:56 PM, T.J. Crowder <[hidden email]> wrote:
>>>
>>> On Tue, Jul 24, 2018 at 11:27 AM, kai zhu <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: javascript vision thing

Michael Theriot
Classes are just sugar for a predominant pattern.

On Wednesday, July 25, 2018, kai zhu <[hidden email]> 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" <[hidden email]> wrote:
>
> Classes are widely used on the web. See any modern web framework.
>
>
> On Wednesday, July 25, 2018, kai zhu <[hidden email]> 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
>> [hidden email]
>>
>>> On 24 Jul 2018, at 5:56 PM, T.J. Crowder <[hidden email]> wrote:
>>>
>>> On Tue, Jul 24, 2018 at 11:27 AM, kai zhu <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: javascript vision thing

Jacob Pratt
In reply to this post by T.J. Crowder-2
Mostly a lurker here. I fully agree with your points, and also use JS for non-web projects.

On Wed, Jul 25, 2018, 07:34 T.J. Crowder <[hidden email]> wrote:
Lurkers: If I'm alone in this, please say so. If I'm **not** alone, please say so (publicly this time). Either way, I'm done as of this message other than linking back to it.

On Wed, Jul 25, 2018 at 11:33 AM, kai zhu
> 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

This is where we differ (well, one place we differ), as I've said many times before, and others have said many times before. That future is now.

How we got here is irrelevant. Where we **are** is that JavaScript is a general-purpose programming language good for a lot more than just web-related work. And "web" technologies are used for a lot more than just the web, witness all those mobile app frameworks using HTML/CSS/JavaScript, Windows store apps, Electron, etc. It's also a good language for writing *nix shell scripts and command-line utilities, particularly now that it has `async`/`await`. There are at least a dozen JavaScript engines for doing embedded device work, completely removed from the web environment. And so on.

Separately, the idea that web projects don't benefit from features like `class`, `async`/`await`, and meta-programming features and such is flatly contradicted by the evidence.

But leave all that aside. We all know you don't agree with that. You've told us, ad nauseum. It's not that we haven't heard what you're saying, it's that we disagree with it. (I say "we" because I've had private messages from people supporting my pushback on this. I wish they'd be made publicly.) Taking every vague opportunity to push your view of JavaScript as a niche, limited language is not constructive at this point. Robustly-expressed differing views are an essential part of consensus-building, but there comes a point where one has to accept that one's view has not been successful *and move on*. I think frankly we're well past that point on this topic, and have been for a while. Specific input on proposals is great, including raising specific concerns with serialization etc. (ideally with a proposed solution, but sometimes just raising a concern is useful). Putting forward constructive, specific proposals for things you think TC39 should be acting on is great. Constantly trying to push a view clearly at odds with the consensus of the community here is just not useful, and gets in the way of useful conversations we could be having, including about the things you care about getting done. Please, please move on.

And again: I think you're right that issues around JSON interop with new features like BigInt need focus (here, in the proposal itself, in some JSON working group, somewhere), and there seems to be interest in doing so. So if that's an area of interest for you, please contribute to that effort, rather than spending time beating this dead horse.

I'm not going to keep writing these replies, I'll just refer to this one from now on.

And again, lurkers, please weigh in.

-- T.J. Crowder

_______________________________________________
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: javascript vision thing

Pier Bover
Lurker here, I also agree with most points expressed by T.J. Crowder.

JavaScript is a scripting language that can serve many purposes. I think the addition of class and async/await only make the language better, and if optional static types were included (a la TypeScript or ES4) it would probably make JavaScript the best scripting language.

I also think the Node ecosystem is a mess, and that Electron is a plague, but those points are completely unrelated to the language itself. There are projects such as https://nodekit.io/ that aim to provide a bloat-free universal Electron / Cordova replacement.

On Wed, Jul 25, 2018 at 12:00 PM, Jacob Pratt <[hidden email]> wrote:
Mostly a lurker here. I fully agree with your points, and also use JS for non-web projects.

On Wed, Jul 25, 2018, 07:34 T.J. Crowder <[hidden email]> wrote:
Lurkers: If I'm alone in this, please say so. If I'm **not** alone, please say so (publicly this time). Either way, I'm done as of this message other than linking back to it.

On Wed, Jul 25, 2018 at 11:33 AM, kai zhu
> 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

This is where we differ (well, one place we differ), as I've said many times before, and others have said many times before. That future is now.

How we got here is irrelevant. Where we **are** is that JavaScript is a general-purpose programming language good for a lot more than just web-related work. And "web" technologies are used for a lot more than just the web, witness all those mobile app frameworks using HTML/CSS/JavaScript, Windows store apps, Electron, etc. It's also a good language for writing *nix shell scripts and command-line utilities, particularly now that it has `async`/`await`. There are at least a dozen JavaScript engines for doing embedded device work, completely removed from the web environment. And so on.

Separately, the idea that web projects don't benefit from features like `class`, `async`/`await`, and meta-programming features and such is flatly contradicted by the evidence.

But leave all that aside. We all know you don't agree with that. You've told us, ad nauseum. It's not that we haven't heard what you're saying, it's that we disagree with it. (I say "we" because I've had private messages from people supporting my pushback on this. I wish they'd be made publicly.) Taking every vague opportunity to push your view of JavaScript as a niche, limited language is not constructive at this point. Robustly-expressed differing views are an essential part of consensus-building, but there comes a point where one has to accept that one's view has not been successful *and move on*. I think frankly we're well past that point on this topic, and have been for a while. Specific input on proposals is great, including raising specific concerns with serialization etc. (ideally with a proposed solution, but sometimes just raising a concern is useful). Putting forward constructive, specific proposals for things you think TC39 should be acting on is great. Constantly trying to push a view clearly at odds with the consensus of the community here is just not useful, and gets in the way of useful conversations we could be having, including about the things you care about getting done. Please, please move on.

And again: I think you're right that issues around JSON interop with new features like BigInt need focus (here, in the proposal itself, in some JSON working group, somewhere), and there seems to be interest in doing so. So if that's an area of interest for you, please contribute to that effort, rather than spending time beating this dead horse.

I'm not going to keep writing these replies, I'll just refer to this one from now on.

And again, lurkers, please weigh in.

-- T.J. Crowder

_______________________________________________
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: javascript vision thing

Isiah Meadows-2
In my experience, Electron is great for prototyping, but it's a mild pain to scale, and creating packaged binaries required building a massive toolkit just to get something that worked for most cases. Bundling scripts for Node itself is still a minor pain, enough that most projects don't bother, and testing support with bundled projects is also a bit sucky. Electron doesn't really help much in this area, since it's more Node than browser, absorbing all the testing and building warts it has. Oh, and don't forget that you *have* to (at least pre-N-API) recompile native extensions to work with it, which is incredibly inconvenient to set up.

Not like this isn't solvable by more tooling, but eventually, it's going to feel like the typical Java + Maven + Ant monstrosity, just replaced with a mess of CLI apps instead. This isn't an issue for prototyping or larger apps where this might affect your workflow minimally, but it's certainly an issue when trying to scale initially. It's not really impossible, just annoying and full of potholes while you hook up all the boilerplate.

On Wed, Jul 25, 2018, 13:42 Pier Bover <[hidden email]> wrote:
Lurker here, I also agree with most points expressed by T.J. Crowder.

JavaScript is a scripting language that can serve many purposes. I think the addition of class and async/await only make the language better, and if optional static types were included (a la TypeScript or ES4) it would probably make JavaScript the best scripting language.

I also think the Node ecosystem is a mess, and that Electron is a plague, but those points are completely unrelated to the language itself. There are projects such as https://nodekit.io/ that aim to provide a bloat-free universal Electron / Cordova replacement.

On Wed, Jul 25, 2018 at 12:00 PM, Jacob Pratt <[hidden email]> wrote:
Mostly a lurker here. I fully agree with your points, and also use JS for non-web projects.

On Wed, Jul 25, 2018, 07:34 T.J. Crowder <[hidden email]> wrote:
Lurkers: If I'm alone in this, please say so. If I'm **not** alone, please say so (publicly this time). Either way, I'm done as of this message other than linking back to it.

On Wed, Jul 25, 2018 at 11:33 AM, kai zhu
> 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

This is where we differ (well, one place we differ), as I've said many times before, and others have said many times before. That future is now.

How we got here is irrelevant. Where we **are** is that JavaScript is a general-purpose programming language good for a lot more than just web-related work. And "web" technologies are used for a lot more than just the web, witness all those mobile app frameworks using HTML/CSS/JavaScript, Windows store apps, Electron, etc. It's also a good language for writing *nix shell scripts and command-line utilities, particularly now that it has `async`/`await`. There are at least a dozen JavaScript engines for doing embedded device work, completely removed from the web environment. And so on.

Separately, the idea that web projects don't benefit from features like `class`, `async`/`await`, and meta-programming features and such is flatly contradicted by the evidence.

But leave all that aside. We all know you don't agree with that. You've told us, ad nauseum. It's not that we haven't heard what you're saying, it's that we disagree with it. (I say "we" because I've had private messages from people supporting my pushback on this. I wish they'd be made publicly.) Taking every vague opportunity to push your view of JavaScript as a niche, limited language is not constructive at this point. Robustly-expressed differing views are an essential part of consensus-building, but there comes a point where one has to accept that one's view has not been successful *and move on*. I think frankly we're well past that point on this topic, and have been for a while. Specific input on proposals is great, including raising specific concerns with serialization etc. (ideally with a proposed solution, but sometimes just raising a concern is useful). Putting forward constructive, specific proposals for things you think TC39 should be acting on is great. Constantly trying to push a view clearly at odds with the consensus of the community here is just not useful, and gets in the way of useful conversations we could be having, including about the things you care about getting done. Please, please move on.

And again: I think you're right that issues around JSON interop with new features like BigInt need focus (here, in the proposal itself, in some JSON working group, somewhere), and there seems to be interest in doing so. So if that's an area of interest for you, please contribute to that effort, rather than spending time beating this dead horse.

I'm not going to keep writing these replies, I'll just refer to this one from now on.

And again, lurkers, please weigh in.

-- T.J. Crowder

_______________________________________________
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: javascript vision thing

Luan Nico
Another lurker, and I agree with both points:

 * I think JS *is* useful for way more than just the Web. It might not be my favorite language of all times, but sure is near the top and my language of choice for several non-web projects, specially bash scripts (I have simple bash utility in JS that I use daily, for instance).
 * I think the new additions were a almost a panacea for a lot of drawbacks I had with the language while developing for the web (and not), including basic frontend websites, especially things like; async/await, destructors, spread operator and default values for parameters. I sincerely cannot believe one could not see the usefulness and benefit of the latter, for instance, in any project of any type whatsoever, in a language without method overloading.

IMHO these additions shed a light on JS that made it stand on the top with the others as a completely valid, useful, powerful, easy to write and read, pretty, delightful language to code tiny or massive web apps or other projects. I like most of the discussions here, that's why I follow the list (I really like the recent Object.pick, for instance, and would personally really like to see my proposed (and many other before me of whom I was unaware) array.flatten), but this particularly topic doesn't seem very productive. Changes have been made, and I love them, but they are optional, backwards compatibility is the absolute goal.

If one has specific and well defined proposals, independent of the philosophy behind them, I'd love to see them made in other topics, specially if they come from someone who doesn't quite like what we have so far. This broad and vague rambling, OTOH, doesn't seem to be adding much. But those are just my couple cents, and in no way I incentivize banning a topic or conversation or nothing of the sort (one can just ignore it if he doesn't like to read). I have to add, if you allow me to, it's actually quite funny to skim through when you have some spare time, and can be very instructive too (some good points on both sides).

On Wed, Jul 25, 2018 at 4:05 PM Isiah Meadows <[hidden email]> wrote:
In my experience, Electron is great for prototyping, but it's a mild pain to scale, and creating packaged binaries required building a massive toolkit just to get something that worked for most cases. Bundling scripts for Node itself is still a minor pain, enough that most projects don't bother, and testing support with bundled projects is also a bit sucky. Electron doesn't really help much in this area, since it's more Node than browser, absorbing all the testing and building warts it has. Oh, and don't forget that you *have* to (at least pre-N-API) recompile native extensions to work with it, which is incredibly inconvenient to set up.

Not like this isn't solvable by more tooling, but eventually, it's going to feel like the typical Java + Maven + Ant monstrosity, just replaced with a mess of CLI apps instead. This isn't an issue for prototyping or larger apps where this might affect your workflow minimally, but it's certainly an issue when trying to scale initially. It's not really impossible, just annoying and full of potholes while you hook up all the boilerplate.

On Wed, Jul 25, 2018, 13:42 Pier Bover <[hidden email]> wrote:
Lurker here, I also agree with most points expressed by T.J. Crowder.

JavaScript is a scripting language that can serve many purposes. I think the addition of class and async/await only make the language better, and if optional static types were included (a la TypeScript or ES4) it would probably make JavaScript the best scripting language.

I also think the Node ecosystem is a mess, and that Electron is a plague, but those points are completely unrelated to the language itself. There are projects such as https://nodekit.io/ that aim to provide a bloat-free universal Electron / Cordova replacement.

On Wed, Jul 25, 2018 at 12:00 PM, Jacob Pratt <[hidden email]> wrote:
Mostly a lurker here. I fully agree with your points, and also use JS for non-web projects.

On Wed, Jul 25, 2018, 07:34 T.J. Crowder <[hidden email]> wrote:
Lurkers: If I'm alone in this, please say so. If I'm **not** alone, please say so (publicly this time). Either way, I'm done as of this message other than linking back to it.

On Wed, Jul 25, 2018 at 11:33 AM, kai zhu
> 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

This is where we differ (well, one place we differ), as I've said many times before, and others have said many times before. That future is now.

How we got here is irrelevant. Where we **are** is that JavaScript is a general-purpose programming language good for a lot more than just web-related work. And "web" technologies are used for a lot more than just the web, witness all those mobile app frameworks using HTML/CSS/JavaScript, Windows store apps, Electron, etc. It's also a good language for writing *nix shell scripts and command-line utilities, particularly now that it has `async`/`await`. There are at least a dozen JavaScript engines for doing embedded device work, completely removed from the web environment. And so on.

Separately, the idea that web projects don't benefit from features like `class`, `async`/`await`, and meta-programming features and such is flatly contradicted by the evidence.

But leave all that aside. We all know you don't agree with that. You've told us, ad nauseum. It's not that we haven't heard what you're saying, it's that we disagree with it. (I say "we" because I've had private messages from people supporting my pushback on this. I wish they'd be made publicly.) Taking every vague opportunity to push your view of JavaScript as a niche, limited language is not constructive at this point. Robustly-expressed differing views are an essential part of consensus-building, but there comes a point where one has to accept that one's view has not been successful *and move on*. I think frankly we're well past that point on this topic, and have been for a while. Specific input on proposals is great, including raising specific concerns with serialization etc. (ideally with a proposed solution, but sometimes just raising a concern is useful). Putting forward constructive, specific proposals for things you think TC39 should be acting on is great. Constantly trying to push a view clearly at odds with the consensus of the community here is just not useful, and gets in the way of useful conversations we could be having, including about the things you care about getting done. Please, please move on.

And again: I think you're right that issues around JSON interop with new features like BigInt need focus (here, in the proposal itself, in some JSON working group, somewhere), and there seems to be interest in doing so. So if that's an area of interest for you, please contribute to that effort, rather than spending time beating this dead horse.

I'm not going to keep writing these replies, I'll just refer to this one from now on.

And again, lurkers, please weigh in.

-- T.J. Crowder

_______________________________________________
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: javascript vision thing

Ranando King
Here's the funny part:

JSON = JavaScript Object Notation

If the OP wants to see improvements in JSON, why not just submit a proposal to alter what ES can do with JSON? If it makes it to stage 4, there's a pretty good chance that the standard for JSON will also change as a result. Sitting around complaining about what's wrong means nothing if you're not even willing to think about a solution and take action accordingly.

On Thu, Jul 26, 2018 at 9:55 AM Luan Nico <[hidden email]> wrote:
Another lurker, and I agree with both points:

 * I think JS *is* useful for way more than just the Web. It might not be my favorite language of all times, but sure is near the top and my language of choice for several non-web projects, specially bash scripts (I have simple bash utility in JS that I use daily, for instance).
 * I think the new additions were a almost a panacea for a lot of drawbacks I had with the language while developing for the web (and not), including basic frontend websites, especially things like; async/await, destructors, spread operator and default values for parameters. I sincerely cannot believe one could not see the usefulness and benefit of the latter, for instance, in any project of any type whatsoever, in a language without method overloading.

IMHO these additions shed a light on JS that made it stand on the top with the others as a completely valid, useful, powerful, easy to write and read, pretty, delightful language to code tiny or massive web apps or other projects. I like most of the discussions here, that's why I follow the list (I really like the recent Object.pick, for instance, and would personally really like to see my proposed (and many other before me of whom I was unaware) array.flatten), but this particularly topic doesn't seem very productive. Changes have been made, and I love them, but they are optional, backwards compatibility is the absolute goal.

If one has specific and well defined proposals, independent of the philosophy behind them, I'd love to see them made in other topics, specially if they come from someone who doesn't quite like what we have so far. This broad and vague rambling, OTOH, doesn't seem to be adding much. But those are just my couple cents, and in no way I incentivize banning a topic or conversation or nothing of the sort (one can just ignore it if he doesn't like to read). I have to add, if you allow me to, it's actually quite funny to skim through when you have some spare time, and can be very instructive too (some good points on both sides).

On Wed, Jul 25, 2018 at 4:05 PM Isiah Meadows <[hidden email]> wrote:
In my experience, Electron is great for prototyping, but it's a mild pain to scale, and creating packaged binaries required building a massive toolkit just to get something that worked for most cases. Bundling scripts for Node itself is still a minor pain, enough that most projects don't bother, and testing support with bundled projects is also a bit sucky. Electron doesn't really help much in this area, since it's more Node than browser, absorbing all the testing and building warts it has. Oh, and don't forget that you *have* to (at least pre-N-API) recompile native extensions to work with it, which is incredibly inconvenient to set up.

Not like this isn't solvable by more tooling, but eventually, it's going to feel like the typical Java + Maven + Ant monstrosity, just replaced with a mess of CLI apps instead. This isn't an issue for prototyping or larger apps where this might affect your workflow minimally, but it's certainly an issue when trying to scale initially. It's not really impossible, just annoying and full of potholes while you hook up all the boilerplate.

On Wed, Jul 25, 2018, 13:42 Pier Bover <[hidden email]> wrote:
Lurker here, I also agree with most points expressed by T.J. Crowder.

JavaScript is a scripting language that can serve many purposes. I think the addition of class and async/await only make the language better, and if optional static types were included (a la TypeScript or ES4) it would probably make JavaScript the best scripting language.

I also think the Node ecosystem is a mess, and that Electron is a plague, but those points are completely unrelated to the language itself. There are projects such as https://nodekit.io/ that aim to provide a bloat-free universal Electron / Cordova replacement.

On Wed, Jul 25, 2018 at 12:00 PM, Jacob Pratt <[hidden email]> wrote:
Mostly a lurker here. I fully agree with your points, and also use JS for non-web projects.

On Wed, Jul 25, 2018, 07:34 T.J. Crowder <[hidden email]> wrote:
Lurkers: If I'm alone in this, please say so. If I'm **not** alone, please say so (publicly this time). Either way, I'm done as of this message other than linking back to it.

On Wed, Jul 25, 2018 at 11:33 AM, kai zhu
> 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

This is where we differ (well, one place we differ), as I've said many times before, and others have said many times before. That future is now.

How we got here is irrelevant. Where we **are** is that JavaScript is a general-purpose programming language good for a lot more than just web-related work. And "web" technologies are used for a lot more than just the web, witness all those mobile app frameworks using HTML/CSS/JavaScript, Windows store apps, Electron, etc. It's also a good language for writing *nix shell scripts and command-line utilities, particularly now that it has `async`/`await`. There are at least a dozen JavaScript engines for doing embedded device work, completely removed from the web environment. And so on.

Separately, the idea that web projects don't benefit from features like `class`, `async`/`await`, and meta-programming features and such is flatly contradicted by the evidence.

But leave all that aside. We all know you don't agree with that. You've told us, ad nauseum. It's not that we haven't heard what you're saying, it's that we disagree with it. (I say "we" because I've had private messages from people supporting my pushback on this. I wish they'd be made publicly.) Taking every vague opportunity to push your view of JavaScript as a niche, limited language is not constructive at this point. Robustly-expressed differing views are an essential part of consensus-building, but there comes a point where one has to accept that one's view has not been successful *and move on*. I think frankly we're well past that point on this topic, and have been for a while. Specific input on proposals is great, including raising specific concerns with serialization etc. (ideally with a proposed solution, but sometimes just raising a concern is useful). Putting forward constructive, specific proposals for things you think TC39 should be acting on is great. Constantly trying to push a view clearly at odds with the consensus of the community here is just not useful, and gets in the way of useful conversations we could be having, including about the things you care about getting done. Please, please move on.

And again: I think you're right that issues around JSON interop with new features like BigInt need focus (here, in the proposal itself, in some JSON working group, somewhere), and there seems to be interest in doing so. So if that's an area of interest for you, please contribute to that effort, rather than spending time beating this dead horse.

I'm not going to keep writing these replies, I'll just refer to this one from now on.

And again, lurkers, please weigh in.

-- T.J. Crowder

_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: javascript vision thing

Brian Barnes-3
In reply to this post by Luan Nico
I'm a half lurker, as I've participated and thrown out ideas.

I've embedded javascript as a scripting languages outside the web, in
both personal and non-personal projects.  I've used Javascript to write
games or experiments just to amuse myself, and this is coming from a
person who still believes C is the best language :)

Everything that has been added to the language of late -- classes and
modules especially -- have been extremely useful.  I am really looking
forward to class fields.  At this point, the only thing I would like it
support for static typing but I know that less likely, full of politics,
and would be a huge lift, though we have systems that have shown us a way.

These additions have made my code more readable (everything I do is open
source), more obvious, more self-documenting, and more contained to
functional unit (modules!)

I write so much in Javascript now because it's cross platform and can
run most anywhere and browsers are strong enough to be app platforms for
many uses.  Easy start up and easy to publish your code for outside parties.

I'm happy with the direction.  Even the # private fields, I can deal
with that and frankly that actually makes things more readable!  Now,
just get us types (I know, had to end on that!)

[>] Brian

On 7/26/2018 10:55 AM, Luan Nico wrote:

> Another lurker, and I agree with both points:
>
>   * I think JS *is* useful for way more than just the Web. It might not
> be my favorite language of all times, but sure is near the top and my
> language of choice for several non-web projects, specially bash scripts
> (I have simple bash utility in JS that I use daily, for instance).
>   * I think the new additions were a almost a panacea for a lot of
> drawbacks I had with the language while developing for the web (and
> not), including basic frontend websites, especially things like;
> async/await, destructors, spread operator and default values for
> parameters. I sincerely cannot believe one could not see the usefulness
> and benefit of the latter, for instance, in any project of any type
> whatsoever, in a language without method overloading.
>
> IMHO these additions shed a light on JS that made it stand on the top
> with the others as a completely valid, useful, powerful, easy to write
> and read, pretty, delightful language to code tiny or massive web apps
> or other projects. I like most of the discussions here, that's why I
> follow the list (I really like the recent Object.pick, for instance, and
> would personally really like to see my proposed (and many other before
> me of whom I was unaware) array.flatten), but this particularly topic
> doesn't seem very productive. Changes have been made, and I love them,
> but they are optional, backwards compatibility is the absolute goal.
>
> If one has specific and well defined proposals, independent of the
> philosophy behind them, I'd love to see them made in other topics,
> specially if they come from someone who doesn't quite like what we have
> so far. This broad and vague rambling, OTOH, doesn't seem to be adding
> much. But those are just my couple cents, and in no way I incentivize
> banning a topic or conversation or nothing of the sort (one can just
> ignore it if he doesn't like to read). I have to add, if you allow me
> to, it's actually quite funny to skim through when you have some spare
> time, and can be very instructive too (some good points on both sides).
>
> On Wed, Jul 25, 2018 at 4:05 PM Isiah Meadows <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     In my experience, Electron is great for prototyping, but it's a mild
>     pain to scale, and creating packaged binaries required building a
>     massive toolkit just to get something that worked for most cases.
>     Bundling scripts for Node itself is still a minor pain, enough that
>     most projects don't bother, and testing support with bundled
>     projects is also a bit sucky. Electron doesn't really help much in
>     this area, since it's more Node than browser, absorbing all the
>     testing and building warts it has. Oh, and don't forget that you
>     *have* to (at least pre-N-API) recompile native extensions to work
>     with it, which is incredibly inconvenient to set up.
>
>     Not like this isn't solvable by more tooling, but eventually, it's
>     going to feel like the typical Java + Maven + Ant monstrosity, just
>     replaced with a mess of CLI apps instead. This isn't an issue for
>     prototyping or larger apps where this might affect your workflow
>     minimally, but it's certainly an issue when trying to scale
>     initially. It's not really impossible, just annoying and full of
>     potholes while you hook up all the boilerplate.
>
>     On Wed, Jul 25, 2018, 13:42 Pier Bover <[hidden email]
>     <mailto:[hidden email]>> wrote:
>
>         Lurker here, I also agree with most points expressed by T.J.
>         Crowder.
>
>         JavaScript is a scripting language that can serve many purposes.
>         I think the addition of class and async/await only make the
>         language better, and if optional static types were included (a
>         la TypeScript or ES4) it would probably make JavaScript the best
>         scripting language.
>
>         I also think the Node ecosystem is a mess, and that Electron is
>         a plague, but those points are completely unrelated to the
>         language itself. There are projects such as https://nodekit.io/
>         that aim to provide a bloat-free universal Electron / Cordova
>         replacement.
>
>         On Wed, Jul 25, 2018 at 12:00 PM, Jacob Pratt
>         <[hidden email] <mailto:[hidden email]>> wrote:
>
>             Mostly a lurker here. I fully agree with your points, and
>             also use JS for non-web projects.
>
>             On Wed, Jul 25, 2018, 07:34 T.J. Crowder
>             <[hidden email]
>             <mailto:[hidden email]>> wrote:
>
>                 Lurkers: If I'm alone in this, please say so. If I'm
>                 **not** alone, please say so (publicly this time).
>                 Either way, I'm done as of this message other than
>                 linking back to it.
>
>                 On Wed, Jul 25, 2018 at 11:33 AM, kai zhu
>                 <[hidden email] <mailto:[hidden email]>> wrote:
>                  > 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
>
>                 This is where we differ (well, one place we differ), as
>                 I've said many times before, and others have said many
>                 times before. That future is now.
>
>                 How we got here is irrelevant. Where we **are** is that
>                 JavaScript is a general-purpose programming language
>                 good for a lot more than just web-related work. And
>                 "web" technologies are used for a lot more than just the
>                 web, witness all those mobile app frameworks using
>                 HTML/CSS/JavaScript, Windows store apps, Electron, etc.
>                 It's also a good language for writing *nix shell scripts
>                 and command-line utilities, particularly now that it has
>                 `async`/`await`. There are at least a dozen JavaScript
>                 engines for doing embedded device work, completely
>                 removed from the web environment. And so on.
>
>                 Separately, the idea that web projects don't benefit
>                 from features like `class`, `async`/`await`, and
>                 meta-programming features and such is flatly
>                 contradicted by the evidence.
>
>                 But leave all that aside. We all know you don't agree
>                 with that. You've told us, ad nauseum. It's not that we
>                 haven't heard what you're saying, it's that we disagree
>                 with it. (I say "we" because I've had private messages
>                 from people supporting my pushback on this. I wish
>                 they'd be made publicly.) Taking every vague opportunity
>                 to push your view of JavaScript as a niche, limited
>                 language is not constructive at this point.
>                 Robustly-expressed differing views are an essential part
>                 of consensus-building, but there comes a point where one
>                 has to accept that one's view has not been successful
>                 *and move on*. I think frankly we're well past that
>                 point on this topic, and have been for a while. Specific
>                 input on proposals is great, including raising specific
>                 concerns with serialization etc. (ideally with a
>                 proposed solution, but sometimes just raising a concern
>                 is useful). Putting forward constructive, specific
>                 proposals for things you think TC39 should be acting on
>                 is great. Constantly trying to push a view clearly at
>                 odds with the consensus of the community here is just
>                 not useful, and gets in the way of useful conversations
>                 we could be having, including about the things you care
>                 about getting done. Please, please move on.
>
>                 And again: I think you're right that issues around JSON
>                 interop with new features like BigInt need focus (here,
>                 in the proposal itself, in some JSON working group,
>                 somewhere), and there seems to be interest in doing so.
>                 So if that's an area of interest for you, please
>                 contribute to that effort, rather than spending time
>                 beating this dead horse.
>
>                 I'm not going to keep writing these replies, I'll just
>                 refer to this one from now on.
>
>                 And again, lurkers, please weigh in.
>
>                 -- T.J. Crowder
>
>                 _______________________________________________
>                 es-discuss mailing list
>                 [hidden email] <mailto:[hidden email]>
>                 https://mail.mozilla.org/listinfo/es-discuss
>
>
>             _______________________________________________
>             es-discuss mailing list
>             [hidden email] <mailto:[hidden email]>
>             https://mail.mozilla.org/listinfo/es-discuss
>
>
>         _______________________________________________
>         es-discuss mailing list
>         [hidden email] <mailto:[hidden email]>
>         https://mail.mozilla.org/listinfo/es-discuss
>
>     _______________________________________________
>     es-discuss mailing list
>     [hidden email] <mailto:[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: javascript vision thing

Anders Rundgren-2
In reply to this post by Ranando King
On 2018-07-26 17:24, Ranando King wrote:
> JSON = JavaScript Object Notation

This obviously broke down when tc39 introduced BigInt leaving the JSON/JS community in limbo.

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

Re: javascript vision thing

T.J. Crowder-2
On Thu, Jul 26, 2018 at 5:23 PM, Anders Rundgren
<[hidden email]> wrote:
> On 2018-07-26 17:24, Ranando King wrote:
>>
>> JSON = JavaScript Object Notation
>
> This obviously broke down when tc39 introduced BigInt leaving the JSON/JS
> community in limbo.

Not supporting all of JavaScript's features is nothing new. JSON
doesn't handle Date instances, Maps, Sets, or Symbols as values either
(much less Symbols as keys).

But JSON support for BigInt (or BitInt support JSON, whatever) is
something to pick up in [its thread][1], not here.

-- T.J. Crowder

[1]: https://esdiscuss.org/topic/json-support-for-bigint-in-chrome-v8
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: javascript vision thing

Jordan Harband
In reply to this post by Anders Rundgren-2
That's a ridiculous claim, considering JSON has never supported functions, or `undefined`, or RegExps, or Dates.

ES6 also introduced `Symbol`, `Map`, `Set`, etc all of which have no JSON representation.

There's no "limbo" - JSON is, and will forever be, a subset of JS. Many new things will be added to JS, and *none* of them will likely ever be added to JSON at this point.

On Thu, Jul 26, 2018 at 9:23 AM, Anders Rundgren <[hidden email]> wrote:
On 2018-07-26 17:24, Ranando King wrote:
JSON = JavaScript Object Notation

This obviously broke down when tc39 introduced BigInt leaving the JSON/JS community in limbo.

Anders

_______________________________________________
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
12345