JSConf.eu 2011 was terrific, bigger and juicier than last year, with a strong sense of community felt from reject.js pre-conf:
to start:
to finish:
Chris Williams makes a moving plea for an end to negativity, meaning trolling, flaming, mocking, and hating in online media.
This sounds utopian, like “an end to history”. But it is good as an aspiration, a constant reminder, since we’ve all seen how many people tend to be more negative online than they are in person. This isn’t just a matter of isolated individual behavior, free of cultural feedback loops. The new media reinforce tribalism.
However, it is hard to be positive about some things. I will persevere….
JSConf.eu had too many awesome talks to cover without bi-locating. Mozillans were well-represented, including dmandelin and dvander on JavaScript JITs, Marijn Haverbeke on DOM implementation techniques, Chris Heilmann on Community JS reloaded – how to rock as a movement, and Andreas Gal on PDF.js. Janet Swisher led the MDC doc sprint in the Hacker Lounge.
I would like to single out Alon Zakai‘s Emscripten talk. Emscripten is an LLVM-to-JS compiler, which means it enables compiling C, C++, and Objective-C (and other languages with LLVM front ends) to JS. What’s more, interpreters written in C for Python, Ruby, and Lua have been compiled and hosted on the web.
Alon’s results are impressive, with lots of room for more wins. At JSConf.eu, jaws dropped and eyes were opened.
For my talk, I reprised some CapitolJS material, including the RiverTrail demo, which won loud and enthusiastic applause when I clicked on the “Parallel” button.
(A few people asked afterward about whether the graphics was running on one of four cores. I’ll repeat the answer here: the particle system demo uses WebGL targeting the GPU for rendering, and the four CPUs’ vector units for n-body solving. All from deadlock-free, data-race-free, seemingly single-threaded JS.)
Here’s the video of my talk:
The amazing Anna Lena Schiller created infographics for all the talks, on the spot — a truly impressive display of concentration and stamina. Here’s the one she did for my talk:
And here are the updated and new slides I presented, showing ES6 work-in-progress (none of it final, so don’t panic) and covering some current controversies.
From recent es-discuss messages, I’m afraid that classes are on their way out of ES6. This seems a shame, and avoidable. In hindsight, we did not have all class advocates working in concert on the hard issues last year and earlier this year. But we also do not agree on what’s required for ES6, and some on TC39 view minimizing as future-hostile.
To be blunt, we lost some “classes” advocates who work for Google to Dart. Others at Google on TC39 seem to want more out of ES6 classes than even Dart guarantees (see the future-hostile point above).
I’m not slamming Google as a company here, since it does still support people working on JS in TC39. I respect the people involved and believe they’re for the most part making their own choices. But Dart and other unrelated Google agenda items do impose clear and significant opportunity costs on Google’s standards actiivities.
To remain positive per “An End to Negativity”, I’ll simply conclude that we TC39ers should pay attention to Dart now that it is out, even though we’ve lost time and potential contributions.
The famous Tony Hoare quote that Bill Frantz cited, which argues for deferring classes, is this:
When any new language design project is nearing completion, there is always a mad rush to get new features added before standardization. The rush is mad indeed, because it leads into a trap from which there is no escape. A feature which is omitted can always be added later, when its design and its implications are well understood. A feature which is included before it is fully understood can never be removed later.
From C.A.R.Hoare’s 1980 ACM Turing Award Lecture
I agree with Erik Arvidsson that “[b]y not providing [class] syntax we are continuing to encourage a million incompatible ‘class’ libraries.” I’m with Erik: I would still like to see TC39 agree on minimal classes. But not at any cost.
Onward to new proposals with sometimes-tentative syntax. I’m continuing to “live in a fishbowl” by showing these proposals, even though doing so risks drive-by misinterpretation that we have finalized the sum of all proposals.
So, please don’t freak out. Not all of this will make it as proposed. We may also make cuts. But it’s important to address the use-cases motivating these proposals, take in the fullness of the problem space and potential solutions, and do the hermeneutic spiral.
Apart from font issues that make <| look lopsided or non-triangular, this proposal looks good. It replaces the main legitimate use-case for assigning to __proto__: presetting the prototype link in an object literal.
Unlike Object.extend, .{ copies only “own” properties from its right-hand-side object literal, and (this is a crucial difference) it also copies properties with private name object keys (which are non-enumerable by definition). For example, base.{[privateName]: value, publicName: value2} given a private name object reference denoted privateName in scope.
Design patterns point to programming language bugs. Nevertheless, this class pattern shows clever work by Allen Wirfs-Brock, decomposing classes-as-sugar into chained operator expressions. It’s still a bit verbose and error-prone in my opinion, and cries out for the ultimate sugar of minimal class syntax (if only we could agree on that).
Much of the Dart class syntax design looks good to me. Possibly TC39 can agree to adopt it, with necessary adjustments. It would still be sugar for constructors and prototypes.
Arrow function syntax faces an uphill battle due to the combination of TC39’s agreement to future-proof by having an unambiguous LR(1) grammar (after ASI and with lookahead restrictions); mixed with the comma expression, (a, b, c), which I copied into JS’s grammar straight from C (not from Java, which left it out, instead providing comma-separated special forms in a few contexts, e.g. for(;;) loop heads). You can’t have both, and we do not want to remove the comma expression in Harmony.
I’m quite in favor of block-lambdas, and they meet formal approval from TC39’s strictest grammarian. Some still object to them as an alien DNA injection from Ruby and Smalltalk, both syntactically and (with Tennent Correspondence Principle conformance regarding return, break, continue, and this) semantically.
At this point, ES6 has no shorter function syntax. This seems like a loss, and fixable, to me. Your comments welcome, especially if they make novel distinctions that help forge consensus.
During the talk and Q&A, I recounted how the WHAT-WG was created to counteract a standards body gone wrong (the 2004-era W3C). I then raised the idea of a community-based group, a “JS-WG”, to augment the much healthier but still under-staffed Ecma TC39 committee.
Besides floating more ideas (really, the point is not to bikeshed endlessly or take in too many proposals to digest), a JS-WG worth organizing might actually develop draft specs and prototype implementation patches for JavaScriptCore, SpiderMonkey, and V8. The maintainers of those engines could use the help, and with patches and patched builds, we could scale up user testing beyond what’s in the cards now.
I know it’s hard to believe, but people are finally realizing that with V8 prototyping alongside SpiderMonkey, ES6 is happening. It’ll be prototyped in pieces. I hope many will be “on by default” (e.g., not under a flag in Chrome) well before the new edition is standardized (end of 2013). That’s how we roll in Firefox with SpiderMonkey.
/be
With all these competing proposals for what amounts to syntactic sugar over more fundamental data-model manipulations, the Lisper in me wonders if anyone’s seriously considered a nice hygenic macro system so everyone can have their preferred flavor of cake.
Zack: defmacro was awesome, but since JS lacks the Lisp nature of code/data equivalence, you can’t really have that. How would you implement backquote-comma, or even simple loop-unrolling-like tricks, in a language that doesn’t represent its code as sexps? Instead, you’d have to end up with read-table macros, which were always pretty sketchy to begin with. In JS, that would look a lot like C++ operator overloading, and I doubt anyone sane thinks it’s a good idea to bring *that* horror back.
I find all of these different line-noisy ways of spelling “lambda” kind of sad. It’s like you’re all trying to avoid saying any word with an “S” in it so that nobody hears your Lisp.
@jwz: JS parse trees can be rendered in JSON, which is homoiconic. The real problem for macros is hygiene, which is still a research topic. Dave Herman, Mozilla Senior Researcher and TC39 member, did his thesis on a theory of hygiene. I think we’ll get there with JS, but it’ll take a while. In the mean time, no point in depriving users of affordances that can be respecified as macros eventually.
/be
Brendan, you should use your position to remind everyone who turned off OCSP in Firefox so that the public wifi would work for them to turn it back on by setting “security.OCSP.enabled” back to 1 in about:config.
(And sorry to say, even though I wasn’t there last year, I liked Proxies Are Awesome! better. But that’s just because proxies are awesome, and beating that kind of inherent being-the-shit-ness is a big task.)
And Alon Zakai is a great public speaker, enough that that’s what was occupying my mind ~10% the time during his talk.
Why are you so anti anything but JS?
Yes JS is good enough and it is getting better. But it isn’t as good as taking everything learnt in 15 years of web dev and creating a new language from scratch.
Whether JS could be replaced is a different question and I don’t disagree that it may be impossible for all browser vendors to agree on a new standard. However, I don’t see the need to be negative towards something of a fresh start language (whether it is dart or something else) since if it did actually succeed it would be great for the web.
Alistair: my post was not negative or “against” anything that’s not JS. Your reply is a good example of post-modern new-media tribalism and zero-sum “positivity for one tribe is negativity toward other tribes”. I don’t buy it.
My post was of course positive about JS. That’s a calculated move, because too many people — including at powerful companies that could fragment the web — are excessively negative about evolving JS, yet there is a public good at stake: the open web as it is, not likely to be replaced on any schedule, and the knowledge distributed among today’s web developers who use JS well.
But anyway: my blog post in fact said some positive things about Dart.
Consider a less tribal, zero-sum point of view: Dart is not likely to be adopted by other browsers even if a native VM ships in Chrome. But JS could be a good “VM” for Dart and for many other languages. And it can learn from Dart. These are reasons to be positive.
/be
I understand there are plans for # but the Dart library approach looks good:
#library(‘slider_sample’);
#import(‘../../base/base.dart’);
#import(‘../../html/html.dart’);
#import(‘../../view/view.dart’);
#source(‘SliderSample.dart’);
main() {
SliderSample.main();
}
The use of a symbol like # is good because it really stands out that some kind of precompiler is executed. Also deals with the global object issue – the revised dom (html.dart) is explicitly imported.
The grammar indicates a second param for import to deal with namespacing:
libraryImport:
’#’ ’import’ ’(’ stringLiteral (’, ’ ’prefix: ’ stringLiteral)? ’) ’;’
The major difference with the ES6 simple modules proposal seems to be that there is no way of modules/libraries being defined inline within the source code.
Overall, imo Dart is maybe too OO and not enough functional and structural – especially with the liberty of a greenish field. Dylan with multimethods and macros was a good approach.
Kevin: agree on Dylan (or Cecil). Dart is quite conservative, apart from the covariant generics heresy.
ES6 modules are shaping up nicely. I don’t see better on that front in Dart, certainly not # syntax. Why use a funny character if we don’t need to? Are you thinking of the unreserved status of ‘module’?
/be
My understanding that the ES6 module construct can fetch code from the internet or a filesystem or whatever. I really think this action is conceptually distinct from standard constructs/keywords – and should be flagged as such. And regarding the unreserved status – a leading character makes it easy to add to constructs without reserved word clashes.
Also useful for pragmas – speaking of which:
#pragma(‘semis’);
// mandatory semi-colons for statement termination. Also include jslint tidy up’s e.g not allowing the hole.
Most serious app code requires semis – and is run through jslint. Why not make it a built-in parsing possibility for serious dev’s and alt-JS’s. Side step the automatic semi-colon insertion issue.
And for the Coffeescript parens free sweetness maybe:
#pragma(‘layout’); // Haskell inspired
function test(x)
let lst = [2,4,6]
for i in lst
print(i)
// anon funcs/lambdas/blocks/whatever still have delimiters
lst.forEach {|i| print(i) }
// Same code without layout mode
function test(x) {
let lst = [2,4,6];
for (i in lst) {
print(i);
}
lst.forEach {|i| print(i); }
}
Should be able to round trip from the curlies/semis source to the layout mode code without loss via the AST.
Damn – the layout mode example lost the indentation.
// with 4 dots representing 4 spaces for indentation
function test(x)
….let lst = [2,4,6]
….for i in lst
……..print(i)
….// anon funcs/lambdas/blocks/whatever still have delimiters
….lst.forEach {|i| print(i) }
Kevin: *prefetch*, not fetch. Big difference — no nested event loop, no preemption. Also, ES next has a pragma syntax: use version 6; is an example (not in quotes, note well). More significant than the syntax are the semantics, which do not in any wise call for a #-prefixed C-pre-processor homage.
/be
Prefetch = imported code is fetched at parsing/compile time – not at runtime. This is what i meant when i said ‘fetch’. Not sure why Dart has lib names in quotes.
Maybe the optimised V8 and JSC code bases are getting quite complex and thus the vendors could be reticent on largish changes. Modules looks like quite a significant change.
Kevin: not sure about JSC but the V8 team in Munich is implementing ES6 proposals — proxies weak maps simple maps&sets already, ‘let’ currently, modules soon from what I hear. Jason Orendorff of Mozilla is implementing modules in SpiderMonkey.
/be
The stuff the V8 team has done are API changes and ‘let’ (with const) is a reserved words and thus in the bag. JSC were the last minute holdouts to ES4.
Is @ available for ES6 – MS did something with it re conditional compilation. Are they OK with repurposing – would be useful to get a yea or nay. To flog a dead horse:
// declare a top level module/library/frozen object named goog
@import https://www.google.com/js/utillib.js goog
The above actually works quite well with the compile time @ MS innovation. (Hey – MS did innovate in the late 90’s – they invented Web2/Ajax in IE5).
Done – i won’t bang on.
Kevin: funny chars need more justification than you seem to be giving. I can’t tell if you are implying V8 won’t implement ‘module’ because it is not reserved in ES1-5 (neither was ‘let’ — only ES5 strict, an opt-in mode, reserves ‘let’ and ‘yield’). It’s not hard to reserve ‘module’ at least in the contexts where the ES6 modules proposal puts it.
It’s harder in fact to reserve ‘yield’ since it occurs in expressions, where so-called restricted productions (the “[no LineTerminator here]” bits in ECMA-262’s grammar) are more user- and backward-compatibility-hostile.
To justify funny chars, we need to employ them for new operators, quote delimiters, generally applicable prefix modifiers (e.g., # for sealing/freezing), and the like — new and well-integrated special forms. Where a keyword will do, no funny chars need apply.
Please don’t pattern-match on other languages’ syntax. Semantics first. And in this light, ‘let’ in V8 is hardly “in the bag” — implementing the correct semantics for block scope requires a fair amount of work.
/be
Ok – i think the Dart approach to libs is better for both syntax and semantics. And also getting buy in from implementors – it’s less complicated. I fear simple modules will prove to be neither simple or that lexical.
Re focusing on the core semantics and the core runtime object model – i could not agree more.
Thanks for your reply Brendan.
I was more taking all the comments you have made on it more so than this post.
I agree that evolving JS is a top priority and if Google is not committed to that then I definitely lose some respect for them. However, I do respect them for trying to introduce a new language that if it did somehow manage to succeed would be great for the web.
I personally do not liken dart to vbscript as I do not think Google is trying to gain control per se, I think they just want to advance the web as their whole business is based on that platform succeeding and I don’t think they want to use that control to drive users towards Chrome.
@Kevin: you haven’t said why Dart’s approach is better. The funny chars? That can’t be it.
ES.next modules have lexical scope only — all of ES.next does in fact. That may be a pain for some code that plays tricks with global properties as global vars, but the win of early errors for typo’ed free variable names is worth this likely-rare migration tax.
Of course there’s the module loader API, which allows dynamic loading — but still no dynamic scoping.
So I can’t imagine what you mean by “nor that lexical” — care to say more, with an example?
@Alistair: there are many “Googles” — some are intentionally making power moves because “the standards process is too slow”, e.g.
Or the knee-slapper about iOS’s native apps being so awesome that, no, not new device/sensor/camera/radio APIs, not better widgets, but a new programming language to rival Obj-C is required. Yeah, right!
These rationales are lame in my view, especially since the particular complainants don’t play nice or at all in the relevant standards bodies for addressing the particular complaints about the web standards.
Also lame because (as I wrote on HN) Google doesn’t have 50-80% market share. If it did, it could perhaps force new de-facto standards. Perhaps it will get to 50%, and the aggressive parties are just “optimizing”.
Still anti-social in my view. The risks for fragmentation and other unintended consequences — just the opp’ty costs to JS and cross-browser standards — are large.
See the Toyota links in my blog post for another power move. I don’t think this is coincidence. Third time is enemy action.
Note some contrasts in Google’s various extensions and how Mozilla is responding:
* WebM: unencumbered, good quality, open source, a spec in progress, *multiple* implementations — we implement.
* SPDY: not a replacement but an “and also”, additive — open source, spec en route to IETF — we implement.
* Pepper: no spec, no independent implementation, and we’re told that in Android.next it *replaces* NPAPI (as ActiveX did in 2001 in IE). It’s ActiveG. We cannot afford to try reverse-engineering so large an API onto Gecko. And if the goal is to support NaCl, we dissent both on principle and (with JS perf and target suitability) on pragmatics.
* Dart: secret sauce till this month, now we can see about aligning ES.next and further Harmony editions of JS’s standard to support Dart better. No sign of a native VM or sweet-talking into other browsers, and I put zero odds of such succeeding without market power.
Don’t kid yourself. Google is not just trying to “advance the web”. Putting things in Chrome that have no standard spec in progress and none in sight, pulling Chrome-only (not just “works best in Chrome”) marketing stunts, paying app developers to do Chrome-only versions, paying for opt-out bundling of Chrome (with default browser opt-out to boot, recently killed by Microsoft when the Skype deal closed). These are intentional acts.
/be
It frightens me that classes and a shorter function syntax are not settled, and may not even be part of ES6 at all. These are badly needed enhancements that will make the lives of boring regular web developers like me much easier. Jettisoning them, while including features like proxies and quasi-literals, is totally backward, and makes you look out-of-touch with what the majority of JS users want and need.
Jon: careful with that “you” in “you look out-of-touch”. I’ve done the work, not just the talk, for shorter function syntax. I am still working the committee and I won’t give up.
As for classes as prototypal sugar, some of us on TC39, including valued Google members, are attempting a rescue. It would help if the future-proofers who object even to minimal classes, including one Googler who didn’t manage to stop Dart with the same kind of objection, would ease off a bit. We can’t disprove hypotheticals about the future without some prototyping.
/be
Brendan: Sorry, by “you” I meant TC39, not you as an individual, but I should have made that explicit; I very much appreciate the work you’ve done. But you (as a person) do seem to be willing to accept ES6 being finished without these features, and while I understand your desire to achieve consensus and to ship something, I think that is a mistake. They should be absolutely non-negotiable, even if it means breaking the committee again and splitting off WHATWG style.
Indeed, the argument from future hypotheticals sounds dangerously close to the XHTML 2.0 pursuit of theoretical goals at the expense of practical reality. The perfect as the enemy of the good, and all that. It’s especially ridiculous given that the entire history of the web, and JS, has been one of imperfect technologies succeeding by virtue of offering something here and now that people need. I need classes and short function syntax. I’d rather have an imperfect version of them now than a perfect version of them in six years time.
Jon: my BDFL coup plans are around here somewhere — they are open source ;-).
Seriously, Ecma TC39 works in the Ecma/ISO tradition, by consensus, but you’re right about argument based on unfalsifiable worries being a problem. More in a bit.
/be
Personally, I’d argue for the prefixed syntax for concise lambda definitions. (a, b) -> … doesn’t just throw off an LR(1) parser, it throws off my human parser as well. I like having an introduction character, like , to immediately say “this is a lambda” without excessive syntax. Also, having an introduction character makes the parentheses optional: x -> x and x, y -> x*y both seem unambiguous.
Anonymous: backslash does not work lexically — it is taken with Unicode identifiers.
I agree that LR(1) and human parseability often line up in some informal rough way, and we should pay attention. But LR(1) is enough because we need an unambiguous grammar to avoid painting the grammar into a corner in the future when trying to add further new syntax.
So, how about block lambdas?
/be
@Brendan
My question then would be, do you see any limitation on what JS can become given enough time via the standards process? eg. Can it become more or less Dart? (I’m not saying it should or that Dart is some be all and end all web language.) Can it get rid of the bad and awful parts as noted by Douglas Crockford?
And perhaps more relevantly, is it likely to significantly evolve via the standards process in a reasonable time frame? Can it keep pace with the web?
Looking at where ES6 is going it seems to be in line with ES5 in that it is a powerful language with a lot of functionality, but to utilise it for a web app in the most intuitive way involves a lot of ugly syntax (for example the ‘The class pattern using triangle-monocle-moustache’).
I think the lack of classes and classical inheritance is a pretty clear strike against the (current) standards process for ECMA. I have only ever seen the inheritance model hacked into JS. I have never seen the prototypal model utilised so I find it disappointing that the class based model isn’t likely to make it since this is apparently what web developers want.
Also, I think it is best to judge Google on what they have done publicly so far. They have released a new language (which is in alpha) that works server side and that can also compile to JavaScript to run in a browser.
At this point this is a good thing. New languages are always good and in this case it can be used optionally instead of JS. Both positives for developers.
I don’t think it is fair to judge them on what they may or may not do in the future. If and when they have a Dart VM in Chrome (yes, I’m sure it will happen) this is the point when it is right to critique them on how open the language is and what language spec is in place.
Another question: Do you think by releasing Dart more pressure is going to be put onto ECMA to advance JS quicker and inline with developer wants? (and thus Dart will have a positive effect on JS?)
Alistair: on classes, I mostly agree. Either let’s do something competitive such as my leather-and-batteries-included get at https://gist.github.com/1332193 — or let us support ‘new’ on objects with ‘constructor’ properties and not do over-minimized classes.
Of course, some in the JS community view classes as an unnecessary complication. How do you respond to them?
On judging Google, if by “publicly” you include leaks, I agree. Everything after the leak includes the leak as “framing”.
/be
Nice, I do like your proposal.
I don’t think they complicate anything as they are completely optional. As to whether they are necessary, I think it is clear that JS needs some kind of inheritance model that developers can use to decomplicate complex applications. The prototypal model doesn’t appear to be it as (and I’m completely guessing here) maybe 90% of large JS based libraries / apps just use something like https://ejohn.org/blog/simple-javascript-inheritance/ .
I don’t include the leaks in what Google has (deliberately) made public. In any case, my point is that the time to judge the openness of Dart and its spec is when Chrome has a Dart VM and Google is pushing other browser vendors to support Dart (at this stage it is just a language in development).
Like for example, at that time Google may attempt to set up a standards body for the language and invite the other browser vendors to participate. Or they may propose a bytecode to allow JS and Dart to co-exist.
I personally don’t think we can say that Google is trying to pull a MS style power move for control at this point. We do know from the memo that they want Dart to replace JS as the standard client side language, but we don’t know how they will go about trying to achieve that and in what timeframe.
Alistair: the leaked memo talked explicitly about the power play, and that is what I responded to in September on HN. Google adjusted after the leak, too.
The framing changed and this cuts both ways — no fair objecting to my September response only in light of what Google did in October. Framing matters in politics, always.
This framing change in response to bad PR is one reason I am positive about JS and its community, enough to look objectively at Dart (late in the ES6 game) to adopt what is good and applicable.
But don’t be naive about the power play. Both Lars and Gilad predicted last week at SPLASH that Dart will replace JS. Google is spending ~1B US$ on Chrome bundling and advertising/promotion. I’ve heard rumors of Java-schools getting money and materials to teach Dart. The power play is in progress.
/be
1. The “extends” keyword is a reserved future word in ecmascript, so why not use that instead of “<|"? An aversion to symbols instead of operators?
2. Instead of ugly ruby/smalltalk block style lambdas, why not reuse the "in" keyword to hoist variables upwards as if they were parameters to an implicit function. e.g.
a.forEach.{
in k, v;
…
}
.{} == function(){}
.{in a; in b;} = function(a,b){}
.{in a, b;} = function(a,b){}
.{in a; var b; in c;} == error
.{var a; in b;} == error
@ASDF: 1, “extends” is the wrong direction for <| which has the object, array, or other literal on the right-hand side, not the left. class Derived extends Base, but let derived = base <| {derived: "properties", here:0}. 2, "ugly" is subjective, but objectively, making 'in' a prefix is confusing and hazardous to refactoring in light of existing binary 'in' operator. It doesn't make sense in English either. These are not "in" parameters. /be
Re less lexical:
1. Cyclic dependencies. Modules have visibility of modules defined later in the source code.
2. Nested modules and visibility of vars defined in outer modules
module acme = {
let myvar = 10;
module submod = {
// Q: is myvar visible here? If so – lexical. If not – not lexical.
}
}
Kevin: modules are second-class, dependencies are fetched at compile time (before any evaluation, and when early errors per the ECMA spec are thrown).
Yes, ES.next lexical scope only means outer let, const, etc., bindings are visible if not shadowed, including across inner module boundaries.
/be
@ASDF: Russell Leggett (see es-discuss just within the last day) proposed ‘extends’ as a prefix binary operator, “extends P {…}” where P is the prototype of the resulting object, and {…} or another literal form of an object (array, function, regexp). That does work better than ‘extends’ as infix operator. It also looks like it might compose with a ‘class’ prefix “operator” of some sort. Promising!
/be