Slashdot Mirror
Brendan Eich Discusses the Future of JavaScript
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."
is here.
We can't expect support for Javascript 2 in Firefox until the next version? But I want it to magically appear in the current one!
The only thing is... I'm worried about how much damage its replacement will cause.
Modding Trolls +1 inciteful since 1999
"[...] use JavaScript as kind of an underlying assembly language [...]"
VBScript sucks balls and Javascript is capable of getting the job done.
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
I wholeheartedly agree with Brendan that we should at any cost stop JavaScript in particulat and Ecmascript in general from being as painful as Java in any way possible. However what we should do is not only improving all of the ECMA-262 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 which is an important step in the direction to allow the Parrot 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.
Karma: Positive (probably because of superiour intellect)
But really I think it shows the understanding Eich has for the thousands of codemonkeys hammering away at JS for IE. I'd be screaming too if I was coding JS for IE.
On the other hand, I've had the (dis)pleasure of a rollicking night of Victory Golden Monkey followed by a visit from the Beer Monkey. Waiting for MS to make IE support JS2 might cause an additional night or two like that.
FWIW, the Beer Monkey usually howls, rather than screams. YMMV... depending on the quantity of Golden Monkeys consumed.
"Trolls they were, but filled with the evil will of their master: a fell race..." -- J.R.R. Tolkien on Olog-hai
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.
Find free books.
This site has an example of Javascript 2, and a translator from Javascript 2 to the current version. I really like the type-safety features and the MUCH better way to do OO.
In response to the parent, in the article they talk about how Microsoft is fixated on 3.1 and not 4. Hence, there is "Project Screaming Monkey" which aims to create a scripting engine for IE that can run Javascript 2 and not depend on Microsoft to support Javascript 2. Then, IE can support Javascript 2 (through the Flash Player - full details in the article). I wonder if it is possible to do something similar for Firefox. Perhaps via a plugin? But I suspect performance would suffer greatly. Or maybe 4->3.1 translator like at ecmascript4.com that would do an "on-the-fly" translation.
Vivin Suresh Paliath
http://vivin.net
I like
Eich says: "Some of these techniques, like HotRuby, actually translate Ruby into JavaScript."
HotRuby implements, in JavaScript, a VM that executes Ruby 1.9 bytecode; it does not translate Ruby into JavaScript.
That's kind of misleading: What he actually says (from TFA) is "They won't be in Firefox 3. They won't be in probably the 3.1 that we've talked about doing, but they might be in our [nightly] builds, our trunk builds. It'll be like a draft version of the spec, so we might call it JavaScript 1.9 or 1.99. We don't want to get people to confuse it with what becomes the final spec, but we have to be able to test it with real programmers and get usability feedback."
I really like javascript as a language, independant of webapps. When I recently wanted to embed a scripting language in a C++ program I work on, I seriously considered javascript, as I thought more people would know it than lua and python. There does not however seem to be an easy way to embed javascript in an arbitrary program. Is there some reason it isn't suitable for this kind of thing, or is it just the browser writers embed the javascript too deeply?
Combination - fun iPhone puzzling
Here's an overview of ECMAScript 4, the new version of JavaScript:
http://www.ecmascript.org/es4/spec/overview.pdf
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
Steve Yegge has said that he thinks he knows what the "Next Big Language" 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.
lf(1): it's like ls(1) but sorts filenames by extension, tersely
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/
If JS was fast enough to encrypt in RSA with a a decent key length, you could use it for secure password authorization without the need for SSL. The server sends a public key, the browser uses it to encrypt the password in an onSubmit(). That would be great. The max I was able to do was RSA-16 (or something ridculously low) on a Pentium III when I tried a few years ago. Any more than that and a "stop script?" dialog popped up. You can't use a one-time pad because you have no secure way to send it to the browser.
I don't mind Javascript 2, that's all well and good but stock Javascript needs to be standardized across the board. It's good that IE8 is finally going to be standards compliant for rendering but they all really need to sit down and figure out how to standardize JS. The irony on this one is that MS came out with some really good extra JS features back in the day so you have these features that the IE team pioneered but then it was added as a stock feature but differently. Libraries like Prototype.js and Mootools are nice but I still want a standard JS setup.
Not to be pedantic, but this isn't strictly true. It's very difficult to even write an iterative solution in, say, Prolog, and you'd probably have to abuse a database to do it, and it almost certainly wouldn't be faster. By contrast, tail-recursive calls tend to be optimized in many implementations so you hit speeds on the order of many iterative constructs in interpreted environments.
And at the bottom of this issue is the fact that it's an implementation issue, not a language issue. There's no reason for certain recursive expressions not to be as fast as certain iterative ones.... except the compiler or interpreter doesn't output them that way.
Tweet, tweet.
Isn't that more or less what they always say when they come up with some new-fangled language?
Are you adequate?
Eich talked about some reasons for the 3.1 update to the language. Based on what I've heard from both Doug Crockford and Chris Wilson is that it would be a good idea to fix some of the really big issues in the current version of the language before throwing a new OO model and type system on top of it. It's best to build on a good foundation. There are also concerns about making the engine slower, but I'm waiting to see benchmarks before making my judgement. Personally I like the programming model of JavaScript as it is, but I'm a minimalist when it comes to code.
... I think that Brendan really pays attention. I've submitted a lot of "policy" bugs (i.e. use threads, bittorrent for the win!) to Mozilla, and he's got strong, and well supported, opinions. I've a lot of respect for him, and he tirelessly puts up with a lot of munchkins (like me) submitting technologically misfit opinions.
Also, non-leading whitespace is not significant in Python.
"Not an actor, but he plays one on TV."
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.
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. 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."
Tweet, tweet.
The ability to communicate via the electronic signals and display results on computerized devices is not Mozilla's or Microsoft's achievement. It is the humanity's achievement.
The international conferences are to be held organized by UN on this subject. We should not allow browsers or other programmes in our countries which are the result of petty squabbles between small groups of marketeers and programmers.
Buggy incompatible browsers should be banned by UN internationally as illegal drugs. Enough is enough. I do not want to see any more these ridiculous "if IE6", "if Mozzilla", etc. There should be the basic standards implemented by the international law, which would provide a safe and effective usage of Internet.
P.S. It's worth noting that trailing whitespace in Javascript may be significant. In particular, under some circumstances, a trailing end-of-line will be treated as if it were a semi-colon...
"Not an actor, but he plays one on TV."
Are you sure you know the difference between the language and the proprietarty APIs the browsers expose to it?
sudo ergo sum
On all points...
1) Generated Javascript from the GWT compiler is on average much faster than hand written JavaScript. Unless you want to make your JavaScript source unmaintainable, compiled code is always faster.
2) Layout is standard in GWT. Meaning, if you use one layout GWT ensures it looks the same in every browser. This is huge for productivity.
3) Hash file names are brilliant. If you understand how HTTP caching works you'll realize this is an automatic versioning system.
4) GWT does not compile in it's libraries each time. In fact, the compiler does excellent dead code elimination with incredible detail. It only includes the code you use. It also is able to optimize the code for size and speed throughout your app, the framework, and any other modules you use. Try doing this with other bloated javascript libraries (which the frameworks themselves are substantially larger than a GWT app). On top of all this when the browser downloads the app it only downloads code for that browser (no IE specific code if you're using FF), which further reduces size. GWT apps are small.
I find it hard to believe that this poster did a decent evaluation because everything is very off base. It sounds like a developer who's invested time in one technology (JavaScript) and has a resistance to another, which is actually perfectly cool. Why learn new technology when you're already good in another. I think GWT is a hard sell to a JavaScript programmer because it basically says "JavaScript sucks" and that can be kinda personal. But just for the record, this guy is wrong on all counts.
It's not about the speed of recursion, its about the inevitable memory footprint issue. A loop, while seldom as elegant, doesn't carry the memory overhead of a recursive function which must reach its boundary condition before beginning it's calculations.
Using a language like LISP or Scheme, you learn to love recursion for its elegance. But when you start trying to apply that love to real world problems you run into significant memory issues, along with a lot of flack from fellow programmers who don't appreciate being forced to read dense recursive code.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
You know, Microsoft's street address also says a lot about their mentality.
That's a good point. I wrote some functions in Haskell to detect irregularities in large text files. I wrote with tail-recursion optimization in mind and got good space and time performance compiling with GHC, which is a *very* smart (and big and slow) compiler. That said, recursion is the natural idiom for a language built around recursively defined data types, which JavaScript isn't.
It's obviously an internal pot shot at the screaming monkey Steve Balmer.
that you read up on tail recursion and the so-called Tail Call Optimization..
Calling php as the classical example of namespaces are not helping in designing big systems is like a joke.
That'd be a great point if that where what I'm doing, but it's not. I'm pointing to PHP as an example of a language that's thoroughly handicapped -- there is no natural mechanism for namespaces -- but has developers and projects who've almost entirely skirted the issue by using certain conventions.
The moral of the story isn't that PHP is Teh Awesome (it has many, many ugly warts, and even with the increased efforts at seeding a smarter development culture, many PHP devs and projects are still messes). The moral of the story is that with a good convention and initiated developers, many perceived handicaps rooted in missing mechanisms are mitigated or eliminated.
the newer efforts towards standardizing next versions of javascript try to tackle it.
Have these additional tools available may indeed turn out to be helpful for certain situations, but it's really a pretty good thing they haven't existed before now, otherwise, it's fairly likely there'd be even fewer people who understand the alternative philosophy, mechanisms, and convention that already exists. And if the new features dilute a culture where people understand these things, it may not be a net win.
Btw. as for rails, it works because the basic structures are outlined by the codegens rails has, the programmer is basically pushed on rails :-) Which means rails enforces certain structures to bypass certain limitations of the underlying language!
I don't really use Rails or Ruby a ton, but this seems wrong to me. The conventions of Rails have nothing to do with any "limitations" of Ruby. They're abstractions for dealing with certain sets of recurring problems, specifically in one type of broad modeling useful for web apps. Like any abstraction, there are real limits to the breadth of situations it's designed for, but the basic ones behind Rails are quite flexible if you understand Ruby and have more than passing familiarity with Rails. Rails is a case not of convention substituting for missing mechanisms, but convention enhancing and enhanced with mechanisms of a broadly powerful dynamic language.
Tweet, tweet.
There is no memory overhead for tail-recursive calls - they are precisely equivalent to a loop.
I find it interesting that there's worry about whether Microsoft will implement JavaScript 2, when they've already done a large chunk of the enhancements in anticipation of the new standard. They call it JScript 8.0 and it runs on the CLR (.NET).
"Not an actor, but he plays one on TV."
Not to be pedantic, but this isn't strictly true.
Shhh, this is where the "almost" part kicks in.