javascript vision thing

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

javascript vision thing

kai zhu
any thoughts? i'll break the ice with a quora question i recently answered

quora question:
> Why is JavaScript so hated?

answer posted:
>the primary reason is because traditional oop skills gained from c#/c++/java/python/etc translate poorly to javascript.
>
>in javascript, class-instantiated objects are inferior to plain-objects, because plain-objects come with JSON.stringify/JSON.parse baked-in, while classes require needless extra serialization/deserialization routines which can easily double your codebase or more (as real-world javascript-code is heavily i/o based). i would say many people burn-out from frontend-programming because they can’t cope with debugging all the i/o edge-cases serializing/deserializing their custom classes.
>
>javascript and frontend-programming is essentially about efficiently managing the program-state like a baton, constantly passing it back-and-forth between the browser’s ui and various backend-servers / persistent-storage. plain json-objects utilizing idiot-proof JSON.stringify/JSON.parse, are naturally better at this baton-passing business than writing classes with custom serializers.



there's currently a civil war going on in frontend-development,
between those who don't want to deal with writing extra class-based
serializers/deserializers and those who do.  these 2 different design
patterns have incompatible styleguides that often break web-projects
when people try to mix-and-match both together.  i don't have a simple
solution to this issue, but tc39 should be made aware of it as they
try to formulate a javascript vision that doesn't alienate
frontend-development.

-kai
_______________________________________________
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
I'm really not sure what "civil war" you're referring to; nor do I agree that JavaScript is any more hated than anything else.

Plain objects don't come with JSON representations "baked in" because functions, undefined, regexes, dates, etc all don't serialize.

Frontend development is not "alienated"; in fact, the additions made in ES6 are widely loved overall (even though there are, as with anything, scattered complaints).

On Wed, Nov 1, 2017 at 8:43 PM, kai zhu <[hidden email]> wrote:
any thoughts? i'll break the ice with a quora question i recently answered

quora question:
> Why is JavaScript so hated?

answer posted:
>the primary reason is because traditional oop skills gained from c#/c++/java/python/etc translate poorly to javascript.
>
>in javascript, class-instantiated objects are inferior to plain-objects, because plain-objects come with JSON.stringify/JSON.parse baked-in, while classes require needless extra serialization/deserialization routines which can easily double your codebase or more (as real-world javascript-code is heavily i/o based). i would say many people burn-out from frontend-programming because they can’t cope with debugging all the i/o edge-cases serializing/deserializing their custom classes.
>
>javascript and frontend-programming is essentially about efficiently managing the program-state like a baton, constantly passing it back-and-forth between the browser’s ui and various backend-servers / persistent-storage. plain json-objects utilizing idiot-proof JSON.stringify/JSON.parse, are naturally better at this baton-passing business than writing classes with custom serializers.



there's currently a civil war going on in frontend-development,
between those who don't want to deal with writing extra class-based
serializers/deserializers and those who do.  these 2 different design
patterns have incompatible styleguides that often break web-projects
when people try to mix-and-match both together.  i don't have a simple
solution to this issue, but tc39 should be made aware of it as they
try to formulate a javascript vision that doesn't alienate
frontend-development.

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

T.J. Crowder-2
On Thu, Nov 2, 2017 at 3:43 AM, kai zhu <[hidden email]> wrote:
> any thoughts? i'll break the ice with a quora question i recently answered

Link to that answer for those who are interested:

> > Why is JavaScript so hated?

I have seen no indication that it is. Quite the reverse. And like Jordan, I see a lot of love for the improvements in ES2015 and ES2017 (and many of the current Stage 3 proposals which seem likely to make it to ES2018, like object rest/spread).

> the primary reason is because traditional oop skills gained from
> c#/c++/java/python/etc translate poorly to javascript.

I disagree. Understanding the concepts of objects and object references, creation patterns (constructor, builder, etc.), functions/methods, pass-by-value (which is dominant in those languages), mutability vs. immutability -- all of these are just the same.

Yes, the fact JavaScript used Java syntax but is prototype-based rather than class-based can trip people up if they don't have experience of prototype-based languages (which are less common today than class-based ones) and don't bother to read a tutorial or two before jumping in. (Disclosure: I made that mistake, years ago.) There are things to learn in any new language. I see Java people tripped up by generics or nested classes every bit as much.

> in javascript, class-instantiated objects are inferior to
> plain-objects, because plain-objects come with
> JSON.stringify/JSON.parse baked-in

No more or less so than objects created with other constructors.

> ..., while classes require
> needless extra serialization/deserialization routines
> which can easily double your codebase or more (as
real-world javascript-code is heavily i/o based).

First, if serialization code is doubling your codebase, you're doing it wrong. :-)

But more importantly, no, serialization is no easier with objects created only with the Object constructor than it is with objects created with other constructors. In both cases, if you want true objects (not just property bags), you have to reattach their methods. Doing so is not difficult.

> javascript and frontend-programming...

False conflation.

> ...there's currently a civil war going on in frontend-development,

The gentlest characterization I can make of that statement is that it's...hyperbolic. There is no civil war. There are a couple of different object creation patterns, and some people use one kind, and other people use another kind. In both cases, you end up with objects with properties and methods, which can interoperate just fine. It's like claiming there's a civil war in the Java world because some projects use constructors and others use the Builder pattern. E.g., a gross mischaracterization.

-- T.J. Crowder


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

FW: javascript vision thing

doodad-js Admin
In reply to this post by kai zhu

-----Original Message-----
From: Claude Petit [mailto:[hidden email]]
Sent: Thursday, November 02, 2017 4:24 PM
To: 'kai zhu' <[hidden email]>; 'es-discuss' <[hidden email]>
Subject: RE: javascript vision thing

For mostly real OOP under JS, please see my project (doodad-js). But I can't warranty its future without a custom language because nobody on TC39 want to works along-side with me on that project, and they are making their own supposed "classes" which are not.

-----Original Message-----
From: kai zhu [mailto:[hidden email]]
Sent: Wednesday, November 01, 2017 11:43 PM
To: es-discuss <[hidden email]>
Subject: javascript vision thing

any thoughts? i'll break the ice with a quora question i recently answered

quora question:
> Why is JavaScript so hated?

answer posted:
>the primary reason is because traditional oop skills gained from c#/c++/java/python/etc translate poorly to javascript.
>
>in javascript, class-instantiated objects are inferior to plain-objects, because plain-objects come with JSON.stringify/JSON.parse baked-in, while classes require needless extra serialization/deserialization routines which can easily double your codebase or more (as real-world javascript-code is heavily i/o based). i would say many people burn-out from frontend-programming because they can’t cope with debugging all the i/o edge-cases serializing/deserializing their custom classes.
>
>javascript and frontend-programming is essentially about efficiently managing the program-state like a baton, constantly passing it back-and-forth between the browser’s ui and various backend-servers / persistent-storage. plain json-objects utilizing idiot-proof JSON.stringify/JSON.parse, are naturally better at this baton-passing business than writing classes with custom serializers.



there's currently a civil war going on in frontend-development, between those who don't want to deal with writing extra class-based serializers/deserializers and those who do.  these 2 different design patterns have incompatible styleguides that often break web-projects when people try to mix-and-match both together.  i don't have a simple solution to this issue, but tc39 should be made aware of it as they try to formulate a javascript vision that doesn't alienate frontend-development.

-kai



---
This email has been checked for viruses by AVG.
http://www.avg.com

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

Re: FW: javascript vision thing

Isiah Meadows-2
Honestly, this entire thread reads as partially misinformed,
borderline trollbait. These kinds of questions and thoughts should
really be asked directly (and a bit more respectfully) to TC39
representatives and/or put in blog posts wherever. es-discuss is
primarily about language design, and although the subject implies it's
about the language's design in the abstract, I'm not convinced the
content and responses really are.

