A Few New Things Coming To JavaScript

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.

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

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

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

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

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

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

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

    super.say(string.toUpperCase());

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

    module myModule = {
        export //blah blah blah
    }

Import, classes, and default parameters have a very strong resemblance to CoffeeScript. In fact, Osmani expresses succinctly -- better than I could have -- why I love Coffee so much over JS syntax:

    Classes in ES.next are there to provide a declarative
    surface for the semantics we're used to (e.g functions,
    prototypes) so that developer intent is expressed
    instead of the underlying imperative mechanics.

The Observables are so much like MVVM in KnockoutJS or SpineJS. (Plus, Spine is written in Coffee, and includes makeArray and a module pattern). I know many developers can't see the advantage to Coffee, but if you are interested in ES6 features you can use them right now by compiling Coffee to JS/ES5. Osmani didn't mention array comprehensions (ES6/JS1.7) or generators (ES6/JS1.8) but they are in Coffee as well.

So please, if you are interested in the future of JS, take another look at Coffee. And bring on ES6!

They're adding a bunch of new features and yet they ignore one of JavaScript's most glaring shortcomings: not tail call elimination. Honestly, I would be ecstatic if this was the only change to the language.

That said, I'm excited about some things. In particular, I really like proxies--being able to customize the behavior of your language (in this case, how objects work) transparently is a good way to decouple parts of your code. Now you can change how an object's properties behave without having to rewrite client code to use methods. Having modules built into the language would be nice too: having everybody use the same system for importing code will make life easier for everyone.

The article mentions that sets "are an effective means of creating ordered list of values". Is this just a mistake on the author's part, or are sets actually to be ordered? Any sane set data type should not be ordered for two reasons: the obvious hash-based implementation isn't, and the actual abstraction (a mathematical set) isn't either.

I believe that they are also planning to add more support for iterators over arrays, maps and sets, which wasn't covered in the blog post. I personally think this is a big mistake. In the recent past, I've had to use iterators pretty widely for a little project. (I was also using a coroutine system very similar to Python's generators.) I found iterators to be a horrible headache. They are essentially anti-functional: they introduce additional state even for benign things like iterating through a sequence! You can't pass them around, you can't use them twice, you have to be careful when writing functions over them... it's really not pleasant.

Anyhow, some of the changes are certainly interesting--both in good ways and in bad ways. There's also always the question of how long it will take for enough browsers to support it. However, with the recent push towards automatically and quickly updating browsers, this shouldn't be as bad as in the past.

Good stuff there, but unfortunately we'll have to wait a few more years for these to be usable (at least for me).

Modules, block scoping, default parameter values are great additions. Proxies sound good as well.

On Maps, the concept is nice but not very useful unless you can do things like

    obj.get('some.deep.nested.value')

or

    obj.set('some.deep.nested.value', {
        'more': {
            'nested': {
                'stuff': 'here'
            }
        }
    })

On Observer again the concept is absolutely great but I wonder if the changes propagate:

    let obj = {
        'some': {
            'deep': {
                'nested': {
                    'value': true
                }
            }
        }
    }

    Object.observe(obj, function(changes){
        changes.forEarch(function(change){
            console.log(change);
        });
    });


    obj.some.deep.nested.value = false 

Will the observer be triggered for all changed properties (some, deep, nested, and value) or just the last one (value)?

For me Maps and Observers are highly important and it seems that no existing open source JS library/framework has implemented them in a way that makes sense.

Has anyone tried implementing these in such a way?

I think we'll start seeing a lot of ES6 to ES5 compilers.

Then it's going to be a question of how to load the appropriate logic into the web page based on what it can do.

I have mixed feelings about this one, but I'm definitely looking forward to the new features.

To every one here saying that we'll not see these features because we have to support IE and we have to wait till IE 11... well IE10 has automatic updates, and what does this has to do with ES.next?

A lot of features cannot shimmed in old FFs and V8s and JSC too, to those browsers' users we'd say "oh, come on! upgrade!".

We're talking about JS itself. Cannot wait to see the awesome improvements brought by ES6 used in SSJS.

BTW: does anybody know why they didn't put in the specs the Executable Class Body thing? It's the coolest part of Coffee-script, and it's the only real meta-programming style for class (IMHO).

The problem with WeakMaps is that their keys are weak, not the values.

While weak keys are useful to provide a place to store extra data about an object, a more useful ability would be to have weak values, so you could find existing objects by string key, if they haven't been GC'd yet.

One big potential use for weak values is in ORMs. When asking for an object with id 5, if one exists you'd like the existing instance. However, you don't want the ORM keeping strong references to all of the instances, preventing them from ever being GC'd if nothing else is using them.

While these features are nice, they doesn't really enable us to do anything we couldn't do already. What I'd like to see are features that would actually make javascript more useful for developing apps, such as an ability to dispatch events while in a loop, or an API for screengrabbing.

Very nice additions.

However, I wonder how long it'll take till we can actively use them in production code...

    Alternatively, many ES.next features can be experimented with using Google's
    Traceur transpiler (useful unit tests with examples here) and there are shims
    available for other features via projects such as ES6-Shim and Harmony
    Collections.'

The module syntax and local relabeling reminds me of module syntax in PLT/Racket a couple years back. Given JavaScript's heavy scheme influence to begin with, it seems like a good thing to me.

Hopefully the browser vendors get this implemented before MS start work on IE11. That's the only way we're going to be able to use this anytime soon.