Lost in Translation or Why GWT Isn’t the Future of Web Development

I recently read Is GWT the future of web development? The post postulates that GWT (“Google Web Toolkit”) is the future because it introduces type safety, leverages the existing base of Java programmers and it has some widgets.

Google has recently put their considerable weight behind it, most notably with Google Wave. I’m naturally hesitant to bet against Google or Lars Rasmussen but the fact is that’s what I’m doing.

On Type Safety and Static Typing

In the 90s type-safety and static typing ruled almost unchallenged, first with C then C++ and Java (yes I realize Pascal, Algol-68 and a plethora of other languages came beforehand). Perl was the calling card of smug, bearded Unix systems administrators.

Performance and the challenges of increasing complexity with relatively low-powered hardware (certainly by today’s standards) were the impetus behind this movement. The idea that variables didn’t need to be declared or that the type could morph as required were tantamount to the sky falling.

Between Javascript, PHP, Python, Perl, Ruby and other languages over the last decade (and yes some have a history going far earlier than that) have clearly demonstrated that indeed the sky hasn’t fallen with loose and dynamic typing.

On Leveraging Java Programmers

This sounds good in theory but let me put it to you another way: if you were to write textbooks in German would you write them in German or write them in English and have a tool convert them to German?

Anyone who has studied or knows a second language knows that some things just don’t translate. The same applies to programming languages. Javascript has lots of features that Java doesn’t: first class functions, closures, extension methods, a vastly different “this” context, anonymous objects, dynamic typing and so on.

The problems you face when writing a “cross-compiler” are:

  1. The weaknesses and limitations of the end result are the combined weaknesses of both languages (or “A union B” in a maths context where A and B are the two languages);
  2. The strengths of the end result are the common strengths (“A intersect B”) of the two languages;
  3. The idioms are different; and
  4. Abstractions are leaky. Jeff Atwood characterized this as All Abstractions Are Failed Abstractions.

This is the same basic problem with ORMs like Hibernate: Object-relational impedance mismatch. Every now and again you end up spending half a day figuring the correct combination of properties, annotations, XML and VM parameters to have a query generate the right two lines of SQL that’ll actually be performant.

Another problem is that GWT fools naive Java developers into thinking they don’t need to learn Javascript.

My position can be summed up as: GWT treats Javascript as a bug that needs to be solved.

On Widgets and Maturity

I’ve programmed with GWT. The widget selection is woeful. The standard GWT widgets look awful, even amateurish. There are some third-party options but ExtGWT is a shockingly bad library. SmartGWT looks like a better alternative (and is actually a community effort rather than a split GPL/commercial mish-mash from someone who simply doesn’t understand Java Generics). There aren’t many other choices.

Javascript has many choices: YUI, ExtJS (completely different beast to ExtGWT), Dojo, jQuery UI, SmartClient and others. Not only is there substantially more choice but the choices are substantially more mature.

Development Speed is King

Java Web apps can take minutes to build and deploy. Within certain restrictions you can hot-deploy classes and JSPs. One of the wonderful things about PHP and Javascript development is that the build and deploy step is typically replaced by saving the file you’re working on and clicking reload on your browser.

GWT compiles are brutal, so much so that significant effort has gone into improving the experience with GWT 1.6+ and 2.0. Draft compiles, parallel compilation, optimized vs unoptimized Javascript and selected targeted browsers in development. These all can help but these are in part counteracted by increasing compile times with each version.

Also compiles are only required when you change your service interfaces. Pure client-side changes can be tested by refreshing the hosted browser (or a real browser in GWT 2.0+). Serverside changes that don’t alter the interface don’t technically require a GWT recompile but this can be problematic to implement (in either Ant or Maven).

Why are long compile times a problem?

Or from The Joel Test: 12 Steps to Better Code:

We all know that knowledge workers work best by getting into "flow", also known as being "in the zone", where they are fully concentrated on their work and fully tuned out of their environment. They lose track of time and produce great stuff through absolute concentration. This is when they get all of their productive work done. Writers, programmers, scientists, and even basketball players will tell you about being in the zone.


The trouble is, getting into "the zone" is not easy. When you try to measure it, it looks like it takes an average of 15 minutes to start working at maximum productivity.


The other trouble is that it's so easy to get knocked out of the zone. Noise, phone calls, going out for lunch, having to drive 5 minutes to Starbucks for coffee, and interruptions by coworkers -- especiallyinterruptions by coworkers -- all knock you out of the zone.

Even a one minute compile can knock you out of the zone. Even Jeff Atwood—still desperately clinging to his irrational hatred of PHP like an indentity asserting life preserver—has seen the light and is a self-proclaimed Scripter at Heart.

Not Every Application is GMail

I think of a Web application as something like GMail. It is typically a single page (or close to it) and will often mimic a desktop application. Traditional Web pages may use Javascript varying from none to lots but still rely on a fairly standard HTTP transition between HTML pages.

GWT is a technology targeted at Web applications. Load times are high (because it’s not hard to get to 1MB+ of Javascript) but that’s OK because in your whole session you tend to load only one page once. Web pages are still far more common than that and GWT is not applicable to that kind of problem.

Even if you limit the discussion to Web applications, all but the largest Web applications can be managed with a Javascript library in my experience.

Now for something truly monumental in size I can perhaps see the value in GWT or at least the value of type checking. Still, I’d rather deal with dynamic loading of code in Javascript that I would with GWT 2.0+ code splitting. Compare that to, say, YUI 3 dynamic loading, which leverages terse Javascript syntax and first class functions.

Of Layers and Value Objects

It’s not secret that Java programmers love their layers. No sooner do you have a Presentation Layer, a Controller Layer and a Repository Layer than someone suggest you also need a Database Abstraction Layer, a Service Layer, a Web Services Layer and a Messaging Layer.

And of course you can’t use the same value object to pass data between them so you end up writing a lot of boilerplate like:

