javascript vision thing

# kai zhu (4 months ago)

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.

# Jordan Harband (4 months ago)

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

# T.J. Crowder (4 months ago)

On Thu, Nov 2, 2017 at 3:43 AM, kai zhu <kaizhu256 at gmail.com> wrote:

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

Link to that answer for those who are interested: www.quora.com/Why-is-JavaScript-so-hated/answer/Kai-Zhu-9

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

# doodad-js Admin (4 months ago)

-----Original Message----- From: Claude Petit [mailto:petc at webmail.us] Sent: Thursday, November 02, 2017 4:24 PM To: 'kai zhu' <kaizhu256 at gmail.com>; 'es-discuss' <es-discuss at mozilla.org>

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

# Isiah Meadows (4 months ago)

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 me at isiahmeadows.com

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

# Andrea Giammarchi (4 months ago)

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:

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:

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

# kai zhu (3 months ago)

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.

# Jeremy Martin (3 months ago)

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

jsbin.com/kasiwevobo/edit?js,console

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.

# Florian Bösch (3 months ago)

On Thu, Nov 2, 2017 at 4:43 AM, kai zhu <kaizhu256 at gmail.com> 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.

# Andrea Giammarchi (3 months ago)

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)

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)

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:

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.

# kai zhu (3 months ago)

@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 @ 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).

# T.J. Crowder (3 months ago)

On Tue, Nov 28, 2017 at 6:40 AM, kai zhu <kaizhu256 at gmail.com> 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

# James Kyle (3 months ago)

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.

# Naveen Chawla (3 months ago)

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.

# kai zhu (3 months ago)

On Tue, 28 Nov 2017 at 6:51 pm, T.J. Crowder <tj.crowder at farsightsoftware.com> 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. kaizhu256.github.io/node-swgg-google-maps/build..beta..travis-ci.org/app/#!swgg_id__2Fmaps_2Fapi_2Fdirections_2Fjson_20GET_1

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

# T.J. Crowder (3 months ago)

On Tue, Nov 28, 2017 at 2:19 PM, kai zhu <kaizhu256 at gmail.com> 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

# J Decker (3 months ago)

On Tue, Nov 28, 2017 at 6:19 AM, kai zhu <kaizhu256 at gmail.com> wrote:

On Tue, 28 Nov 2017 at 6:51 pm, T.J. Crowder < tj.crowder at farsightsoftware.com> 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 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 webvr.info, 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 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 ... mrdoob/three.js/tree/dev/src/math vectors, matrixes, etc....

# kdex (3 months ago)

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.

# Isiah Meadows (3 months ago)

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

# T.J. Crowder (3 months ago)

On Tue, Nov 28, 2017 at 7:41 PM, Isiah Meadows <isiahmeadows at gmail.com>

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

# kai zhu (2 months ago)

i'm generally curious what the overall vision is for those who want continued aggressive evolution of the javascript-language. is it to transform javascript into a class-based language similar to c#?

also, is another part of the vision to add features to javascript to solve special engineering-problems encountered by large companies like google/facebook/microsoft as a trade-off to simplicity and ease-of-use for smaller web-projects?

# Pier Bover (2 months ago)

I doubt there is a long term grand vision for JS. After all the focus is on small incremental changes.

Personally I'd love to see optional static typings implement into the language much like we had in ES4 but I feel it's too big of a change to be considered by TC39.

My hope now is on completely being able to replace JS by Web Assembly in a couple of years and write on whatever language I prefer.

# Jordan Harband (2 months ago)

Adding features in no way sacrifices simplicity or ease-of-use for smaller web projects; as has been said many times on this list, if you don't like any new feature, simply choose not to use it.

# T.J. Crowder (2 months ago)

On Sun, Dec 17, 2017 at 7:21 PM, Jordan Harband <ljharb at gmail.com> wrote:

Adding features in no way sacrifices simplicity or ease-of-use for smaller web projects; as has been said many times on this list, if you don't like any new feature, simply choose not to use it.

And in many or even most cases, markedly improves simplicity and ease-of-use. As has also been repeatedly pointed out.

