As for implicit coercions, I enjoyed Gary Bernhardt's "Wat", referred to it, and at past talks even mocked along with. At Strange Loop, I went through each "Wat" in the "Wat Secrets Revealed" slide series (use down arrow when you see it greyed in).

Of course (!) I regret the implicit conversions that make == not an equivalence relation with disparate types on left and right (NaN is a different story: blame IEEE754). Who wouldn't? As I said at Strange Loop, some colleagues at Netscape were hot for lazy/loose number/string matching, and "I was an idiot! I gave them what they wanted."

There may be hope of fixing even ==, if we get macros done right. You would opt into macrology redefining == to be === or whatever you want. But this is in the future.

And that's the point: JS must grow compatibly, given its cursed/blessed position in the web. There is no other option that costs as little incrementally. True, we could paint into a corner. I don't see that happening, not with the vibrant and very smart JS developer community (communities, really) with whom we are working.

On a practical level, I once ran into someone who used to work at IDEO and became a JS hacker in the course of doing a startup. I asked him about == quirks and the like. He just shrugged and said "you learn what to avoid and move on." That is the voice of practical wisdom (until such time as macros help fix the quirks for good).

So my advice is cheer up!

"Jumping to a JavaScript 2.0" is the hard part. Any successor to JavaScript has to have a compatibility story with all the JavaScript code out there, as well as the DOM APIs and so forth. Either you ship two VMs, in which case each page has two incompatible worlds (yet both can access the DOM -- think about the massive complexity this entails), or you have to think about language versioning, which requires at the very least a functioning static module system.

http://wiki.ecmascript.org/doku.php?id=harmony:let

http://wiki.ecmascript.org/doku.php?id=harmony:const

http://wiki.ecmascript.org/doku.php?id=harmony:block_scoped_...

Some of the new-function/lambda-syntax proposals even support Tennent's Correspondence Principle to some degree.

