Saturday, May 20th, 2006

Google Web Toolkit: The correct level of abstraction?

Category: Editorial, Google

There has been a lot of buzz around Googles new Google Web Toolkit, an Ajax framework that allows Java developers to stay in Java land and ignore JavaScript.

Ironically, a day earlier I was shown XML11 (not a lot of XML) which is a similar toolkit. Both have the ability to take Java code and codegen JavaScript for you, including porting various Java libraries (e.g. some of java.util).

There are problems that I see with these approaches:

  • Debugging: Remember working with C/C++ compilers back in the day? Before we trusted them? I can’t imagine how scary it will be to have a JavaScript error show up in a browser talking about line 2123 which has “a[b] = push(c)” in it. Er. Riiiight.
  • JavaScript isn’t evil: I can understand wanting to stay in your own language. Rails does a good job of this with its abstractions such as RJS. However, I am not scared of JavaScript certainly compared to Java. Ironically with Phonos you could write the client side with GWT and the server-side with JavaScript!
  • Holy JS size batman: GWT claims that there isn’t a huge amount of JS generated. When I looked at one of the simple examples and finally found the JS code that gwt.js automatically downloads I found quite a bit of code. All of it total gobble-di-gook of course (a feature). For anything non-trivial you could see this code getting pretty huge.
  • Abstract higher: One of the lessons learned from MDA was to generate on a higher level of abstraction. Writing assembler code to be run in the JavaScript interpreter seems to be the wrong level of abstraction. Instead, codegen on top of a high level library such as Dojo or Prototype. Rails made a good choice in this manner. As a developer you can even look at the code generated and understand it (and hence tweak it and write your own code gens). When you see the low level assembler speak you get scared from ever looking at it. In the future browsers will be able to have strong namespaces and packages allowing us to share version X of library Y. This library could be JIT’d and hence the JavaScript that you send down is small running on a fast immediate runtime.
  • It isn’t JavaScript, it is browser diffs: Developers are not scared of JavaScript per se. The issue that we have is with cross browser inconsistencies. This problem goes away if we put effort into the toolkits (Dojo, Proto, …) and write on top of those layers.
  • What about the cool stuff?: So you have access to Java APIs. Kinda. You can’t use ANY old Java class. XML11 allows you in theory to keep recursively compiling your code, but what if you get to native code? A lot of Java code won’t make sense in the browser context. At the end of the day you feel good as you are in Java code land, but you are crippled. We have seen that libraries such as script.aculo.us allow us to do fantastic effects in our browser applications. Try to do those effects in Swing and you will be scared off. There is no one-line Effect.* library that is for sure. If you dismiss JavaScript you ignore all of the great features, components and libraries available.

I see how these toolkits hit a sweet spot for some developers and teams, but I would like to think that only a small group would fit the bill. What do you think?

Posted by Dion Almaer at 8:12 am
40 Comments

+++--
3.7 rating from 134 votes

40 Comments »

Comments feed TrackBack URI

Answering to your debugging complaint: since you are programming in Java, you can obviously debug in Java. Only when your code runs without problems you then generate the JavaScript and deploy. If you still find a bug, you can always go back to your Java version of the code and debug it again.

Regards,

Luis.

Comment by Luis — May 20, 2006

[…] Google Web Toolkit: The correct level of abstraction?There has been a lot of buzz around Googles new Google Web Toolkit, an Ajax framework that allows Java developers to stay in Java land and ignore JavaScript. Ironically, a day earlier I was shown XML11 (not a lot of XML) which is a … […]

Pingback by Google Web Toolkit: The correct level of abstraction?There has been -- Centplus Tech Blog — May 20, 2006

[…] There’s a a great writeup on Ajaxian discussing the major drawbacks to using a framework like GWT to abstract away the JavaScript in AJAX. Interesting stuff. […]

Pingback by Neil Mix » Blog Archive » More on GWT-ish Frameworks — May 20, 2006

One line script.aculo.us Effect.* library is there. 3 days after toolkit release.

http://groups.google.com/group/Google-Web-Toolkit?hl=en

Regards,
Alexei

Comment by Alexei — May 20, 2006

