You\\\'re right, it seems Opera uses their own renderer called Presto. http://en.wikipedia.org/wiki/Presto_(layout_engine)

Richard\'s arguments are often limp and usually foul mouthed ;P

Just because you don\\\'t agree doesn\\\'t make my arguments \\\'limp\\\'. Condordian for all the reasons I gave is a dire, appalling attempt at BDD that should be closed down as a public code health hazard. And Antony is a static type bunny so take his comments with a grain of salt :-)

Really interesting stuff in the GQuery presentation - love the compiling phase with the elimination of unneeded library portions...
But to use it - it does mean you have to take your existing application and put it into a GWT project right?

flipping heck - this captcha is ridiculously hard. and the audio is useless!

@Antony - Interesting indeed. I love presentations with Ray Cromwell, there\\\'s always something to learn.
Here\\\'s another couple
about code generators and deferred binding
GWT Extreme!

Finally, the whole conference \\\'voices that matter\\\' is really interesting

If you want to use GQuery, it\\\'ll have to be in a GWT project and if you have stuff already in jQuery you\\\'ll need to port it. Unless you want to include the jQuery library (GWT doesn\\\'t optimize 3rd party JavaScript libraries, as far as I understand).

What I haven\\\'t got clear is how that could work when the application is made of many pages, a problem for which Ray was proposing GQuery as a solution.
GWT runs a script at page load that is not cachable. That means, for each page it\\\'ll have to be reloaded.

1. Opera based on Webkit? Please show the evidence.
2. GWT is an awesome idea. Maybe the implementation is lacking (dunno), but the idea is great. They could change it to start spitting out flash, or silverfish, or whatever is flavour of the month. Awesome!
3. Richard\\\'s Concordian argument was too limp for words. SHAME

Hi,

interesting discussion about GWT.
My only problem with it is the widgets. An entire GUI built in JavaScript with common (for Java) patterns like MVC generates just too much code and it\'s very slow. That problem must be the same (or worse) for libraries like Ext-JS.
When the requirements demand smaller size and faster code, you might want to consider the GQuery project:
http://code.google.com/events/io/sessions/ProgressivelyEnhanceAjaxApps.html

With this port of jQuery you can still work effectively with HTML/CSS layouts and rip the benefit of GWT regarding tooling and faster, smaller compiled javascript.

Interesting show! I like that you guys talk about a broad range of languages (and platforms, IDEs, ...), some of which I\\\'ll never find the time or will to keep up with.

I agree with Richard on Barcamp. The passive audience style isn\\\'t as fun as a round-table (or no-table) discussion. The software craftsmanship session at Barcamp 3 was great mainly since we got to hear from a bunch of folks.

Apologies to Mark for my horrendously under-prepared and under-attended talk in the first Barcamp! :-) (In my defence, the folks who asked for a Lisp discussion on the day didn\\\'t turn up for the slot, so we didn\\\'t get the Q&A or conversation I\\\'d hoped for. C\\\'est la vie.)

A posteriori specifications for dynamic languages seem to be the norm. Even ANSI CL was finalized long after Common Lisp was popular. Now it\\\'s interesting to watch the dust settle around Clojure, as its conventions morph into reference techniques for ported implementations like ClojureCLR and ClojureScript, and could eventually become specifications.

I\\\'d like to hear Richard\\\'s thoughts on why Clojure isn\\\'t a \\\'Java.Next\\\' candidate -- I didn\\\'t catch much explanation in the audio. It seems to me Clojure goes out of its way to interop: in using and generating Java classes, interface and types, having special builtin syntax, and being usable from Java. I hope it\\\'s not just the scary parens... :-)

Cheers!