Slashdot Log In
Brendan Eich Discusses the Future of JavaScript
Posted by
ScuttleMonkey
on Mon Jun 23, 2008 05:49 PM
from the everyone-should-know-a-little-javascript dept.
from the everyone-should-know-a-little-javascript dept.
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."
Related Stories
[+]
Move Over AJAX, Make Room for ARAX 409 comments
sasserstyl writes "eWeek reports that Microsoft's Silverlight platform will support Ruby client-side scripting, enabling ARAX — or Asynchronous Ruby and XML. Would be cool to have the option to script client-side in something other than Javascript. 'In essence, using ARAX, Ruby developers would not have to go through the machinations of using something like the RJS (Ruby JavaScript) utility, where they write Ruby code and RJS generates JavaScript code to run on the client, Lam said. "Sure, you could do it that way, but then at some point you might have to add some JavaScript code that adds some custom functionality on the client yourself," he said. "So there's always that sense of, 'Now I'm in another world. And wouldn't it be nice if I have this utility class I wrote in Ruby...' Today if I want to use it in the browser I have to port it to JavaScript. Now I can just run it in the browser."'"
[+]
Developers: Was Standardizing On JavaScript a Mistake? 525 comments
snydeq writes "Fatal Exception's Neil McAllister questions the wisdom of standardizing on a single language in the wake of the ECMA Committee's decision to abandon ECMAScript 4 in favor of the much less ambitious ECMAScript 3.1, stunting the future of JavaScript. Had the work continued, McAllister argues, it could have ushered in an era of large-scale application development that would ensure the browser's ability to meet our evolving needs in the years ahead. 'The more I hear about the ongoing efforts to revise the leading Web standards, the less convinced I am that we're approaching Web-based applications the right way,' McAllister writes. 'If anything, the more we talk about building large-scale Web applications, the more we should recognize that a single style of programming will never suit every job.' McAllister's simple truth: JavaScript will never be good for everything — especially as the Web continues to evolve beyond its original vision. His solution? 'Rather than shoehorning more and more functionality into the browser itself, maybe it's time we separated the UI from the underlying client-side logic. Let the browser handle the View. Let the Controller exist somewhere else, independent of the presentation layer.'"
[+]
IT: Brendan Eich Explains ECMAScript 3.1 To Developers 94 comments
VonGuard writes "On April 9, ECMA International produced the final draft for the first major update to JavaScript since 1999. It's called ECMAScript 3.1, but will soon be known as ECMAScript, Fifth Edition. You'll know it as JavaScript, the Next Generation. Mozilla will begin implementing these features after Firefox 3.5, and Microsoft is already showing prototypes behind closed doors. The question, however, is what this will change for JavaScript coders. To get those answers, I tracked down Brendan Eich, Mozilla's CTO and the creator of JavaScript. I transcribed the interview without any editorial since he explains, perfectly, what's changing for programmers. Long story short: Json will be safer, getters and setters will be standard, and strict mode will make things easier to debug."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
1-page version (Score:5, Informative)
Really? (Score:4, Insightful)
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!
Re: (Score:2)
Re: (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.
Parent
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
Parent
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]
Parent
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."
Parent
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.
Parent
Re:The Point: OO != Classes & imp. inheritance (Score:5, Insightful)
instead exposing the virtual method table directly. (Prototype is nothing else)
Not precisely, since the prototype property also exposes properties, as well as methods. Or, more precisely, methods are properties in javascript, since functions are first-class.
You cannot really design big systems without those two constructs
Not at all true. Well, it's tautologically true. You can't design big systems the way that most programmers who currently work on big systems design them in statically-typed explicitly class-based languages. And by some accounts, this turns out to be a huge advantage, because you get a LoC compression similar to what you'd see with Ruby.
(As for namespaces -- PHP has the same problem, but worse, given that you can't even appropriate static ad-hoc classes as a namespace mechanism. And yet the namespace problem has been more or less practically addressed by conventions, and you can't argue anymore that people aren't building large systems in it.)
different incompatible inheritance constructs by third party libraries
It's true composing "extends" implementation inheritance implementations across libraries is likely to get you in trouble. But then again, simply using implementation inheritance can get you in trouble, in C++, in Java. And having to settle on conventions and libraries is not a fatal hit to a project.
In the end javascript is the classical example of a 95% academic language.
Acadmic? Why? Because it's functional, or didn't start life with "extends"?
Javascript's shown itself as quite practical contender in a huge amount of the heavy lifting that's gone on in the RIA space over the last 5 years, and that's not half what's going to happen as it gets traction elsewhere [blogspot.com].
Parent
Re: (Score:3, Insightful)
Re: (Score:3, Funny)
Ow. (Score:4, Funny)
"[...] use JavaScript as kind of an underlying assembly language [...]"
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.
Parent
Javascripts popularity is no real suprise (Score:3, Insightful)
Re:Javascripts popularity is no real suprise (Score:5, Insightful)
Javascript has the potential to be really useful. Well, it already is. I was at JavaONE earlier this year and I went to a few Javascript sessions. One of the most eye-opening sessions was the one where the presenter described Javascript as a LISP-1 language that just happens to look like C.
As far as improvement, I think it needs a proper object oriented model (the current one is far too confusing), and also should be friendlier to implementations that require recursion. You can write recursive code in Javascript now, but it's very slow. Iterative solutions are faster.
Parent
Re: (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 c
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.
Parent
Re: (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: (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.
Re: (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 hav
Re: (Score:3, Insightful)
Re: (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 befor
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.
Parent
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.
Re: (Score:3, Funny)
Or use line breaks.
Re: (Score:3, Insightful)
Re: (Score:2)
screaming monkey? (Score:4, Funny)
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 [urbandictionary.com]. 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.
Re:screaming monkey? (Score:4, Interesting)
Parent
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: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.
Parent
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.
Parent
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."
I want embedded javascript (Score:4, Interesting)
Re: (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).
Parent
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.
Parent
Re: (Score:3, 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: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.) :-)
Parent
Re:Google Web Toolkit? (Score:4, Insightful)
No, that was the long of it.
This is the short:
Now for the medium:
Parent
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.
Parent
ECMAScript 3.1 (Score:3, Interesting)
Re: (Score:2)
Re: (Score:3, Insightful)
Are you sure you know the difference between the language and the proprietarty APIs the browsers expose to it?
Re: (Score:3, Informative)