A Few New Things Coming To JavaScript
addyosmani.com
addyosmani.com
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.
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.
Would you like to type this?
var myModule = (function(root){
var lib = {};
root.lib = lib;
return lib;
}(this));
module myModule = {
export //blah blah blah
}
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.
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.
This allows the constructor to inherit its properties from a parent constructor:
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` is indeed new semantics though, so that is definitely true.
super.say(string.toUpperCase());
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.
So please, if you are interested in the future of JS, take another look at Coffee. And bring on ES6!
[1] http://wiki.ecmascript.org/doku.php?id=harmony:generator_exp...
And it is not the exact same syntax (Harmony uses `for (e0 of e1)` paralleling its for-of iteration syntax and semantics), and more importantly the semantics are completely different. Finally, the syntactic similarity would already be covered by the array comprehension mention.
Thus, there's nothing even remotely close to generator expressions in coffeescript at this point, as far as I know.
However, it is possible to get a near-equivalent of generators (albeit with more overhead) using Continuation Passing Style and Iced CoffeeScript await/defer or another CPS lib. There are many who have explored this concept before myself, and I am now inspired to create an example to demonstrate IcedCS's ability with such a concept once I'm through the holiday.
And you're completely right about Coffee not able to implement ES6 generators.
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.
Sets are unordered: http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_a...
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')
obj.set('some.deep.nested.value', {
'more': {
'nested': {
'stuff': 'here'
}
}
})
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
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?
[1] https://github.com/jclem/steeltoe
[2] http://www.reddit.com/r/javascript/comments/13cuxh/steeltoe_...
In particular, it allows the use of arbitrary, non-string keys. Objects (commonly used as Maps) can have only String keys.
In contrast, desiring a way to `get` a nested String value is easily emulated in terms of current JavaScript semantics. In Ember, for example, obj.get('some.nested.path') works in all browsers because it does not require any new primitives.
Observers are a similar story. `Object.observe` adds a new primitive to the language: the ability to receive asynchronous notifications about changes made to some object. On top of that, it is possible to implement semantics for nested objects and "computed properties".
The Ember team has already been exploring how to incorporate Object.observe into Ember's observer system when it is more broadly available. We support observing nested paths, and the Object.observe primitive gives us enough to build what we need on top.
You can expect that if certain patterns on top of these primitives become popular, TC39 will consider them in future versions of the specification.
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.
That said, many of the features are sugar around existing patterns, like rest and default parameters to functions or arrow functions, so I expect that even an incomplete transpiler would be broadly useful as the specification solidifies.
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).
In an effort to get a class syntax into the spec, members of TC39 advocating for classes intentionally pared down their ambitions to something that could get a consensus of the members. Given the time-frame for ES6, I am happy that this proposal was accepted, because it gives us a base to work off of.
As a Rubyist, I consider "executable class bodies" or something like them to be crucial for user-land declarative syntax. I plan to do some work in the near-future on a proposal that should address this use-case.
Browsers do not need to wait for a spec to be fully finalized before starting to implement features. Firefox and Chrome have already started to implement large swaths of the more locked down parts of ES6.
Object.observe is actually a feature approved for ES7, and Chrome has already begun implementation. I tend not to think about the precise spec version that a feature is a part of, and more about getting consensus in the committee that a feature should be part of JavaScript period.
Perfectly fine for me.
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.
In short: whenever a WeakReference is dereferenced, a temporary strong reference to the object is created that is dropped at the end of the turn of the event loop.
There might still be non-determinism, but it is limited to the type that is already common in JS. Behavior across event turns (i.e. happening in asynchronous callbacks) cannot make any assumptions about what else may have happened between callback registration and callback execution.
For example, jQuery stores information on a unique, generated key on DOM nodes. Ember does something similar for meta-information about an object. With WeakMaps, both could store the information in a WeakMap, and avoid polluting the object.
WeakMaps are easier to get into the language because the GC-related semantics are unobservable. If you have a key you can use in `get`, the key is by definition not collectible. For reasons involving security leaks, it is more tricky (but not impossible) to add features to the language that allow third-parties to observe when an object is collected.
That said, I am personally a strong advocate for Weak References in the language, and have been advocating their inclusion on TC39. Two open proposals are http://wiki.ecmascript.org/doku.php?id=strawman:weak_referen... and http://wiki.ecmascript.org/doku.php?id=strawman:weak_refs. Active discussions involve post-mortem-finalization and avoiding security leaks.
As the maintainer of Ember and Ember Data, I fully agree with the need for this feature and will continue to work towards including it in the language.
Not sure I understand that one, what's the problem with dispatching events while in a loop?
> or an API for screengrabbing.
That makes absolutely no sense as part of ECMAScript.
Screengrabbing does make sense, and is required for web conferencing. All other features are there (audio/video/canvas), screengrabbing is the only one missing.
Also despite what you say you CAN trigger an event (or whatever) inside a loop, it just won't do anything until you're out of the loop. This is because your browser implements javascript in a single thread. There are two easy solutions: Don't use a loop that's going to last for a long time, or use a Web Worker. This is, again, something that browsers have implemented, not a part of javascript. http://en.wikipedia.org/wiki/Web_worker
So by "the event loop is not fired" you mean "the event loop does not run" when you're already being run by the event loop? That seems to be... logical.
> You have to use setTimeout and break out of the loop.
You can also use e.g. window.postMessage. but yes to make the event loop run you do indeed have to yield to the event loop.
> and sometimes the browser chugs along even when you do use setTimeout.
Again, I'm not exactly clear on what you mean. Javascript has a toplevel event loop and a queue of fired events, when you yield to the event loops it runs the event queue in order, not sure what's surprising about this.
Hell, I'm not even sure this discussion makes sense as part of ECMAScript comments either, the event loop is not part of ECMAScript and it's perfectly possible to have JS runtimes with no event loops (the tracemonkey console for instance)
> Screengrabbing does make sense, and is required for web conferencing. All other features are there (audio/video/canvas), screengrabbing is the only one missing.
Reading comprehension. It happens to be a thing.
I didn't say screengrabbing made no sense, I said it made no sense as part of ECMAscript. It might make sense as part of WebRTC or as part of some DOM API, as part of ECMAScript it does not make any.
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 compatibility table is here: http://kangax.github.com/es5-compat-table/es6/
Result: IE10 supports exactly zero of these features. We can start using them (maybe) once IE10 is dead.
Because Microsoft has bet on JavaScript heavily for Windows 8 apps (at least for now), and Windows 8 apps have full support for ES5, they have very good insights about ES5.
ES6 is still "coming". Many features are still in flux, and I don't blame Microsoft for not committing to in-flux ES6 features in the timeline of IE10.
IE9 still can't draw stroked text, for example.