While I’m not yet a front-end developer extraordinaire, GWT is my tool of choice for rich-client browser applications, and this means it’s been effectively deprecated.
Which, after my initial reaction (“What?! GWT rulez!11!!"), I realized, this is actually pretty damn cool. This post is my brief explanation of why.
To explain, here are the four primary reasons why I like GWT in the first place:
- I’m a static typing bigot.
- I’m addicted to Eclipse and not ashamed of it (although vi bindings FTW).
- I like GWT’s components-based approach to widgets/UI.
- I like GWT’s integrated “toolkit” approach of doing most things you’ll need (minification, spriting, i18n, browser tweaks, etc.) out of the box.
Now, if you cast each of these reasons to apply to Dart:
- Static typing? Eh, optional, but, okay, good enough. Check.
- Eclipse? With static types, JDT-level Eclipse integration should be doable; Google has an Eclipse plugin team, so hopefully they’ll have this sooner rather than later. Check.
- Components? UI components aren’t, AFAIK, Dart-/language-specific, so I assume GWT’s Dart-based successor will follow a similar approach. Check.
- Toolkit? Same thing as 3. Check.
To do this, GWT performs some browser/extension magic to force your browser to talk back and forth with a running JVM (where your code actually runs as regular Java code, so Eclipse can see/debug it), often times in a very chatty manner.
Surprisingly, this normally works quite well. However, it also means you are paying an RPC cost for every cross browser/JVM call (anytime your Java code touches the DOM and vice versa), and that can add up to a less-than-fast developer experience.
If only GWT could run your statically-typed code directly in the browser…
…which is exactly what Dart will do. Nice!
So, I’m optimistic: I see Dart as a way of getting an even better GWT.
Obviously, I’m speculating a lot since the keynote hasn’t happened yet, but, in a bit of naive projecting, I would assume the GWT users/developers within Google feel the same way I do. If you can provide a GWT-like experience, with less hacks and cruft, that sounds like a good thing to me.
That being said, a few thoughts:
Just because it’s from Google doesn’t mean the language is going to rock; see Go. I’d be really surprised if this is the case with Dart, if only because the memo suggests a non-trivial amount of people are working on the project.
That being said, scala-gwt has made some great progress, so perhaps a
scala-dartproject could be started if the syntax is less-than-ideal.
I’m really surprised the Dart VM will be for front-end servers as well; I assumed the JVM was king here and they’d stay with it. I’m unlikely to give up the JVM on the server-side, given the various libraries and APIs, all JVM-based, it uses to do its thing.
Which, while in theory the “same language on both client/server” sounded great, in practice I’ve rarely had a significant amount of code that could reused across each. Other than trivial validation, most code makes a surprising amount of assumptions based on the environment it’s in.
So, I’m looking forward to the Dart keynote. It’ll be interesting to see what it looks like, what the current progress is, and if/when real working prototypes will be available. As a GWT developer, it will also be interesting to see if any announcements are made about GWT next-gen, either in the keynote itself or by the GWT team afterwards.
Given the amount of GWT code Google itself has internally, and the amount of GWT code in other companies, I’m not worried about the GWT ecosystem dying on Oct 11th. Instead, depending on the GWT next-gen migration path/timeline, it might be a pretty happening place (well, as an introvert, I have a very loose definition of “happening”).