Kai: Genuine questions are fine. Questions which are really just you pushing your agenda of "don't change anything ever again" and your personal -- and solitary -- claim that "all this new stuff makes life difficult for people" are, at best, pointless. Your position has been made crystal clear. There's no need to bang on about it.

-- T.J. Crowder

# Terence M. Bandoian (2 months ago)

I appreciate hearing Kai's point of view and don't think he should be silenced.

-Terence Bandoian

# Frederick Stark (2 months ago)

I appreciate hearing Kai's point of view and think that we've had this exact discussion enough times. At this point it just adds to inbox weight without changing any minds

# Naveen Chawla (2 months ago)

Javascript won't lose plain objects. Classes simplify cases of type hierarchies that require overriden methods, and offer a memory performance gain in the case of when there are many instances vs using plain objects to do the same (which incurs a memory overhead for each instance's functions even when they are the same as each other). The only encapsulated way of doing this before ES6 was to use prototype, which is easier to get wrong especially if there is more than two levels of depth of method inheritance.

You get to chose what works for you. You can even argue for using plain objects in certain cases where somebody has decided to use classes. That has nothing to do with what the language offers for those whose applications are simpler and more performant using classes instead.

# Isiah Meadows (2 months ago)

For one specific example, plain objects can be treated like C structs. For most scenarios you'd want "methods", you could get away just as easily with functions taking the instance as an argument (in particular, you could still use this, although I don't in practice).

I've used this pattern quite a bit when I have a bit of state that needs accessed in several places, but actions are more easily encapsulated. This isn't as elegant for things like DSLs, but it's useful for more stateful programming.

Isiah Meadows me at isiahmeadows.com

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

# Naveen Chawla (2 months ago)

Using static methods with plain objects can be cool if you don't want method overriding and/or inheritance. Otherwise using classes and methods makes that simpler to accomplish.

# kai zhu (2 months ago)

On Dec 19, 2017 01:36, "Naveen Chawla" <naveen.chwl at gmail.com> wrote:

Using static methods with plain objects can be cool if you don't want

method overriding and/or inheritance. Otherwise using classes and methods makes that simpler to accomplish.

@naveen, have you tried adding asynchronous features (e.g. typeahead search or typeahead input-validation) to a frontend-ui that primarily relied on classes? you generally cannot implement these features like you would for BLOCKING code (as taught in college cs) by simply updating a class-method or two. in practice, you oftentimes have to rewrite the entire class to accomodate a "simple" ui feature-request that changed the async data-flow. classes normally end up being a non-reusable pile of async-hacks as a frontend-ui evolves, which makes them no better than writing throwaway static-functions from the start. at least there's no pretension for re-usability when writing throwaway static-functions, with the more realistic expectation they will be constantly re-written as async-feature-request get added.

On Mon, 18 Dec 2017 at 20:53 Isiah Meadows <isiahmeadows at gmail.com> wrote:

For one specific example, plain objects can be treated like C structs. For most scenarios you'd want "methods", you could get away just as easily with functions taking the instance as an argument (in particular, you could still use this, although I don't in practice).

I've used this pattern quite a bit when I have a bit of state that needs accessed in several places, but actions are more easily encapsulated. This isn't as elegant for things like DSLs, but it's useful for more stateful programming.

Isiah Meadows me at isiahmeadows.com

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

On Mon, Dec 18, 2017 at 6:25 AM, Naveen Chawla <naveen.chwl at gmail.com>

wrote:

Javascript won't lose plain objects. Classes simplify cases of type hierarchies that require overriden methods, and offer a memory

performance

gain in the case of when there are many instances vs using plain

objects to

do the same (which incurs a memory overhead for each instance's

functions

even when they are the same as each other). The only encapsulated way

of

doing this before ES6 was to use prototype, which is easier to get

wrong

especially if there is more than two levels of depth of method

inheritance.

You get to chose what works for you. You can even argue for using plain objects in certain cases where somebody has decided to use classes.

That has

nothing to do with what the language offers for those whose

applications are

simpler and more performant using classes instead.

On Mon, 18 Dec 2017 at 03:31 Frederick Stark <coagmano at gmail.com>

wrote:

I appreciate hearing Kai's point of view and think that we've had this exact discussion enough times. At this point it just adds to inbox