public class TranslationUtils {
  public static CustomerVO translate(Customer customer) {
    CustomerVO ret = new CustomerVO();
    return ret;

Or you end up using some form of reflection (or even XML) based property copying mechanism.

Apparently this sort of thing is deemed a good idea (or is at least common practice). The problem of course is that if your interfaces mentions that class you’ve created a dependency.

What’s more Java programmers have a predilection with concerning themselves about swapping out layers or putting in alternative implementations that never happen.

I am a firm believer that lines of code are the enemy. You should have as few of them as possible. As a result, it is my considered opinion that you are better off passing one object around that you can dynamically change as needed than writing lots of boilerplate property copying that due to sheer monotony is error-prone and because of subtle differences can’t be solved (at least not completely) with automated tools.

In Javascript of coruse you can just add properties and methods to classes (all instances) or individual instances as you see fit. Since Java doesn’t support that, it creates a problem for GWT: what do you use for your presentation objects? Libraries like ExtGWT have ended up treating everything as Maps (so where is your type safety?) that go through several translations (including to and from JSON).

On Idioms

Managers and recruiters tend to place too much stock in what languages and frameworks you (as the programmer candidate) have used. Good programmers can (and do) pick up new things almost constantly. This applies to languages as well. Basic control structures are the same as are the common operations (at least with two languages within the same family ie imperative, functional, etc).

Idioms are harder. A lot of people from say a Java, C++ or C# background when they go to something like PHP will try and recreate what they did in their “mother tongue”. This is nearly always a mistake.

Object-oriented programming is the most commonly misplaced idiom. PHP is not object-oriented (“object capable” is a more accurate description). Distaste for global is another. Few things are truly global in PHP and serving HTTP requests is quite naturally procedural most of the time. As Joel notes in How Microsoft Lost the API War:

A lot of us thought in the 1990s that the big battle would be between procedural and object oriented programming, and we thought that object oriented programming would provide a big boost in programmer productivity. I thought that, too. Some people still think that. It turns out we were wrong. Object oriented programming is handy dandy, but it's not really the productivity booster that was promised. The real significant productivity advance we've had in programming has been from languages which manage memory for you automatically.

The point is that Java and Javascript have very different idioms. Well-designed Javascript code will do things quite differently to well-designed Java so by definition you’re losing something by converting Java to Javascript: idioms can’t be automagically translated.


Scripting is the future. Long build and deploy steps are anachronistic to both industry trends and maximizing productivity. This trend has been developing for many years.

Where once truly compiled languages (like C/C++ and not Java/C#, which are “compiled” into an intermediate form) accounted for the vast bulk of development, now they the domain of the tools we use (Web browsers, operating systems, databases, Web servers, virtual machines, etc). They have been displaced by the “semi-compiled” managed platforms (Java and .Net primarily). Those too will have their niches but for an increasing amount of programming, they too will be displaced by more script-based approaches.

GWT reminds me of trying to figure out the best way to implement a large-scale, efficient global messaging system using telegrams where everyone else has switched to email.


Curtis Mayfield said...

You lost me at the weird slight of hand where you turned "these languages haven't imploded due to lack of type safety" into "type safety is not a win".

Anonymous said...

...And you lost me when you quoted Jeff Atwood among legitimate industry giants.

Dan Billings said...

Joel and Jeff Atwood are not the only authorities on programming... far from it.

GWT has the potential to offer highly optimized code, dead-simple RPC, and cross-browser JS generation.

True, the widgets need some TLC, but the community is well-informed and necessarily at the cutting edge.

Finally, Wave is a huge testament to the power of this toolkit. I think enterprise-level websites will make GWT shine brighter than any other framework.

Anonymous said...

I have been trying to put GWT to use on several personal projects for a while, but I keep ending up in writing it with Perl, Template::Toolkit and DBIx::Simple. The speed of development for most simple apps using scripted languages like PHP and Perl is awesome.

The downside, reusability, is in my case countered by the lack of cost: I can write and rewrite the application in the same timeframe a usuall Java/GWT application is built.

I sincerely hope that, one day, this same speed of development and deployment cycles will be made possible with toolsets like GWT.


Anonymous said...

This web page displayed incorrectly. Part of the Dilbert comic was overwritten by text. I'm guessing that when it comes to web programming YOU DON'T KNOW JACK.

Anonymous said...

I agree with most of your points, and as a Java developer, will admit that we tend to create overly complex frameworks, when sometimes a standard perl cgi or PHP page embedded with html would have worked fine.

And yes, things like Hibernate have a heck of a learning tool, and it sometimes feels that it would be a lot easier to just write out the standard SQL and convert from db to model objects.

On the other hand, any sort of site that ends up being more than a few pages can get extremely ugly when multiple developers are each using his/her idea of 'correct' PHP or perl. Huge amounts of work end up getting recreated as the helper files of functions starting adding up. Good luck to new developers getting up to speed in this mess.

With a good framework (like Sping MVC) and a developer or two that know what they're doing, a large and complex project can be broken down well enough so that all layers are easy to understand for new developer, and the front side team doesn't have to try to find their way among a bunch of mixed PHP /Perl scripting within the view layer. The complexity of transactions and scoping of variables (session, request, multi-request, etc.) can be defined, and a lot of tools are getting better at providing auto generated code, including the controllers, DAO, and model objects.

just depends on the size and complexity of each project.

Anonymous said...

"Java programmers love their layers" has absolutely nothing to do with GWT, you should cut that section out and paste into an anti-Java rant. Nothing is stopping you from writing a "layerless" GWT application.

The bit about Java, Javascript, impedance mismatch, English vs German, etc. is totally irrelevant. The GWT compiler does what it says it does. A Java programmer can write (and debug, using familiar Java-based tools) a GUI application in Java, and the magic of GWT makes it run in a browser using Javascript. I think that's great!

It's easy enough to refute the silly "GWT is the future of web development" statement, and you do offer some valid criticisms. But ultimately, GWT is a great option for Java developers who want to make highly interactive, mostly-client-side GUI apps that run in a browser.

But you go beyond the fair criticisms into dissing GWT because it's centered around Java, and Java is inferior to wave-of-the-future script languages like PHP and Javascript. Whatever.

Anonymous said...

GWT: The training wheels of the web.

Anonymous said...

Don't confuse types with compilation and REPLs. Many typed languages offer instant evaluation.

Because of types, in any non-trivial Javascript framework codebase, GWT will produce smaller code, because it can prune fields, methods, parameters and obfuscate much better than existing JS minifiers/packers/compressions. To achieve with GWT does, JS programmers have to spend time manually stripping away unused routines. This is not taken into account when you talk about productivity. GWT Code Splitting and YUI dynamic loading are not the same thing.

GWT Code Splitting is automated. I decide which callsite might be loaded asynchronously, and the compiler splits off the entire calltree of dependencies. If you were writing your own JS library, and wanted to allow chunks of it to be loaded asynchronously, you'd have to split it up into pieces by hand, making sure not to leave out dependencies (A depends on B which depends on C & D...)

The compilation comments are irrelevant. If browsers shipped a scripting VM that took generic ASTs or bytecode, instead of JS syntax, then GWT would simply output those. It is simply the fact that browsers only expose their VMs/JIT through JS that makes JS the 'assembly language' in this situation. (BTW, parse time is significant on mobile devices, so an efficient bytecode representation for those devices would make sense)

Compilation times are a valid concern, but that is an implementation detail of the compiler, not an intractable problem with compiled code. After all, Javascript is JIT compiled, many languages like OCaml, Haskell, Scala, et al, offer hybrid REPL/compilation environments.

If your argument is based solely on compilation speed, and hatred of Java, I think you'll find that technologies like GWT will be the future of web development, and GWT will evolve to deal with other input languages, like Scala, Groovy, or Clojure.

What's the alternative that you're suggesting? That all web applications written by anyone for the next 100 years use Javascript and that no one is ever allowed to develop in a different language that is cross-compiled?

Matthew Holloway said...

To show that this article has little to do with the approach of GWT see the Python implementation of GWT called Pyjamas, http://pyjs.org/

The idea of maintaining state on the server and dealing with widget abstractions (which is ultimately what GWT provides) isn't Java-specific, let alone GWT specific.

soru said...

In every other area of development, there are problems for which scripting languages are appropriate, and others where compiled languages are a better choice.

I donlt see why the web should be different.

Anonymous said...

I love it when people know the future. Scripting is the future! What else is the future? I hope there are Transporters(*crossing fingers*)

Anonymous said...

You clearly do not have much experience writing REAL enterprise systems. Let's see how your dynamic types and ad-hoc class signature changes stand up when you have millions of lines of code across dozens of servers.

Try writing an article after you understand the fundamentals of OOA/D and software engineering in general.

Anonymous said...

I think you missed the entire point of GWT. Java is just the language that Google picked. The same thing can be done with Python and Pyjamas. And any other language.

The idea is that you develope web applications like "traditional" desktop applications. There are many programmers including myself that haven't done any "web" based programming because of the "mess" that it is.

GWT clears up this mess...my code looks and behaves like code written for standard desktop applications.

This will increase the amount of "good" quality web apps out there. Google wants more programmers to develope for the web - they made it really easy now for "traditional" programmers.

nothing to do with specific languages or scripting - if its good or not

Anonymous said...

It's pretty funny that when some of the smartest engineers in the world created gwt, they forgot there would still be morons who can't step aside from their biases to evaluate a technology properly.

I would challenge anyone to create a cross-browser, cross-language, accessible, desktop like website faster than a gwt developer that knows their shit.

GWT is the future of web *applications*. Web sites, nope. Have you actually built a desktop like web-application in js? I have, and it's much more difficult with jquery/dojo than it is with gwt.

Anonymous said...

"GWT: The training wheels of the web."

Spoken like a true script kiddie.

Sam Terrell said...

I think some of those complaints prove his points more than refute it. :)

The idea that web development is a mess or a problem IS THE PROBLEM. When in Rome, do as the Romans. The web doesn't need you bringing your baggage to it's party. Write good web code. Don't try to write a boot strap and a scheduler because you are used to kernel programming.

I'm still quite uncomfortable with GWT. I think there are two kinds of web interfaces out there, and each have their place. One of them is the content-oriented sites that make up 90% of the web as we know it. The other side is the process-oriented sites. I think GWT might make more sense for the process-oriented approaches to web development, where flipping pages just doesn't make sense. On the other hand, if you find yourself constantly just looking up forms and content in your GWT, you are definitely not working on a GWT problem.

I know that was a false dichotomy, but it's easier to make the point that way. Most application will actually fall somewhere in between. I would argue that the applications of the future will use both, and they need to start playing well together sooner rather than later. We don't need to be writing browsers in javascript or embed forms in a choose your adventure kind of content mgmt system.

While javascript seems like a natural language to use for the more dynamic applications, I would say that to build services for your javascript, a lot of times you end up writing a widget of sorts in javascript to call your personal clone of CouchDB. You can't implement your security model in javascript (nor GWT), so I think it's not even solving the problem I need it to. I personally like using Lakeshore for the parts that look like an application, and just plain old JSPs and Servlets for things that look like pages, in the absence of a toolkit that does both.

Why is it we always get the "you never worked on a big project" argument every time you suggest scripting. Scripting projects are not smaller because they won't work on big problems, they are smaller because they solve problems with less effort. I've never seen a newbie step into a spring application without shell-shock. The motives for spring are misguided, and the results are spaghetti code. If you have to open 25 files and sort through a 100 line stack trace for a single page view, then you are most definitely doing something WRONG. I would argue that is more unmaintainable than a decently constructed project in Ruby, where DI and IOC are basically free, if you every wanted them for some reason (no interface code required, and objects can much more easily be assembled in a dynamically typed language).

Anonymous said...

Sam, if you think that Spring produces spaghetti code or that the "number of open files" is a valuable metric, you ALSO have not worked on a significantly large enough enterprise web application to have a valid opinion.

Web development said...

GWT has the potential to offer highly optimized code, dead-simple RPC, and cross-browsers JS generation. Walk through the installation and first steps needed to get a GWT application up and running up and running. From there, work through the fundamentals of GWT development with an in-depth GWT tutorial.
web development

Tom said...

Holy long rant about Java, Batman.

There is no reason why there can't be GWT + Scala + Background compilation.

That makes all the many words you have written totally pointless.

Anonymous said...

Web development IS a problem, because designing predictable user interfaces with browser layout engines on multiple platforms using CSS is quite difficult. That's why every JS programmer uses JS libraries to "fix" these issues.

A large project by definition would be something like a GMail-like client, Office application, or Google Wave. GMail is already written in Javascript (before GWT existed) and it's quite large, for example. The size is not a factor of the syntax, it's a factor of the sheer amount of functionality.

The reason why you don't see many applications like GMail is because they are hard to produce with pure Javascript without the assistance of all kinds of tools. The flaws in Javascript for large scale programming are quite obvious if you look at how people implicitly extend it with tools or idioms (JSDoc type annotations, ant 'build' scripts, Objective-J/Cappucino/etc). Ruby/Python are better in this regard. JS even lacks a standardized import/module system, which means everyone cooks up their own, mutually incompatible, dependency tracking systems.

Ray Cromwell said...

In the old days of programming language wars, we had the concept of the "Macho" assembly programmer, who would exhibit a sense of superiority because he programmed "close to the metal", and people using high level languages were ignorant of the hardware, and coded "with training wheels"

Now we have come full circle. Some Javascript programmers complain about cross-compilation treating JS as mere "assembly language", and exhibit a sense of superiority because they program "close to the browser" (metal), eschewing abstractions that might hide Web development issues.

If you are not willing to suffer through the pain of cross-browser CSS fluid layouts, you're a wuss who wants to develop with "training wheels". So, although Javascript developers hate the analogy of JS as "assembly language of the Web", they are behaving like the Macho assembly language programmers of old.

Anonymous said...

Very interesting. For the most part I totally agree, especially about the long compile times in GWT, which really put me off it. The one thing I'd disagree with - JavaScript would (and perhaps one day will) benefit hugely from a standard way to declare optional type information, at least to drive IDE features like auto-completion. There's a system for this in Visual Studio, based on limited type inference and special comments, but it's not great, and there isn't much adoption of it; we need types in JS to make it great.

Also without a standard concept of types, JS library authors in their documentation have to each invent a way to describe exactly what you're expected to pass to a method.

Auto-completion allows beginners to learn, but it also allows experts to massively increase their productivity as well. It removes the need to memorise the exact naming used in APIs, so less time is spent breaking your flow by looking up stuff in documentation. A plain dumb text editor for code is a joke in this day and age. But without declared type information, it's hard to implement anything much better.

If anything, what hurts the argument here is saying that "scripting is the future" and hence JS is okay. JS doesn't have anything to do with "scripting". Although flawed, the irony is that it is a much more powerfully expressive language than Java! It would have made a lot more sense for Google to have picked a simple way to add types to JavaScript. By hiding it behind Java, they've made Web development into a crummier, more toy-like system.

So the problem with GWT is not that static typing has no value - it has huge value. The problem is that Java is a poor example of a statically-typed language.

Tom said...

Not every application is Gmail.

Absolutely. Most people don't need GWT

Anonymous said...

Most site don't need JS either, as most sites are content driven. Just a few short years ago, practically every interaction was an HTTP round trip.

This doesn't invalidate the point that Web apps are becoming more and more sophisticated, especially as browser engines get faster and more powerful, and as this trend continues, it is simply unacceptable to have only a single syntax for accessing it. Those who fight this are suffering a form of cognitive dissonance, that because they've invested so much time and energy into learning JS, everyone else must be forced to as well, and JS represents somehow an optimal sweet spot.

The reality is, JS is just one scripting language, not necessarily the best scripting language, there are several problems in the spec (most of which can't be fixed in a compatible way).

As for why Java was chosen? A simple theory: Path of least resistance. Existing parser/compiler library (GWT uses Eclipse JDT), existing IDEs, existing VM, existing build tools, existing test frameworks, existing bug checkers, existing user base who already knows the language. It's inevitable that other languages will follow, but 2 years ago, picking Scala or Haskell as the GWT source language would have made it a research curiosity.

Choosing Java as a compromise got huge volumes of developers onboard. The GWT developers have declared no love for Java, it's a matter of market reality. Forking Javascript would be a non-starter, and Javascript2 (which added optional types) got aborted, a shame really, because JS2 would have made a nice input language to GWT.

Anonymous said...

Nice post!

But I think you're missing a point. You're trying to argue against GWT as being "the future of web development" by doing an analysis of its technical merits (or lack thereof).

But as we all know and history has proven, technical merit alone cannot be used to predict the success of any technology, including programming languages and frameworks. A lot of the time being "good enough" is sufficient for (sometimes phenomenal) success.

Anonymous said...

check gwt2, most of the problems u mentioned are already solved and keep in mind even wave uses gwt2

Unknown said...

Please refrain from posting other people's creative works without consent and/or copyright notices. You posted art from XKCD without following their attribution policy. Show some respect.

Anonymous said...

I like dynamic programming. Hell, my thesis advisor created Scheme. Nevertheless, there is a much bigger difference in productivity between coding in a competently designed language and an incompetently designed one than in a dynamic one to a static one. Java ain't great, but JavaScript is among the shittiest languages ever designed.

I'll give an analogy. If you're transporting lumber, you want a truck. Nevertheless, you're much better off with a Ford Windstar minivan (Java) than you are with a Tonka toy truck (JavaScript).

JavaScript was designed in about a week. It has issues with lack of types. It has issues with browser cross-compatibility. It has swarms of other issues.

My best guess is that, 10 years down the line, JavaScript will evolve into essentially a bytecode, encoded in ASCII instead of binary. Step 1: People will compile to it. Step 2: Browsers will optimize to the compiled code. Step 3: Compilers will optimize to the new browser runtimes. Step 4: People will ignore all fundamentally low-performance parts of JavaScript, and use only the parts used see in a bytecode. It'll resemble an x86 CPU -- CISC, with a bunch of crud you're not supposed to use because it is slow.

Peter Thomas said...

I do agree that GWT's unique approach results in some leaky abstractions making themselves felt. Here's some analysis I did:


William Shields said...


"You can post xkcd in your blog (whether ad-supported or not) with no need to get my permission."

Unknown said...

It's unfortunate to see another long rant based on the same misunderstandings that we've seen from the day we released GWT. Very briefly, here are the major issues I see:

1. I don't like Java, because Java programmers write reams of unnecessary abstraction.
We largely agree on this point (speaking for myself, at least, not everyone at Google). J2EE is a monstrosity, as is whatever library led to RequestBuilderFactoryFactory. This has precisely squat to do with Java the language.

2. Translating Java to Javascript necessarily leads to bad code, because some things can't be translated well.
This is, in some sense, true. I really wish Java had a first-class function/method object (C# delegates would be fine). I wish Enum weren't so damned heavy (we're working on that). But the things that aren't present in Java, that would be useful when translating to Javascript, probably account for <5% of the code we generate. So it's irritating but largely irrelevant.

3. Compilation times take too long.
I hate them too. So what? But if you're not using hosted (development) mode 99% of the time, you're either doing something wrong, or you fall into one of a few special cases (e.g., new mobile libraries) that we're working to address. Development mode gives you basically the standard edit/refresh cycle you get with Javascript, except that the compiler, generators, and other tools all get a chance to do work and catch errors.
Also, if you think you can get away without some sort of compilation process for a large Javascript application, you're unfortunately mistaken. Badly. You can't just concatenate a few hundred thousand lines of Javascript, strip out the comments, and hope for the best. You'll end up with a monstrosity of several megabytes, even for a medium-sized app.

4. The widgets suck.
Fair enough. Hell, I wrote half of them, and don't entirely disagree. Go write some that don't. Oh, and when you run off to talk about how much Ext sucks, realize that you're saying that Ext-JS sucks as well. Neither is the fastest library in the world, but they are very complete and cover a huge variety of use-cases. They made a very different set of tradeoffs than we did, but they're a legitimate set of tradeoffs, and appeal greatly to enterprise developers that need to get a lot of UI built quickly.

5. Not all applications are Gmail.
No kidding. If I were a real pedant, I would point out that this is a tautology. But yes -- if you're building a simple "page at a time" app and need to add a little script to it, by all means use JQuery or whatever you feel like. That's appropriate. Use the right tool for the job.

GWT was built to solve a specific set of problems, and we took what we believe are the right set of decisions to do so. Plenty remains to be done, and we continue to work on it. I wrote up a clarification on several of these points some time ago:
I hope this proves helpful to some.

Web Developers Chennai said...

Hi all.. really i am happy to see this site and all.. it has lot of information's to the public.. thanks for sharing this in internet...


Anonymous said...

There is only one web and its not the Java Web or C# Web or Perl Web etc... It's 3 main ingredients are HTML, CSS and Javascript, and they are the reason it has been so successful. Learn them sometime they might come in useful!!

Ray Cromwell said...

Post hoc ergo propter hoc, The Web was successful before CSS and before AJAX, it's not quite clear to me that they are the driving forces behind everything. Dialup internet itself was rapidly expanding in the years prior to Netscape/Mosaic, but often required too much technical skill to use. I think you can chalk up the introduction of inline images, tables, and forms into HTML, and the HTTP protocol itself for the rapid growth that followed. The whole dot-com boom proceeded mostly without Javascript, and with liberal use for <FONT> for style and <TABLE> for layout.

In fact, I would go so far as to say that the Web has been successful in SPITE of CSS, because the introduction of CSS, DOM, and JS programming massively increased the complexity of web developer compared to what existed previous, due to broken specifications and broken implementations in various browsers. The continued defense of this state of affairs (as opposed to acknowledging the problem) retards future progress, locks in legacy, and appears to be due to cognitive dissonance and ego.

Anonymous said...

i like GWT and the fact that it makes creating RIA so easy .. but its future depends on microsoft and their IE (~44% of the market). Sure IE sucks and probably any person with a common sense only use it to download other web browser... but big companies still use it. These companies (their managers) don't care about JavaScript efficiency or JIT compilers, all they care are their money.

Just imagine how much would it cost to install firefox on say 1000 pc in one company so that one program written in GWT could run smoothly, sure a lot especially if one would consider additional cost of users support by IT departments. Worse probably there would be even people saying that only IE guarantee security.

So instead of writing more and more dynamic web applications, software providers have to target their efforts on supporting most used platforms (their potential clients use IE :( ). As things stand microsoft doesn't think about upgrading their JavaScript engine so that web applications could run more efficiently,, instead they're trying to improve page rendering times as a whole... so the bottom line is that applications using a lot of JavaScript and DOM manipulations (like GWT does) will run slowly on IE. Any software provider has to protect its investment so while GWT might be attractive from many points of view it still falls short in terms of user perception using IE .As long as microsoft doesn't change its plans to IE i don't think GWT could succedee.

i think projects like: dojo, jquery, smartclient which give AJAX capabilities will be used more & more in the future (along with existing frameworks requiring req/res page approach e.i. struts, jsf, springmvc)

i've been reading microsoft plans for IE9 and there was nothing about JavaScript... instead they're talking about some shortcuts a user could click on its keyboard in order to e.g. store a page or do a bookmark. The other thing was twitter and easy access to the site...

i wish i was wrong with GWT future

razvan said...

Hello, I'd like to point out an error in your text.

In the penultimate paragraph, "now they the domain of the tools we use" should probably be "now they are the domain".

-- Răzvan Ionescu

Brian Arnold said...

William -- from that same xkcd page you linked to, there's this quote.

"Note: You are welcome to reprint occasional comics pretty much anywhere (presentations, papers, blogs with ads, etc). If you're not outright merchandizing, you're probably fine. Just be sure to attribute the comic to xkcd.com."

Every strip that Randall Munroe produces, he puts under this Creative Commons license:

That license carries the caveat of attribution: "You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work)."

Randall's about page requests attribution to xkcd.com, which you do not provide. You should edit the article, add a small caption below the image saying something like "(via xkcd.com)", preferably linking to the strip you're referencing. Otherwise, you're in violation of the copyright on the content. :)

Alik Elzin said...

Don't miss joel's comment - it is a nice contra to this article.

Olivier said...

Wow... what a bunch of biased opinions.

GWT isn't about leveraging Java programmers, it's about leveraging Java tools. Whatever you think of Java, it has great IDEs with a whole lot of tools that help you write code faster, refactor painlessly, debug efficiently. JavaScript IDEs are no match.

You say that GWT fools Java developers into thinking they don't need to learn JavaScript. Actually, I am a living proof that GWT lets Java developers write AJAX applications without needing to learn a single line of JavaScript. And I've been working with GWT for 2 years building serious business-critical apps.

Oh of course the generated JavaScript code might not use all language idioms and might not be as efficient as code hand-written by a very experienced JavaScript programmer, but so what? it's probably way more efficient than code written by most actual JavaScript programmers. If you need that extra bit of performance, then I'll agree that you need to write JavaScript. Just like you need to write assembly code if you really need to write the fastest native application. But otherwise, would you reject using a high-level language over assembly, just because you're not using all the assembly language idioms? In both cases (GWT to JavaScript and high-level language to assembly), it's the compiler's job to ensure that target language idioms are used appropriately. Not being able to use those idioms in the source language doesn't mean the compiler can't use them.

It's really inappropriate to judge GWT by the visual appeal of the built-in widgets. They are meant to provide minimalistic functional components, not be the ultimate widget set. I'm working with Ext-GWT (and I share your views about it), but despite its horrible API, the widgets are very nice to use. Again, don't blame GWT for the lack of genericity in Ext-GWT or the design flaws of its API.

GWT is very nice to work with in development mode, because what you are actually compiling and testing is a native Java application, so your IDE most probably does the incremantal compilation, all you have to do after you've made changes is hit the "refresh" button in the hosted mode window! So who cares that GWT compilations for web mode are long, as long as your app behaves correctly in dev mode, it will behave the same in web mode. The compilation should not be done on the developer's workstation but on the integration server, except maybe once in a while to check how web mode performs compared to dev mode. If you're constantly compiling for web mode, you're doing something wrong.

Layers: again I don't see what this point has to do with GWT. If you think that using a scripted language on the client makes it a good idea to send server-side business objects over the wire, you should reconsider. Server-side manipulates business objects, client-side manipulates UI objects; they don't abstract the same concepts. Once again, you're blaming GWT for bad design.

I think there is definitely a place for scripted languages in web development, but I will argue that as of today, GWT is the only sensible way to approach a large-scale project involving an AJAX front-end.

Anonymous said...

Google has written a very large rich-client web app in each of the technologies in question: Gmail in pure JavaScript and AdWords in GWT. How many GWT detractors can boast such bona fide practical experience on both sides of this issue?

Well, Google's engineers rendered their verdict by selecting GWT as the platform for their next big project: Wave. No offence, and notwithstanding your mostly-theoretical criticisms, but I'll take their word over yours.

Anecdotally, I've written non-trivial web apps in Rails, JSF, Struts and GWT, and I have found GWT to be head-and-shoulders above the rest for both developer and user experience.

Dan Sickles said...

Make it a bytecode to Javascript compiler and the other JVM languages will get to play too.

Anonymous said...

First of all I dont understand definition of web application you are assuming here and comment on gmail like web apps. Isnt twitter, facebook all webapps? Cant they all be modeled from UI point of view as a single page desktop like app? Heck facebook actually looks like a semi desktop app already.
Second things long build and deployment cycles - have you checked out hosted mode development? have you checked out few plugins available which can attached hosted mode with actual browser with out compromizing hosted mode advantages.
Widget look and feel - have u seen GQuery - jQuery port for GWT? have you checked google wave? have you checked tones of another third-party libraries available.
Most of the time you use jQuery, Dojo and then when you actually need to customize them, its hard. I have worked on multiple projects where we had to design UI on paper considering what Dojo and jQuery can support. that was the point where we chose GWT for all future projects.
Testability - most of the web app programmer who work on simple projects, dont test UI code ie unit test it. No offense but complexity of such app is so low that they can get away with it. Any thing few points complex-er and they struggle, getting it to work on IE beast. GWT helps a lot in that.

Question you need to ask while choosing a technology for a project is - how much time it is going to get me to complete first use-case and how much time in supporting the web app.
If you are a product manager who will have to support the app for years if you are successful then GWT is the choice for front end.

P.G. Taboada said...

It might not be the future, but actually I feel like it is the present of web development. I don't see any better approach.

GWT brings software engineering to the web. And does it by providing optimized javascript. I don't see anyone other providing better Javascript than GWT. GWT does not only cross compile, don't forget it has the code generators - there is where the GWT magic happens. RPC, Sprites, I18N - please show me better approaches.


Marc Golinelli said...

Zawinski's Law: Every program attempts to expand until it can read mail.
GWT approach is definitely the future of web development for large application, even if at the time speaking most of libraries targets webtop application developpers. Dawning of the web software engineering...

Unknown said...

Agree that GWT doesn't provide beautiful widgets, but that isn't the point of GWT. It has been created as facilitator.

Disagree that GXT is terrible, whilst somethings relating to API consistency and design are indeed terrible on the whole it is a fantastic library.

I can't really comment on the JavaScript side of things, I have wrapped a few native methods in GWT but apart from that I know nothing.

GWT combined with GXT has enabled me to create an awesome professional services application that enables all consultants and staff to log in using any machine anywhere and do what was previously done via a crappy desktop client via RDP.

In conclusion, if you love javascript so much why don't you marry it and then use whatever expertise you have, I am assume you are a guru with javascript, to improve GWT in the areas that you have harped on about or create something better.

Carl Scott said...

"Give a man a hammer, and everything look like a nail"

That's definitely not the best approach to take to programming in general. There are many tools to use to accomplish a particular programming task, and you need to find the right one. GWT has its niche as does simple scripting, but at the end of the day, if you have 10 developers working on a large-scale rich-client web application, GWT is the holy grail. The code ends up being more maintainable and reusable, which is priceless in a business setting. If you're a solo coder trying to quick-fast-in-a-hurry get a simple site up, script away. Use the right tool for the job.

I actually find myself sometimes combining practices, writing scripts invoked from my Java code or vice versa, because a certain section of a project may lend itself to be written a certain way; or, I may have scripts around that I need to integrate that don't translate to Java.

So, is GWT the future of web development? Yes. Web applications are becoming increasingly complex and, more important, the audience is starting to expect this. In the past, people were used to downloading and installing desktop applications to accomplish major tasks; now, the power of web applications is being realized and people are actually using these apps. The more they use it, the more demands will be placed on developers to create even richer apps, more complex modules, and provide more services. As demand causes web applications to scale, a scalable platform will be the thing to have -- and that, is GWT.

Not to completely disregard you, you do make valid points, but I think your conclusion is wrong. Good thing everyone has their own opinions!


Anonymous said...

i also agree that GXT is horrible, because many of the bugreports they are refuse it as "thats by design" :-(

Anonymous said...

GXT is a piece of s%$#@. Please, get away from it. Besides, they try to charge you for a bunch of bugs. But that's what you get when you force people to pay for debugging your application.

andrew j said...

Wholeheartedly agree that GXT is an inferior quality product. It might be a "pure" GWT third party library, but that doesn't make it a good product. It's "pure" crap if you ask me.

It's not just that the product has a lot of bugs but the product design and API's are fundamentally flawed. It's a copycat of Ext JS and a lot of design choices are not sound. Generics were introduced all over the place by the author who clearly had no clue how generics work. The users helped clean some of this but it's still very messy to work with.

Anonymous said...

You really should take a look of Vaadin ( vaadin.com ). It is built on GWT, but get away from the slow compilations by moving most of the UI to server. The widgets look really good ( demo.vaadin.com/sampler )and license is Apache 2.0.

magnesium said...

Web development is a broad term for any activity to developing a web site for the World Wide Web or an internet. This can include e-commerce business development, web design, web content development, client-side/server-side scripting, and web server configuration. However, among web professionals, "web development" usually refers only to the non-design aspects of building web sites, e.g. writing markup and coding. Web development can range from developing the simplest static single page of plain text to the most complex web-based internet applications, electronic businesses, or social network services.

Wyatt said...

Implying that HTML + CSS + JavaScript + server side logic can't successfully be applied in a "software engineering" context is entirely bogus. Dynamic vs static typing, blah blah, yawn. Perhaps for some sufficiently large project, the JS approach wouldn't be sufficient, but I suspect that for the vast majority of Web apps it is. Yes, JS has some issues, but so does every language and programming environment.

Question: how do you integrate a 3rd party JS library into a GWT app? I don't have direct experience with this, but a coworker has said that the effort is non-trivial and that you either need to rely on a 3rd party adapter or write your own. For some (me), this is a non-starter.

Anonymous said...

"if you were to write textbooks in German would you write them in German or write them in English and have a tool convert them to German?"

...simple, it depends on a few factors! If German is your native language I'd write it in German. But if you're not familiar with German or you barely can order can order a coup of coffee without looking up every second word in a dictionary and your German is still terrible... well, then I'd certainly use this converter. Also some things you can explain in English much less complicated than in German.

And finally, the killer argument FOR GWT: Google is behind this! If it's not yet a standard paradigm for web app development, it'll become one soon! Also GWT evolves very fast. And the side-effect – some code parts have to be rewritten if you upgrade your GWT SDK.

Anonymous said...

There is no impedence missmatch. No problem. Using this argument you should program in assembler, not javascript !

So what, you don't want to use java for client side and prefer javascript. That's your choice.

But i bet, it's not everyone choice ! Most of your arguments are Java vs Javascript comparison and how YOU prefer javascript.

That fine, but it's not necessary what every developper will think.

Kevin Wong said...

@Wyatt - There are GWT wrapper libraries for most JS libs, but if none exist, yes, you'll have to write one, or call the JS directly using GWT's convenient JSNI. But you'll find that GWT makes many of these JS libs irrelevant. What are you looking for, widgets, effects, data marshaling? The GWT widget space is admittedly young, but it's growing quickly. See SmartGWT, GXT, GWT incubator, etc.

Anonymous said...

Could you re-elaborate your thoughts thinking that your comparison would be a lot more appropriate if it were worded like: "if you were to write a textbook for Germany (the "web") what language would you use knowing plain German won't work ("browser incompatibilities")?"

Anonymous said...

I agree with the author. Putting another layer to translate from Java to Javascript won't be the final solution to solve incompatability on different browser issue. Every browser is developing. How long will GWT to catch up to offer the latest features in browsers.

It is also awkward to make HTML, CSS, Javascript working perfectly in GWT.

ExtJS is not a good library either. Its memory leak is like a sieve!!!

BGerrissen said...

GWT is brilliant, the problem lies more with usage. Fact is, Java developers are generally not UI experts and it's a naive to think that with some widget or component framework like Ext, you have all you need to develop slick apps.

UI knowledge, SEO implementation, accessibility, progressive enhancement are usually not among the skillset of your average Java developer *if they are, you ROCK!* so any apps build with GWT might look sweet and it will work, but every other factor which is important to webdevelopment will be total and utter crap.

Seen some Java devs utilize GWT for enteprise applications. The HTML was crap, accessibility was crap, SEO was crap, there was no progressive enhancement present at all so if JS breaks somewhere on your page (due to third party scripts and you cant fix it because no one know JS), your app breaks. And even usability was crap, it did work, but waiting ages for a huge grid to load or chunking client side processes up in an evented model or basically any JS best practise idioms simply goes out of the window.

This is not the fault of GWT, you can do all of that, but for your average Java developer, it would take too much time because they *usually* haven't learned to create great UI's and are not familiar with JS idioms and methodology or how UI's are glued together in the first place.

That said, I am a *script kiddy* myself that works for a Java joint that deploys enterprise level applications. There's a lot wrong on all ends, wether it's script side or compile side, fact is, we're not there yet on either side.

Work with the tools and resources you have, read articles including the rants that follow to get a good view. Don't stick to one narrow minded opinion because chances are, you will be wrong, whatever you preach.

Anonymous said...

Can't say I agree. I've worked with GWT, and with php/js. GWT for complex RIA is far preferable.

Anonymous said...

So nice to see so many comments on this subject, as they provide an opinion coming from a legit background.

Here is our website, kodingen.com an online IDE, we used PHP + Jquery on the frontend. I thought i showed you this to demonstrate the scale that i'm talking about.

Am I happy, no! It took us 4 months to make sure that everything works, since only testing we could do was to click everywhere. you tell me about your compile times.

Now I'm looking forward to the day that we port everything to GWT with Vaadin.

Why? because, php+js is a mess regardless how well you write it, compared to Java. Of course creating a mess doesn't limit itself to a specific language but if you have developed a large scale app like we did, you will know what I mean.

'you' know your classes, there is no one way of implementing them, there are no standards, and it's almost improbable to think that a large team will be fine with php+js (unless your father is rich), you will end up converting PHP to a compiled language as facebook did with HipHop if your website made it to 200 million users.

Even then, as it's name suggests, it's going to be a hiphop not a contemporary art.

I don't know the future, but now, if you are reading this and want to create something big or small, learn GWT, Java or Vaadin, you will thank me later. Here is my opinion about this


Anonymous said...

I've used both heavily, and I'm both a Java and JS guy, so no language issues. I've got to say GWT is just amazing for building large complex Web 2.0 apps. The only points above that I can agree with in any way are about the widgets, and we've crafted our own - problem solved.

Anonymous said...

GWT is revolutionary and will allow the development of large complex apps on the browsers of all makes and shapes. Widgets will improve with time.

Good luck in your JavaScript world. You're going to need it.

Anonymous said...

I need to say that you are a joke sir.

Mr. Java said...

You are my hero. Amen.

Unknown said...

Great article and thanks for highlighting my site!


Anonymous said...

The funny thing with these "the future is not x" articles is that they are so fun to look back at when the future has come, and it is x. Like the one that wrote "the internet is a flop and will die in a few years", sometime in 1996.

I just started writing my first GWT application. Yes, the compile time is a lill pain. Not anywhere NEAR the pain it would be to spend hours debugging the complex javascript code it would take to make the ajax application i build in no time using gwt.

I belive the future is ajax. Backends will respond as web services, not web pages build using JSP / PHP etc. Gwt is a techologie that is giving us a framework to do this in a type safe manner, with a good library, integrated into top IDE's.

I do not know if gwt is the future, but I belive it is going to be somewhat along those lines. Reading the comments, it seems your predictions are not shared by many.

Anonymous said...

With untyped languages you'll sooner or later get into trouble as applications become more and more complex, need to be troubleshot/maintained/migrated/etc. JS for the small-to-medium and/or prototype projects is nice, for the big/strategic things I prefer GWT plus 'widget set' (SmartGWT)


Anonymous said...

P.S. broswer abstraction (maybe by 90%) is another big argument for a GWT approach

Web Design Company Dubai said...

Very well explanation about GWT.. keep going...

Anonymous said...

"GWT: The training wheels of the web"

As much as a 3GL is training wheels for writing machine code. Funny... I never felt the need to write massive applications in machine code ;)

Anonymous said...

You obviosly have no idea what you are talking about, not to offend you, but you really don't know much about GWT.
The fact that it completely separates Presentation Layer from anything else is awesome. It even beats any current ajax application by sending less HTTP request at the webserver. It does this by renedring everything client and effectively just asking for 'data' from the webserver. This has major advantages from a performance perspective, and not a single other technology can beat a GWT app when it comes to scalability and speed. For me speed is the most crucial aspect of a user experience.

Anonymous said...

@Anonymous - "It even beats any current ajax application by sending less HTTP request at the webserver. It does this by renedring everything client and effectively just asking for 'data' from the webserver."

I'm currently working on an AJAX application that does exactly that. The presentation is snippets of HTML. When I need such a snippet, I can load it into a div:


By putting classes on certain elements in that snippet, I can splat all the properties of an object into it, and thus 'populate' it with data. That's about two lines of jQuery.

To get data, I can hit any backend service that returns JSON or XML:

$.get('someService.bla', function(data) {
// do something with data, which is an object

The whole thing starts with one index.html page that loads all the script and css. I append all my scripts into one file so they can be cached as a unit.

It's absolutely optimal. It works on all browsers. It's easy!

Why hide JavaScript behind Java? Until they add closures to Java, JavaScript is by far the better language.

Anonymous said...

I don't know the future. Yet I know that Vaadin (built on GWT) rocks.


Post a Comment