@Luis – what if you have a bug in the browser environment which it is not present in the Java environment? What then?

Comment by Dean Edwards — May 20, 2006

[…] Google Web Toolkit: The correct level of abstraction?There has been a lot of buzz around Googles new Google Web Toolkit, an Ajax framework that allows Java developers to stay in Java land and ignore JavaScript. Ironically, a day earlier I was shown XML11 (not a lot of XML) which is a … […]

Pingback by Instant gratification, Google Video styleIf you prefer stories of love -- Centplus Tech Blog — May 20, 2006

I have to agree with Dean.
My analogy is the difference between people who only know Dreamweaver/Frontpage/GoLive (read: not coders) versus those who can use any of these tools because they know the web.
Clearly the Java community is very experienced in coding, so the analogy might not fit 100 percent. But hands down, if you want to kick butt in JS then you need to learn JS. It’s 2006 and DW/FP/GL still muck up basic html, I’m not convinced that this is entirely different even though it’s code>code and not wysiwyg>code.
And you’re totally right, Dion. The only way to get fully optimized code is to write it that way. You don’t have to be ultra-low-level; you can use a higher-level library that is very low-level optimized. There is a reason people still write crazy-efficient desktop apps in assembler, often weighing in at only a few hundred K. It’s not for everyone, it’s not as rapid development, but boy can you kick some butt if you know your stuff.
JS is way easier than assembly language. People need to remember that there is already a performance hit with interpreted (not compiled binary) code. That code needs to be efficient. Use a well written high-level library, or write it yourself as low-level as you can get. This language-to-language talk is all corporate politics to me, makes no logical sense at all. It’s more business than engineering, for sure.

Comment by Bradley — May 20, 2006

The GWT approach is very smart when you consider what it is designed for: building applications for the Google ecosystem.

A codegen/class library approach is the best way to ensure consistency and compatibility of these apps. Google can engineer in the capabilities, UI standards, look & feel, performance characteristics, etc that are appropriate for G-applications. If you develop an app using GWT, you (and Google) can be fairly comfortable that it will be compatible with other G-applications. Think portlets.

Of course, this approach assumes that the class library is perfectly complete for your applications’ requirements. But that is the whole point – this toolkit is not intended for general web application development – it is intended for G-applications.

Interesting to compare this against Yahoo’s mashup-friendly APIs. Most Ajaxians today will probably favor Yahoo, but you can’t ignore the potential size of the G-application market. These guys are going up against Microsoft, for sure.

Comment by Jeff Dill — May 20, 2006

[…] Google Web Toolkit: The correct level of abstraction?There has been a lot of buzz around Googles new Google Web Toolkit, an Ajax framework that allows Java developers to stay in Java land and ignore JavaScript. Ironically, a day earlier I was shown XML11 (not a lot of XML) which is a … […]

Pingback by Issues with the site: operator queryIf you are checking your -- Centplus Tech Blog — May 20, 2006

To me it just seems a bit sad that Javascript is… feared. Because that’s the impression I get, that it is somehow seen as bad or dirty if you “have to get down to” developing in Javascript.

Comment by Gonzalo — May 20, 2006

I personally think that java is a better language than javascript. But I don’t prefer GWT, since it will limit your freedom of programming

Comment by raid_ox — May 20, 2006

I created a website with some gwt components http://gwt.components.googlepages.com/. Take a look. Script.aculo.us effects are there already.

Alex

Comment by Alex — May 20, 2006

Fatti non foste a viver come bruti

In one of those frequent bloggers coincidence, I was preparing to post a message on JavaScript and web toolkits, when I noticed BenÂ’s post on Ajaxian titled “Google Web Toolkit: The correct level of abstraction?”. In fact his opinion resonates quite…

Trackback by Anonymous — May 20, 2006

To me it just seems a bit sad that Javascript is… feared.

@Gonzalo: This fear mostly comes from software development managers who fear the costs of JavaScript/DHTML development, based on past experience. The Ajaxian community is just beginning to scratch the surface of what large business software vendors have been working on for the past 8 years. These companies have spent literally $100Ms on Ajax development, and they lost more than a few bets when they tried to do it in-house.

