Brendan Eich Discusses the Future of JavaScript 164
snydeq writes "JavaScript creator Brendan Eich talks at length about the future of JavaScript, ARAX, disputes with Microsoft, and the Screaming Monkey scripting engine for IE in an interview with InfoWorld's Paul Krill. JavaScript 2, which Mozilla's Eich expects to be available in some form by the end of the year, will 'address programming in the large.' To do that, Eich hopes to improve the integrity of the language without sacrificing flexibility and making JavaScript 'painfully static in a fixed way like Java does.' Eich does not expect Firefox support for JavaScript 2 until at least Version 3.1 of the browser. As for Internet Explorer, Eich explains how Screaming Monkey will help bring JavaScript 2 to IE should Microsoft drag its heels on providing meaningful support."
Insightful (Score:4, Interesting)
I wholeheartedly agree with Brendan that we should at any cost stop JavaScript [wikipedia.org] in particulat and Ecmascript [wikipedia.org] in general from being as painful as Java [wikipedia.org] in any way possible. However what we should do is not only improving all of the ECMA-262 [ecma-international.org] derivatives but to make a systematical progress towards better flexibility and interoperability of various scripting approaches in the future. Take for example the wonderful project by Mehmet Yavuz Selim Soyturk called PJS [fulladsl.be] which is an important step in the direction to allow the Parrot [parrotcode.org] virtual machine, designed to run Perl, Tcl, Javascript, Ruby, Lua, Scheme, Befunge, Lisp, PHP, Python, Perl 6, APL, Java, .NET, et al., to run on JavaScript, so all of those languages could be used together to enhance your browsing experience on the Web. For this to be even remotely plausible the JavaScript must be as flexible and as fast as possible because it would basically mean running high-level language code compiled to the Parrot intermediate representation (PIR, or IMC), that converted to the Parrot assembly language, assembled, linked, converted to Parrot bytecode and then execuded on the Parrot virtual machine or PVM which would itself be a large JavaScript interpreted script running in a Web browser, running in the operating system... You get the picture. A logical step forward would be to include PVM in all of the major browsers to run the Parrot bytecode natively and efficiently in the browser. There are already plans to include PVM interpreter in Firefox which means it will be available as a viable target for scriping dynamic html pages for all of its derivatives like Camino, Galeon and Konqueror. Hopefully the commercial browsers would follow (the Artistic license is not anti-commercial like GPL so there should be no legal problems with the integration). I really look forward to the future of perfect interoperability when every single Web page could potentially run scripts written in literally dozens of programming languages simultaneously. One day we will experience that synergy thanks to people like Brendan Eich,Mehmet Yavuz Selim Soyturk, Larry Wall, et al. if they only agree to work together on one common solution to the big mess of Web scripts that we have today. Let's all hope they will.
synergy with html 5 (Score:5, Interesting)
IMO the changes proposed for js 2 aren't very exciting. The biggest problems with js aren't really problems with the language design, they're problems with the lack of standardization in the interface to the browser. I don't see the burning need to make js more oo, more statically typed, or more like java.
What I think really will be cool is the synergy between js and html 5. Html 5 has lots of good features for doing web apps, including audio, persistent storage, and graphics (canvas, inline svg without xhtml). Most of this is stuff you could have done before using java applets or flash, but now you'll be able to do them using a w3c standard that the vast majority of users will probably end up actually having supported in their browsers.
Re:Insightful (Score:1, Interesting)
What I wonder is does the idea of embedding the Parrot VM into Firefox mean that the Mozilla developers have re-thought their stance on the "no threads in JavaScript" issue?
To me this is still the single missing feature that makes me believe that JavaScript is still a toy language that really shouldn't be used for anything major. Without dedicating a thread to the UI, there's absolutely no way to ensure that you have a responsive UI. It also makes unit testing certain things a huge bitch. The other serious issues that are being addressed in JavaScript 2 (packaging, typing, etc) are all basically annoyances compared to this issue.
Re:screaming monkey? (Score:4, Interesting)
I want embedded javascript (Score:4, Interesting)
Bright future (Score:4, Interesting)
Here's an overview of ECMAScript 4, the new version of JavaScript:
http://www.ecmascript.org/es4/spec/overview.pdf [ecmascript.org]
It sure looks to me like they are taking all the coolest stuff from Python and grafting it onto JavaScript.[1] The result will be a language a lot like Python, but with code blocks wrapped in curly braces and no significant whitespace.
One of the biggest changes will be a class inheritance model much more like Python's. The prototype-based inheritance will still be available, but I for one will be happy to use the new model.
Already, my favorite features from Python have been grafted on to JavaScript, and are available right now in Firefox 2:
http://developer.mozilla.org/en/docs/New_in_JavaScript_1.7 [mozilla.org]
Steve Yegge [blogspot.com] has said that he thinks he knows what the "Next Big Language" [blogspot.com] will be. I think he is talking about JavaScript, and I think he may be right.
steveha
[1] If you are a fan of some other language, it may look to you like they are grabbing cool things from your language. And far be it from me to argue about which language a feature was "really" borrowed from. Python borrowed much of its cool features from other languages anyway.
Google Web Toolkit? (Score:5, Interesting)
I can't believe nobody brought up GWT (http://code.google.com/webtoolkit/) yet.
GWT is a system put out by Google whereby you write your code in a subset of Java and then it compiles the Java down to cross-browser compatible speed and size optimized Javascript.
The implementation of Java is pretty good and includes just about everything you would expect except for threads. It's absolutely effortless to program in compared to hand coded Javascript -- especially for large projects.
The other benefit is "hosted mode" whereby you run your webapp in a special runtime that lets one use Eclipse's modern interactive debugger to fix bugs in the Java code that gets turned into equivalent Javascript.
If you want to see a neat demo of what can be done with GWT check out :
http://www.gpokr.com/ [gpokr.com]
Re:Here's what Javascript 2 looks like (Score:5, Interesting)
I really like the type-safety features
Fortunately, the type safety features will be optional.
and the MUCH better way to do OO.
This is a matter of opinion, and is definitely contested.
Q: "If you could do Java over again, what would you change?"
A: "I'd leave out classes" - James Gosling
Re:Ow. (Score:4, Interesting)
I've heard it said that the JavaScript code output by GWT often gives better performance than hand-coded JavaScript, because the GWT compiler is free to use every dirty syntactic trick in the book to wring the most performance out of the code. By comparison, hand-coded JavaScript has to be read and maintained by humans. Almost everyone sacrifices a little bit of performance for the sake of being able to maintain the code. But since you don't ever maintain the JavaScript part of the GWT application -- you write in Java, maintain the Java code, and treat the JavaScript pretty much as bytecode -- there's no need to worry about whether the JavaScript is written in the "cleanest" way possible. It's OK for GWT to generate code that favors performance over any other criteria.
Re:I want embedded javascript (Score:3, Interesting)
Re:I want embedded javascript (Score:4, Interesting)
I've not had a lot of experience with JavaScript, but the whole concept of writing a large application in a prototype-based language seems daunting to me. Probably because I always start with an object diagram, translate that to a class diagram, and then write the classes. What sort of code diagram would you use to describe the high-level object interactions in a javascript app? How does the source code get broken up? (I tend to use 1 file per class).
Re:synergy with html 5 (Score:4, Interesting)
It may not by a w3c standard, but I'd rather use Flash. The vast majority of end users already have it downloaded, and it really is uniform across browsers/OSes, unlike w3c standards. At least I don't need 5 browsers and 2 boxes to test all the significant combinations.
Also, thanks to Adobe (probably the only think worth thanking them for) protecting the Flash name, Microsoft cannot do the embrace/extend/extinguish path on the name. HTML, JS, CSS, Microsoft was able to invent alternates for all these w3c standards. Even Java with J++. Not so with Flash.
So I guess my point is, I'm willing to bet on greater market penetration of Flash, then of w3c compliant browsers.
ECMAScript 3.1 (Score:3, Interesting)
Re:I want embedded javascript (Score:3, Interesting)
Hmm, this sounds like an advertisement -- they're not paying me, I swear! I am just a very satisfied user (been using Qt for more than 5 years).
The Point: OO != Classes & imp. inheritance (Score:5, Interesting)
Not the same as saying that he didn't want java to be OO.
Oh, no, that's not the point at all. The point is this:
OO != Classes
And in fact that Classes may not be the ideal way to orient a program around objects. And the bonus point is that the person who implemented what's the arguable current king of OO languages understands this. He's not the only one. The Drupal Devs also have a thing or two to say on the subject [drupal.org].
I'm very familiar with the Allen Holub article you referenced -- stumbled across it three or four years ago, and it eventually led me to buy Holub's book on patterns [holub.com]. The takeaway point about the hazards of implementation inheritance is one that I think he overstates, but it's absolutely necessary given the way most people learn OO programing these days. Most books and tutorials hammer on extends and necessarily use examples of class hierarchies because it's necessary to teach what all the OO syntax does, but this really isn't what OO programming is about.
The interesting thing is that Javascript is one of the few popular languages where this is quite clear. There are weak clases, there is no "extends", and therefore very little magic implementation inheritance. You can code up syntax for this, if you like, as many of the major libraries do, which I think illustrates the power of the model and the language, but by and large, the prototype inheritance method means that you're doing interface inheritance or very explicit implementation sharing. This means the pitfalls Holub points out are easier to avoid, and there's many other bonuses. It also unfortunately means a bit extra work in some cases where implementation inheritance is handy and less dangerous, but it's not all that much, and I think the tradeoff is worth it.
Now, the next version of Javascript will particularly be nice for developers of libraries who have reasons not to trust the developers using what they're producing, because they'll be able to freeze things they can't freeze now with the static typing and class definitions.
But I'm pretty afraid a prevalent culture that seems to have a fairly narrowly scoped idea of object orientation and "best practices" is going to clap their hands and grab onto the familiar classes as they approach Javascript, rather than really understand the breadth of the language, and in 3-4 years, you'll have newly-minted team leads fresh from their recent readings of Fowler and GoF talking about tortured design patterns using static types and classes when a little sprinkling of dynamic language will do the job.
Please, allay my fears by not saying "JS2 finally bring real OO programming to Javascript."
Re:The Point: OO != Classes & imp. inheritance (Score:4, Interesting)
In the end javascript is the classical example of a 95% academic language. Looks nice on paper, it is very fast in designing small systems, it is very flexible which makes the academic crowd cheer but fails utterly once you have to design bigger systems because the productivity of the language goes down the toilet due to the fact that vital 5% of the language are missing.
Re:Javascripts popularity is no real suprise (Score:3, Interesting)
You make be taking this claim that JavaScript is a LISP language a little too far. A couple fundamental things that are missing are macros, tail recursion ... Lastly, and perhaps most importantly, this is not how JavaScript is widely being taught and used.
Re:Javascripts popularity is no real suprise (Score:3, Interesting)
It's not a claim:
JavaScript Programming Language: The language everyone loves to hate [sun.com]
Javascript and LISP [tech.coop]
Douglas Crockford's page on Javascript [crockford.com]
As far as your last point regarding how Javascript is being widely taught and used, all it states is a major problem with the way the language is understood. Just because a language is taught a certain way doesn't mean that the language IS that way. If you delve deeper into Javascript you'll see that it's more like lisp and less like C or Java.