javascript vision thing

classic Classic list List threaded Threaded
6 messages Options
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