Now the tide is turning with better browsers, stronger frameworks & tooling, and community knowledge. But it is still very expensive to do significant engineering at the lower levels. And the memory of hyper-risky DHTML development projects will take time to fade. You can’t blame these guys for being gunshy…but time heals all. :)

Comment by Jeff Dill — May 20, 2006

[…] Update: just saw that the Ajaxians have been thinking about GWT as well. Great to see more thinking around who our users are and how we can best make their lives better.   if(!mmposts){var mmposts=[];} mmposts[mmposts.length]=”558″; […]

Pingback by Continuing Intermittent Incoherency » And So It Begins — May 20, 2006

I sense that Javascript is beeing “defended”…why? Ajax has risen thanx to Javascript. Let the contenders argument their way to “popularity”.

Considering the brain-power acquired by Google, I am not at all impressed of what they are producing…

Comment by Hakan Bilgin — May 20, 2006

Excellent post Dion,
I find it hilarious that one would perhaps use an even higher level language to create something that’s easier. I could only imagine someone who actually knew how to do something in JavaScript but then didn’t know how to do it in Java using the toolkit… “hmm… what’s that function called to do document.getElementById?”

None of this is to say that it’s not a sweet framework for Java Developers. But why not just use something like Prototype, Dojo, or YUI instead. They were made with these things in mind. The language is actually easier to write.

Comment by Dustin Diaz — May 20, 2006

I have to admit that the concept is pretty cool– but in the end, we can generate the same content with straight JS, using the libraries the exist today, and secondly the toolkit has a relatively primitive RPC foundation from the likes of Seam or DWR.

Comment by Jacob — May 20, 2006

How come no mention of the fact that Google did not provide full source code for their Java-to-Javascript compiler? Where do you go if it has a bug? Call Google for support? What if the compiler phones home or generates code that phones Google everytime it is run? Clearly, no one can take this Google offering seriously. And since we’re on the topic, Google is a consumer of GPL software – and profits handsomely from it – how come they do not create GPL’d software and distribute it?

Comment by Xargon Magnifico — May 21, 2006

@Jeff: I’ve been doing this sort of thing for some time. In-house (there were not a lot of toolkits back then) and on really big projects. And there was never a problem with it. And, well, it was never expensive.

As a matter of fact, for the last two years I’ve been called to at least 4 different projects where they needed an inmediate solution -delivery in less than a month- and had almost no budget -two people, three at most-. In all those cases they called me because they knew I’d been doing this stuff and it was that in all cases what made us able to deliver on time.

I was not blaming these companies. I was pointing more to things like GWT. “The benefit of developing in Java! No need to do Javascript!”. Duh. I can do both, Java, Javascript. For different purposes I’ll use different tools.

Sorry for the rant, but I really don’t like ‘language translators’.

Comment by Gonzalo — May 21, 2006

[…] Ajaxian » Google Web Toolkit: The correct level of abstraction? […]

Pingback by Deep Codes » The Correct Level of Abstraction? — May 21, 2006

I looked at the generated Javascript code. It is littered with strings refering to Java class names and method names on the server. Surely this is a security concern. The browser client should not be aware of the implementation on the server, or be given the opportunity to call arbitrary methods (or call known methods in a different order or with different inputs).

Comment by J. Johanson — May 21, 2006

I can’t see myself writing the Javascript in Java instead, but haXe looks very exciting ! I definitly have to try it when I get some free time.

Comment by Steve — May 21, 2006

I have to agree, I was originally excited, but it seems like a level of obsfucation that isnt necessary. Its not like Java and JS are that different.

Comment by Hubris Sonic — May 21, 2006

The one thing I like about the GWT approach is that it lets you write your code in an environment that at least does some basic syntax checking, giving one of the benefits of a compiled language in a JavaScript environment. Other than that though, I don’t like the approach. In my experience, just about every tool and/or library that comes along with the goal of making complex tasks simple (GWT, JSF, IBM RAD Wizards, VB, etc.) eventually reaches its limit, and springs a leak. When that happens, what do you do? In the case of something like GWT, you may be looking at several hours or days of sifting through inscrutable JavaScript code to find a problem, which is not an idea I like the sound of.

