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."
1-page version (Score:5, Informative)
Re:Ow. (Score:2, Informative)
It means that the target language of the compiler is JavaScript. In this case, Ruby code, which the browser does not understand, is compiled to JavaScript code, which the browser can run. The association is that normally computer languages are compiled to some sort of assembly language, which is then compiled to object code.
Re:Javascripts popularity is no real suprise (Score:3, Informative)
Here's what Javascript 2 looks like (Score:5, Informative)
This site [ecmascript4.com] 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.
Re:Javascripts popularity is no real suprise (Score:2, Informative)
Which means... it's pretty much like every imperative language on the planet?
HotRuby (Score:5, Informative)
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.
JS 2 in FF3.1? (Score:4, Informative)
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."
Re:Javascripts popularity is no real suprise (Score:4, Informative)
Which means... it's pretty much like every imperative language on the planet?
The Javascript interpreter in browsers does not really optimize recursive code. Compare this to other interpreted languages [acm.org] (this paper talks about LISP, and Javascript incidentally, is a LISP-1 language), or compilers. This is why most tips for Javascript optimization talk about removing recursion because of bad performance of recursive code in Javascript.
So if you're able to optimize for recursion in Javascript 2, it wouldn't impact performance as much as it does now.
Re:Standard JS Please (Score:3, Informative)
Iterative vs Recursive is an implementation issue (Score:3, Informative)
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.
Re:Google Web Toolkit? (Score:5, Informative)
I've used GWT. Here's the long and short of it...
Pros: GWT is very cool in that you can quickly write Java-based interfaces that run in the web browser as Javascript. Because GWT includes a wide variety of components, interfaces are super-simple to create. You can even make your own widgets and reuse them as libraries to make even more complex widgets.
Cons: (Better grab a seat.) It's nearly impossible to debug code outside of the GWT test shell. Which really sucks if your code relies on a web application in some way, but you can't decipher "Error in line 127: b is null". Which brings me to the next major problem. GWT does not integrate with Javascript very well. You can use a JNI-style interface to run bits of Javascript code in a Java method, but for the most part the worlds stay far apart. Which means that you can't easily use GWT objects or Javascript objects interchangeably to solve problems. More often than not, a Javascript object would be faster than the Java code you're writing. But since you can't intertwine them...
Which brings me to the next con. Because the layout is determined by the construction of the built-in widgets, it's often difficult to achieve a layout that meets the specs. Doing simple things like removing spaces from tables, or applying pre-existing styles invariably end up more difficult to do than they should be. And even when you can apply a style, it applies the style to an element which is inside a container element (or vice-versa), thus preventing you from styling the layout of the specific element you're trying to target.
Another frustrating aspect is that GWT dumps out hashed file names. Different hashes for every compile, too. Which wreaks all kinds of havoc with source control systems. Ideally you'll want to generate the Javascript code at compile-time because of this mis-feature. Unfortunately, GWT does not ship with an ANT plugin. You can find a few that people have made, but I haven't yet found one that's of particularly high quality.
Generated GWT code is obviously quite large. Whatever you save with GWT's obfuscator is more than made up for by the fact that GWT compiles in its libraries every time.
Last but not least (and quite possibly the most frustratingly), you can only plug the components together at compile time. Mixing and matching renderers, data models, and I/O backends at runtime is pretty much a no-no. You get it right when you compile it. Period. Which really reduces the flexibility of the technology. Instead of being able to combine plugins at runtime, you have to create a new project for every variation of the component. Alternatively, you can write your code to have a half-billion runtime settings.
--
If you want my advice, learn Javascript. GWT may provide you with a good stop-gap solution, but the trade-offs can be incredibly painful at times. And since Javascript is obviously not going anywhere, you know you'll get a good return on investing in the education. If you need a good place to start, Douglas Crockford has an excellent introduction to the language here [yahoo.com]. Also, trying READING the Javascript Client Guide [sun.com]. It really does explain the language well, including some of its incredibly advanced features. (That 95% of so-called JS coders have no idea exist.) :-)
Re:I want embedded javascript (Score:4, Informative)
Many of these would probably suit you: List of ECMAScript Engines [wikipedia.org].
Some helpful documentation:
How to embed SpiderMonkey in your C/C++ program [mozilla.org] (try Rhino [mozilla.org] for Java apps).
Although in my opinion Lua is so similar to JavaScript in all the right ways, and is so easily embedded, that it might be a better choice anyway.
Re:Really? (Score:3, Informative)
Re:I want embedded javascript (Score:1, Informative)
Qt let's you do this. It comes with a Ecma-262 [trolltech.com] engine (i.e. javascript) that integrates with the rest of Qt in your code.
Re:Here's what Javascript 2 looks like (Score:5, Informative)
> "If you could do Java over again, what would you
> change?" "I'd leave out classes," he replied.
"After the laughter died down, he explained that the real problem wasn't classes per se, but rather implementation inheritance (the extends relationship). Interface inheritance (the implements relationship) is preferable. You should avoid implementation inheritance whenever possible. "
Not the same as saying that he didn't want java to be OO.
http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html [javaworld.com]
Re:synergy with html 5 (Score:4, Informative)
Javascript sure has it's problems, but at least their is FLOSS code with which to fix them. With Flash, Adobe can pull the rug out from under you any time they like, as they did with their SVG plugin.
Re:Insightful (Score:1, Informative)
You can sort of do threads in JavaScript.
Well, except you can't touch any UI, that's all single-threaded main-thread-only. That means you can never do it for web pages, because those things have a global object that's, umm, the window. As in, a UI thing. Oops.
Using threads in JS XPCOM components that never touch the DOM (which would be analogous to what a hypothetical Parrot VM would be doing; see also PyXPCOM) would work. Mostly. (The global object there is "BackstagePass")
You just have to ignore a few assertions.
Re:Javascripts popularity is no real suprise (Score:4, Informative)
That's what TFA and Javascript 2 is about: JS1 is the way it is because it was meant to be small and simple. Usage has changed and thus requirements, and JS2 is the first opportunity to fix the big things.
Re:Google Web Toolkit? (Score:4, Informative)
I use GWT for a fairly large project. It does have it's problems, but I think they're far outweighed by the gains.
Looking at your cons:
Debugging outside of hosted mode is a bit of a pain, but there are things that make it easier. There is a module you can add that gives you a debug console, allowing 'printf' style debugging. Combine that with setting the compiler to output full names, rather than compressed ones helps. That said, I find it pretty rare to need to do that. 99% of issues are taken care of in hosted mode where you have proper debugging with eclipse.
Styling of widgets appropriately comes with practice. You learn where you need to call .setStyleName/.addStyleName pretty quickly, and using things like firebug to experiment with CSS options makes it no more difficult than anything else.
Hashed filenames are used to prevent browser caching issues. The browser will cache the large hashed filename, but not the small 'loader' file (because that's how you configure your server). So when you update the application, the client will always get the latest version. On the other hand, if you haven't updated, then the client can cache the large wad of javascript, thereby reducing load times. I don't put the derived files into version control anyway...they're derived files, you shouldn't need to do that, typically.
You don't need an ANT plugin. I use: /] /] /]
[java classpathref="gwt-classpath" classname="com.google.gwt.dev.GWTCompiler" fork="true" maxmemory="1512m" failonerror="true"]
[arg value="-logLevel"/]
arg value="ERROR"/]
[!--arg value="-style"/]
[arg value="PRETTY"/]--]
[arg value="-out"
[arg value="dist/gwtbuild"
[arg value="${entrypoint}"
[/java]
(de-XMLed for slashdot)
and it works fine.
While the compiled javascript can be quite large, it's not accurate to say it includes all its libraries every time. It optimises any unused code out in order to reduce the size (I think this is why the compile process takes so damn long on a large project). If, instead, you mean that it doesn't load on demand, or separate them into files, or whatever...you (as a browser user) don't want that, it'll increase load time by causing more HTTP requests.
I do agree that there is no runtime introspection such as reflection, in order to customise behaviour, but I haven't found that to be an issue. I just wrote the application to be flexible on its own. Load a different application model to have it do different things within one runtime. But, that is the way most regular java apps work anyway, until you get in to dependency injection and similar techniques.
However, if you want to use all the handy tools that java coding gives you, and (almost) seamlessly pass complex objects between the server and the browser, there is nothing better that I'm aware of. Basically, our application manages a lot of data and presents it in various ways while allowing the user to interact with it in the browser, and GWT has been ideal for this. It's also nice that you can manipulate the output code if you really need to (e.g. part of my build.xml modifies the compiled javascript to prevent a bad interaction between firebug and the way the GWT JS does something).
There are tradeoffs involved in taking a language from one environment (JVM) to another (JS), but I really don't think it's as bad as you make out.
I can only suggest (Score:1, Informative)
that you read up on tail recursion and the so-called Tail Call Optimization. [wikipedia.org].
Re:Javascripts popularity is no real suprise (Score:3, Informative)
But I have. If you delve deeper into LISP you will see that calling a language without tail recursion and macros LISP-like is an exaggeration ...
The links you have provided concentrate on closures, and closures, while no doubt very useful, are not the one defining characteristic of LISP. The first link (the PDF) is the only one that actually contains any data to justify the claim, but it simply ends up repeating the same thing several times for stronger effect. "Functions are first class objects" - no more than in most other languages including C. "Functions can be higher order" - duh, this is implied by closures. In short, while the individual arguments are true, the whole PDF loses credibility because it doesn't objectively discuss the important differences between LISP and JavaScript. It is not sufficient to simply emphatically claim something :-)
I do agree that JavaScript has some important LISP-like traits, and that it is more powerful than many people really realize, but calling it a LISP is just exploiting the unfortunate fact that almost nobody knows LISP.
Re:Javascripts popularity is no real suprise (Score:3, Informative)
I'd say a strong case is made for Javascript's "LISPness" even without tail-recursion and macros. I get what you are trying to say, in that LISP != Javascript and that Javascript is not LISP (because it's a language in its own right). But I'd go so far as to say that Javascript has more in common with LISP-like languages than imperative ones. This is why Javascript is used wrongly quite often. In fact, when I realized Javascript was so much like LISP, everything fell into place. I've written LISP code before and once I started thinking "functionally", Javascript suddenly became more powerful.
"Functions are first class" and "Functions can be higher order" in that document are not simply there for effect. The fact that Javascript has closures is very important because you can have lambdas/anonymous functions just like lisp. For example, consider the Y-combinator in Javascript:
function Y(le) function Y(le) {
return function (f) {
return f(f);
}(function (f) {
return le(function (x) {
return f(f)(x);
});
});
}
vs. the same in Lisp:
(define Y
(lambda (le)
((lambda (f) (f f))
(lambda (f)
(le (lambda (x) ((f f) x)))))))
You couldn't do it that easily if Javascript wasn't so lisp-like :)