1. Claims of a language "civil war" don't belong on this list, and are
objectively false. Yes, there's disagreement, but even TC39 members
aren't exactly in agreement here - consider the difference between
Lodash/Ecmarkdown (Domenic Denicola) and Ecmarkup (Brian Terlson).
Please take that into account.
2. Yes, there are multiple idiomatic uses of JavaScript, but it's
large enough you can carve out a subset and be done with it. You don't
like classes? Don't use them. You don't like arrow functions? Don't
use them. You don't like `array.map`? Don't use it. Just because they
exist doesn't obligate you to use them, and they don't hurt you in any
way if you don't. Also, complaints of a person's or group's choice of
idiom do *not* belong on this list whatsoever. Leave that crap to a
private message, a blog post (if it's a group), or whatever.
3. JavaScript "classes" are not technically class-based OOP, and TC39
members have acknowledged this in blog posts. It's 99% sugar over the
existing prototype-based model, just with easier native subclassing.
You could in theory replicate this in the rest of the language with a
combination of `Object.defineProperty`, `Object.setPrototypeOf`,
`new.target`, and existing ES5.
-----

Isiah Meadows
[hidden email]

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com


On Thu, Nov 2, 2017 at 4:32 PM, doodad-js Admin <[hidden email]> wrote:

>
> -----Original Message-----
> From: Claude Petit [mailto:[hidden email]]
> Sent: Thursday, November 02, 2017 4:24 PM
> To: 'kai zhu' <[hidden email]>; 'es-discuss' <[hidden email]>
> Subject: RE: javascript vision thing
>
> For mostly real OOP under JS, please see my project (doodad-js). But I can't warranty its future without a custom language because nobody on TC39 want to works along-side with me on that project, and they are making their own supposed "classes" which are not.
>
> -----Original Message-----
> From: kai zhu [mailto:[hidden email]]
> Sent: Wednesday, November 01, 2017 11:43 PM
> To: es-discuss <[hidden email]>
> Subject: javascript vision thing
>
> any thoughts? i'll break the ice with a quora question i recently answered
>
> quora question:
>> Why is JavaScript so hated?
>
> answer posted:
>>the primary reason is because traditional oop skills gained from c#/c++/java/python/etc translate poorly to javascript.
>>
>>in javascript, class-instantiated objects are inferior to plain-objects, because plain-objects come with JSON.stringify/JSON.parse baked-in, while classes require needless extra serialization/deserialization routines which can easily double your codebase or more (as real-world javascript-code is heavily i/o based). i would say many people burn-out from frontend-programming because they can’t cope with debugging all the i/o edge-cases serializing/deserializing their custom classes.
>>
>>javascript and frontend-programming is essentially about efficiently managing the program-state like a baton, constantly passing it back-and-forth between the browser’s ui and various backend-servers / persistent-storage. plain json-objects utilizing idiot-proof JSON.stringify/JSON.parse, are naturally better at this baton-passing business than writing classes with custom serializers.
>
>
>
> there's currently a civil war going on in frontend-development, between those who don't want to deal with writing extra class-based serializers/deserializers and those who do.  these 2 different design patterns have incompatible styleguides that often break web-projects when people try to mix-and-match both together.  i don't have a simple solution to this issue, but tc39 should be made aware of it as they try to formulate a javascript vision that doesn't alienate frontend-development.
>
> -kai
>
>
>
> ---
> This email has been checked for viruses by AVG.
> http://www.avg.com
>
> _______________________________________________
> 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: FW: javascript vision thing

Andrea Giammarchi-2
I agree with everything else you said but since you mentioned the word "misinformed" I'd like to improve this misleading sentence:

It's 99% sugar over the existing prototype-based model

This has been one of the most misunderstood and undertaken parts of ES6.

Classes are *not* just sugar, thinking about classes as just sugar that can be replicated on ES5 is FUD and even if I've pointed out Babel documentation has a wrong description of classes it's still there and 99% of developers believe classes are like that, just sugar over prototypal inheritance.

This is so wrong that TypeScript fails with the most basic extend:

```js
class List extends Array { method() {} }

(new List) instanceof List; // false
(new List).method(); // throws because it's not a List so no method
```

To simulate ES2015 classes you need `Reflect.construct`, unavailable in ES5.
Polyfilling Reflect.construct with ES5 features is not enough: you need Symbols too.

Symbols are technically impossible to polyfill (i've gone very close, yet not a perfect poly).
Symbols are needed to keep the instance so that in a transpiled world:

```js
(new List).slice() instanceof List; // true
```

Most developers that went for classes have broken code out of the box thanks to transpilers and yet at the end of 2017 we keep writing that ES classes are just sugar on top of ES5.

We should stop starting from this ML to keep spreading this wrong information.

Thank you all for your understanding.

Regards







On Fri, Nov 3, 2017 at 4:49 AM, Isiah Meadows <[hidden email]> wrote:
Honestly, this entire thread reads as partially misinformed,
borderline trollbait. These kinds of questions and thoughts should
really be asked directly (and a bit more respectfully) to TC39
representatives and/or put in blog posts wherever. es-discuss is
primarily about language design, and although the subject implies it's
about the language's design in the abstract, I'm not convinced the
content and responses really are.

1. Claims of a language "civil war" don't belong on this list, and are
objectively false. Yes, there's disagreement, but even TC39 members
aren't exactly in agreement here - consider the difference between
Lodash/Ecmarkdown (Domenic Denicola) and Ecmarkup (Brian Terlson).
Please take that into account.
2. Yes, there are multiple idiomatic uses of JavaScript, but it's
large enough you can carve out a subset and be done with it. You don't
like classes? Don't use them. You don't like arrow functions? Don't
use them. You don't like `array.map`? Don't use it. Just because they
exist doesn't obligate you to use them, and they don't hurt you in any
way if you don't. Also, complaints of a person's or group's choice of
idiom do *not* belong on this list whatsoever. Leave that crap to a
private message, a blog post (if it's a group), or whatever.
3. JavaScript "classes" are not technically class-based OOP, and TC39
members have acknowledged this in blog posts. It's 99% sugar over the
existing prototype-based model, just with easier native subclassing.
You could in theory replicate this in the rest of the language with a
combination of `Object.defineProperty`, `Object.setPrototypeOf`,
`new.target`, and existing ES5.
-----

Isiah Meadows
[hidden email]

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com


On Thu, Nov 2, 2017 at 4:32 PM, doodad-js Admin <[hidden email]> wrote:
>
> -----Original Message-----
> From: Claude Petit [mailto:[hidden email]]
> Sent: Thursday, November 02, 2017 4:24 PM
> To: 'kai zhu' <[hidden email]>; 'es-discuss' <[hidden email]>
> Subject: RE: javascript vision thing
>
> For mostly real OOP under JS, please see my project (doodad-js). But I can't warranty its future without a custom language because nobody on TC39 want to works along-side with me on that project, and they are making their own supposed "classes" which are not.
>
> -----Original Message-----
> From: kai zhu [mailto:[hidden email]]
> Sent: Wednesday, November 01, 2017 11:43 PM
> To: es-discuss <[hidden email]>
> Subject: javascript vision thing
>
> any thoughts? i'll break the ice with a quora question i recently answered
>
> quora question:
>> Why is JavaScript so hated?
>
> answer posted:
>>the primary reason is because traditional oop skills gained from c#/c++/java/python/etc translate poorly to javascript.
>>
>>in javascript, class-instantiated objects are inferior to plain-objects, because plain-objects come with JSON.stringify/JSON.parse baked-in, while classes require needless extra serialization/deserialization routines which can easily double your codebase or more (as real-world javascript-code is heavily i/o based). i would say many people burn-out from frontend-programming because they can’t cope with debugging all the i/o edge-cases serializing/deserializing their custom classes.
>>
>>javascript and frontend-programming is essentially about efficiently managing the program-state like a baton, constantly passing it back-and-forth between the browser’s ui and various backend-servers / persistent-storage. plain json-objects utilizing idiot-proof JSON.stringify/JSON.parse, are naturally better at this baton-passing business than writing classes with custom serializers.
>
>
>
> there's currently a civil war going on in frontend-development, between those who don't want to deal with writing extra class-based serializers/deserializers and those who do.  these 2 different design patterns have incompatible styleguides that often break web-projects when people try to mix-and-match both together.  i don't have a simple solution to this issue, but tc39 should be made aware of it as they try to formulate a javascript vision that doesn't alienate frontend-development.
>
> -kai
>
>
>
> ---
> This email has been checked for viruses by AVG.
> http://www.avg.com
>
> _______________________________________________
> 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: FW: javascript vision thing

kai zhu
it may be standard-operating-procedure to sub-class builtin arrays in
other languages.  but it becomes awkward in javascript when time comes
around to serializing/reconstructing the custom array-type while
baton-passing it around frontend<->backend<->database via JSON.

On 11/3/17, Andrea Giammarchi <[hidden email]> wrote:

> I agree with everything else you said but since you mentioned the word
> "misinformed" I'd like to improve this misleading sentence:
>
>> It's 99% sugar over the existing prototype-based model
>
> This has been one of the most misunderstood and undertaken parts of ES6.
>
> Classes are *not* just sugar, thinking about classes as just sugar that can
> be replicated on ES5 is FUD and even if I've pointed out Babel
> documentation has a wrong description of classes it's still there and 99%
> of developers believe classes are like that, just sugar over prototypal
> inheritance.
>
> This is so wrong that TypeScript fails with the most basic extend:
>
> ```js
> class List extends Array { method() {} }
>
> (new List) instanceof List; // false
> (new List).method(); // throws because it's not a List so no method
> ```
>
> To simulate ES2015 classes you need `Reflect.construct`, unavailable in
> ES5.
> Polyfilling Reflect.construct with ES5 features is not enough: you need
> Symbols too.
>
> Symbols are technically impossible to polyfill (i've gone very close, yet
> not a perfect poly).
> Symbols are needed to keep the instance so that in a transpiled world:
>
> ```js
> (new List).slice() instanceof List; // true
> ```
>
> Most developers that went for classes have broken code out of the box
> thanks to transpilers and yet at the end of 2017 we keep writing that ES
> classes are just sugar on top of ES5.
>
> We should stop starting from this ML to keep spreading this wrong
> information.
>
> Thank you all for your understanding.
>
> Regards
>
>
>
>
>
>
>
> On Fri, Nov 3, 2017 at 4:49 AM, Isiah Meadows <[hidden email]>
> wrote:
>
>> Honestly, this entire thread reads as partially misinformed,
>> borderline trollbait. These kinds of questions and thoughts should
>> really be asked directly (and a bit more respectfully) to TC39
>> representatives and/or put in blog posts wherever. es-discuss is
>> primarily about language design, and although the subject implies it's
>> about the language's design in the abstract, I'm not convinced the
>> content and responses really are.
>>
>> 1. Claims of a language "civil war" don't belong on this list, and are
>> objectively false. Yes, there's disagreement, but even TC39 members
>> aren't exactly in agreement here - consider the difference between
>> Lodash/Ecmarkdown (Domenic Denicola) and Ecmarkup (Brian Terlson).
>> Please take that into account.
>> 2. Yes, there are multiple idiomatic uses of JavaScript, but it's
>> large enough you can carve out a subset and be done with it. You don't
>> like classes? Don't use them. You don't like arrow functions? Don't
>> use them. You don't like `array.map`? Don't use it. Just because they
>> exist doesn't obligate you to use them, and they don't hurt you in any
>> way if you don't. Also, complaints of a person's or group's choice of
>> idiom do *not* belong on this list whatsoever. Leave that crap to a
>> private message, a blog post (if it's a group), or whatever.
>> 3. JavaScript "classes" are not technically class-based OOP, and TC39
>> members have acknowledged this in blog posts. It's 99% sugar over the
>> existing prototype-based model, just with easier native subclassing.
>> You could in theory replicate this in the rest of the language with a
>> combination of `Object.defineProperty`, `Object.setPrototypeOf`,
>> `new.target`, and existing ES5.
>> -----
>>
>> Isiah Meadows
>> [hidden email]
>>
>> Looking for web consulting? Or a new website?
>> Send me an email and we can get started.
>> www.isiahmeadows.com
>>
>>
>> On Thu, Nov 2, 2017 at 4:32 PM, doodad-js Admin <[hidden email]>
>> wrote:
>> >
>> > -----Original Message-----
>> > From: Claude Petit [mailto:[hidden email]]
>> > Sent: Thursday, November 02, 2017 4:24 PM
>> > To: 'kai zhu' <[hidden email]>; 'es-discuss' <
>> [hidden email]>
>> > Subject: RE: javascript vision thing
>> >
>> > For mostly real OOP under JS, please see my project (doodad-js). But I
>> can't warranty its future without a custom language because nobody on
>> TC39
>> want to works along-side with me on that project, and they are making
>> their
>> own supposed "classes" which are not.
>> >
>> > -----Original Message-----
>> > From: kai zhu [mailto:[hidden email]]
>> > Sent: Wednesday, November 01, 2017 11:43 PM
>> > To: es-discuss <[hidden email]>
>> > Subject: javascript vision thing
>> >
>> > any thoughts? i'll break the ice with a quora question i recently
>> answered
>> >
>> > quora question:
>> >> Why is JavaScript so hated?
>> >
>> > answer posted:
>> >>the primary reason is because traditional oop skills gained from
>> c#/c++/java/python/etc translate poorly to javascript.
>> >>
>> >>in javascript, class-instantiated objects are inferior to
>> >> plain-objects,
>> because plain-objects come with JSON.stringify/JSON.parse baked-in, while
>> classes require needless extra serialization/deserialization routines
>> which
>> can easily double your codebase or more (as real-world javascript-code is
>> heavily i/o based). i would say many people burn-out from
>> frontend-programming because they can’t cope with debugging all the i/o
>> edge-cases serializing/deserializing their custom classes.
>> >>
>> >>javascript and frontend-programming is essentially about efficiently
>> managing the program-state like a baton, constantly passing it
>> back-and-forth between the browser’s ui and various backend-servers /
>> persistent-storage. plain json-objects utilizing idiot-proof
>> JSON.stringify/JSON.parse, are naturally better at this baton-passing
>> business than writing classes with custom serializers.
>> >
>> >
>> >
>> > there's currently a civil war going on in frontend-development, between
>> those who don't want to deal with writing extra class-based
>> serializers/deserializers and those who do.  these 2 different design
>> patterns have incompatible styleguides that often break web-projects when
>> people try to mix-and-match both together.  i don't have a simple
>> solution
>> to this issue, but tc39 should be made aware of it as they try to
>> formulate
>> a javascript vision that doesn't alienate frontend-development.
>> >
>> > -kai
>> >
>> >
>> >
>> > ---
>> > This email has been checked for viruses by AVG.
>> > http://www.avg.com
>> >
>> > _______________________________________________
>> > 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: FW: javascript vision thing

Jeremy Martin
it becomes awkward in javascript when time comes
> around to serializing/reconstructing the custom array-type

To be honest, I've found that overriding `toJSON()` and providing some static helpers for your `JSON.parse()` reviver lead to pretty expressive (de)serializability:

class MySerializableArray extends Array {
  
  toJSON() {
    return {
      $type: this.constructor.name,
      items: Object.values(this)
    }
  }
  
  static isSerializedInstance(val) {
    return typeof val === 'object' &&
        val.$type === 'MySerializableArray' &&
        Array.isArray(val.items);
  }
  
}

const reviver = (key, val) => {
  if (MySerializableArray.isSerializedInstance(val)) {
    return new MySerializableArray(...val.items);
  }
  return val;
};

const instance = new MySerializableArray('a', 'b', 'c'),
      serialized = JSON.stringify(instance),
      parsed = JSON.parse(serialized, reviver);


If that's too much boilerplate for you, there's probably some low hanging fruit for a decorator implementation that generalizes some reasonable default serialization behavior.


On Sat, Nov 25, 2017 at 2:14 AM, kai zhu <[hidden email]> wrote:
it may be standard-operating-procedure to sub-class builtin arrays in
other languages.  but it becomes awkward in javascript when time comes
around to serializing/reconstructing the custom array-type while
baton-passing it around frontend<->backend<->database via JSON.

On 11/3/17, Andrea Giammarchi <[hidden email]> wrote:
> I agree with everything else you said but since you mentioned the word
> "misinformed" I'd like to improve this misleading sentence:
>
>> It's 99% sugar over the existing prototype-based model
>
> This has been one of the most misunderstood and undertaken parts of ES6.
>
> Classes are *not* just sugar, thinking about classes as just sugar that can
> be replicated on ES5 is FUD and even if I've pointed out Babel
> documentation has a wrong description of classes it's still there and 99%
> of developers believe classes are like that, just sugar over prototypal
> inheritance.
>
> This is so wrong that TypeScript fails with the most basic extend:
>
> ```js
> class List extends Array { method() {} }
>
> (new List) instanceof List; // false
> (new List).method(); // throws because it's not a List so no method
> ```
>
> To simulate ES2015 classes you need `Reflect.construct`, unavailable in
> ES5.
> Polyfilling Reflect.construct with ES5 features is not enough: you need
> Symbols too.
>
> Symbols are technically impossible to polyfill (i've gone very close, yet
> not a perfect poly).
> Symbols are needed to keep the instance so that in a transpiled world:
>
> ```js
> (new List).slice() instanceof List; // true
> ```
>
> Most developers that went for classes have broken code out of the box
> thanks to transpilers and yet at the end of 2017 we keep writing that ES
> classes are just sugar on top of ES5.
>
> We should stop starting from this ML to keep spreading this wrong
> information.
>
> Thank you all for your understanding.
>
> Regards
>
>
>
>
>
>
>
> On Fri, Nov 3, 2017 at 4:49 AM, Isiah Meadows <[hidden email]>
> wrote:
>
>> Honestly, this entire thread reads as partially misinformed,
>> borderline trollbait. These kinds of questions and thoughts should
>> really be asked directly (and a bit more respectfully) to TC39
>> representatives and/or put in blog posts wherever. es-discuss is
>> primarily about language design, and although the subject implies it's
>> about the language's design in the abstract, I'm not convinced the
>> content and responses really are.
>>
>> 1. Claims of a language "civil war" don't belong on this list, and are
>> objectively false. Yes, there's disagreement, but even TC39 members
>> aren't exactly in agreement here - consider the difference between
>> Lodash/Ecmarkdown (Domenic Denicola) and Ecmarkup (Brian Terlson).
>> Please take that into account.
>> 2. Yes, there are multiple idiomatic uses of JavaScript, but it's
>> large enough you can carve out a subset and be done with it. You don't
>> like classes? Don't use them. You don't like arrow functions? Don't
>> use them. You don't like `array.map`? Don't use it. Just because they
>> exist doesn't obligate you to use them, and they don't hurt you in any
>> way if you don't. Also, complaints of a person's or group's choice of
>> idiom do *not* belong on this list whatsoever. Leave that crap to a
>> private message, a blog post (if it's a group), or whatever.
>> 3. JavaScript "classes" are not technically class-based OOP, and TC39
>> members have acknowledged this in blog posts. It's 99% sugar over the
>> existing prototype-based model, just with easier native subclassing.
>> You could in theory replicate this in the rest of the language with a
>> combination of `Object.defineProperty`, `Object.setPrototypeOf`,
>> `new.target`, and existing ES5.
>> -----
>>
>> Isiah Meadows
>> [hidden email]
>>
>> Looking for web consulting? Or a new website?
>> Send me an email and we can get started.
>> www.isiahmeadows.com
>>
>>
>> On Thu, Nov 2, 2017 at 4:32 PM, doodad-js Admin <[hidden email]>
>> wrote:
>> >
>> > -----Original Message-----
>> > From: Claude Petit [mailto:[hidden email]]
>> > Sent: Thursday, November 02, 2017 4:24 PM
>> > To: 'kai zhu' <[hidden email]>; 'es-discuss' <
>> [hidden email]>
>> > Subject: RE: javascript vision thing
>> >
>> > For mostly real OOP under JS, please see my project (doodad-js). But I
>> can't warranty its future without a custom language because nobody on
>> TC39
>> want to works along-side with me on that project, and they are making
>> their
>> own supposed "classes" which are not.
>> >
>> > -----Original Message-----
>> > From: kai zhu [mailto:[hidden email]]
>> > Sent: Wednesday, November 01, 2017 11:43 PM
>> > To: es-discuss <[hidden email]>
>> > Subject: javascript vision thing
>> >
>> > any thoughts? i'll break the ice with a quora question i recently
>> answered
>> >
>> > quora question:
>> >> Why is JavaScript so hated?
>> >
>> > answer posted:
>> >>the primary reason is because traditional oop skills gained from
>> c#/c++/java/python/etc translate poorly to javascript.
>> >>
>> >>in javascript, class-instantiated objects are inferior to
>> >> plain-objects,
>> because plain-objects come with JSON.stringify/JSON.parse baked-in, while
>> classes require needless extra serialization/deserialization routines
>> which
>> can easily double your codebase or more (as real-world javascript-code is
>> heavily i/o based). i would say many people burn-out from
>> frontend-programming because they can’t cope with debugging all the i/o
>> edge-cases serializing/deserializing their custom classes.
>> >>
>> >>javascript and frontend-programming is essentially about efficiently
>> managing the program-state like a baton, constantly passing it
>> back-and-forth between the browser’s ui and various backend-servers /
>> persistent-storage. plain json-objects utilizing idiot-proof
>> JSON.stringify/JSON.parse, are naturally better at this baton-passing
>> business than writing classes with custom serializers.
>> >
>> >
>> >
>> > there's currently a civil war going on in frontend-development, between
>> those who don't want to deal with writing extra class-based
>> serializers/deserializers and those who do.  these 2 different design
>> patterns have incompatible styleguides that often break web-projects when
>> people try to mix-and-match both together.  i don't have a simple
>> solution
>> to this issue, but tc39 should be made aware of it as they try to
>> formulate
>> a javascript vision that doesn't alienate frontend-development.
>> >
>> > -kai
>> >
>> >
>> >
>> > ---
>> > This email has been checked for viruses by AVG.
>> > http://www.avg.com
>> >
>> > _______________________________________________
>> > 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



--
Jeremy Martin
661.312.3853

_______________________________________________
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

Florian Bösch
In reply to this post by kai zhu
On Thu, Nov 2, 2017 at 4:43 AM, kai zhu <[hidden email]> wrote:
> the primary reason is because traditional oop skills gained from c#/c++/java/python/etc translate poorly to javascript.
I've never found that to be the case.

>in javascript, class-instantiated objects are inferior to plain-objects, because plain-objects come with JSON.stringify/JSON.parse baked-in, while classes require needless extra serialization/deserialization routines which can easily double your codebase or more (as real-world javascript-code is heavily i/o based). i would say many people burn-out from frontend-programming because they can’t cope with debugging all the i/o edge-cases serializing/deserializing their custom classes.
>
>javascript and frontend-programming is essentially about efficiently managing the program-state like a baton, constantly passing it back-and-forth between the browser’s ui and various backend-servers / persistent-storage. plain json-objects utilizing idiot-proof JSON.stringify/JSON.parse, are naturally better at this baton-passing business than writing classes with custom serializers.
I dislike many things about JS, and I've been writing JS since 2002. It never occured to me, not once, until 3 minutes ago, that this was in any way, shape or form some significant JS disadvantage, primary concern of anything or even any sort of impediment.

_______________________________________________
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

Andrea Giammarchi-2
If classes contain all the "super powers" and their instance handle their own states it's straight forward to serialize JS these days following basic conventions (easy to do with poisoned objects)

```js
class Serializable {

  // usable as JSON.parse(str, Serializable.fromJSON)
  static fromJSON(key, value) {
    if (value.hasOwnProperty('__proto__')) {
      const Class = value.__proto__.split('.').reduce(
        (o, k) => o[k],
        typeof global === 'object' ? global : window
      );
      delete value.__proto__;
      return Object.create(Class.prototype, value);
    }
    return value;
  }

  // provide a way to retrieve your class back
  // from a namespace
  static toJSON() {
    return this.name;
  }

  // serialize any instance
  toJSON() {
    return Object.defineProperty(
      Object.getOwnPropertyDescriptors(this),
      '__proto__',
      {
        enumerable: true,
        value: this.constructor.toJSON()
      }
    );
  }
}

```

Assuming the class is somehow reachable, something that is an issue with any other language too (the class must be available to properly unserialize)

```js
window.Anything = class Anything extends Serializable {
  constructor(pub, acc) {
    super();
    this.public = pub;
    this.accessor = acc;
  }
  get accessor() {
    return this._private;
  }
  set accessor(value) {
    Object.defineProperty(this, '_private', {
      configurable: true,
      value
    });
  }
};
```

you can serialize and unserialize instances with ease:

```js
const before = new Anything(123, 456);

const serialized = JSON.stringify(before);

const after = JSON.parse(serialized, Anything.fromJSON);
console.log(
  after.public,
  after.accessor
);
```

There are also battle tested utilities to make recursive properties serializable too (CircularJSON to name one).

Yet, what everyone serliazes and unserializes instead, is some data any instance could eventually consume so having full classes/instances there doesn't apparently bring much value.

Serialization is IMO one of those things when you come from capable langauges you apparently cannot live without, but you forget on your way with JS and its debugging ability across various environments.

Regards




On Mon, Nov 27, 2017 at 8:17 PM, Florian Bösch <[hidden email]> wrote:
On Thu, Nov 2, 2017 at 4:43 AM, kai zhu <[hidden email]> wrote:
> the primary reason is because traditional oop skills gained from c#/c++/java/python/etc translate poorly to javascript.
I've never found that to be the case.

>in javascript, class-instantiated objects are inferior to plain-objects, because plain-objects come with JSON.stringify/JSON.parse baked-in, while classes require needless extra serialization/deserialization routines which can easily double your codebase or more (as real-world javascript-code is heavily i/o based). i would say many people burn-out from frontend-programming because they can’t cope with debugging all the i/o edge-cases serializing/deserializing their custom classes.
>
>javascript and frontend-programming is essentially about efficiently managing the program-state like a baton, constantly passing it back-and-forth between the browser’s ui and various backend-servers / persistent-storage. plain json-objects utilizing idiot-proof JSON.stringify/JSON.parse, are naturally better at this baton-passing business than writing classes with custom serializers.
I dislike many things about JS, and I've been writing JS since 2002. It never occured to me, not once, until 3 minutes ago, that this was in any way, shape or form some significant JS disadvantage, primary concern of anything or even any sort of impediment.

_______________________________________________
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
@jeremy and @andrea the workarounds using to/fromJSON wouldn't be
necessary in first place, if static-functions were employed instead of classes.

if i were asked what the vision of javascript is my current answer would be:
"javascript is a tool to take JSON-input, manipulate it, and output it back out
(via DOM, event-handling, network-socket, file-io, or db-driver)."
that vision is the same whether javascript is used in browsers,
servers, or embedded-systems.

es5 was the epitomy of achieving that vision in the simplest way possible.

what did es6 bring?  symbols, meta-programming, and fancy ways to
construct classes.  but classes in javascript are usually transient
things whose ultimate purpose is to serialize to JSON-output and then
get destroyed.  that is a poor use for them, compared to using
static-functions to directly manipulate JSON-input and outputting it
back out.  i would say most things you write in es6 with classes to handle JSON
data could be done more efficiently with half-the-code using
static-functions.  and a growing number of people with javascript
fatigue probably realize this.

for a real-world example of what i'm talking about, here's a web-demo
of a google-maps javascript-client @
https://kaizhu256.github.io/node-swgg-google-maps/build..beta..travis-ci.org/app/#!swgg_id__2Fmaps_2Fapi_2Fdirections_2Fjson_20GET_1

the app use no classes whatsoever. it relies entirely on
static-functions to baton-pass JSON-data between dom <-> browser <->
proxy-server <-> google-server (or nodejs <-> google-server).



On 11/28/17, Andrea Giammarchi <[hidden email]> wrote:

> If classes contain all the "super powers" and their instance handle their
> own states it's straight forward to serialize JS these days following basic
> conventions (easy to do with poisoned objects)
>
> ```js
> class Serializable {
>
>   // usable as JSON.parse(str, Serializable.fromJSON)
>   static fromJSON(key, value) {
>     if (value.hasOwnProperty('__proto__')) {
>       const Class = value.__proto__.split('.').reduce(
>         (o, k) => o[k],
>         typeof global === 'object' ? global : window
>       );
>       delete value.__proto__;
>       return Object.create(Class.prototype, value);
>     }
>     return value;
>   }
>
>   // provide a way to retrieve your class back
>   // from a namespace
>   static toJSON() {
>     return this.name;
>   }
>
>   // serialize any instance
>   toJSON() {
>     return Object.defineProperty(
>       Object.getOwnPropertyDescriptors(this),
>       '__proto__',
>       {
>         enumerable: true,
>         value: this.constructor.toJSON()
>       }
>     );
>   }
> }
>
> ```
>
> Assuming the class is somehow reachable, something that is an issue with
> any other language too (the class must be available to properly
> unserialize)
>
> ```js
> window.Anything = class Anything extends Serializable {
>   constructor(pub, acc) {
>     super();
>     this.public = pub;
>     this.accessor = acc;
>   }
>   get accessor() {
>     return this._private;
>   }
>   set accessor(value) {
>     Object.defineProperty(this, '_private', {
>       configurable: true,
>       value
>     });
>   }
> };
> ```
>
> you can serialize and unserialize instances with ease:
>
> ```js
> const before = new Anything(123, 456);
>
> const serialized = JSON.stringify(before);
>
> const after = JSON.parse(serialized, Anything.fromJSON);
> console.log(
>   after.public,
>   after.accessor
> );
> ```
>
> There are also battle tested utilities to make recursive properties
> serializable too (CircularJSON to name one).
>
> Yet, what everyone serliazes and unserializes instead, is some data any
> instance could eventually consume so having full classes/instances there
> doesn't apparently bring much value.
>
> Serialization is IMO one of those things when you come from capable
> langauges you apparently cannot live without, but you forget on your way
> with JS and its debugging ability across various environments.
>
> Regards
>
>
>
>
> On Mon, Nov 27, 2017 at 8:17 PM, Florian Bösch <[hidden email]> wrote:
>
>> On Thu, Nov 2, 2017 at 4:43 AM, kai zhu <[hidden email]> wrote:
>>
>>> > the primary reason is because traditional oop skills gained from
>>> c#/c++/java/python/etc translate poorly to javascript.
>>>
>> I've never found that to be the case.
>>
>> >in javascript, class-instantiated objects are inferior to plain-objects,
>>> because plain-objects come with JSON.stringify/JSON.parse baked-in,
>>> while
>>> classes require needless extra serialization/deserialization routines
>>> which
>>> can easily double your codebase or more (as real-world javascript-code
>>> is
>>> heavily i/o based). i would say many people burn-out from
>>> frontend-programming because they can’t cope with debugging all the i/o
>>> edge-cases serializing/deserializing their custom classes.
>>> >
>>> >javascript and frontend-programming is essentially about efficiently
>>> managing the program-state like a baton, constantly passing it
>>> back-and-forth between the browser’s ui and various backend-servers /
>>> persistent-storage. plain json-objects utilizing idiot-proof
>>> JSON.stringify/JSON.parse, are naturally better at this baton-passing
>>> business than writing classes with custom serializers.
>>>
>> I dislike many things about JS, and I've been writing JS since 2002. It
>> never occured to me, not once, until 3 minutes ago, that this was in any
>> way, shape or form some significant JS disadvantage, primary concern of
>> anything or even any sort of impediment.
>>
>> _______________________________________________
>> 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

Screen Shot 2017-11-28 at 2.21.10 PM.png (530K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: javascript vision thing

T.J. Crowder-2
On Tue, Nov 28, 2017 at 6:40 AM, kai zhu <[hidden email]> wrote:
>
> if i were asked what the vision of javascript is my current
> answer would be:
> "javascript is a tool to take JSON-input, manipulate it, and
> output it back out (via DOM, event-handling, network-socket,
> file-io, or db-driver)."

You mean, it's a tool to write computer instructions for taking input, manipulating it, and generating output? Breaking news: That's what all programming languages are.

If you mean *specifically* JSON, and *specifically* a DOM, and *specifically* network I/O and DBs and...well, sorry; as you've been repeatedly told, *your* vision is at odds with that of the JavaScript community at large and, I believe, of the committee. JavaScript is bigger than that. Cope. Because I don't see that changing. Harping on about that conflict on this list is simply not useful.

> es5 was the epitomy of achieving that vision in the simplest way possible.

Great. Again: Keep using it. Nothing is stopping you or anyone else. The committee have done a *huge* amount of work to maintain backward compatibility. (Speaking of which: In all the harping, I don't recall hearing a thing from you *appreciating* that hard work from the committee. Did I just miss it?) Yes, it's 99.99999999% instead of 100%, and code written assuming nothing would ever change (say, values from `typeof`) was ever-so-slightly impacted. Well, that's unfortunate, but it's very much an exception to the rule of compatibility, the decision was not made lightly or without research on impact, and it's not like it takes any significant time to fix the code in question. Rather less time than complaining about it on the list, in fact.

You have a different view from most reasonably-informed people on this. You're entitled to it. As a reasonably-informed person, you're entitled to express it, and you have. It's time to move on.

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

James Kyle
I don't understand what this thread is even trying to achieve.

This mailing list should really just be shut down. The lack of moderation ruins it and it sucks having to subscribe to it for the occasional important/interesting information/discussion. I'd rather have that content moved to one of the other channels of communication which have been more successful.

On Tue, 28 Nov 2017 at 6:51 pm, T.J. Crowder <[hidden email]> wrote:
On Tue, Nov 28, 2017 at 6:40 AM, kai zhu <[hidden email]> wrote:
>
> if i were asked what the vision of javascript is my current
> answer would be:
> "javascript is a tool to take JSON-input, manipulate it, and
> output it back out (via DOM, event-handling, network-socket,
> file-io, or db-driver)."

You mean, it's a tool to write computer instructions for taking input, manipulating it, and generating output? Breaking news: That's what all programming languages are.

If you mean *specifically* JSON, and *specifically* a DOM, and *specifically* network I/O and DBs and...well, sorry; as you've been repeatedly told, *your* vision is at odds with that of the JavaScript community at large and, I believe, of the committee. JavaScript is bigger than that. Cope. Because I don't see that changing. Harping on about that conflict on this list is simply not useful.

> es5 was the epitomy of achieving that vision in the simplest way possible.

Great. Again: Keep using it. Nothing is stopping you or anyone else. The committee have done a *huge* amount of work to maintain backward compatibility. (Speaking of which: In all the harping, I don't recall hearing a thing from you *appreciating* that hard work from the committee. Did I just miss it?) Yes, it's 99.99999999% instead of 100%, and code written assuming nothing would ever change (say, values from `typeof`) was ever-so-slightly impacted. Well, that's unfortunate, but it's very much an exception to the rule of compatibility, the decision was not made lightly or without research on impact, and it's not like it takes any significant time to fix the code in question. Rather less time than complaining about it on the list, in fact.

You have a different view from most reasonably-informed people on this. You're entitled to it. As a reasonably-informed person, you're entitled to express it, and you have. It's time to move on.

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

Naveen Chawla
I oppose moderation. These views about ES, however misguided they might seem, allow us to reaffirm the reasons why decisions were made and guide those with similar views to the answers to their concerns. I don't see any loss, only gain, in engaging these concerns.

On Tue, 28 Nov 2017 at 13:46 James Kyle <[hidden email]> wrote:
I don't understand what this thread is even trying to achieve.

This mailing list should really just be shut down. The lack of moderation ruins it and it sucks having to subscribe to it for the occasional important/interesting information/discussion. I'd rather have that content moved to one of the other channels of communication which have been more successful.

On Tue, 28 Nov 2017 at 6:51 pm, T.J. Crowder <[hidden email]> wrote:
On Tue, Nov 28, 2017 at 6:40 AM, kai zhu <[hidden email]> wrote:
>
> if i were asked what the vision of javascript is my current
> answer would be:
> "javascript is a tool to take JSON-input, manipulate it, and
> output it back out (via DOM, event-handling, network-socket,
> file-io, or db-driver)."

You mean, it's a tool to write computer instructions for taking input, manipulating it, and generating output? Breaking news: That's what all programming languages are.

If you mean *specifically* JSON, and *specifically* a DOM, and *specifically* network I/O and DBs and...well, sorry; as you've been repeatedly told, *your* vision is at odds with that of the JavaScript community at large and, I believe, of the committee. JavaScript is bigger than that. Cope. Because I don't see that changing. Harping on about that conflict on this list is simply not useful.

> es5 was the epitomy of achieving that vision in the simplest way possible.

Great. Again: Keep using it. Nothing is stopping you or anyone else. The committee have done a *huge* amount of work to maintain backward compatibility. (Speaking of which: In all the harping, I don't recall hearing a thing from you *appreciating* that hard work from the committee. Did I just miss it?) Yes, it's 99.99999999% instead of 100%, and code written assuming nothing would ever change (say, values from `typeof`) was ever-so-slightly impacted. Well, that's unfortunate, but it's very much an exception to the rule of compatibility, the decision was not made lightly or without research on impact, and it's not like it takes any significant time to fix the code in question. Rather less time than complaining about it on the list, in fact.

You have a different view from most reasonably-informed people on this. You're entitled to it. As a reasonably-informed person, you're entitled to express it, and you have. It's time to move on.

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

kai zhu
> On Tue, 28 Nov 2017 at 6:51 pm, T.J. Crowder <[hidden email]> wrote:
> You mean, it's a tool to write computer instructions for taking input, manipulating it, and generating output? Breaking news: That's what all programming languages are.

@T.J. the thing about javascript as a "tool mainly for baton-passing
JSON-data around",
is that unlike other programming languages that take generic io data,
javascript oftentimes doesn't need a
class-abstraction layer to parse the input, or serialilze to output,
because they are already in JSON.

i already demonstrated the feasibility of a non-trivial webapp
that has no class-abstraction layer -
it relies on static-functions instead to directly manipulate JSON/plain-text
to/from io (aside from builtin classes like XMLHttpRequest that i have
to use for ajax).

showing you can efficiently manage javascript's JSON-focused io with
static-functions and no class-abstraction layer then raises the
question of the necessity of all the class-related tc39 proposals
being considered.

demo urls:
1. https://kaizhu256.github.io/node-swgg-google-maps/build..beta..travis-ci.org/app/#!swgg_id__2Fmaps_2Fapi_2Fdirections_2Fjson_20GET_1

2. https://kaizhu256.github.io/node-swgg-wechat-pay/build..beta..travis-ci.org/app/#!swgg_id__2Fpay_2Fmicropay_20POST_1




On 11/28/17, Naveen Chawla <[hidden email]> wrote:

> I oppose moderation. These views about ES, however misguided they might
> seem, allow us to reaffirm the reasons why decisions were made and guide
> those with similar views to the answers to their concerns. I don't see any
> loss, only gain, in engaging these concerns.
>
> On Tue, 28 Nov 2017 at 13:46 James Kyle <[hidden email]> wrote:
>
>> I don't understand what this thread is even trying to achieve.
>>
>> This mailing list should really just be shut down. The lack of moderation
>> ruins it and it sucks having to subscribe to it for the occasional
>> important/interesting information/discussion. I'd rather have that
>> content
>> moved to one of the other channels of communication which have been more
>> successful.
>>
>> On Tue, 28 Nov 2017 at 6:51 pm, T.J. Crowder <
>> [hidden email]> wrote:
>>
>>> On Tue, Nov 28, 2017 at 6:40 AM, kai zhu <[hidden email]> wrote:
>>> >
>>> > if i were asked what the vision of javascript is my current
>>> > answer would be:
>>> > "javascript is a tool to take JSON-input, manipulate it, and
>>> > output it back out (via DOM, event-handling, network-socket,
>>> > file-io, or db-driver)."
>>>
>>> You mean, it's a tool to write computer instructions for taking input,
>>> manipulating it, and generating output? Breaking news: That's what all
>>> programming languages are.
>>>
>>> If you mean *specifically* JSON, and *specifically* a DOM, and
>>> *specifically* network I/O and DBs and...well, sorry; as you've been
>>> repeatedly told, *your* vision is at odds with that of the JavaScript
>>> community at large and, I believe, of the committee. JavaScript is
>>> bigger
>>> than that. Cope. Because I don't see that changing. Harping on about
>>> that
>>> conflict on this list is simply not useful.
>>>
>>> > es5 was the epitomy of achieving that vision in the simplest way
>>> possible.
>>>
>>> Great. Again: Keep using it. Nothing is stopping you or anyone else. The
>>> committee have done a *huge* amount of work to maintain backward
>>> compatibility. (Speaking of which: In all the harping, I don't recall
>>> hearing a thing from you *appreciating* that hard work from the
>>> committee.
>>> Did I just miss it?) Yes, it's 99.99999999% instead of 100%, and code
>>> written assuming nothing would ever change (say, values from `typeof`)
>>> was
>>> ever-so-slightly impacted. Well, that's unfortunate, but it's very much
>>> an
>>> exception to the rule of compatibility, the decision was not made
>>> lightly
>>> or without research on impact, and it's not like it takes any
>>> significant
>>> time to fix the code in question. Rather less time than complaining
>>> about
>>> it on the list, in fact.
>>>
>>> You have a different view from most reasonably-informed people on this.
>>> You're entitled to it. As a reasonably-informed person, you're entitled
>>> to
>>> express it, and you have. It's time to move on.
>>>
>>> -- 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

Screen Shot 2017-11-28 at 2.21.10 PM.png (530K) Download Attachment
Screen Shot 2017-11-28 at 9.30.24 PM.png (703K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: javascript vision thing

T.J. Crowder-2
On Tue, Nov 28, 2017 at 2:19 PM, kai zhu <[hidden email]> wrote:
>
> > On Tue, 28 Nov 2017 at 6:51 pm, T.J. Crowder ... wrote:
> > You mean, it's a tool to write computer instructions for taking
> > input, manipulating it, and generating output? Breaking news:
> > That's what all programming languages are.
>
> ...the thing about javascript as a "tool mainly for baton-passing
> JSON-data around",
> is that unlike other programming languages that take generic io
> data...

Well, no, it isn't. It's just like other programming languages: Used in a variety of environments, with different inputs and outputs. A point which has repeatedly been made to you by multiple different people.

> i already demonstrated the feasibility of a non-trivial webapp
> that has no class-abstraction layer

I never said you couldn't. You can write just about everything with just about every paradigm out there. Which is entirely irrelevant.

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

J Decker
In reply to this post by kai zhu

On Tue, Nov 28, 2017 at 6:19 AM, kai zhu <[hidden email]> wrote:
> On Tue, 28 Nov 2017 at 6:51 pm, T.J. Crowder <[hidden email]> wrote:
> You mean, it's a tool to write computer instructions for taking input, manipulating it, and generating output? Breaking news: That's what all programming languages are.

@T.J. the thing about javascript as a "tool mainly for baton-passing
JSON-data around",
is that unlike other programming languages that take generic io data,

javascript has grown to be a generally useful language; and indeed because it had the ability to read generic IO data; maybe that's somewhat incorrect... systems supporting javascript have been created that allow generic IO.

NodeOS   https://node-os.com/
some really powerful fontend chosts - Electron and NWJS for instances ( above and beyond what a browser can do itself, or working standalone without requiring passing batons to anyone)

3D and Vr programming https://webvr.info/  https://threejs.org/

I used it to create 100's of millions of bingo cards (would have been able to do that faster if I had threads but broke it up into several processes in parallel and managed it quite quickly) Those got output as a binary format (also SQL and CSV flavors)

It even works well to add logic to GUI elements created outside of a browser https://www.npmjs.com/package/sack.vfs#frame-methods

I do think you're looking at the world somewhat myopically or with a bit of tunnel vision.

While true, classes don't help in basically any of those cases... and they really tke javascript as just the pure functional language it started as ( just like it's C roots, which I found rather amused that Functional Programming is this 'grand new thing that javascript does' 

I would have used classes more, but since they encapsulate no data, I found them more of a hinderance to develop since I had to do all the work in a constructor/factory anyway the extra cryptic layer I find unnessecary.  If it had supported data fields, I'd think there would be additional performance benefits to having a full template, without having to adjust underlaying tracking to add fields all the time.

From long time in C, my development practice is always to create the data structures I'm using and then create the functions to manipulate said structures;  having functions first and nothing to operate on is kinda useless... Javascript does such a habit a little harder to follow, requiring a factory for the structure first  like these ... https://github.com/mrdoob/three.js/tree/dev/src/math vectors, matrixes, etc....


 
javascript oftentimes doesn't need a
class-abstraction layer to parse the input, or serialilze to output,
because they are already in JSON.

i already demonstrated the feasibility of a non-trivial webapp
that has no class-abstraction layer -
it relies on static-functions instead to directly manipulate JSON/plain-text
to/from io (aside from builtin classes like XMLHttpRequest that i have
to use for ajax).

showing you can efficiently manage javascript's JSON-focused io with
static-functions and no class-abstraction layer then raises the
question of the necessity of all the class-related tc39 proposals
being considered.

demo urls:
1. https://kaizhu256.github.io/node-swgg-google-maps/build..beta..travis-ci.org/app/#!swgg_id__2Fmaps_2Fapi_2Fdirections_2Fjson_20GET_1

2. https://kaizhu256.github.io/node-swgg-wechat-pay/build..beta..travis-ci.org/app/#!swgg_id__2Fpay_2Fmicropay_20POST_1




On 11/28/17, Naveen Chawla <[hidden email]> wrote:
> I oppose moderation. These views about ES, however misguided they might
> seem, allow us to reaffirm the reasons why decisions were made and guide
> those with similar views to the answers to their concerns. I don't see any
> loss, only gain, in engaging these concerns.
>
> On Tue, 28 Nov 2017 at 13:46 James Kyle <[hidden email]> wrote:
>
>> I don't understand what this thread is even trying to achieve.
>>
>> This mailing list should really just be shut down. The lack of moderation
>> ruins it and it sucks having to subscribe to it for the occasional
>> important/interesting information/discussion. I'd rather have that
>> content
>> moved to one of the other channels of communication which have been more
>> successful.
>>
>> On Tue, 28 Nov 2017 at 6:51 pm, T.J. Crowder <
>> [hidden email]> wrote:
>>
>>> On Tue, Nov 28, 2017 at 6:40 AM, kai zhu <[hidden email]> wrote:
>>> >
>>> > if i were asked what the vision of javascript is my current
>>> > answer would be:
>>> > "javascript is a tool to take JSON-input, manipulate it, and
>>> > output it back out (via DOM, event-handling, network-socket,
>>> > file-io, or db-driver)."
>>>
>>> You mean, it's a tool to write computer instructions for taking input,
>>> manipulating it, and generating output? Breaking news: That's what all
>>> programming languages are.
>>>
>>> If you mean *specifically* JSON, and *specifically* a DOM, and
>>> *specifically* network I/O and DBs and...well, sorry; as you've been
>>> repeatedly told, *your* vision is at odds with that of the JavaScript
>>> community at large and, I believe, of the committee. JavaScript is
>>> bigger
>>> than that. Cope. Because I don't see that changing. Harping on about
>>> that
>>> conflict on this list is simply not useful.
>>>
>>> > es5 was the epitomy of achieving that vision in the simplest way
>>> possible.
>>>
>>> Great. Again: Keep using it. Nothing is stopping you or anyone else. The
>>> committee have done a *huge* amount of work to maintain backward
>>> compatibility. (Speaking of which: In all the harping, I don't recall
>>> hearing a thing from you *appreciating* that hard work from the
>>> committee.
>>> Did I just miss it?) Yes, it's 99.99999999% instead of 100%, and code
>>> written assuming nothing would ever change (say, values from `typeof`)
>>> was
>>> ever-so-slightly impacted. Well, that's unfortunate, but it's very much
>>> an
>>> exception to the rule of compatibility, the decision was not made
>>> lightly
>>> or without research on impact, and it's not like it takes any
>>> significant
>>> time to fix the code in question. Rather less time than complaining
>>> about
>>> it on the list, in fact.
>>>
>>> You have a different view from most reasonably-informed people on this.
>>> You're entitled to it. As a reasonably-informed person, you're entitled
>>> to
>>> express it, and you have. It's time to move on.
>>>
>>> -- 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

kdex
I apologize for my ignorance, but I've been seeing this thread in my inbox for
around a month now, and most of what's being discussed is just people
glorifying ES5 and other people justifying the usefulness of recent language
additions.

This discussion has gone way off-topic and appears to be a general rambling
thread about certain language standards or even the language itself. I don't
see how this discussion is productive in any way.

Could someone please point out the exact problem that this discussion is
trying to solve? Note that the usual platitudes apply, i.e.,

- Classes have been standardized and aren't going anywhere, and the same
applies to functions. Get used to things evolving.
- The language has its weirdnesses, yes, but so does every other language.
- Classes are just syntactic sugar, so why would it be so tremendously hard to
mix them?
- What stops you from just not using the features that your personal ideology
or religion forbids you to use?

Please *do* correct me if I'm missing the point here, but I just can't see
what this thread is trying to achieve.

On Tuesday, November 28, 2017 3:46:05 PM CET J Decker wrote:

> On Tue, Nov 28, 2017 at 6:19 AM, kai zhu <[hidden email]> wrote:
> > > On Tue, 28 Nov 2017 at 6:51 pm, T.J. Crowder <
> >
> > [hidden email]> wrote:
> > > You mean, it's a tool to write computer instructions for taking input,
> >
> > manipulating it, and generating output? Breaking news: That's what all
> > programming languages are.
> >
> > @T.J. the thing about javascript as a "tool mainly for baton-passing
> > JSON-data around",
> > is that unlike other programming languages that take generic io data,
>
> javascript has grown to be a generally useful language; and indeed because
> it had the ability to read generic IO data; maybe that's somewhat
> incorrect... systems supporting javascript have been created that allow
> generic IO.
>
> NodeOS   https://node-os.com/
> some really powerful fontend chosts - Electron and NWJS for instances (
> above and beyond what a browser can do itself, or working standalone
> without requiring passing batons to anyone)
>
> 3D and Vr programming https://webvr.info/  https://threejs.org/
>
> I used it to create 100's of millions of bingo cards (would have been able
> to do that faster if I had threads but broke it up into several processes
> in parallel and managed it quite quickly) Those got output as a binary
> format (also SQL and CSV flavors)
>
> It even works well to add logic to GUI elements created outside of a
> browser https://www.npmjs.com/package/sack.vfs#frame-methods
>
> I do think you're looking at the world somewhat myopically or with a bit of
> tunnel vision.
>
> While true, classes don't help in basically any of those cases... and they
> really tke javascript as just the pure functional language it started as (
> just like it's C roots, which I found rather amused that Functional
> Programming is this 'grand new thing that javascript does'
>
> I would have used classes more, but since they encapsulate no data, I found
> them more of a hinderance to develop since I had to do all the work in a
> constructor/factory anyway the extra cryptic layer I find unnessecary.  If
> it had supported data fields, I'd think there would be additional
> performance benefits to having a full template, without having to adjust
> underlaying tracking to add fields all the time.
>
> From long time in C, my development practice is always to create the data
> structures I'm using and then create the functions to manipulate said
> structures;  having functions first and nothing to operate on is kinda
> useless... Javascript does such a habit a little harder to follow,
> requiring a factory for the structure first  like these ...
> https://github.com/mrdoob/three.js/tree/dev/src/math vectors, matrixes,
> etc....
>
> > javascript oftentimes doesn't need a
> > class-abstraction layer to parse the input, or serialilze to output,
> > because they are already in JSON.
> >
> > i already demonstrated the feasibility of a non-trivial webapp
> > that has no class-abstraction layer -
> > it relies on static-functions instead to directly manipulate
> > JSON/plain-text
> > to/from io (aside from builtin classes like XMLHttpRequest that i have
> > to use for ajax).
> >
> > showing you can efficiently manage javascript's JSON-focused io with
> > static-functions and no class-abstraction layer then raises the
> > question of the necessity of all the class-related tc39 proposals
> > being considered.
> >
> > demo urls:
> > 1. https://kaizhu256.github.io/node-swgg-google-maps/build..
> > beta..travis-ci.org/app/#!swgg_id__2Fmaps_2Fapi_
> > 2Fdirections_2Fjson_20GET_1
> >
> > 2. https://kaizhu256.github.io/node-swgg-wechat-pay/build..
> > beta..travis-ci.org/app/#!swgg_id__2Fpay_2Fmicropay_20POST_1
> >
> > On 11/28/17, Naveen Chawla <[hidden email]> wrote:
> > > I oppose moderation. These views about ES, however misguided they might
> > > seem, allow us to reaffirm the reasons why decisions were made and guide
> > > those with similar views to the answers to their concerns. I don't see
> >
> > any
> >
> > > loss, only gain, in engaging these concerns.
> > >
> > > On Tue, 28 Nov 2017 at 13:46 James Kyle <[hidden email]> wrote:
> > >> I don't understand what this thread is even trying to achieve.
> > >>
> > >> This mailing list should really just be shut down. The lack of
> >
> > moderation
> >
> > >> ruins it and it sucks having to subscribe to it for the occasional
> > >> important/interesting information/discussion. I'd rather have that
> > >> content
> > >> moved to one of the other channels of communication which have been
> > >> more
> > >> successful.
> > >>
> > >> On Tue, 28 Nov 2017 at 6:51 pm, T.J. Crowder <
> > >>
> > >> [hidden email]> wrote:
> > >>> On Tue, Nov 28, 2017 at 6:40 AM, kai zhu <[hidden email]> wrote:
> > >>> > if i were asked what the vision of javascript is my current
> > >>> > answer would be:
> > >>> > "javascript is a tool to take JSON-input, manipulate it, and
> > >>> > output it back out (via DOM, event-handling, network-socket,
> > >>> > file-io, or db-driver)."
> > >>>
> > >>> You mean, it's a tool to write computer instructions for taking input,
> > >>> manipulating it, and generating output? Breaking news: That's what all
> > >>> programming languages are.
> > >>>
> > >>> If you mean *specifically* JSON, and *specifically* a DOM, and
> > >>> *specifically* network I/O and DBs and...well, sorry; as you've been
> > >>> repeatedly told, *your* vision is at odds with that of the JavaScript
> > >>> community at large and, I believe, of the committee. JavaScript is
> > >>> bigger
> > >>> than that. Cope. Because I don't see that changing. Harping on about
> > >>> that
> > >>> conflict on this list is simply not useful.
> > >>>
> > >>> > es5 was the epitomy of achieving that vision in the simplest way
> > >>>
> > >>> possible.
> > >>>
> > >>> Great. Again: Keep using it. Nothing is stopping you or anyone else.
> >
> > The
> >
> > >>> committee have done a *huge* amount of work to maintain backward
> > >>> compatibility. (Speaking of which: In all the harping, I don't recall
> > >>> hearing a thing from you *appreciating* that hard work from the
> > >>> committee.
> > >>> Did I just miss it?) Yes, it's 99.99999999% instead of 100%, and code
> > >>> written assuming nothing would ever change (say, values from `typeof`)
> > >>> was
> > >>> ever-so-slightly impacted. Well, that's unfortunate, but it's very
> > >>> much
> > >>> an
> > >>> exception to the rule of compatibility, the decision was not made
> > >>> lightly
> > >>> or without research on impact, and it's not like it takes any
> > >>> significant
> > >>> time to fix the code in question. Rather less time than complaining
> > >>> about
> > >>> it on the list, in fact.
> > >>>
> > >>> You have a different view from most reasonably-informed people on
> > >>> this.
> > >>> You're entitled to it. As a reasonably-informed person, you're
> > >>> entitled
> > >>> to
> > >>> express it, and you have. It's time to move on.
> > >>>
> > >>> -- 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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: javascript vision thing

Isiah Meadows-2

I think you pretty much hit the nail on the head here. Probably best if we can just let this thread die now.


On Tue, Nov 28, 2017, 10:20 kdex <[hidden email]> wrote:
I apologize for my ignorance, but I've been seeing this thread in my inbox for
around a month now, and most of what's being discussed is just people
glorifying ES5 and other people justifying the usefulness of recent language
additions.

This discussion has gone way off-topic and appears to be a general rambling
thread about certain language standards or even the language itself. I don't
see how this discussion is productive in any way.

Could someone please point out the exact problem that this discussion is
trying to solve? Note that the usual platitudes apply, i.e.,

- Classes have been standardized and aren't going anywhere, and the same
applies to functions. Get used to things evolving.
- The language has its weirdnesses, yes, but so does every other language.
- Classes are just syntactic sugar, so why would it be so tremendously hard to
mix them?
- What stops you from just not using the features that your personal ideology
or religion forbids you to use?

Please *do* correct me if I'm missing the point here, but I just can't see
what this thread is trying to achieve.

On Tuesday, November 28, 2017 3:46:05 PM CET J Decker wrote:
> On Tue, Nov 28, 2017 at 6:19 AM, kai zhu <[hidden email]> wrote:
> > > On Tue, 28 Nov 2017 at 6:51 pm, T.J. Crowder <
> >
> > [hidden email]> wrote:
> > > You mean, it's a tool to write computer instructions for taking input,
> >
> > manipulating it, and generating output? Breaking news: That's what all
> > programming languages are.
> >
> > @T.J. the thing about javascript as a "tool mainly for baton-passing
> > JSON-data around",
> > is that unlike other programming languages that take generic io data,
>
> javascript has grown to be a generally useful language; and indeed because
> it had the ability to read generic IO data; maybe that's somewhat
> incorrect... systems supporting javascript have been created that allow
> generic IO.
>
> NodeOS   https://node-os.com/
> some really powerful fontend chosts - Electron and NWJS for instances (
> above and beyond what a browser can do itself, or working standalone
> without requiring passing batons to anyone)
>
> 3D and Vr programming https://webvr.info/  https://threejs.org/
>
> I used it to create 100's of millions of bingo cards (would have been able
> to do that faster if I had threads but broke it up into several processes
> in parallel and managed it quite quickly) Those got output as a binary
> format (also SQL and CSV flavors)
>
> It even works well to add logic to GUI elements created outside of a
> browser https://www.npmjs.com/package/sack.vfs#frame-methods
>
> I do think you're looking at the world somewhat myopically or with a bit of
> tunnel vision.
>
> While true, classes don't help in basically any of those cases... and they
> really tke javascript as just the pure functional language it started as (
> just like it's C roots, which I found rather amused that Functional
> Programming is this 'grand new thing that javascript does'
>
> I would have used classes more, but since they encapsulate no data, I found
> them more of a hinderance to develop since I had to do all the work in a
> constructor/factory anyway the extra cryptic layer I find unnessecary.  If
> it had supported data fields, I'd think there would be additional
> performance benefits to having a full template, without having to adjust
> underlaying tracking to add fields all the time.
>
> From long time in C, my development practice is always to create the data
> structures I'm using and then create the functions to manipulate said
> structures;  having functions first and nothing to operate on is kinda
> useless... Javascript does such a habit a little harder to follow,
> requiring a factory for the structure first  like these ...
> https://github.com/mrdoob/three.js/tree/dev/src/math vectors, matrixes,
> etc....
>
> > javascript oftentimes doesn't need a
> > class-abstraction layer to parse the input, or serialilze to output,
> > because they are already in JSON.
> >
> > i already demonstrated the feasibility of a non-trivial webapp
> > that has no class-abstraction layer -
> > it relies on static-functions instead to directly manipulate
> > JSON/plain-text
> > to/from io (aside from builtin classes like XMLHttpRequest that i have
> > to use for ajax).
> >
> > showing you can efficiently manage javascript's JSON-focused io with
> > static-functions and no class-abstraction layer then raises the
> > question of the necessity of all the class-related tc39 proposals
> > being considered.
> >
> > demo urls:
> > 1. https://kaizhu256.github.io/node-swgg-google-maps/build..
> > beta..travis-ci.org/app/#!swgg_id__2Fmaps_2Fapi_
> > 2Fdirections_2Fjson_20GET_1
> >
> > 2. https://kaizhu256.github.io/node-swgg-wechat-pay/build..
> > beta..travis-ci.org/app/#!swgg_id__2Fpay_2Fmicropay_20POST_1
> >
> > On 11/28/17, Naveen Chawla <[hidden email]> wrote:
> > > I oppose moderation. These views about ES, however misguided they might
> > > seem, allow us to reaffirm the reasons why decisions were made and guide
> > > those with similar views to the answers to their concerns. I don't see
> >
> > any
> >
> > > loss, only gain, in engaging these concerns.
> > >
> > > On Tue, 28 Nov 2017 at 13:46 James Kyle <[hidden email]> wrote:
> > >> I don't understand what this thread is even trying to achieve.
> > >>
> > >> This mailing list should really just be shut down. The lack of
> >
> > moderation
> >
> > >> ruins it and it sucks having to subscribe to it for the occasional
> > >> important/interesting information/discussion. I'd rather have that
> > >> content
> > >> moved to one of the other channels of communication which have been
> > >> more
> > >> successful.
> > >>
> > >> On Tue, 28 Nov 2017 at 6:51 pm, T.J. Crowder <
> > >>
> > >> [hidden email]> wrote:
> > >>> On Tue, Nov 28, 2017 at 6:40 AM, kai zhu <[hidden email]> wrote:
> > >>> > if i were asked what the vision of javascript is my current
> > >>> > answer would be:
> > >>> > "javascript is a tool to take JSON-input, manipulate it, and
> > >>> > output it back out (via DOM, event-handling, network-socket,
> > >>> > file-io, or db-driver)."
> > >>>
> > >>> You mean, it's a tool to write computer instructions for taking input,
> > >>> manipulating it, and generating output? Breaking news: That's what all
> > >>> programming languages are.
> > >>>
> > >>> If you mean *specifically* JSON, and *specifically* a DOM, and
> > >>> *specifically* network I/O and DBs and...well, sorry; as you've been
> > >>> repeatedly told, *your* vision is at odds with that of the JavaScript
> > >>> community at large and, I believe, of the committee. JavaScript is
> > >>> bigger
> > >>> than that. Cope. Because I don't see that changing. Harping on about
> > >>> that
> > >>> conflict on this list is simply not useful.
> > >>>
> > >>> > es5 was the epitomy of achieving that vision in the simplest way
> > >>>
> > >>> possible.
> > >>>
> > >>> Great. Again: Keep using it. Nothing is stopping you or anyone else.
> >
> > The
> >
> > >>> committee have done a *huge* amount of work to maintain backward
> > >>> compatibility. (Speaking of which: In all the harping, I don't recall
> > >>> hearing a thing from you *appreciating* that hard work from the
> > >>> committee.
> > >>> Did I just miss it?) Yes, it's 99.99999999% instead of 100%, and code
> > >>> written assuming nothing would ever change (say, values from `typeof`)
> > >>> was
> > >>> ever-so-slightly impacted. Well, that's unfortunate, but it's very
> > >>> much
> > >>> an
> > >>> exception to the rule of compatibility, the decision was not made
> > >>> lightly
> > >>> or without research on impact, and it's not like it takes any
> > >>> significant
> > >>> time to fix the code in question. Rather less time than complaining
> > >>> about
> > >>> it on the list, in fact.
> > >>>
> > >>> You have a different view from most reasonably-informed people on
> > >>> this.
> > >>> You're entitled to it. As a reasonably-informed person, you're
> > >>> entitled
> > >>> to
> > >>> express it, and you have. It's time to move on.
> > >>>
> > >>> -- 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

T.J. Crowder-2
On Tue, Nov 28, 2017 at 7:41 PM, Isiah Meadows <[hidden email]> wrote:
>
> I think you pretty much hit the nail on the head here.
> Probably best if we can just let this thread die now.

Thirded. ;-)

-- T.J. Crowder

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12