weight

without changing any minds

On Dec 18 2017, at 8:23 am, Terence M. Bandoian <terence at tmbsw.com>

wrote:

I appreciate hearing Kai's point of view and don't think he should be silenced.

-Terence Bandoian

On 12/17/2017 2:03 PM, T.J. Crowder wrote:

On Sun, Dec 17, 2017 at 7:21 PM, Jordan Harband <ljharb at gmail.com>

wrote:

Adding features in no way sacrifices simplicity or ease-of-use for smaller web projects; as has been said many times on this list, if you don't like any new feature, simply choose not to use it.

And in many or even most cases, markedly improves simplicity and ease-of-use. As has also been repeatedly pointed out.

Kai: Genuine questions are fine. Questions which are really just you pushing your agenda of "don't change anything ever again" and your

personal

-- and solitary -- claim that "all this new stuff makes life

difficult for

people" are, at best, pointless. Your position has been made crystal

clear.

# Naveen Chawla (2 months ago)

Aynchronicity has nothing to do with whether you use class instance methods or static functions. The only difference is whether this or an arg is the instance, and the ability to override in type hierarchies, and whether you can use a plain data object (without functions/methods) as the instance. Every other logical necessity when things change is the same.

Just use the one that's simpler to implement based on what your app is doing!

To answer your question, yes I've done async with classes. It poses no additional challenge whatsoever.

# kai zhu (2 months ago)

To answer your question, yes I've done async with classes. It poses no

additional challenge whatsoever.

did you do async with classes on the frontend or backend? because its generally more difficult to do when working with the ui (and also why javascript-fatigue is so prevalent among frontend developers).

for example (and this is a great frontend interview question btw), how many proponents on this mailing-list who envision transforming javascript into c# know how to implement a frontend-class to upload images/files (encompassing the ui-element, ajax form-uploader, progress-indicator, and post-upload previewer), that can be made re-usable across different use-cases such as facebook and gmail? if you don't know how to implement such a re-usable class, then your opinion on the design and architecture of javascript classes doesn't mean much from a frontend-perspective.

i suspect most backend nodejs programmers would not know how to implement such re-usable code. frontend-engineers otoh, are now constantly being asked to write such stuff using es6 classes (but its so simple! frontend! easy compared to backend!). if many of the javascript new-comers transitioning from backend c# were put in such frontend-shoes, it wouldn't be hard to imagine them developing javascript-fatigue and burning out as well.

On Dec 20, 2017 3:02 PM, "Naveen Chawla" <naveen.chwl at gmail.com> wrote:

Aynchronicity has nothing to do with whether you use class instance

methods or static functions. The only difference is whether this or an arg is the instance, and the ability to override in type hierarchies, and whether you can use a plain data object (without functions/methods) as the instance. Every other logical necessity when things change is the same.

Just use the one that's simpler to implement based on what your app is

doing!

To answer your question, yes I've done async with classes. It poses no

additional challenge whatsoever.

On Wed, 20 Dec 2017, 8:44 am kai zhu, <kaizhu256 at gmail.com> wrote:

On Dec 19, 2017 01:36, "Naveen Chawla" <naveen.chwl at gmail.com> wrote:

Using static methods with plain objects can be cool if you don't want

method overriding and/or inheritance. Otherwise using classes and methods makes that simpler to accomplish.

@naveen, have you tried adding asynchronous features (e.g. typeahead

search or typeahead input-validation) to a frontend-ui that primarily relied on classes? you generally cannot implement these features like you would for BLOCKING code (as taught in college cs) by simply updating a class-method or two. in practice, you oftentimes have to rewrite the entire class to accomodate a "simple" ui feature-request that changed the async data-flow. classes normally end up being a non-reusable pile of async-hacks as a frontend-ui evolves, which makes them no better than writing throwaway static-functions from the start. at least there's no pretension for re-usability when writing throwaway static-functions, with the more realistic expectation they will be constantly re-written as async-feature-request get added.

On Mon, 18 Dec 2017 at 20:53 Isiah Meadows <isiahmeadows at gmail.com>

wrote:

For one specific example, plain objects can be treated like C structs. For most scenarios you'd want "methods", you could get away just as easily with functions taking the instance as an argument (in particular, you could still use this, although I don't in practice).

I've used this pattern quite a bit when I have a bit of state that needs accessed in several places, but actions are more easily encapsulated. This isn't as elegant for things like DSLs, but it's useful for more stateful programming.

Isiah Meadows me at isiahmeadows.com

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

On Mon, Dec 18, 2017 at 6:25 AM, Naveen Chawla <naveen.chwl at gmail.com>

wrote:

Javascript won't lose plain objects. Classes simplify cases of type hierarchies that require overriden methods, and offer a memory

performance

gain in the case of when there are many instances vs using plain

objects to

do the same (which incurs a memory overhead for each instance's

functions

even when they are the same as each other). The only encapsulated

way of

doing this before ES6 was to use prototype, which is easier to get

wrong

especially if there is more than two levels of depth of method

inheritance.

You get to chose what works for you. You can even argue for using

plain

objects in certain cases where somebody has decided to use classes.

That has

nothing to do with what the language offers for those whose

applications are

simpler and more performant using classes instead.

On Mon, 18 Dec 2017 at 03:31 Frederick Stark <coagmano at gmail.com>

wrote:

I appreciate hearing Kai's point of view and think that we've had

this

exact discussion enough times. At this point it just adds to inbox

weight

without changing any minds

On Dec 18 2017, at 8:23 am, Terence M. Bandoian <terence at tmbsw.com>

wrote:

I appreciate hearing Kai's point of view and don't think he

should be

silenced.

-Terence Bandoian

On 12/17/2017 2:03 PM, T.J. Crowder wrote:

On Sun, Dec 17, 2017 at 7:21 PM, Jordan Harband <ljharb at gmail.com>

wrote:

Adding features in no way sacrifices simplicity or ease-of-use for smaller web projects; as has been said many times on this list, if you don't like any new feature, simply choose not to

use

it.

And in many or even most cases, markedly improves simplicity and ease-of-use. As has also been repeatedly pointed out.

Kai: Genuine questions are fine. Questions which are really just

you

pushing your agenda of "don't change anything ever again" and

your personal

-- and solitary -- claim that "all this new stuff makes life

difficult for

people" are, at best, pointless. Your position has been made

crystal clear.

# Isiah Meadows (2 months ago)

Kai, I'll come at this from a full stack perspective - I've done a lot of both front-end and Node.js work, and I know how they compare.

  1. Promises are useful for pretty much any one-off async action. They're way easier to manage than callbacks for anything substantial, and they take less code.
  2. Event emitters and callbacks are easier to manage for anything async that's not one-off. They're much simpler than classes for most things.
  3. Sometimes, if your view is a class, it's easier to add a handleEvent and use the instance itself with multiple event handlers.
  4. Node.js work usually requires a lot more one-off async actions (like reading files) than the front end.
  5. "JavaScript fatigue" has more to do with the mass of library options (and is especially prevalent in React circles) than anything actually about the language.

C#'s event model is like the DOM's or Node's if you were to factor event names to separate variables, like foo.bar.listen(callback) instead of foo.on("bar", callback). Android's works similarly to JavaScript, although it uses enums instead of strings.

Also, JavaScript idiomatically prefers classes without much inheritance, and it prefers using promises/observables directly over wrapping them. Don't confuse it with the typical Java/C# idiom of subclassing.


Isiah Meadows me at isiahmeadows.com

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

# Pier Bover (2 months ago)

C#'s event model is like the DOM's or Node's if you were to factor event names to separate variables, like foo.bar.listen(callback) instead of foo.on("bar", callback). Android's works similarly to JavaScript, although it uses enums instead of strings.

foo.bar.listen(callback) is not an event but a signal.

# Naveen Chawla (2 months ago)

Front end.

You wouldn't create the uploader in a JavaScript class. You would do so in a component HTML template and use its associated JavaScript class as the model/controller layer. Async stuff is really easy. This doesn't change whether you use the class / a static function / another class.

Isiah - JavaScript has no idiomatic preference in terms of depth of inheritance for classes. In fact that's where classes become really useful in the first place.