This presentation saddened me.<p>The presentation focused on what it perceived as missing features: structs (seriously?), classes, modules, syntactic sugar, macros, etc. 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.<p>Language designers tend to incrementally add junk to languages until they are complex, unweieldy monstrosities like C++ or Java. Rarely do they fix fundamental errors in the language because that would require backward-incompatible changes. So they stick to adding lipstick to the pig. But JavaScript isn't like other languages: its fundamental errors are so glaring, and impact so negatively on the language, that the benefit of jumping to a "JavaScript 2.0" massively outweighs its incompatibility disadvantages. That's why we see languages like CoffeeScript cropping up despite all their downsides, notably debugging.<p>The class bit particularly made me sad: JavaScript has a perfectly cromulent, even elegant, object model in the form of prototypes. But a variety of syntactic sugar hacks, weird constructor stuff, and general desperation to be a class-based language have sullied what would otherwise be an elegant mechanism. The solution appears to be: move more towards classes! Thus we still have all the language hacks, and <i>two</i> generally incompatible object models to boot. Plus structs!<p>Somehow after reading this presentation, I was struck with Yoda's admonition: Eich seems to be looking to the future, never his mind on where his language <i>was</i>.
> NaCl? Not portable.<p>To dis NaCl on this basis and not even mention PNaCl is dishonest. <a href="http://www.chromium.org/nativeclient/pnacl/building-and-testing-portable-native-client" rel="nofollow">http://www.chromium.org/nativeclient/pnacl/building-and-test...</a><p>> Defined by implementation.<p>As it should be, until the implementation settles and it's clear what interfaces should be standardized. What a waste of time it would have been to standardize the pre-PNaCl work, for example. I wouldn't expect Rust (for example) to be standardized at this point either.<p>> No view source.<p>It's highly unlikely that JavaScript spit out by a code generator (this would be the competition for NaCl) is going to be at all readable. I'm guessing it will be about as readable as the portable BitCode that comprises the PNaCl image (which you could view if you really want to).<p>It's disappointing to continuously see this anti-NaCl propaganda from Mozilla. Here you have a promising and highly innovative technology that is pushing the bounds of what is possible on the web. It's being developed completely in the open with papers and code being published continuously. Mozilla's mission is "to promote openness, innovation and opportunity on the web." I just can't see what part of that mission involves campaigning against an open technology that could advance the web and help it compete with native apps.<p>I could understand if their position was "we're reserving judgment until it's portable, stable, and standardized." I could understand "we want to be more involved in the process." I could understand "we are waiting to see if it can demonstrate a compelling advantage over JavaScript." But everything I have heard indicates that they are publicly and completely opposed to ever supporting it, which will make it all the harder for them to ever change their mind on this point without losing face.<p>I grew up watching Mozilla develop from an unstable binary called "apprunner" into a full-featured open-source browser with cutting edge extension capabilities. I downloaded almost every single milestone and tried it out, craving the day when I could ditch crappy old Netscape 4 for good. I got warm fuzzies when the Mozilla Foundation was created; it felt good knowing that there would always be a way to use the web with open source software, and that there would always be an advocate for openness and freedom. I just never expected to see them fighting against open technology. It's disappointing.
The last slide was interesting:
<a href="http://brendaneich.github.com/Strange-Loop-2012/#/50" rel="nofollow">http://brendaneich.github.com/Strange-Loop-2012/#/50</a><p><pre><code> - First they said JS couldn't be useful for building 'rich internet apps'
- Then they said it couldn't be fast
- Then they said it couldn't be fixed
- Then it couldn't do multicore/GPU
- Wrong every time
- My advise: always bet on JS
</code></pre>
It turns out that JS might soon be a mature language which can be used to build real apps. That future has arrived (or at least you can see the train).<p>es6/7+hardware accelerated graphics+ continued broadband adoption and speed increases (gigabit internet) make the 'web as a platform' dream a reality. I'd love to peek at Microsoft's medium term plan to deal with this.<p>Also: I wonder how long until we see a full replacement for something like eg:3DSMAX with GUI on the client and rendering done in the 'cloud'?
Is it just me or does the proposed ES6-standard smell of heavy feature creep?<p>- we get classes _and_ modules _and_ typed objects. Yeah, those all have their merits and are all somehow different, but having them all seems to add only slightly more value while increasing the overall difficulty of the language considerably.<p>- same with macros and codegens. While they certainly are different animals, there seems to be overlap in the area they will be employed.<p>To me, there seems to be feature envy on the side of the JS crowd to try and bake every nice feature into the language. I am not convinced this is the right direction.
Aside from my personal distaste for his backing up the semantic truck and dumping it into ES6, I think it's a bit annoying -- to the point of being disrespectful -- that Brendan doesn't mention V8 in his history of JavaScript. Without V8, there is no JavaScript on the server-side (sorry, Rhino and SpiderMonkey), there is no Chakra and there is no TraceMonkey/JagerMonkey/IonMonkey: given that JavaScript had survived for a decade in its pre-V8 state of abysmal performance, it's entirely reasonable to assume that it would have slept away another decade had it not been jarred out of its slumber by V8. So it would be nice to see some respect where it's clearly due...
The fact is that adding classes to JavaScript fundamentally alters the lispyness of the language in a detrimental fashion.<p>I don't want to see JavaScript turned into Java script.
Here's a more detailed write-up on some of the ES6 features mentioned in the slides -<p><a href="https://brendaneich.com/2012/10/harmony-of-dreams-come-true/" rel="nofollow">https://brendaneich.com/2012/10/harmony-of-dreams-come-true/</a>
My jaw dropped on the byte code slides. Even though probably foolish to expect that the Javascript creator would offer non-Javascript solutions, I would guess that it would be significantly better to compile Javascript/CSS to a more efficient, stable, portable target byte code or source language (Go? Scheme? Postscript?) than to compile languages to Javascript. For example, when I played with it the Hello World ClojureScript example compiled to a Javascript file of over 100kbytes. It seems like Go and JIT'ed languages have demonstrated that extremely fast compilation of extremely efficient high level native code is possible.<p>Long-term it seems like it would be significantly better to encode these web language extensions (new CSS/Javascript syntax) as libraries instead of as API/run-time extensions so that each new version of web languages doesn't require all the run-times (Firefox, Chrome, Safari, IE) to adopt it and old run-times to phase out. The current standards/run-time process doesn't seem to be extremely well-thought out. Has anyone on these standards communities ever had to actually build or maintain a web application?
Am I the only one who really dislikes the recent trend of just posting slides without any kind of commentary at all?<p>Slides are not very helpful on their own :(
Surely the fact that NaCl is currently led by Google should not disqualify it from being a potentially valuable contribution to web apps. Most prevalent technologies started in this way, include js. And most started in a much less 'open' way than NaCl. The point surely is not where they originate but rather whether they offer enough distinctive value that they are compelling enough to be adopted more widely and hence become a key part of our ecosystem. Hence the question is, does NaCl have such a compelling value proposition? Evidently, in Brandan's eyes, and those of several of his colleagues, the answer is no. But other people can disagree and hope that the value is sufficient to eventually win over a broader market share. A good example of such a community is those with large code bases in say C, or C++ who would rather port their code than rewrite it all with all the ensuing maintenance problems. Imho NaCl does have something distinctive to offer and I wish the project well.
Kind of annoying presentation style quirk: but some slides are on a vertical stack which you can access by hitting the down arrow instead of going right. You can tell in the bottom right which directions are available from the slide you're on.
Hope they have the video out sometime! Seems to be some crossover with his keynote at Fluent: <a href="http://www.youtube.com/watch?v=Rj49rmc01Hs" rel="nofollow">http://www.youtube.com/watch?v=Rj49rmc01Hs</a> - but these slides go into a lot more depth and include some of the newer goodies coming along.
This is from the a section on custom iterators in the related blog post (<a href="https://brendaneich.com/2012/10/harmony-of-dreams-come-true/" rel="nofollow">https://brendaneich.com/2012/10/harmony-of-dreams-come-true/</a>):<p>"We require opt-in to avoid future-hostility against custom iterators for collection objects. Such objects probably do not want any kind of general property iterator default, which if left on Object.prototype, might be object-detected and prevent installation of the correct custom iterator factory."<p>I can see the sense in that but I find all the little caveats in JS are one of it's weaknesses which makes me dislike this idea. Am I wrong to think they should have just put in a default iterator but made it easy to spot it so that you could replace it with a custom iterator where appropriate?
I would expect to hear something like that not from a respected tehnologist but rather from yet another "cool kid". He could just say "JavaScript is awesome" on a single slide and that wouldn't tell much less than what the whole presentation did.<p>> First they said JS couldn't be useful for building rich internet apps<p>Who said it is? Rich - yes. Anything near to match complexity of the desktop apps - never(think Photoshop).<p>> Then they said it couldn't be fast<p>Benchmarks, maybe?<p>> Then it couldn't do multicore/GPU<p>Webworkers are nice, but you can add bindings to all of this stuff for virtually any programming language.<p>> JavaScript's parser does a more efficient job... than the JVM's bytecode verifier.<p>Figures again?<p>> No view source<p>How viewing at minified JS is going to help me? Especially in the light of what he had on his previous slide:<p>function f() {
L0:
g();
L1:
if (p)
goto L0;
o.m();
goto L1;
}<p>Good luck "view source" on what he calls "the assembly of the web".<p>Then the screenshots of 3D games that presumably use WebGL - that just doesn't cut it. Just about every game demo I tried out on my previous generation hi-end ATI graphics card had performance issues. And the level of graphics is comparable to what native games had 10 years ago. That's a joke.<p>> Typed arrays<p>Until they add records so that I can declare an array of <i>any</i> type efficiently don't even bring this up. This is an ad-hoc solution.
Every time I read an article or see a presentation like this - about JavaScript, Node.js, etc I feel like I am somehow appeared in the club of very particular interest (say, leather clothes with large openings on the back). And, despite of discussing the main subject, the members every time tend to talk about world politics, religion, and science, and how all these are affected by the size of the openings on the back. Wierd.
Need some advice here. I want to learn JavaScript -- but after reading all that, I wonder if all those changes/additions means that I should wait? Or will learning JavaScript now make little difference and all those changes/additions will make sense when enacted?
One of the slides mentions WeakMap. The issue with them is that they have weak keys, not weak values. If you're trying to keep track of weak values (say to prevent duplicate instantiations of managed objects, while still allowing them to be garbage collected, for example), WeakMap won't work.<p><a href="https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/WeakMap" rel="nofollow">https://developer.mozilla.org/en-US/docs/JavaScript/Referenc...</a><p>Is there any work to add weak values to JavaScript? There's a node module, but nothing for client-side code.<p><a href="https://github.com/TooTallNate/node-weak" rel="nofollow">https://github.com/TooTallNate/node-weak</a>
I think he missed mentioning the new lambda syntax. Hope it's still in ES6.<p>Also, my pet peeve: there is no language that needs await/defer as much as JS.<p>EDIT: Maybe it could be done with macros, which is on its way.
To those who say that creating a JavaScript 2.0 would break compatibility... couldn't you have a .js2 extension and compile a .js as a fallback. The newer browser would ignore the fallback and use the js2. Thoughts??<p>Example:
<!-- JavaScript 2.0, unsupported browsers ignore -->
<script src="main.js2" fallback="main.js"></script>
<!-- Fallback compiled to current JavaScript -->
<script src="main.js"></script>
There is also a thread about the related blog post:<p><a href="http://news.ycombinator.com/item?id=4629952" rel="nofollow">http://news.ycombinator.com/item?id=4629952</a>
With regards to the comments here:<p>I don't think pNaCl could ever happen how do you get an IR general but with enough detail to capture enough information to be able to optimize effectively and without pulling in half of llvm codegen?<p>The issue isn't a web 'bytecode' the issue is a standardized compiler bytecode.<p>Also haberman are you still working on the gazelle parser?
The Strangeloop talk seems to be quite similar to the one given at BrazilJS:<p><a href="http://www.youtube.com/watch?v=84l0BrOlJwk" rel="nofollow">http://www.youtube.com/watch?v=84l0BrOlJwk</a> (part 1)
<a href="http://www.youtube.com/watch?v=IlQTjb794as" rel="nofollow">http://www.youtube.com/watch?v=IlQTjb794as</a> (part 2)
What's the compile-to-JS language mentioned on<p><a href="http://brendaneich.github.com/Strange-Loop-2012/#/22" rel="nofollow">http://brendaneich.github.com/Strange-Loop-2012/#/22</a><p>with the lambda-in-yin/yang logo? It mentions macros, but nothing on the altjs.org front page mentions macros.
Aren't most of these language features already in the now defunct ES4 aka ActionScript 3? I'm just wondering why that language is never mentionned when it's already a glimpse in the future for Javascript (for better or worse ... who knows!)
Not working for me in Chrome, works ok in Firefox. Could really do with a very basic guide on how to use the slideshow. Simplicity is good but this is bordering on frustrating and irritating.
I thought we weren't supposed to use javascript directly anymore. that's why all the 'first intro to' tutorials for all the hostest frameworks are all in coffeescript.
Fixed that for you ;)<p><pre><code> - First they said JS was not practical for building 'rich
internet apps' because of performance issues combined with
the well known maintainability problem with JS in large
code bases.
- Then they said it wasn't currently fast
- Then they said it hadn't been fixed
- Then it doesn't do multicore/GPU
- Right every time
- My advise: always bet on JS* being behind most other
languages because it is a slow moving standards based
language created in a dictatorial fashion by a committee
and input from a few powerful entities.</code></pre>
I am sure glad that a small committee of people can use their influence to dictate the standards of the web. We get so much more progress and innovation this way and at such a higher rate of speed don't we?<p>We don't need no stinking competition in the space. The standards people have a few people in high places here and there that the management in your company will blindly listen to to keep the standards alive.<p>Long live the dictatorial monarchy of the all powerful omniscient governing body of web standards.