I prefer something like JSLint to check my JavaScript code at build time, and using libraries to isolate me from browser-specific stuff.

Comment by kelly — May 22, 2006

I just wanted to say that as someone who first learnt to program using Java and then moving over to web development I’ve found the transition really easy and picking up JavaScript was not a problem. All you have to remember is that everything is an object (just like java). All you need then is the DOM reference and you’re away. Any java developer should be able to make the transition without a hitch. The biggest problem is, as mentioned already, the browser inconsistencies, but that is getting better all the time. (Will ms have it right with ie7?).
Debugging is also getting easier with the appropriate plug-ins.

As for the GWT it does sound like something that will make it more complicated for the standard app but I’m sure will help if you want to integrate with Google, though I don’t have the time or inclination to try it yet.

Bottom line; learn to use the right tool (skill set) for the job.

Comment by ian — May 22, 2006

Interesting article, thanks. :]

(I came from technorati btw)

Comment by Jordan Meeter — May 22, 2006

Does Google Eat its Own Dogfood?

Google recently released the Google Web Toolkit. The basic idea behind the toolkit is that you can write AJAX applications in Java: public class Hello implements EntryPoint { public void onModuleLoad() { Button b = new Button(Click me, new ClickListener()

Trackback by Agile Ajax — May 23, 2006

FYI: JWAX team released a UI Framework for AJAX modeled after Swing/SWT originally in January, with version .4b last Tuesday. This frameworks supports runtime generation of L&F through renderkits. It is an oo component/event framework with support for aggregated components and plugable themes. You can review this toolkit at http://www.jwax.org for more information.

JWAX Team

Comment by JWAX — May 23, 2006

Honestly I only started trying out GWT lastnight so I can’t comment much on that sepcifically, but I do believe having a layer of abstraction for the browser is the future. Writing code in XML, Java, whatever that is then compiled into html/javascript is how much development will occur in web based software interfaces starting in the next couple years in my opinion. I think browser based development will soon have a similar workflow to what Adobe/Macromedia is doing wth Flex/MXML and what has been available on the desktop for decades in GUI development. I would predict Javascript be the defacto language for managing UI changes in these environments but if there is an abstraction layer for this so that interfaces can be compiled to various platforms then so be it.

Comment by Dan Roberts — May 25, 2006

Wow, I just don’t get where any of this is coming from. GWT allows me to write in Java, to share my code via JAR’s, to do ANYTHING that I could do in JavaScript while still retaining access to powerful Java tools. As AJAX apps get larger, we need something better, and I think GWT is a good start. As for “fearing” JavaScript, I don’t fear it… I just can’t find a halfway descent editor for JavaScript that has good code completion and refactoring capabilities. JavaScript was made to be simple, and this simplicity has made it difficult to build good tools. In short, with GWT I get the tool support I need to build large applications.

Comment by Robert Hanson — May 30, 2006

“I just can’t find a halfway descent editor for JavaScript that has good code completion and refactoring capabilities.”

Did you try JSEcplise?. It’s a Eclipse plug-in that brings code completion, code templates and a lot of other neat stuff to Javscript.

Comment by Hermann Klinke — May 31, 2006

Whenever you want to code a slightly above than average UI using JS, a UI that could emulate a desktop UI at the most basic level, you have to gather up a bunch (and I mean a whole bunch) of JS libraries: YUI for DnD and maybe its event model, Mochikit for DOM manipulation (it has a good event model too: which one to choose?), maybe Moo, why not a touch of Rico (nice accordeons for the last two: which one are the nicest?), Prototype for some low level operations (hurray for the $() operator). Or, if you’re not faint at heart, go the Dojo way with its vast expenses of undocumented code. You might just end up with 20 tags in the head section of your html document, wishing it all works together like a big happy family.

Oh, I was forgetting! If you’re serious about your UI, you will need to find a way to muster some OO structure in your javascript code: roughly a dozen different valid ways (and probably another dozen of no so valid ways) to force some object-orientation in a language that was meant to put a little flash in static HTML, not build complex UI. Let’s choose one technic among those. And then, let’s hope IE doesn’t leak when all these libraries are put together!

The GWT way: uniform model for UI, which UI you describe in an OO language, in a way that’s natural to any SWT or Swing programmer. It’s in its infancy (but what a beautiful babe!): we’ll see a lot of improvement coming from all over the place from talented people. Thanks Alexei for your nice work on Scriptaculous. We should try some integration with YUI.

Comment by François — June 4, 2006

[…] Ajaxian: GWT – The correct level of abstraction? [Link] […]

Pingback by webthreads.de » del.icio.us Thread #1 - GWT — June 8, 2006

[…] The GWT approach is very smart when you consider what it is designed for: building applications for the Google ecosystem.A codegen/class library approach is the best way to ensure consistency and compatibility of these apps. Google can engineer in the capabilities, UI standards, look & feel, performance characteristics, etc that are appropriate for G-applications. If you develop an app using GWT, you (and Google) can be fairly comfortable that it will be compatible with other G-applications. Think portlets.Of course, this approach assumes that the class library is perfectly complete for your applications’ requirements. But that is the whole point – this toolkit is not intended for general web application development – it is intended for G-applications.Interesting to compare this against Yahoo’s mashup-friendly APIs. Most Ajaxians today will probably favor Yahoo, but you can’t ignore the potential size of the G-application market. These guys are going up against Microsoft, for sure.Lees het hele stuk (voor meer perspectieven) hier […]

Pingback by Itude » Blog Archive » Google Web Toolkit pt II — November 1, 2006

Google have released the Google Web Toolkit — “Build AJAX apps in the Java language”. At first I thought this might just be their version of the Yahoo UI Library, but it turns out to be a completely different approach to the same problem. The YUI Library (and most other Ajax libraries) allow you to build a Web UI directly, using HTML and JavaScript. With GWT, you write a GUI application in Java, and GWT translates it into JavaScript and HTML for web deployment. It’s a less flexible approach, but could make it easier for Java developers to develop web applications with desktop-style GUIs — if this is what they really want.

Differences between Google and Yahoo in the tools they provide developers for AJAX-style interfaces…….

Comment by MalkolM — November 22, 2006

Google has just released version 1.2 of the Google Web Toolkit (GWT) with full Mac OS X support provided by WebKit. GWT allows web developers to create shiny AJAX web applications entirely in Java, which GWT compiles to JavaScript. While Mac users were able to use the GWT compiler in previous versions, they couldn’t use GWT’s hosted browser to debug their web apps. WebKit has made it possible for Google to bring these development tools to the Mac, and, as a surprise Mac-only bonus, web developers using GWT get to use the Web Inspector, too!

Comment by Scott Brison - Self help cente — December 7, 2006

Thank god someone has cared to look at the downside. All that I’d read about GWT was good and I was beginning to wonder if it has any flaws at all. Your article has definitely helped me to decide.

Comment by shruti — July 3, 2007

I am a java developer, and looking at this, I think that this is in it’s current state very cumbersome. Swing ui development is a far cry from the simplicity of web ui development, as the web browser handles many of the nasty details. I could this being useful for the generation of very small and optimized libraries, but otherwise, why create another layer of abstraction which is non-standard, not easily accessible, and causes people to have to shift to another paradigm.

I have done a lot of swing programming, some fairly complex, and I fear swing/mfc much more than web and javascript.

I think the fractured nature of the libraries and frameworks can be problematic, however, adding a whole new layer of unrelated tools is not a solution I like.

Eventually there probably will be a standardized, compiled or compilable language for web ui, but until standardized across several browsers, I wouldn’t waste my time learning it.

Comment by scott taylor — October 26, 2007

Hi,
While compiling the GWT project, we get HTML and js files. I donno How i can integrate them to my web archive. Should I have to do it manually? If so then I hv to alter the links of other pages also is it??
I am getting confused with it.
In my project we have normal JSP’s. Assume that I have only some JSP’s and not all JSP’s where i need the functionality of GWT.So How can I integrate the pages generated by GWT with the existing JSP pages?

Finally, I am very new to GWT…

Thanks in Advance…

Comment by Suresh — November 15, 2007

Leave a comment

You must be logged in to post a comment.