Pages

May 26, 2011

2 reasons to avoid GWT

Hi guys,

Say your role involves dealing with UI technologies and part of it, naturally, is deciding which technology fits your project best so you've probably came across the big debate of Flash/Flex vs. GWT.
Although the two can live happily together without stepping on each other's toes sometimes the project dictates using one exclusively.
Both technologies mentioned above have their pitfalls, but allow me to focus on GWT and hand you 2 good reasons why you should avoid it :)

The first reason is cross-browsers compatibility:
Well - that's a complete bullshit, and if you've been messing with HTML/JS/CSS long enough you know it. GWT only claims to be fully browser compatible but the reality shows different. Gecko, Trident,  Webkit and other browsers engines interpreter JavaScript differently. It is a fact. There is no one standard there. Read it again - it is a fact!
GWT claims it can compile for each browser permutation, but reality shows that it's simply not working on all browsers the same way.  Forget my bad experience with it - let's rely on logic and ask, can the GWT team guarantee that they have covered all aspects of JavaScript for each JS interpreter engine? All of it? Can they? Come on...
Hold on, you know what? let's say that GWT, at it's core, is browser compatible. Does anyone use GWT alone for building RIA's? I mean, the framework don't have half of the controls needed for it yet. So what do you do? You rely on 3rd parties such as Smart Client. Now, did anyone guaranteed that Smart Client is a full browser compatible? Let me help you - it's not. How about blending IE's quirks-mode into the dance? Oh, now you're dancing, mate...
So when people tell you that GWT is browser compatible, you can tell them that you will believe it when you see a full RIA application running on IE, FF, Chrome, Safari, Opera the same way.

The second reason is memory profiling (especially on IE):
While Firefox has it's amazing Firebug (got to admit it, it's pretty amazing) IE is lacking a good developer tools, at least on IE8, which doesn't have memory profiling for it's developer tool, and for a good reason, it seems, since IE is probably the worst option to run JS on, memory-wise. Modules that run smoothly on FF or Chrome, are jammed on IE, generating an embarrassingly high memory foot print. IE simply doesn't know how to decouple JS from the DOM efficiently enough, leaving objects the GC can't touch.
Now, after searching the web for different memory profiling I came up with a few solutions, but when trying them, the information was so abstract, that I couldn't pinpoint the cause for the memory leak I was experiencing.
Having GWT generate JS code under the hood keeps you wondering why the hell objects are not marked for deletion when you have no real ability to track down the reason. I hate code generators. This truly sucks ass.
So you can always remind GWT evangelists that profiling GWT memory consumption is pure hell. At least on IE.

Needless to say, but Flash and Flex do not suffer from the 2 critical problems mentioned above. Flash is truly a cross browser technology, and profiling it's memory is easy.

With that said, you will probably make your own decision, but remember what you've learned here, just in case…

:)

Cheers.

12 comments:

לירון טנצר said...

maybe the reason Google wants to keep browser compatibility is the reason that they still don't have all the components, because each component they add needs to work the same and that is not an easy task.
I wonder if all the component they already have do that (I would like to believe so).

Regarding the memory on IE, well nothing i can except IE should be declared as a bug and not a web browser (at least older versions, 9 seems better), it is a shame GWT needs to suffer from a faulty browser but it is a problem none the less.

however flash has its own limitation which can be problematic in other cases, like the fact that you need to download and install plugin (which believe it or not, is not always that simple, i just recently had a problem with a mix of 64/32 bit version that just blocked me from using flash), and when moving to smart phone then flash support is still missing from some...

Flashmattic said...

No - Flash is missing from just one :).

jDramaix said...

"Just" one but one used a lot by users of web application...

Flashmattic said...

I disagree.
iOS is not the leading Mobile OS in the market. Actually, Android is gaining more and more users over iOS as I write these lines, but this is not the issue brought here, although the connection is evident.

flex development company India said...

I agree with you Flashmattic

Kari Surakka said...

I agree that "built in" controls of GWT are not enough for real application, I had to built many by myself. But it is nice that they can be built.

I'm a bit skeptic that Flash/Flex would do much better "out of box". Is there any example of good data driven application made with Flash?

Not trying to flame, just curious.

Flashmattic said...

Hi Kari,
Well - Flex gives you a component architecture that is much more robust than what GWT offers, with things like layout framework detached from the logic and much more...
I'm not talking about extensions to the GWT but rather the core package - it has a lot of room to improve.
As for Flash/Flex data driven applications, well... there are so many that a simple Google search will leave you overwhelmed. Flex was (and to some part still is) the best UI solution for J2EE applications. Flash is not usually the tool you would use for that, though, it can be done.

oedo said...

A lot of people overlook the fact GWT is built for JAVA developers rather than flash/web designers. I'm a back end programmer and with GWT I've been able to make some epic strides. The apps you make with GWT are batshit insanely fast, nothing gets near it in terms of speed if you use it correctly. Code splitting is so freaking easy, if you use the gquery library you'll get a 'faster than jquery' port of jquery. Also with clientbundle you can bring the number of requests down to a really minimal level and your apps are perfect for devices operating over mobile connections which is my biggest pet hate with the internet today. 1mb+ pageloads (400k is plenty) with 300+ requests. Oh make sure you install windowsbuilder pro in eclipse if you plan to play with is so you can make projects with the MVP components. SO MUCH WIN!

Flashmattic said...

Well put, and I'm sure that the reasons you've counted here are a true win.
One thing though - most Java developers I know don't know the first thing about developing UI, and developing UI for the web (I said most) :)
Even Google is planing to abandon GWT and move forward with it's Dart initiative... I guess that time will tell :)

cxillo said...

Sadly Adobe has already abandon Flex. Probably was the best tool for doing UI, even if it has a lot of flaws, but now i thing the future of Flex it´s uncertain.

Christian Sterzl said...

Flash on mobile never existed. GWT is still alive. I think it has won the debate.
Your arguments are pretty lame by the way, even for 2011.

Flashmattic said...

Hi Christian,
Well.., you took me back some year from now with this comment but I feel that it still worth a reply.
It's not completely true that Flash for mobile never existed. AIR had a fairly nice go at this which made Steve Jobs add (yet) another limitation into the endless list of limitations one must follow in order to deploy an app on the app store - he strictly banned any application that used a compiler to convert it to Objective-C. But that's history now.
GWT, my friend, is long dead. Google buried it a long ago and are focusing on AngularJS and Dart these days. If you really need some hard proof you can ask the guys from Double-Click who converted their entire project from GWT to Angular.
I see that you don't agree with arguments and I wonder if you have any other arguments we can debate about (other than "lame" which I have to admit is a strong argument but still feels that there can be more to it ;)).

Cheers