10 comments

[ 3.0 ms ] story [ 34.1 ms ] thread
With the new optimizations I will be twice as productive as I previously was (but still half as productive as I would be with native JS).
Compiler speed and memory usage are the focus of the next quarter for Google.
The number of permutations impose a pretty harsh limit on how much progress can ever be made in this area. This is one of the reasons why I'm very excited to hear that Dart, when compiled to javascript, will only emit one for all browsers.
You can have 1 permutation in GWT if you want, you'll have to choose either

1) dropping support for older browsers like IE6/IE8/Firefox 3.

2) using Soft Permutations (also known as capability checks in the JS work). GWT can automatically collapse permutations into capability checks. The downside is increase of JS code size.

Dart won't really solve this issue, but it more likely that it will just target modern browsers.

With GWT 2.5 and Elemental, you can drop back to HTML5 browsers only and use only 1 permutation.

That's welcome news. The only downside of improving compiler speed is that I'll have less time to peruse HN.

PS - Great job on the presentation today. Sort of felt like it devolved into a marketing pitch (with Sencha et al.), but you're a hard act to follow!

There originally more Steering Members who were going to talk about what contributions they were going to make, but some couldn't make it. So I used the extra time to let Sencha and Vaadin talk about what they do. Since they are investing heavily in GWT, hiring additional people to work on it, offering commercial support, and now contributing code to it, I thought it only fair to let them talk about their products, some of which are quite good.
I am looking forward to "Super Dev Mode" over OOPHM; got tired of reinstalling plugins per browser version.
Super Dev Mode and Elemental (appear to) take away two of my big complaints with GWT.

The biggest still remains: pounding OO Java into a functional paradigm.

One of my favorite quotes (http://matt.might.usesthis.com/):

"One should always choose the programming language that reduces the impedance mismatch between a problem and its solution."

Java for rich web = impedance mismatch. We're in a polyglot world folks.

I'm not really sure OO vs functional is the real impedance mismatch. The big impedance mismatch is the fact that the browser is fundamentally asynchronous event model driven, and so a language without lexical closures makes event oriented programming overly verbose.

But stuff browser-APIs I don't feel mismatch either OO or functional style, and some of the IDLs behind the C++ browser APIs are explicitly OO type hierarchies. There's somewhat of an impedance mismatch between WebIDL and Javascript itself if you look at the language binding source.