I gave two talks recently, first at O’Reilly Media’s go-big-with-JavaScript FluentConf, and then at my favorite regional JS conference, the delightful TXJS (gorgeous site design), curated and stage-managed by Alex Sexton, Rebecca Murphey, and other usual suspects.
My Fluent video was up in record time, one achievement that the O’Reilly folks can brag about:
There I played the JS clip from Gary Bernhardt‘s hilarious Wat lightning talk, and gave bleeding-edge demos that my TXJS talk updated (video link for TXJS to be posted as soon as it’s available).
At TXJS, my title perhaps referenced Larry Niven (but let’s hope not), and my content directly cited the work of the late Lynn Margulis, champion of endosymbiotic theory. If JS is a mitochondrion, what in our modern web world correspond to the eukarya? I suspect we are in the midst of finding out. Node is probably involved.
At TXJS I mixed new metaphors like mixed drinks, harkened back to my last year’s TXJS talk, and gave the latest demos.
The big-picture story is renewed humility in the face of community feedback. My goal is to help the JS standards body be the best it can be as one of several symbiotic critters in an evolving system.
In last year’s TXJS talk I elaborated on how Ecma TC39 works, and also malfunctions sometimes. The important point is the hermeneutic spiral.
The spiral lives, and it works — although newcomers to es-discuss sometimes think consensus has been achieved within one 16-message thread. Not so fast! But consensus on ES6 is being achieved.
Lots of learning and re-learning here:
- Versioning is an anti-pattern on the web, wherefore 1JS.
- Syntax as programming language user-interface should evolve, but unlike standard library additions, developers can’t fix it or abstract over it (no macros yet, sigh). I made JS’s object model mutable at the start so people could polyfill, and they continue to do so for good reason. New syntax has to be minimal, righteous, and user-tested to get into Harmony, and that’s the way it should be.
- One new syntax-suite that many agree pays its way, maximally minimal classes, still isn’t in ES6. Working on it…
- My old “dunder-proto” (LOL, @littlecalculist was inspired in this pronunciation of
__proto__by Dunder-Mifflin) vanquished triangle (ugly typography didn’t help triangle either). - People still rant about JS’s privileged client-side status, but it’s a curse more than a blessing (Python, Lua, Ruby all would have been frozen badly if wedged into Netscape 2 in 1995).
The only hope is mutualism in an evolutionary struggle toward something better than either TC39 or JS developers could achieve by themselves. I tend to believe that this struggle will end well, better than master-planned would-be alternatives that don’t have a prayer of catching on as native-VM-implemented-yet-cross-browser on the Web as currently constituted.
JSFixed represents both a cry from the heart by some in the JS developer community, and an attractor for bikeshedding and tons of noise. But with excellent curation by @angustweets, @valueof, @rwaldron, and @KitCambridge, it has produced a reasonable set of recommendations. Now it’s up to TC39 to engulf the recommendations that it can stomach, as if we were a hungry cell and they a primitive bacterium, and then for both sides to find mutual wins in the resulting ensemble.
These are straightforward, but I expanded on maximin classes in the next slide.
Only => (fat arrow) made it into ES6; thin arrow may be an arrow too far, but I will try again at the July TC39 meeting.
The existential operator, ?., is relatively straightforward. I will put it on the agenda for July. It could fit in ES6, IMHO, without breaking any budgets or agreements.
I intend to write up Object.prototype.forEach as a strawman, based on JSFixed’s recommendation. It relies on Object.keys order, which in turn is for-in order, but no big deal. It’s a useful object method, shadowed by Array.prototype.forEach.
JS in 2gyr? More like at birth + 35yr. CoffeeScript forks off and rejoins with Ruby bacterial DNA engulfed. Is that Dart near the bottom? 😛
Evolution does sometimes paint a clade into a dead-end corner, or leave the evolved system with harsh dilemmas and “pick any two” trilemmas.
The quest for shorter function syntax runs afoul of this binding. As I said in my talk, if we are counting fairly, then => and -> are not a single short function syntax, they are two syntaxes grouped by being “arrows” or having two chars ending in >.
This slide refers to the default operator proposal for Harmony, which I’ve recently edited based on several rounds of es-discuss and twitter feedback. It is looking good, IMHO, with the only remaining issue (also open for parameter default values) of whether null as well as undefined should trigger defaulting.
Somehow, @rmurphey knew I would be speaking about Unicorns.
ES6 is already partly implemented in top browsers, and it is coming to more browsers soon. Time to start experimenting with it and giving feedback.
My demos:
- Box2d with 80 boxes (source)
- BananaBread (source)
- Shumway racing demo
- LLJS Demo
- @littlecalculist‘s new TC39 wiki draft (compare to old wiki)
- UPDATE: bonus live REPL session showing off int64 and uint64 value objects in SpiderMonkey
So yeah: 3D games, Flash, and C/C++ in JS. Can you dig it?
I close by praising Wesley Snipes again (this time with a jwz memory), and taunting those who doubt either JS or Passenger 57.
I do not taunt for the sake of JS in itself, which started life as good-not-great where it wasn’t just silly. Rather, for JS as an over-maligned, unique evolving system that somehow still unites a standards group (made of competing browser vendors) with faithful JS developers, working together for a better symbiosis.
No other language has the curse or the blessing of this fate. Let’s do our best. Thanks to the JSFixed crew for doing theirs.
/be
I feel fortunate to have attended both…
Re arrow functions. Are named functions possible?
area(b,h) => b * h;
// creates a block scoped const binding
// const area = (b,h) => b * h;
Arrows are expressions, without intrinsic names. TC39 wants binding forms to start with a keyword: const let var function. But the lack of an intrinsic name is a loss compared to long-hand function expressions. Thanks for reminding me, this came up on es-discuss a while ago but I didn’t address it in the proposal.
/be
If in ES6 developers as best practice prefer the following form in ES6 to a standard ‘function’:
const myfunc = (x)-> {… blah …}
then maybe a case for sugar:
myfunc(x) => {… blah …}
Do arrow functions have expandos and use the Function prototype:
mfunc.x = 5; // set expando to 4
myfunc.WhereDidThisComeFrom; // property on Function prototype set previously
If not then named Arrow functions could fulfil some of the requirements in:
https://wiki.ecmascript.org/doku.php?id=strawman:const_functions
Previous comment should start with ‘If’.
@Kevin: WP with my theme lays out comments oddly — your “If” is there, just over on the right of the date and (Edit) links. Anyone know of a fix?
To answer your questions, please see
https://wiki.ecmascript.org/doku.php?id=harmony:arrow_function_syntax
Fat arrows express true function objects, can have expandos, delegate to Function.prototype, but (like ES5 Function.prototype.bind results) have bound |this|. Fat arrows do not have [[Construct]] or a .prototype property, you can’t ‘new’ them.
I do not think “best practices” will favor
const f = (a) => a*a;
over
function f(a) { return a*a; }
for all functions. For a short “square the argument” function like that, maybe — but more likely you’d write the => expression where it’s needed, usually passed down as a funarg. For declaring (as opposed to expressing) named functions with longer bodies, long-hand function will endure.
/be
Oops – should have read the wiki – it’s all there. Optional leading identifier – deferred.
But re best practices and the form:
const f = (a) => {
… block of code…
}
For declaring ‘traditional’ non-method functions this form has the advantages of being:
1. block scoped via const. Not hoisted. Also cannot be assigned too.
2. more self-documenting. Says upfront – i’m not a method. And if a |this| is added to the body it is clear that it is lexical. No ambiguity.
thank you sincerely for these updates brendan. they are immensely useful and appreciated by the dev community.
Brendan, thank you for all these updates and great blog posts. Often I bookmark pages and forget to read later but I’ll be making it a point to read through your blog – which I stumbled upon while skimming over RiverTrail; it’s really a gem and I appreciate the effort.
I apologize for asking this in a comment, but do you have any reading materials you’d suggest which reflect a level similar to the content you’ve posted on your own blog? I’m finding it very difficult to really push beyond common libraries such as ExtJS and into higher performance computing with JavaScript. I’m also curious how developers push new ES standards while supporting incompatible browsers (eg: ES5 on IE7).
Thank you!