Lastly, the new class stuff doesn't actually change the inheritance/object models in JavaScript. It's syntactic sugar on top of prototypes, and the "weird constructor stuff" is quite analogous to existing constructor functions. For example, from the [ecmascript wiki](http://wiki.ecmascript.org/doku.php?id=strawman:maximally_mi...): "Class declarations/expressions create a constructor function/prototype pair exactly as for function declarations."

I'm clearly a bit of a fanboi and obviously biased, so take all of this with a grain of salt - but most of these new language features are a good thing. I'm glad to see JavaScript evolving in big ways. It was getting boring watching new editions come out with nothing more interesting than Array.prototype.reduce in them. Especially when you consider server-side contexts like Node.js, stuff like typed arrays, generators, Maps, etc. are welcome additions.

Yoda said "where you are" but you used "was". Possibly just a tense-typo, but it matters. Tracking where JS is is a part of the TC39 job, but only a part. It's easy to fall into a trap where we standardize only what developers can express given the language's current semantics and so miss the chance to extend those semantics.

But I'll take the tense-corrected bait: yes, I talk about the future. The past (including its most recent instantaneous sample known as "the present") is greedy. With no one to look ahead or synthesize ideas from compile-to-JS and other languages that win user support, JS will tend to stagnate, all else equal. Champions (not just me) must fight for a better future.

Stagnation on the web is a social ill. It costs developers tons of time. We know this not only from IE6, but from Android 2.x WebKit. Some not-disinterested parties might want to make use of a crisis of this sort, to force a "new JS" (Dart? remember WPF and WPF/E in the past) to be adopted for want of anything to relieve the stagnation.

Not me. The cost is too high, the lessons learned in JS will be half- or three-quarters-lost, and too much code and developer brainprint will be thrown away. I'm reminded of the XML Utopia that was planned in w3.org to save us from bad old HTML, before a few of us called b.s. and started the whatwg.org to do HTML5.

The web is an evolving system, JS is part of the web standards and must evolve too. Skate where the puck will be. Or to wannabe Yoda on ice: where the puck will be, you must skate!

==, numbers as strings => Problem: Type Coercion eval => Problem: Interpreted Language incorrect definitions of false => Problem: Type Coercion semicolon insertion => Problem: Language improper lexical scoping => Problem: Not block scope?

>The class bit particularly made me sad: JavaScript has a perfectly cromulent, even elegant, object model in the form of prototypes.

Both forms of object creation are valid.

[Object.create] http://jsfiddle.net/X4Bxq/

[new] http://jsfiddle.net/UGTga/

Both take advantage of prototypes (the later takes full advantage today, with all browsers. The former requires a hack where you lose your type information).

What is more important is that they are both awkward. So much so that most "JavaScript" programmers don't even use them. Those that do, spend most of their time arguing on which one is more correct. This is a problem. Introducing 'class' would sort this out by providing an easier syntax for class creation and an end to the arguments.

The nature of a widely-used technology is that you can't remove features, you can only add. And yet adding features causes an increase in complexity. So what to do? The answer is to add features judiciously: prefer general features that cover a wide array of use cases and can provide better ways to do things that the existing features don't do or don't do well. (But also avoid over-general features that destroy important invariants -- for example, just say no to call/cc or threads.)

> But the huge gaping holes in Javascript are not missing features. They are fundamental errors in the language. Things like ==, numbers as strings, eval, incorrect definitions of false, semicolon insertion, and -- heaven help us all -- improper lexical scoping.

ES6 -- and potentially down the road, macros -- are paving paths to fix many of these problems you mention, and other important problems besides (e.g., callback hell). Lexical scoping is partially improved with ES5's "use strict" and further improved with ES6 modules. Block scoping finally exists thanks to `let`. ES6's module loaders allow translation hooks to enable dialects or alternative languages to be run in-browser (which you can do with preprocessing and build steps and directly, but using them in-language streamlines the "shift-reloadability" development experience). Module loaders also provide a saner eval, which allows you to completely sandbox the evaluated code. Macros could even allow rebinding operators like `==` to have cleaned-up semantics. We intend to try this out with sweet.js, building something like "restrict mode" (http://restrictmode.org) as a module you can import.

Dave

There aren't "typed objects". There is a new library for working with binary data efficiently.

Classes and modules serve different purposes. Classes provide syntactic sugar for prototypal inheritance. Modules provide a baked-in mechanism for encapsulating and sharing code.

same with macros and codegens

Neither of these are on tap for ES6. Brendan showed them as interesting experiments that may be proposed for a future release.

I think there's a lesson from C and C++: don't add complexity unless it's absolutely necessary.

Yes.

JS is never going to take over on the server for me until it can compete with Python's statistics support, I didn't see much in these slides that suggests it could.

Would highly recommend Javascript: The Good Parts, don't know where I would be without it.

Yes, as someone who has programming background, it sometimes seems to be directed at those with no programming experience, but it still helps to start from the beginning and walk through.

As someone with a some CSS, HTML knowledge and no CLUE what the DOM was or how javascript interacts with HTML/CSS, it's been a good few days for me.

http://wiki.ecmascript.org/doku.php?id=harmony:generators

is a more general abstraction, which allows expressing async/await-type constructs: http://taskjs.org/

What I can't understand is the fundamentalist reaction to the very idea of native code, the ignoring/dismissing of serious work to solve the problem of portability, the liberal use of words like "never" and "non-starter," spread of FUD by invoking inaccurate comparisons like ActiveX (vis a vis its security model) and DLL Hell, and the spreading of misinformation. For example, PNaCl is not, and as far as I can tell never has been, dependent on machine word size. The link you cited doesn't apply because it is arguing against a different approach than what PNaCl actually does.

PNaCl works by defining a little-endian ILP32 machine as the target and fixing all important characteristics of this machine independently of the characteristics of the underlying CPU. This abstract machine's characteristics are defined in such a way that they can efficiently be translated to native code on any modern CPU. This is all covered in the introductory doc: http://src.chromium.org/viewvc/native_client/data/site/pnacl...

> a cross-browser approach targeting JS VMs, which are already there and getting fast enough with typed array memory models to compete with PNaCl? (We aim to demonstrate this.)

This is a far more reasonable and compelling story. By all means talk up your stuff and argue that you can win in the free market of ideas. I'm not arguing that I or anybody else should be able to dictate to developers what technology they use; on the contrary it is the Mozilla argument of "no one gets to the machine except through our VM and our GC" that paternalistically ties developers' hands and limits their options.

Silverlight is closed-source, patent-encumbered, and released by a company with a history of "embrace, extend, extinguish." That someone who appears to be speaking for Mozilla would draw this comparison is, again, disappointing.

> If PNaCl ever happens and is not directly tied to Chrome's internals (which it is at the moment), the discussion can be revisited.

This claim is directly at odds with the public statements of Mozilla's Chris Blizzard, who argues against the very idea of native code delivery to browsers. His arguments aren't against the NaCl implementation, process, etc, they are fundamental arguments against native code in general: http://www.theregister.co.uk/2011/09/12/google_native_client...

> Basically, as far as I can tell your argument comes down to saying that Mozilla should be open to implement PNaCl (not NaCl)

I'm not even hoping for that at the moment, at this stage I'm only hoping for them to stop maligning it publicly, like Chris Blizzard saying it will lead to DLL hell, or like with Brendan's slide that desaturates a picture of salt as if (P)NaCl is going to come for your children in the night.

As in, Mozilla would implement a common core of NaCL features, perhaps omitting some of the less-core ones that Chrome has, and adding their own extensions, and they could see what was good and what was bad, and experimental features could gradually become part of the standard? Sure, sounds good.

But for google to try and define a standard when they only have the only one immature implementation would just be stupid.

For example, NaCl doesn't provide Garbage Collection (GC) last I checked. Applications can link in GC libraries for themselves, however that's more code for clients to download, and it may mean that the GC can't do all the low-level things that modern GCs do to get good performance. Is this an acceptable tradeoff for the web? I believe questions like this one are the important ones.

@pcwalton Please assure me that rust won't compile to javascript, and it will remain Native (C/C++ compatible, ahead-of-time). Rust is my last haven, let it remain rust only!!

If you had told me in the 90s when Microsoft was king that someday "proprietary" would be used to describe a completely open-source, documented, published technology that its creator encourages others to adopt, I would have laughed and said it's impossible.

> NaCl is weak at handling dynamically generated code

They got it working for x86 (http://static.googleusercontent.com/external_content/untrust...) and it's currently just not prioritized for PNaCl AFAIK.

> PNaCl from what I recall relies on LLVM which is yet to demonstrate low latency code generation performance

Sounds like the kind of problem that can be addressed once other much bigger problems are solved. It's not like any such problem would be fundamental or insurmountable.

> in contrast to older more mature code generators such as TAOS, LuaJit.

I don't know about TAOS but LuaJIT 2.0 (with it's completely rewritten code generator) is only 5 years old compared to LLVM's 12 years. Even LuaJIT 1 is only 7-8 years old.

To give a recent example, what if you'd like to start serving Opus audio to all your users? The standard response to that idea now is "that's funny, Internet Explorer will never even support Vorbis, and that's over a decade old." If safe native code execution was a standard part of the browser right now, it would be trivial to distribute an Opus decoder alongside the "web app" you implemented in Javascript. Opus would just be your competitive advantage, not something you need to beg people to implement. It would already be ubiquitous.

Before anyone mentions X implementation of Y audio codec in Javascript in an attempt to discredit the value of native code execution, just stop. I highly doubt it will work acceptably on my mom's computer (the average computer that accesses your site is almost surely a hell of a lot less powerful than you may assume it is), and I highly doubt you'll ever be able to rival the performance of native code for processing on the order of video codecs anyways. Not to mention the fact that the majority of the nontrivial Javascript audio demos you've heard were made possible in no small part due to standardized, native code linear filtering and convolution.

"Frustration" would be the word that sums up the whole "web app" movement to me. When I see that someone's made a client-side GIF animating "web app," all I can think about is how it would have taken two seconds to hook an existing highly performant C GIF encoder up to some Javascript, and instead we had to wait for someone who knows Javascript to hack a painfully slow (and therefore useless for the vast majority of users) alternative together. You know how ubiquitous similar server-side services are? That's because all it takes to make one is a simple Javascript/HTML form (or HTTP, if you want to get trivial)-based interface to an existing C program. Just think of where client side web apps could be right now if the same were true for them.

So make a toolchain that runs in the browser. There's nothing stopping you from building NEXE modules at runtime; you could compile LLVM itself for NaCl and embed the whole toolchain in the browser and compile at runtime.

  - Then they said it didn't have an ecosystem of frameworks like OSX or .NET

Bakground paragraph: I've been thinking about the issue since 2004 or so and always assumed that a widget toolkit would develop like it did for desktop environemnts and one or two would eventually win. The launch of mobile app development changed things. The kinds of apps being delivered were outright better than what equivalent web apps were delivering. Not the perf, I assume perf is going to be solved by better hardware and engine improvements, but what the apps accomplish. My conclusion is that every project has a semi-fixed budget of resources and that web developers burn roughly 50% of that budget on building a custom one-off interface solution for every project they work on. The obvious answer is components but component frameworks had not been catching on so the question is why.

The normally cited problem is the composition problem. It's incredibly difficult to achieve component isolation in the DOM and the Web Components effort is attempting to address. I approve the effort but I do not believe it will solve the problem. It's possible(ref yui3) to write components that will cleanly drop into pages that keep their CSS tweaks class based and that restriction isn't unreasonable in an app. Component use happens more frequently in apps but is not the default like it needs to be to escape the one-off tar pit. The issue is social.

The web's roots in documents mean that pretty much everybody wants a custom UI. All existing component libraries, following desktop toolit precedents, come as a packaged markup/CSS/behavior combo. These two requirements are opposed and that opposition is the core problem. I have never used a component library and not had to customize a signfiicant number of components. When doing so, I either have to maintain a private fork of the component or suffer in download/perf as the framework is super heavy and caters to all possibilities. The yui3 (and looks like current dojo) approach of core+plugin composition with auto dependency resolution is the best solution I know of but overriding is still non-trivial. Tweaking the CSS usually means having to build a complete theme and using generated markup is hit and miss.

My current thinking is that Web Components are a start but there needs to be a good solution for selectively overriding a part of the markup and for overriding style. CSS preprocessor features are also required to achieve styling goals efficiently. The rise of Bootstrap might prove me wrong by starting as an incomplete system, getting buy in (multiple themes, adoption for simple uses), and growing to a more complete one but we'll see.

It was none of those things. You two merely disagree.

>TraceMonkey shipped before v8 did.

No, that's not true. TraceMonkey shipped in June 2009 with FF 3.5. V8 shipped with the first release of Chrome in September 2008. At the time, TraceMonkey was in beta, but it's unclear which began development first.

That said, the idea that V8 sparked the JS arms race is preposterous.

Likely nothing. The presentation has a slide on compiled-to-JS languages, and a link to a listing site. Eich doesn't seem to mind languages compiled to JS so far.

Javascript was made during an era where rich web applications didn't exist and there only was a need for client side verification for form input. Why do you refuse Photoshop in evolution but allow it for JS?

The point was not about using Photoshop for design on the web, but rather its complexity. IDE's, CAD, engineering applications. Well, we don't even have to go that far. When Google Docs are going to process 500k row spreadsheets? I use Google Docs casually for quick and simple stuff, but for any serious work - probably not.

> I know many designers who have already ditched it for in-browser development

I know many people(all of them are extremely bright) who use Linux on the desktop. I use Linux too(I am not implying I am a clever bloke here). Does this mean Linux is winning the OS war? Otherwise this is just argumentum ad populum. I'll look through the slides and get back to you.

> I sense trollery here: "but you can add bindings to all of this stuff for virtually any programming language." Who said otherwise? The bogus claims against JS (going back to the "RIA" era, where IBM and Macromedia/Adobe made such arguments) already fell.

I apologize if you suspected a troll in me, but I did not imply comparison with Flash. Flash is just another competitor for you. What What I meant by "but you can add bindings to all of this stuff for virtually any programming language." is if use C/C++ or any other language with access to the OS APIs I don't depend on the wits of browser vendors shipping a particular API for me.

> And play BananaBread, for crying out loud (https://developer.mozilla.org/en-US/demos/detail/bananabread). You simply do not know what you are talking about by your next-to-last paragraph.

Believe me or not, but this is exactly the game I was referring to. The link was on the HN last week or so. To be more specific, my graphics card is AMD Radeon HD 6970, capable of running Crysis 2, and I was experiencing lags. As for the graphics, have you ever played Half-Life 2? It was released in 2004 and I can't see this game having any better graphics if not worse. Not to mention that Half-Life would have at least 3x higher FPS on my hardware. Could you please clarify on "You simply do not know what you are talking about"?

> Yes, typed arrays were ad-hoc (so are many incremental web standards that win). Binary data (arrays and structs, which compose) as proposed in ES6 are not.

Ok, it's good to see JS is going in the right direction. And thanks for taking time to responding to my message. I am actually excited about the work you do at Mozilla on Rust, and I'd like to see a language like that to be available on the client side. But I understand that it's not going to happen anytime soon.

Just skimmed through the presentation, yes I had to be there because the slides don't tell too much. On the other hand there is no point in going to the conference where the speaker uses the work "fuck" on every other slide and concludes it with "YOU ARE ALL AWESOME". I'd prefer to attend more technical talks, without any "awesomeness". And I can't see how she made Photoshop irrelevant. I'd expect a more credible study on it.

"Hate" is the wrong word. There's nothing to hate in a well-done SFI-enforcing compiler. I admire the R&D effort. We -- bad old Mozilla, including evil-me -- are seriously considering using NaCl (not Pepper) for SFI in native code parts of Servo. No "hate" here, so do try to grow up: "You hate NaCl" is just weak, beneath you, as an analysis of motives and causes.

Let's step away from NaCl as pure tech for safer compilation of unsafe languages.

I do call Google's business strategy pushing NaCl+Pepper via games and even (till it all fell apart last November) Flash heavy-handed, and one-sided to such an extent that what's pushed can never be standardized.

What's belligerent here is for someone (haberman), who I hear works for Google, a company that has all the money and power in the world, and which makes actual "pro-NaCl propaganda" as well as pays game developers and others to use the Chrome-only tech (NaCl, not PNaCl, note well), to fire first on this thread. It wasn't me who showed "belligerence".

That first shot even tried open-washing, lamely, and it tellingly put Mozilla in the subordinate position. ''I could understand "we want to be more involved in the process."''

If you don't work for Google or hold a brief for them, ask yourself why haberman's presumption is that Mozilla, or any other browser maker, should be asking or begging to be included in a process that we were excluded from and practically speaking could never participate in without equal big bucks and market power.

The great thing about the Web is that no one owns it. Browser vendors, tool makers, and developers (whom the first two groups avidly court) have to reach consensus via standards. And I find that developers, not just pure web devs, definitely including @kripken (Emscripten's creator), @jashkenas (CoffeeScript), and others, are more creative and faster moving than many highly-paid C++-first hackers, including those perpetrating single-vendor follies such as NaCl+Pepper.

Whine at me, cry "hate" and "belligerence" while turning a blind eye to the big gun who fired first, and shoot the messenger. It doesn't matter. NaCl+Pepper have already lost to JS for portable cross-browser high-performance native code compilation.