Hacker News Reader

Comment by angersock | Hacker News Reader

Some of the more utilitarian features are kind of nice, but I'm not sure how I feel about the module and class support.

I understand that the current situation is a bit annoying, but one of the attractive things to me about ES is that you can fake near anything using the prototypical nature of the language--adding this other stuff seems to me to be bloating things for the sake of a little less effort when trying to use ES like Java or something similar.

ES is an ugly little language, but at least it's little.

EDIT: I'd rather they simply standardize a lot of, say, the underscore.js functionality into the core APIs.

View on HN

The "classes" are merely a short-hand for creating constructor functions with their prototype property already assigned: they add no new semantic complexity to the language, they are mere syntax.

They also add class-side inheritance.

This allows the constructor to inherit its properties from a parent constructor:

    class Class {}
    Class.hello = "hello";

    class SubClass extends Class {}
    SubClass.hello // "hello"

This doesn't add any new semantics on top of the already-approved `__proto__` (which already exists in all browsers but IE):

    Class = function() {};
    Class.hello = "hello";

    SubClass = function() {};
    SubClass.__proto__ = Class;
    SubClass.hello // "hello"

EDIT: Oh, and they add `super`:

    class Speaker {
      say(string) { console.log(string); }
    }

    class Yeller extends Speaker {
      say(string) { super(string.toUpperCase()); }
    }

    new Yeller().say("hi") // "HI"

Ah, I'd forgotten it now mutated [[Prototype]] and not the prototype property's [[Prototype]] (IIRC, earlier drafts had it mutating the latter, i.e., `SubClass.prototype.__proto__`).

`super` is indeed new semantics though, so that is definitely true.

About the last example, I think you meant :

    super.say(string.toUpperCase());

See: http://wiki.ecmascript.org/doku.php?id=strawman:maximally_mi...

Yeah, they're syntactic sugar.

I'd bet you they will allow browsers to optimize their compilation steps, so they are more then just sugar.

No, they're just sugar. It has no relation to whether you can use them to optimise things or not.

It's called Type Specialization http://dl.acm.org/citation.cfm?id=1542528

Class declarations will be equivalent (can be desugared to) a function declaration and some manipulations of the function's prototype. JS VMs already optimize this pattern, so why should syntax sugar for classes be anything special for the compiler?

Because it takes time and CPU cycles for them to figure out what is a Type and what is not. They don't know how much memory to allocate to these objects for instance, but now with classes they will know types immediately.

While I think I understand you, and maybe a little sympathetic to keeping the language little, I simply cannot agree because what you said is basically contradictory.

It's same old argument I guess, but MIPS is simple and consists of only very few instructions. Are you going to program in MIPS everyday? The same argument goes for JS. JS is too little in terms of functionality, so it requires lots of ceremony to write common idioms that other languages have had for decades. Javascript is a terrible language as it stands now, but its adoption and usage has matured enough that there's a lot less risk in pissing people off by adding syntactic sugar on idioms that people already use. I actually welcome these ES6 additions wholeheartedly.

So, the proper argument here would be in support of something like CoffeeScript which compiles to JS, much as we would expect C compilers to generate our MIPS code for us.

My concern is basically born out of my background using C++; a lot of very well-meaning additions have been made over time to that language, and now it's so sprawly that using it at different shops is annoying. C++ these days is basically begging to be replaced by C with bindings to a scripting engine, because it's too damned unwieldy for most other purposes (the joke goes, everybody uses a different 90% of the features).

I'm just concerned that JavaScript, an elegant if flawed little language, is going to get enterprisified by well-meaning developers who lack foresight and who haven't learned from others.

That's a terrible analogy. JS is small and simple but it's far far far more powerful and friendly than MIPS. What functionality is missing from JavaScript that needs to be supplemented by the things outlined in this post? What kind of things are you doing that "require a lot of ceremony?"

Scoping.

Would you like to type this?

    var myModule = (function(root){
        var lib = {};
        root.lib = lib;
        return lib;
    }(this));

Or this?

    module myModule = {
        export //blah blah blah
    }

Data structures.

There's not map or set in JS even to this day that actually acts like a map or set you've learned in your data structure class. Object literal is a poor substitution for a map.

Reply on news.ycombinator.com