Is the Google Web Toolkit Right For You?

An anonymous reader writes "The recently released Google Web Toolkit (GWT) is a comprehensive set of APIs and tools that lets you create dynamic Web applications almost entirely in Java code. However, GWT is something of an all-or-nothing approach, targeted at a relatively small niche in Web application development market. This article shows you what GWT can do and will help you decide if it's the best tool to use for your web development."

Comments

When I hear OO ... When I hear Java

[neonprimetime]

Where I hear OO ... I think good ... there'll be readable code, there'll be clean code, there'll be re-usable code
When I hear Java ... I think arg ... poor performance & not truly open source

Looks interesting, but who will take the chance on it?

Re:When I hear OO ... When I hear Java

[Anonymous Coward]

I'm guessing that Google will.. (?)

Re:When I hear OO ... When I hear Java

[Serapth]

What do you think when you hear "Code Generator?"

Thats my biggest beef with the way this kit works. The JSNI interface seems like a pure hack to start with doing things like embedding javascript code in a java file using code like the following:

private native void applyEffect(Element element, String effectName) /*-{

// Trigger named Scriptaculous effect
$wnd.Effect[effectName](element);
}-*/;

I find these kinds of toolkits get you up and going quickly, especially if you are new. However, the first time you run into something the toolkit can't handle, the black box nature means your SOL.

Re:When I hear OO ... When I hear Java

[neonprimetime]

What do you think when you hear "Code Generator?"

Great for college research (took multiple classes on it)... but annoying in the real world ... if it's possible ... I'll delete as much of the auto-generated code as possible and start from scratch ...

Re:When I hear OO ... When I hear Java

[stratjakt]

When I hear someone say what you said I think... "another hack who's never programmed anything, never will, but read some shit on slashdot about it and now believes he's an expert"

There's plenty of unreadable, unusable OO code out there, as well as plenty of well performing Java.

Re:When I hear OO ... When I hear Java

[jrockway]

> What do you think when you hear "Code Generator?"

Perl 6. Perl 6 will be compilable to JavaScript, so you can write your web applications completely in Perl :)

Re:When I hear OO ... When I hear Java

[Doctor Memory]

the first time you run into something the toolkit can't handle, the black box nature means your SOL.

This is exactly the reason I gave up on VB. Want to do something even mildly handy (say, check the amount of free space on a disk)? Better figure out the WinAPI call format and figure out how to cast your arguments to FAR_WPTR[1], 'cause VB itself is absolutely worthless for this. OK, so you're not totally SOL, but if you don't have some experience with cross-language subroutine calls, you'll be pulling your hair out for days.

[1] Not a real data type. Not that UINT8 is any better...

Re:When I hear OO ... When I hear Java

[neonprimetime]

I'm too lazy to type it twice

Re:When I hear OO ... When I hear Java

[Hoolala]

We are taking advantage of it. We really look forward to the ability to develop rich Web Apps using a standard IDE and Java "OO" paradigm. ==== Beaches & Casinos: http://buddytrace.com/

Re:When I hear OO ... When I hear Java

[Valthan]

Umm... Java IS an Object Orientated language... (unless you mean something else by OO, in which case I would love to be enlightened..)

Re:When I hear OO ... When I hear Java

[neonprimetime]

Yes ... Java is an OO language
No ... Java != OO
Thus it's ok to have different opinions on them.

Re:When I hear OO ... When I hear Java

[Valthan]

OK, Now I am confused... Who wants to explain to the first year CS student?!

Re:When I hear OO ... When I hear Java

[frantzdb]

What do you think when you hear "Code Generator?"

When I hear "code generator", I think compiler.

Re:When I hear OO ... When I hear Java

[mdielmann]

I wrote a VB 6 app in a couple hours that not only notified me of the amount of free space in a given folder (including the root folder), but displayed it in a chart so I could easily pinpoint where all my hard drive space went. Not counting the VB Form, I used two objects: the chart object (crappy, but all I needed) and the filesystemobject object. It took about two hours to get it to where I needed, and I was doing it as a semi-useful learning task (elements of the filesystemobject that I hadn't used before). I imagine it could be done more easily in VB.Net, but I haven't bothered to try.
I'm not saying there aren't better tools than VB out there, or that it is easier to do what you were looking for in VB, but don't pass off your lack of knowledge as fact.

Re:When I hear OO ... When I hear Java

[neonprimetime]

OO = Object Oriented
Many computer languages are or can be Object Oriented (Java, C#, VB.NET, C++, etc.)
Therefore Java is a sub set of Object Oriented Programming
Object Oriented Programming is not just Java though, cause as said above it could be C++, C#, VB.NET, etc.
Therefore, I believe it's ok to say then that Java (as a subset of OO) may suck ... but Object Oriented Programming in general does not (cause for example C++ rocks).
Well, I tried.

Re:When I hear OO ... When I hear Java

[Valthan]

OH, OK, I thought at first he was trying to say that Java was not part of the OO grouping, which really threw me for a loop.

And personally I like Java, (although all I have to compare it to as far as programming goes is VB and Turing so...)

Re:When I hear OO ... When I hear Java

[neonprimetime]

In school ... my favorite languages were probably in the following order

• C++ - I learned this first, and it was tricky, but incredibly beneficial to learn
• Java - Once I already new C++, Java was REAL REAL easy ... and I also just loved how clean and easy it was to program in ... although in larger projects, at least back when I was in school, I did notice significant performance differences as compared to C++
• C - After learning C++, C was like a fun throwback ... it becomes a very interesting language ... and I sometimes just wrote programs in C instead of C++ just for the fun of it.

Now sadly ... since I've graduated ... I've had to move into the corporate world ... and I find myself stuck programming in C# and VB.NET (which both are incredibly easy to learn if you already know C++ and/or Java). I do miss the days though in college of C++, Java, and C programming ... and thus I hope to go back to academia sooner or later.

Good luck with your schooling ... my tip : experiment with everything, don't just do the homework assignment in class, try doing the same assignment in another language ... test out C++, C, Java, Perl, Python, everything ...

Re:When I hear OO ... When I hear Java

[jrockway]

Here's the link for this, BTW:

http://svn.openfoundry.org/pugs/perl5/PIL2JS/

Re:When I hear OO ... When I hear Java

[Doctor Memory]

Gee, VB's changed since VB5 (when I gave up on it). Who'da thunkit?

Re:When I hear OO ... When I hear Java

[mdielmann]

Sorry about the tone of that reply, I shouldn't have assumed that you had used VB as recently as I had. I didn't use VB5, but I did hear some pretty ugly things about it.

Re:When I hear OO ... When I hear Java

[zootm]

Java's performance isn't "poor" — as is frequently pointed out on this site, this is largely an outdated myth. As for not truly open source, it's a definate issue, yes, although there is open implementations.

Re:When I hear OO ... When I hear Java

[dgatwood]

Perl code can be readable, but usually resembles line noise.... The mere fact that it is possible to write readable perl code does not negate the fact that by design, the language lends itself to unreadable code.

In a similar way, you can write poorly-performing code in any language, but I can't think of any language that has such a high percentage of slow programs. I know that various folks have proven that it is possible to write software that performs reasonably well in Java. However, the sheer number of dog slow Java apps I've used over the years does suggest that there is something inherently wrong with either Java or the design patterns that its use encourages. Whether the problem is a sociological one or a technological one, the blame still lies with Java, IMHO. Thus, while it isn't purely true that Java is slow, it is an accurate characterization more often than not.

My cynical suspicion is that the whole "Java is slow" mentality, coupled with the whole "let the language do all the nasty stuff for me and protect me from myself" mentality has led to a whole generation of lazy programmers who won't spend the time to optimize their code, instead choosing to blame the language. Couple that with people using the wrong level of abstraction to do the job (e.g. passing around a dozen bool values for flags when a single flag integer is more efficient, passing strings around where a single-byte tokenization would be sufficient, etc.) and you get a slow mess.

In a rather ironic twist, Java's simplicity---the representation of everything as a class, lack of pointers, etc.---has led to some really spectacularly bad code---not because it is impossible to write good code, but because C's crudeness often forced you to write good code or crash....

Re:When I hear OO ... When I hear Java

[zootm]

That's not the issue though — the issue was that there's just a stigma around Java now because it was slow in the past (due to a less refined implementation) and because its desktop APIs are generally terrible so desktop apps written in Java tend to be clunky and slow. If you used Java apps a while ago, or Java desktop apps, to gain your opinion of it being slow, you're damned right. But Java itself is not slow.

My cynical suspicion is that the whole "Java is slow" mentality, coupled with the whole "let the language do all the nasty stuff for me and protect me from myself" mentality has led to a whole generation of lazy programmers who won't spend the time to optimize their code, instead choosing to blame the language.

I'm always surprised with how much weight people put on optimisation. Generally I find that a few days with a profiler will find any serious bottlenecks, and otherwise a well-written system will be fairly performant anyway. Over-optimisation is as dangerous as anything else, and rarely yields positive results.

C's crudeness often forced you to write good code or crash....

"Good" code is subjective in this context — I've seen a lot of incredibly poorly-written C code which is that way just because "it didn't work" and was hacked until it did. While its true that generally it's easier to get going with a language like Java (well, other than the verbose nature of the OO implementation), I don't think that this "lower entry requirement" leads to poorer code in general. That's just my positive view though, I realise that a great number of PHP apps are evidence to the contrary here ;).

But yes, Java ends up being slow in desktop apps, a lot of the time. In general, however, as Java implementations get better, even older apps will improve with it.

Re:When I hear OO ... When I hear Java

[panaceaa]

I believe the way native methods are specified in geniously elegant. It uses the native keyword for its designed use -- to specify that there's a method with an implementation in the interpreter's native language. In the case of GWT, that's Javascript. And instead of extracting the Javascript implementations to an external file where dependencies must be mapped through convention or configuration, the /*-{ ... }-*/ block provides a clean way to put the native methods right into their class. The big problem with GWT is it's difficult integration with existing codebases (it doesn't play that well with others). But the overall syntax of class file definitions is brilliant.

Re:When I hear OO ... When I hear Java

[NaDrew]

What do you think when you hear "Code Generator?"

I think about cake, but then I'm a bit odd.

No...

[Anonymous Coward]

...because I can't program :-)

34

Google takes more ground...

[utopianfiat]

I, for one, welcome our weather-reporting overlords.

Re:Google takes more ground...

[spacedsteve]

I for one welcome ...ohh wait no I dont. I like html. web 1.0. non of that fancy stuff. you can stick all that ajax balony where the css dont shine.

Mingling of server and client code is "unusual"?

[xxxJonBoyxxx]

"The GWT takes an unusual approach to Web application development. Rather than employing the normal separation of client-side and server-side codebases, GWT provides a Java API that lets you create component-based GUIs and then compile them for display in the user's Web browser."

I think that's how ASP.NET components have worked for years too. So, I wouldn't say that it's unusual unless you're coming from a completely "my text editor is my development environment" world.

Does it have an "I'm feeling lucky" feature?

[purpledinoz]

Does it have a "I'm feeling lucky" feature, where it will deploy your project for the first time without bugs?

Re:Does it have an "I'm feeling lucky" feature?

[moochfish]

Sometimes.

Othertimes your computer might explode, your hard drive might vaporize, or your program might erase itself.

google web server? gwis?

[Wikipedia]

HELLO WORLD
94732 94732
HELLO WORLD
1D9BA67D23125E86CB9C2766A10181239F1CA5837518E57308 3EBFB33F2246EB
701EF312163B68F68B8A2B495DFDBF7B10723415C482D8A9EB 897A74180D41D4
5AA2D6C72FD377A6595210A184A4FEE0C5A624386CAF068889 338E1479AB03DC
3070EFA41430C2BAB39CA4F4976EDAE9481C4C868233DC0434 7535C51E66D577
K-BYE

Short answer: No.

[xxxJonBoyxxx]

GWT does have a couple of fairly significant flaws. First among them is its lack of provision for graceful degradation. Best practice in modern Web application development is to create pages that work without JavaScript, and then use it where available to embellish and add extra behavior. In GWT, if JavaScript isn't available, you won't get any UI at all.

In other words, if you want to make sure your site "just works", GWT isn't a good technology to use. If your management team is paying attention, that should pretty much stick a fork in this technology.

Re:Short answer: No.

[purpledinoz]

I think this would be useful in developing internal corporate web-apps, where people don't want to spend a lot of time developing, and where everyone in your company would be using the same web browser (or at least where everyone has access to the same web browser). I use Firefox mostly at work, but I use IE to view the internal corporate website, since some things don't work with Firefox. Actually, now that I think about it, it's really stupid that I have to change browsers to make a website work.

Re:Short answer: No.

[Rombuu]

Sounds perfect for intranet and extranet sites where you get to dictate the browser users may access the site with.

Re:Short answer: No.

[misleb]

I think the policy of graceful degradation has gone way too far when it comes to the web. I think it is just fine to assume a client has Javascript. Javascript is far too valuable when it comes to writing sophisticated web apps to work without it. It multiplies the workload on coders and it dumbs down the applications. And for what? Cell phones with an incomplete web browser? The 1% of users who are too paranoid to allow Javascript? Screw 'em. If they want to cripple their browsing experience, that is their business. Why should everyone else suffer?

Of course, i depends on the application. There are cases (most cases?) when Javascript really does nothing but add "flare" to a site which would otherwise work fine without JS. But then there are some apps which actually leverage JS to work around the significant limitations of HTML/HTTP. The latter is becoming more and more common.

-matthew

Re:Short answer: No.

[morgan_greywolf]

        GWT does have a couple of fairly significant flaws. First among them is its lack of provision for graceful degradation.

In other words, if you want to make sure your site "just works", GWT isn't a good technology to use. If your management team is paying attention, that should pretty much stick a fork in this technology.

Why? You can still do graceful degradation -- Google does this with it's own properties. Turn off Javascript and go visit Google Maps or Gmail. You'll get a 'non-interactive' version of the Web page. They just develop it two different ways, detect JavaScript, and then go to the appropriate version. What's wrong with that? It's a perfectly valid development approach.

Re:Short answer: No.

[big_gibbon]

Disabled users? Blind users? Screw 'em. If they want to be cripples, that is their business. Why should everyone else suffer?

Ever think that it's not always someone's *choice* whether they can use JavaScript enhancements?

P

Re:Short answer: No.

[SashaMan]

Like many slashdot replies, the parent is only thinking from a consumer website point-of-view. A huge market for this technology is corporate web applications where the company can dictate browser support (and "you must have javascript enabled" is a pretty minimal requirement from the corporate application perspective). Company XYZ doesn't care if it's sales quoting app doesn't work in lynx.

Re:Short answer: No.

[Steffan]

I disagree with your assertion. I often use lynx (a text-only browser) to access sites, both internal to my company and externally. Sometimes when you are connected via an SSH connection, console is all you have. It is very annoying to me when sites make use of javascript as the only method of navigating a site, especially when it detracts from normal functionality. It is not that difficult to make a very basic site that allows for at least a minimal level of functionality to a text-based user.

Don't even get me started on *flash* sites...

Re:Short answer: No.

[Opie812]

Disabled users? Blind users? Screw 'em. If they want to be cripples, that is their business. Why should everyone else suffer?

Agreed!!

Re:Short answer: No.

[Rogerio Gatto]

I really think the problem is on screen readers/browser interface. Can't they monitor DOM changes and read the new content, or signal that some part of the page changed and prompt the user if it should be read? I believe that there's enough technology to do that already. If there isn't, it should be built. Javascript and DHTML can be made accessible if screen readers learn how to handle them. I just don't think it's fair to non-disabled users that javascript/DHTML should not be used because screen readers can't read them.

Re:Short answer: No.

[Anonymous Coward]

Blind users? Screw 'em.

While I agree with your overall message I could not get over the irony of mod'ing your comment as 'insightful.' Perhaps if you had written about mute users I would have stayed quiet

Re:Short answer: No.

[Seraphim_72]

Just did this in elinks. If by "graceful degredation" you mean no map and no link to find the map - then yeah, I can still zoom in and out on a blank slate.

Sera

Re:Short answer: No.

[misleb]

I disagree with your assertion. I often use lynx (a text-only browser) to access sites, both internal to my company and externally. Sometimes when you are connected via an SSH connection, console is all you have.

Although I have done this, it was more out of convenience (to find/download a patch or piece of software). I could have just as easily have used my load web browser to find the URL and then use fetch/curl/wget to download it. No big deal. I can't imagine why you need lynx as your primary web browser.

It is not that difficult to make a very basic site that allows for at least a minimal level of functionality to a text-based user.

Depends on the site. I can imagine a site with a lot of content that would be terribly difficult to reformat into a text-friendly version. And for what? The .001% of vistors using text based browsers? The only valid argument against Javascript I've heard concerns disabled users with screen readers and such.

-matthew

Re:Short answer: No.

[aCapitalist]

Disabled users? Blind users? Screw 'em. If they want to be cripples, that is their business. Why should everyone else suffer?

Ever think that it's not always someone's *choice* whether they can use JavaScript enhancements?

They have the choice of not going to the web site. But I guess fascist, nanny-staters would try and outlaw anything that doesn't conform to some lowest common denominator.

Re:Short answer: No.

[angel'o'sphere]

  If your management team is paying attention, that should pretty much stick a fork in this technology.


Not really, we are talking about AJAX web applications not about mere (more interactive?) web pages. A user who needs a rich client, will have the right web browser, e.g. a user in a corporate internet accessing a corporate application that happeens to use AJAX / HTML as front end.

angel'o'sphere

Re:Short answer: No.

[big_gibbon]

Firstly, the two aren't mutually exclusive. It's a very satisfying experience to use JS as it was designed, making a site which works perfectly without using JS at all, then layering over the JS to add gloss and shininess. Progressive enhancement is what it's all about :)

I agree with you about screen readers, to an extent. Screen reader developers are simply not keeping up-to-date with movements in web accessibility. You could argue that this makes sense, since a sizable proportion of sites (probably the majority) are still developed with mid-nineties attitudes towards these issues, so it's more useful to try and make sense of crappy sites. However a browser which properly uses the DOM and takes full advantage of the additional features that many developers are putting in just doesn't exist at the moment.

There's a problem with interface design though. Someone developing a browser which can announce these changes in the DOM has difficult decisions to make. Should they announce every change of a news ticker, interrupting the user reading the site? What if one user action triggers several DOM changes? How can we tell which of these is the valuable content?

I agree though that these questions should be asked, rather than just being ignored as they are at present. Unfortunately there's still plenty of users stuck with JAWS etc who need a usable site.

Re:Short answer: No.

[freemywrld]

You could always snag the IE Tab extention for FF. Saved my sanity when I was doing web design and needed cross-browser compatibility.

Huh?

[r00t]

You haven't seen bad OO code? (maybe YOU'RE the bastard who writes it) You don't know how to write good non-OO code? It exists.

There is an OO equivalent to spaghetti code, and it's fearsome.

Re:Huh?

[neonprimetime]

I think you're confusing yourself ... I didn't say anything to the effect of non-OO code being bad ... or OO code always being good ... basically ... I personally find it much easier to write clean code in an OO language like Java ... than in a semi-OO lanaguage like C or C++ ... With C / C++ there are so many tricks, shortcuts, and multiple ways of doing things that I always end up finding myself writing obfuscated code ... where as in Java, I find myself sticking to a standard format ... where everything looks similar. That said ... I've been around programming long enough (I've even taught, C, c++, and Java courses), so I've seen the good, the bad, and the ugly in all languages.

Re:Huh?

[Anonymous Coward]

Jesus Christ, please try to complete a sentence without ... stopping ... and ... breaking ... it ... up.

Thank you.

Re:Huh?

[hicksw]

You haven't seen bad OO code? ... There is an OO equivalent to spaghetti code, and it's fearsome.

Don't you mean "OO is equivalent to spaghetti code"?

GWT feels like GUI programming

[aymanh]

From a web developer point of view, and as the article states several times, the Google Web Toolkit uses an approach similar to Swing, code written for GWT feels like GUI code more than web code, while I don't have anything against this and I believe it does have audience, I think many would prefer a more web-like approach such as Prototype or the Yahoo UI library.

Re:GWT feels like GUI programming

[stratjakt]

That's because that's what it is.

From TFA: GWT essentially exploits the browser as a run-time environment for lightweight GUI applications, and the result is much closer to what you might develop with Morfik, OpenLaszlo, or even Flash, than to normal Web applications

It seems more suitable for client development in intranet-type situations, rather than for stuff to go on the web at large. GWT is walled off from the traditional web page, it seems, and the article says there's no way to take values out of widgets to use in a form submission.

It's interesting, the company I'm working for finally caught "browser based applications" fever, and this is another possible platform we could use. Of course since we aren't a Java house, we'll end up using ASP.NET.

Re:GWT feels like GUI programming

[jimktrains]

I find it funny that I know alot of people who are trading swing code for HTML-like (XML based, but HTML-like for comparison) GUI design langs like JAXX. I always hate writting GUI code, and JAXX works for me, because it is like HTML and I can jsut type up the form and it makes it. I am just wondering if a good AJAX library would do better for developers than things such as GWT (well, I know it woudl be me and I was jsut wondering if I was a minority).

As if..

[misleb]

Using GWT is far closer to developing with Swing or SWT than the usual experience of Web application development,

As if GUIs in Swing or SWT weren't slow and clunky enough. Now Java developers have a slower and clunkier alternative. Yay!

-matthew

Re:As if..

[An Onerous Coward]

That's a little off-the-mark. It's not saying that your users will suddenly have Swing GUIs running in their browser. It's just saying that writing code for GWT feels an awful lot like writing code for Swing.

Re:As if..

[Jobe_br]

I can't complain about Eclipse or Sun's Studio Creator 2/Netbeans. The former is written in SWT and is damn snappy, the latter is written in Swing and its no slouch, either. And a previous poster's point holds as well: this is still AJAX and Web, just because the API and programming paradigm have resemblances to Swing/SWT, doesn't mean that there's any more resemblance than that.

Re:As if..

[Anonymous Coward]

The former [Eclipse] is written in SWT and is damn snappy

Let me guess, you run Windows, don't you? For those of us on less-optimized platforms, Eclipse can get quite slow. Don't get me wrong...SWT is great (I've developed SWT apps and, compared to Swing and AWT, it rocks), but there is a serious need for someone to pick up IBM's ball and run with in on other platforms. As it is now, I do some of my developing on OS X and some on Windows. If Apple (or someone else) would contribute some OS X optimization work to SWT, I could ditch the PC.

Re:As if..

[misleb]

You're using them on Windows, right? On a Mac, and to a lesser extent Linux, SWT and Swing both suck ass. I refuse to use any Java app unless it uses Cocoa.

Anyway, I didn't mean to imply that GWT was actually like SWT. I just meant that it was an (clunky, IMO) alternative UI tookit

-matthew

Re:As if..

[Jobe_br]

Actually, I use SWT a lot on the Mac. And while it isn't Cocoa, its no slouch, either. I haven't used it much on Linux, but I know of many who do and I haven't heard any complaints in this area from that camp. I agree, though - GWT is definitely not SWT.

Re:As if..

[angel'o'sphere]

On a Mac, and to a lesser extent Linux, SWT and Swing both suck ass. I refuse to use any Java app unless it uses Cocoa.


I disagree.

On my Mac applications like Eclipse (Java IDE written in SWT) look pretty good, and applicagtions like CodeGuide (Java IDE written in Swing) look pretty normal.

I think you need to be a Cocoa Fanboy or java hater to find much diffrences in the look and feel.

All applications I write, are either web applications, or Swing applications on my Mac ... no mac user complained so far about using Java/Swing ;d

angel'o'sphere

Re:As if..

[Anonymous Coward]

pointless reply: the subject was the approach, not the specific libraries

read QT or Cocoa if you prefer, Swing and SWT where used only because we are in Java context here

Re:As if..

[misleb]

On my Mac applications like Eclipse (Java IDE written in SWT) look pretty good, and applicagtions like CodeGuide (Java IDE written in Swing) look pretty normal.

While I haven't used Eclipse proper on my Mac, I have used RadRails (Ecplise based) and it was unusable as far as I am concerned. And I ditched that bloated, ugly piece of crap Azureus not too long ago.

I think you need to be a Cocoa Fanboy or java hater to find much diffrences in the look and feel.

I think you need to be a Java developer to actually like Java UIs. Besides look and feel, there are also OS integration issues with Java apps. For example, I had a heck of a time getting Azureus to load a torrent file when I double clicked on it (the torrent file). I never did get it to work right.

All applications I write, are either web applications, or Swing applications on my Mac ... no mac user complained so far about using Java/Swing ;d

But certainly you've heard many other people such as myself complain about Swing? I know I'm not expressing some fringe opinion here. And I am not a "Cocoa fanboy." Java UIs are notorious for being clunky.

I wonder how many simply aren't using your applications because they use Swing. I usually don't waste my time complaining to developers about their choice in tools. (unless it is slashdot where such is the norm) I either just don't use the applications or I suffer through them because it is something I absolutely need. Fortunately the latter is quite rare. OS X has enough native software available that there is usually a native Cocoa alternative. Same with Linux, strangely enough.

-matthew

Re:As if..

[misleb]

Somehow Java developers seem to be immune to the awefulness that is SWT/Swing. Maybe they spend so much time using the Java developer tools that they just don't notice (or care) anymore. Ever notice how almost all of the examples of "great" Java UIs are developer tools? Anytime I bring my distaste for Java UI's, Java apologists inevitably mention Ecplipse and Netbeans... and maybe Azureus, but then they concede that Azureus is a pretty clunky.

Anyway, I've complained enough. I'll just leave you with a quote that I think sums up my feelings: "Saying Java is good because it works on all platforms is like saying anal sex is good because it works on all genders."

-matthew

Re:As if..

[Jobe_br]

Java apologist? Listen, every language has its place. Ruby is an excellent script language, so is Python and Perl. C# is a rich language that simplifies development on Windows and qualifies as a RAD language in Visual Studio. Java is a good OO language, with compatible runtimes on practically every platform. It also has a rich developer community and a number of sophisticated frameworks, APIs, and specifications (J2EE, J2ME, etc.) that help businesses get rich applications developed quickly, consistently, and reliably. Many of the platform runtimes feature JIT-C, so platform independence performance penalties are minimized. Its not perfect, hardly any language out there is (Lisp is pretty darn close, though).

Anyhow, well written apps in any language will rock, whereas poorly written apps will suck. I've used all too many poorly written native Windows/Linux/MacOS apps to know that. I think Swing/SWT have plenty of well-written apps other than IDEs, like the Swinglabs demo at JavaOne 2006: Aerith (https://aerith.dev.java.net/) and LimeWire (http://www.limewire.com/english/content/home.shtm l) - not as clunky as Azureus.

Re:As if..

[misleb]

Java apologist? Listen, every language has its place. Ruby is an excellent script language,

Yes, a Java apologist. I use Ruby a lot and the major complaint about Ruby is that the interpreter is slow. And I accept that. I don't appoligize for it. I don't go around saying "anyone can write a slow script..." It is slow. I deal with it. A Java apoligist, on the other hand, when faced with claims that Java UIs are generally somewhat clunky, inconsistent (with the OS), and slow compared to native apps say things like:

Anyhow, well written apps in any language will rock, whereas poorly written apps will suck.

Must be a lot of sucky Java programmers out there. Where are the good Java programmers spending their time? Do they all work on the awesome IDEs so the poor programmers can churn out clunky applicaitons for us users?

I think Swing/SWT have plenty of well-written apps other than IDEs, like the Swinglabs demo at JavaOne 2006: Aerith (https://aerith.dev.java.net/)

Sorry, no use for it.

and LimeWire (http://www.limewire.com/english/content/home.shtm l) - not as clunky as Azureus.

Wow, Limewire. Is that still around?

-matthew

Re:As if..

[Jobe_br]

Actually, most Java application developers work on business applications that never see the light of the public day. And I would disagree, again - well written Ruby can certainly be fast, if you're using Ruby in the right way. Of course, you wouldn't use Ruby to write the firmware for a cell phone, would you? No, didn't think so. You might use C, or you might drop to Assembler, and hey - that's appropriate for that use. I don't agree with the camp of folks that need to pit languages against each other and have one come out on top. Even languages like VB have their place, that's why folks use 'em and companies support 'em.

Re:As if..

[misleb]

Actually, most Java application developers work on business applications that never see the light of the public day.

And don't you think there migth be a reason for this? Portability doesn't matter to most users. Most users are not willing to sacrafice OS integration and OS consistency for portability. For example, given a native Cocoa app and a Swing app which do about the same thing and are both resonably well designed, I can guarantee you most users will go with the native app. Businesses, however, often don't care if an interface is a little clunky. Just so long as it gets the job done.

And I would disagree, again - well written Ruby can certainly be fast, if you're using Ruby in the right way.

No, the ruby interpreter is measurably slower than other scripting languages. That much is a fact. Ruby can be "fast enough" for many uses, but it does have a certain disadvantage.

Of course, you wouldn't use Ruby to write the firmware for a cell phone, would you? No, didn't think so. You might use C, or you might drop to Assembler, and hey - that's appropriate for that use.

Likewise, I probably wouldn't try to write a complex GUI in Java Swing either unless portability was important.

I don't agree with the camp of folks that need to pit languages against each other and have one come out on top.

Good. I'm not in that camp.

-matthew

Re:As if..

[Jobe_br]

Actually, most businesses don't care about portability either. They probably care more about ease of development, adequate tools and frameworks, and time to deployment. Most of the apps I've seen deploy to Windows.

If its OS integration you're most concerned with, you'll be happy to hear that Mustang is taking numerous steps in that direction (systray, integration with native app handlers (mail, browse, etc.))

And personally, if I were doing a complex app, I'd probably do it in the language that has the most mindshare and the most deveopers, Java - last I heard. I certainly wouldn't use C++ (or C#).

Feeling Inadequate

[ruben.gutierrez]

I had to stop after the third line... "Level: Advanced"

we just weren't right for each other

[revery]

I mean, I tried to make it work, but I couldn't ever get her to give me a callback...

Re:we just weren't right for each other

[Intron]

You wanted to server, but you found out you were just a client.

Re:Mingling of server and client code is "unusual"

[hey!]

I think that's how ASP.NET components have worked for years too.

Not to mention EchoPoint.

It's a good idea, but the devil is in the details.

App developers are overwhelmed with details they have to manage. And we all know that the essence of good design is not having to worry about details until the appropriate time. The flip side is when you do focus on some other details you'd been ignoring up to this point, you don't want to have to worry about details you've already taken care of.

So, the idea is that programmers should be able to program with your framework without worrying that they are doing something web based. That's good. But the flip side of that is that designers should be able to design without worrying about the fact the programmers are using your framework.

The problem with past attempts at this paradigm fall short of ideal because they enforce non-standard or proprietary ways of doing things. They may be good enough, but they could be improved on.

Re:Mingling of server and client code is "unusual"

[Anonymous Coward]

The main difference is that ASP.NET generates the HTML/Javascript at runtime, whereas GWT compiles Javascript applications beforehand. So performance on the server is not affected by Java at all -- seems like a good use of a managed language.

I'm working on a project that exposes a similar code design environment to GWT, but does so in managed .NET code on the server at runtime, generating rich client side widgets and managing the client-server communication. It's sort of like a cross between GWT and ASP.NET, I like it because it gives you the full stack of language functionality, and server functionality when you want it, rather than restricting what available libraries you can use when you're writing your code.

The project is GPL'd, and the website is www.emergetk.com if you're interested.

--ben

haxe

[ncannasse]

There's been several JS code generators recently. Apart from GWT there's also haXe which is more ambitious. haXe can also be used on the Server Side and includes some facilities for Dynamic programming (whereas Java is strongly typed 100% of the time).

Re:haxe

[mrchaotica]

...facilities for Dynamic programming (whereas Java is strongly typed 100% of the time).

What, are generics (in Java 5) not good enough?

Re:haxe

[ncannasse]

Far from being enough. Having structural signatures, first-class functions and method closures are big plus. Watch the haXe Language Reference for more infos. Also, I was not talking about "Dynamic" as reusable but as dynamicly typed.

Re:haxe

[larry_larry]

> Java is strongly typed 100% of the time

With Jython or Groovy you've essentially got dynamically typed Java.

Re:haxe

[Anonymous Coward]

http://haxe.org/api/js/lib

This is the entire haXe javascript API?

Needs more time in the oven. I can do more with mochikit.

Re:haxe

[ncannasse]

Yes but having dynamic typing 100% of the time or static typing 100% of the time is maybe not the best. While typing helps for general application architectures, there are times (like when accessing the HTML DOM) when you simply want to turn it off locally or it becomes a bother.

Re:haxe

[aCapitalist]

Agree, that's why I like languages like Boo that uses type inference most of the time, but you also have the option of using duck typing.

Accessibility?

[metamatic]

Also, what's the state of the art in screen readers? Do they have sufficient JavaScript support? (*)

If not, using GWT for a corporate web site is just a lawsuit waiting to happen.

(*) This is not an idle question, I'm sincerely interested in real answers and pointers to software.

Re:Accessibility?

[xxxJonBoyxxx]

If I had mod points today, I'd boost you up. If you go by the ADA provisions*, I think you need to provide enough content in plain old HTML code and text (Javascript doesn't count) so that all the content is available inline and enough links, text boxes and other items (also in plain old HTML code) so that someone can navigate your entire site without any Javascript.

*Section 508 Standards for Electronic and Information Technology;
SubSection 1194

Re:Accessibility?

[NutscrapeSucks]

Well, I'm glad that someone finally provided a reference to this claim that Javascript is somehow prohibited by the ADA. But you have completely misreprsented what the regulations state -- there is NOT a prohibition on javascript navigation:

When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.

So, basically your script navigation has to provide text labels or alt tags, which they nearly always do.

Re:Accessibility?

[wavedeform]

How do loathsome Flash sites get around this? They must run into the same issue, no?

Re:Accessibility?

[metamatic]

You've kinda missed the point of my question.

I don't want to provide the bare minimum legally mandated accessibility. I want to provide actual accessibility, so real people with real special needs software can access my sites.

So I'm not really interested in what the law says, I'm more interested in what the actual software out there can do.

Re:Accessibility?

[NutscrapeSucks]

I'm more interested in what the actual software out there can do

Actually, me too -- I'd love to get a testing copy of a screen reader. I'm just reacting to the assertation which gets floated here that "works in Lynx" is somehow legally requried.

Re:Accessibility?

[POWRSURG]

Yes well, the courts have previously ruled that ADA does not apply to the web. Sure, there are other laws out there that cover similar topics, but not the ADA.

Re:Accessibility?

[bkocik]

One of my colleagues at AOL has developed a solution that enables AJAX applications to work with the JAWS screen reader. With it, JAWS detects and reads parts of the page that are updated dynamically with an XMLHttpRequest, or really with any other DOM update -- it's not just limited to AJAX stuff. It's done with standard (but really clever) JavaScript.

He's working right now to figure out how to get it out to the world. Once it's made available, I'm not sure where it will be announced. If you'd like, feel free to fire me an email at "bkocik at gmail dot com" and I'll be happy to let you know once it's ready.

YAHOO UI Toolkit

[Foofoobar]

We've already got an MVC LAMP architecture here at work and I have limited Javascript development until the framework was further along. But now the designers are getting edgy because I won't let them incorporate Javascript.

My issue was that I wanted a unified javascript library so we didn't have redundant code snippets all over the place and some way to standardize the development. So after a little searching, I found the Yahoo UI toolkit that is still in beta. It's a unified javascript library released under a BSD license that has been tested in multiple browsers.

No I have a unified library, tested in multiple browsers and standardized that all I have to do is drop into a directory and hook into the framework.

I know this is probably unrelated but since we were talking about toolkits, I thought this would be handy to mention this as well since it saved us a month of work.

Re:YAHOO UI Toolkit

[Reality Master 101]

Google gets the lion's share of publicity, but there are a lot of AJAX toolkits out there that do a lot of the grunt work. I've been thinking about using some AJAX in a project I'm working on, and Yahoo was definitely one of the ones I'm considering. The "Sajax" one also looks interesting.

My thoughts exactly

[metamatic]

When I saw the announcement I was initially excited... then I saw that the first stage was to write a Java Swing application.

Well, I'm writing a Java Swing application at the moment for non-GWT purposes, and it's a horrible, painful process. I'd rather write raw HTML and JavaScript any day. It's not just a Swing issue; there are still too many things in Java that are way, way more difficult than they ought to be. (Like date and time handling, for instance.)

I really wonder why they built this thing using Java as the source language, when they could have chosen something easy and painless to learn and write like Scheme, Ruby, Python, or even (shudder) BASIC.

Re:My thoughts exactly

[Anonymous Coward]

"DateFormat provides many class methods for obtaining default date/time formatters based on the default or a given locale and a number of formatting styles. The formatting styles include FULL, LONG, MEDIUM, and SHORT. More detail and examples of using these styles are provided in the method descriptions.

DateFormat helps you to format and parse dates for any locale. Your code can be completely independent of the locale conventions for months, days of the week, or even the calendar format: lunar vs. solar."

Re:My thoughts exactly

[Anonymous Coward]

There are still too many things in Java that are way, way more difficult than they ought to be. (Like date and time handling, for instance.)"

If you think date and time handling are difficult you must be totally incompetent. I admit that the date and time handling part of the API isn't great and could use some improvement, but it's still incredibly trivial to use.

"I really wonder why they built this thing using Java as the source language, when they could have chosen something easy and painless to learn and write like Scheme, Ruby, Python, or even (shudder) BASIC."

Is this a joke or are you actually this dense? I know this may be hard to believe, but when you step into the real world of large scale application development, which is the target market for this product, practically no one uses Scheme, Ruby, Python or BASIC. And don't bother giving a couple of bullshit examples of companies who do as the number of enterprises using Java as an application development platform is not even remotely comparable to any of the languages you mention. The only platform that is remotely comparable in this aspect right now is .NET.

I'm sure some dumb ass will come out and say that Google uses Python, however, as always they'll fail to mention that they only use Python for very small internal scripts. Practically everything else, in terms of web development, is deployed with a Java back end; including Gmail, Google Search, Google Maps etc.

Re:My thoughts exactly

[metamatic]

OK, AC smartass, now show us the "simple" code to generate a date in ISO 8601 format given a Calendar object.

Re:My thoughts exactly

[metamatic]

If you think date and time handling are difficult you must be totally incompetent.

OK then, show us the incredibly trivial code to parse an ISO8601 date into a Calendar object, and to turn a Calendar object back into an ISO8601 date. And why not a quick example of printing the current date and time in that format?

I know this may be hard to believe, but when you step into the real world of large scale application development, which is the target market for this product, practically no one uses Scheme, Ruby, Python or BASIC.

Doesn't matter. We're not talking about actually executing any of the code, so whether anyone would be prepared to deploy it in an enterprise is irrelevant. Google are just using the code as a representation language for defining what a web interface should look like. Java may be wonderful for running on a back-end server, but it's totally sub-optimal for describing a UI.

Re:My thoughts exactly

[Anonymous Coward]

ISO 8601 "describes a large number of date/time formats. For example it defines Basic Format, without punctuation, and Extended Format, with punctuation, and it allows elements to be omitted. ... The aim is to simplify the use of ISO 8601 in World Wide Web-related standards, and to avoid the need for the developers and users of these standards to obtain copies of ISO 8601 itself."

Re:My thoughts exactly

[ForumTroll]

I'm not the parent poster however:

Date date = cal.getTime();
SimpleDateFormat dFormat = new SimpleDateFormat("yyyy-MM-dd");
String sDate = dFormat.format(date);

Where cal is the reference to your Calendar object. If that's not exactly the format you want look at the Javadocs for SimpleDateFormat. You can adjust the format accordingly in the above constructor or through the applyPattern method. You can also use the parse method in SimpleDateFormat to parse Date objects from a String. If you then want those Date objects converted to Calendar objects use the setTime(Date) method in Calendar. Hope that helps.

Re:My thoughts exactly

[Anonymous Coward]

Why don't you post your current code so that we can showcase it properly.

Re:My thoughts exactly

[Anonymous Coward]

"OK then, show us the incredibly trivial code to parse an ISO8601 date into a Calendar object, and to turn a Calendar object back into an ISO8601 date. And why not a quick example of printing the current date and time in that format?"

I'm not here to do your homework and someone above has pointed you in the right direction. If you'd look at the API for a few minutes you'd realize that it IS in fact very trivial.

"Java may be wonderful for running on a back-end server, but it's totally sub-optimal for describing a UI."

That's an opinion and nothing more. I personally disagree and obviously a lot of other people, including Google, do too.

Re:My thoughts exactly

[metamatic]

I meant date and time. As in 2005-04-23T12:13:15-0600 or 2004-06-09T14:01:02Z. As in something you need to do all the time when dealing with Atom feeds, for example.

Re:My thoughts exactly

[metamatic]

I'm not here to do your homework blah blah RTFM blather blather...

2005-06-27T12:13:14-0500 and 2003-07-09T06:05:03Z, String to/from Calendar. Show us how utterly trivial it is. Put up or shut up. Arguing "it is because I said so" isn't going to cut it on Slashdot, especially not from an Anonymous Coward.

Re:My thoughts exactly

[ForumTroll]

Then change the format using the SimpleDateFormat constructor or through the applyPattern method. For example, the first format you provided (2005-04-23T12:13:15-0600) could be achieved like this:

SimpleDateFormat dFormat = new SimpleDateFormat("yyyy-MM-dd\'T\'HH:mm:ssZ");

See the SimpleDateFormat Javadocs here for a complete explanation of how it works including the symbols used in the formatting.

Re:My thoughts exactly

[Anonymous Coward]

You're the perfect example of someone who should NOT have a blog. You can't code for shit and yet you feel like your opinions on matters of programming are accurate and valid anyways.

P.S. You can't even parse and format a date... LOL

Re:My thoughts exactly

[metamatic]

I know that. But when you go

dFormat.format(calendar);

in the obvious trivial way it blows up, because you can't apply a SimpleDateFormat to a calendar. Instead you have to extract the TimeZone from the Calendar, apply the TimeZone to the SimpleDateFormat, extract the Date from the Calendar, and finally ask the SimpleDateFormat to format the Date.

And going the other way is similarly ugly. You can't just construct a Calendar from a Date and TimeZone, or even from y/m/d/h/m/s numbers. No, you have to obtain a GregorianCalendar, look up a TimeZone (because 'Z' isn't recognized so you have to convert it to 'GMT'), apply the TimeZone to the Calendar, get a Date from your SimpleDateFormat's parse routine, and pass that to the Calendar.

Of course, I realize that a lot of this is because the original Date API wasn't thought through carefully enough. So they deprecated practically all of it, replaced it with Calendar, and added a way to get a Date in and out of a Calendar. Except the replacement Calendar API hasn't managed to replace everything, and there are simple things like formatting dates that still require the old objects--so you get an ugly mix.

This is the problem with a lot of Java, in fact. Hence 4 different kinds of array, and so on.

In Ruby, it's

d1 = Date.parse("2006-08-05T12:13:14Z")
puts d1.strftime("%Y-%m-%dT%T%z")

That's my benchmark for "trivial".

Re:My thoughts exactly

[ForumTroll]

Ahh, I understand the issue you're having now and I definitely agree that the conversions both ways are really ugly and a pain. If you're able to use a third party API you might want to check out Joda; that is of course, if you haven't already. Cheers.

Re:Mingling of server and client code is "unusual"

[Hoolala]

There are developers who still use VI for Web developments :)

GWT is the heavy favorite to serve as the core for our new webapp.

====

Beaches & Casinos: http://buddytrace.com/

Ahem

[Morosoph]

*Kaffe*

There's not a lot of tolerace for criticism of corporations, is there?
I think that most coders feel the same way.

Why not learn the tools instead

[Anonymous Coward]

Hmm, all the examples in the article look pretty much the same than they were written in JavaScript, but in a more complex way. Why not actually learn the trade. Its easier to fix problems if you're working with the actual code that runs in the browser, not the "meta code".

Re:Why not learn the tools instead

[richdun]

Almost modded up, but hopefully someone else will take care of it for me.

Expanding on parent's point, a lot of problems I see in my short time in web development is that too many people are getting into it not by learning basics (like how to build a well-formed XHTML/HTML document with DTD and such, or how to make an image swap sources onmouseover or whatever) but by diving straight into frameworks. I understand the want (and need, in some case) to make programming of all flavors more non-programmer friendly, but without that base foundation we'll end up with a bunch of forums full of "how do i make it do this" questions that are elementary in nature and, even worse, a bunch of web apps that are riddled with problems in security, UI, or other. There's no harm in asking questions, but when everyone is asking the same question that is answered in chapter 2 of any good HTML book, that's a lot of wasted time.

I'm not saying everyone needs to learn how to build Slashcode from the ground up using only Notepad, Mountain Dew, and a bag of Doritos, but learning the basics first then going to a framework to speed up your work on complex projects would seem like a better option. It will almost always be cheaper and faster to write simple things in the base language, but so many are so fixed on frameworks they wouldn't know how to do that.

Re:Why not learn the tools instead

[Anonymous Coward]

HTML/Javascript developer - Mountain Dew and a bag of Doritos

Java developer - Evian and arugula salad with roquefort dressing

Fortran developer - coffee and ham sandwich on Wonder Bread

XML developer - cyanide

Re:Why not learn the tools instead

[Jobe_br]

Easy answer: because a lot of folks wear different hats in their organization. Its not easy to dive into an area and stay current and still have that be only 15-20% of your day-to-day responsibilities. The reality is, there is a need for developers to be able to create AJAX applications that aren't cobbled together, that can be unit tested with robust testing frameworks, and whose code can be audited, if necessary - and a lot of that just isn't going to happen easily, effectively, or affordably by saying "these folks just need to learn proper JavaScript/XHTML/CSS."

Its about focusing on the business part of your application and relying on a robust framework for the plumbing. In a way, it might be bad practice for a developer in a financial institution to be writing framework/plumbing code (like validation, string manipulation, AJAX RPC, session clustering, etc.) - they should use a robust underlying framework that does this for them, and then just write the business specific logic/configuration/etc. So, "validate this field isn't empty", versus writing code that actually does the check, raises an error, and initiates the appropriate response.

Re:Why not learn the tools instead

[curunir]

Its easier to fix problems if you're working with the actual code that runs in the browser, not the "meta code".

Normally, yes. However, there's one key ability that GWT (and other such frameworks that generate the Javascript layer) give you that you just don't have with the "actual code". Namely, the ability to write unit tests. Javascript has some attempts at a unit testing framework, but everything I've seen falls way short of what you need to write comprehensive tests.

GWT solves this by moving your code into an environment which can be thoroughly unit tested. When you reach a certain level of complexity, unit tests become the only practical way to fix bugs while still being sure that you haven't inadvertantly caused others.

This does beg the question of whether the framework itself is stable and well-tested enough to rely upon, but Google are in a great position to have their code used by a lot of developers who will uncover a lot of the bugs in the framework. As a developer, it's incredibly difficult to find minor platform-specific bugs on platforms other than the ones we develop on. However GWT gets developers from all sorts of platforms working with it. It's much more likely that they will run into platform-specific GWT bugs on their platform than for a developer to uncover platform-specific bugs on a platform other than his/her normal platform.

Creating a single application platform that is easily testible and burying all the platform-dependent web-development hell below that platform, you can create a better developer experience that is more likely to work on every platform available rather than just the 2 or 3 major ones that a web developer or company has time/money to invest in.

Google Map's GWT API 1.1.5

[lenulus]

Hey, this is a bit of a shameless plug for my open source project, but it's on topic to GWT. Speaking to the subject of the post, regarding the utility of GWT, I point to my API and API like it so say there is probably a larger market for GWT than this fellow is speculating, and frankly from my experience with the interface I don't see how he could reasonablely charictarize it as all-or-none (the project google generates is example of how to integrate google GWT into your current HTML using named elements and replacing them....). Features: Fully implemented all the major classes including the new Geocoder and events. Available for download on SourceForge (http://sourceforge.net/projects/gwt/). For anyone interested in helping help please e-mail me (developers, testers, documenters welcome).

In all fairness

[argoff]

In all fairness, untill Sun works out the java problems reguarding their control and non-free implementation, it's simply not worth it for developers to lock themselves in like that.

Re:In all fairness

[toriver]

Bah. Until certain whiners in the OSS community gets off their asses and work on the existing OSS implementations instead of demanding a non-OSS implementation should be opened up, it's simply not worth it debating with them like that.

It's not like GCC was written by AT&T.

Article misses the point a bit?

[Penguin Programmer]

I would never, ever, ever even _think_ of trying to write an Ajax application. I hate javascript way too much for that, and the whole asynchronous web-page dynamicness scares the shit out of me. However, I can stand writing GUI code in Java, and I already have some knowledge of how it works. GWT enables me to write super-cool Ajax websites without worrying a bit about javascript. I think this is the true power of GWT: it enables _application_ developers (rather than web developers) to write nice web applications without learning a whole new skillset. This is a win for developers because we can do cool things without learning a whole new trade, and it's a win for consumers because web apps can be written by skilled application developers instead of photoshop gurus.

Also, just because GWT provides some server-side machinery doesn't mean you have to use it. GWT will happily make asynchronous calls to any old URL, so you can write your backend in PHP or Perl or C or whatever you like. Personally, I've been playing with GWT using PHP/SQLite as my backend (following Juan Hurtado's great tutorial). It works great, and since I'm already comfortable with Java, PHP and SQL, it doesn't require a steep learning curve to create very nice web apps.

That said, I will certainly be taking a deeper look at TFA later and perhaps following its example to learn how to use the Java server-side machinery. Could be interesting.

Re:Article misses the point a bit?

[An Onerous Coward]

Anything in particular about Javascript that draws your ire? Last year, I knew almost nothing of it, and my mind associated it with nothing but ugly, hackish code to deliver ugly, annoying popups and redirect you to malicious websites.

Under duress, I've had to become familiar with it these last few months, and it really does have some impressive capabilities. Try investigating the prototype.js library; lots of things in there that show just how elegant Javascript code can be, especially if you're a Python/Ruby fan.

Re:Article misses the point a bit?

[pkulak]

I've programmed extensivly in Java and JavaScript and I prefer JavaScript + Prototype. There are plenty of advantages of an interpreted language, with the disadvantage of execution speed. By writing JavaScript in Java you get the rigidness of a compiled language with the slowness of an interpreted one... yay!

counter = 0;
rows.each(function(row) {
   counter++;
   row.onclick = function() {
      alert("You clicked on row " + counter);
   };
});

You can't do cool stuff like that in Java (sytax may be a bit off, but you get the idea).

Re:Article misses the point a bit?

[Anonymous Coward]

Actually, you can achieve the exact same thing in Java by using an anonymous inner class. Obviously, the syntax would be different but that is most definitely doable. It would be at the most 2 or 3 lines longer, possibly 2 or 3 lines shorter, depending on your coding style.

Re:Article misses the point a bit?

[Abcd1234]

No, you can't. The only way this would work is if the counter variable was a class variable, which greatly limits the utility of anonymous inner classes. Fundamentally, this is because Java has no concept of lexical closures, something which is at the heart of Javascript. This is a *huge* pain in the ass, IMHO (especially if you're used to LISP, Smalltalk, Perl, Ruby, or even the semi-crippled Python), and makes things like the collection classes far less useful.

'course, if you've grown up in the C++-derived world, you probably have no idea what a closure is, let alone the useful programming constructs it enables, such as higher-order functions.

Re:Article misses the point a bit?

[Abcd1234]

I hate javascript way too much for that

Why? My experience with Javascript is that it's a rather nice merger of object oriented and functional programming methodologies, rivaling Smalltalk in many ways (not the least of which is ubiquity).

Re:Article misses the point a bit?

[Anonymous Coward]

The main reason Javascript sucks has to do with the environment in which it's executed. Browsers really don't implement anything beyond the basics of the language in a consistant manner. If you work with Javascript long enough, you end up finding a seemingly unending list of things that work differently in each browser (or even give you a "feature not implemented" error in IE).

The other reason Javascript sucks is that it's basically stuck at a certain feature set that can't really be changed. There are a number of seriously needed changes that could be made, but even if they were, we couldn't use them since we have to support older browsers. It's really easy to upgrade your own setup, it's much harder to require end users do the same.

Also, Protoype is about as ugly as code gets. If you use Prototype, you can almost guarantee that it will break any third-party code that isn't specifically designed to work with Protoype. Dojo is better, but has some serious performance concerns when it comes to interacting with the DOM. There are a few others out there, but no one has really gotten it right yet.

But most importantly, writing code in Java instead of Javascript allows you to use the much more evolved testing facilities of Java (JSUnit doesn't really cut it, IMHO). Any serious web application needs to have thorough testing at all levels, UI included.

But hey, go ahead and try implementing a serious AJAX web application, it's the only way you can truly appreciate what something like GWT actually gives you...

GWT vs. Echo2

[arigi]

This seems like a useful article. At work we were just discussing the possibilities of using the GWT. Currently we use NextApp's Echo1 and are also pondering upgrading to Echo2. The demo app for Echo2 is actually mighty impressive; I'd say moreso than GWT's. Though I wonder how much of it is just more time spent on fancy graphics as opposed to a better quality framework.

Re:GWT vs. Echo2

[distributed]

The team I used to work for 3 years ago wanted a web gui layer framework similar to this back then.. and i remember Echo 1.x was one of the first ones we prototyped. Then there also was millstone http://www.millstone.org/ And i think echo was also featured on slashdot http://developers.slashdot.org/article.pl?sid=03/0 9/09/2337216
Echo 2.x seems to have now added support for ajax.. a demo is available here: http://demo.nextapp.com/Demo/app ..and it runs smoother than the ajax controls found on flickr atleast. In the end it seemed that the world wasnt ready for this... and higher management didnt like the risk associated with trying something completely new.

I'm confused...

[Anonymous Coward]

Does using Java to write JavaScript make you some sort of super Java ninja?

Re:Mingling of server and client code is "unusual"

[MobyDisk]

The Computer Science terms you are looking for are "coupling" and "cohesion." A good design minimizes coupling and maximizes cohesion.

Why GWT Isn't A Good Framework

[WombatControl]

As a disclaimer, I'm a huge fan of Ruby on Rails, and not at all a fan of Java.

The problem with the GWT and other framworks like it as it ignores the reality that browsers today suck. IE's rendering engine is suckier than Monica Lewinsky holding a Dyson at the event horizon of a black hole. Firefox doesn't quite yet pass Acid2, but is as close to a reference platform as one can get. Safari shows promise, but it has a weak JavaScript environment that doesn't support things like ContentEditable. The whole problem is that the GWT assumes a much more stable platform than actually exists.

The real challenge for web application developers is that there are no frameworks (that I know of) that provide for things like fully semantic code, graceful degradation of capabilities, and full separation of content, behavior, and presentation. (For why that separation is important A List Apart has a great article on the subject.) Not even Ruby on Rails gets this right by default.

GWT tries too hard to abstract the actual code that user agents see from the code the programmers create - and that level of abstraction just doesn't work yet. Just like trying to translate a passage in French to English and Japanese with a machine translator, the GWT tries to take Java code and translate it into a mish-mash of XHTML, CSS, and JavaScript - and the results are as mangled as one would expect.

Until someone comes along with a framework that creates clean, semantic code with full separation of behavior, presentation, and content, web application developers have to be mindful of their code and do a lot by hand. Frameworks can save time, but they also cause a trade-off in terms of code quality and compatibilty. The GWT goes too far in that balance IMHO, and isn't something I'd use to develop public applications. Like ASP.NET, it's too reliant on abstracting XHTML/CSS/JavaScript from what the programmers deal with, and that always leads to bloated masses of code that frustrate users and hog bandwidth.

Re:Why GWT Isn't A Good Framework

[kevin_conaway]

IE's rendering engine is suckier than Monica Lewinsky holding a Dyson at the event horizon of a black hole

Mod -1: Trying too hard.

Seriously though, you say GWT tries to take Java code and translate it into a mish-mash of XHTML, CSS, and JavaScript - and the results are as mangled as one would expect. and then go on to say Until someone comes along with a framework that creates clean, semantic code with full separation of behavior, presentation, and content.... Isn't that kind of contradictory? If its spitting out xhtml, css and javascript, that seems like content, presentation, and behavior are all clearly defined.

Re:Why GWT Isn't A Good Framework

[Anonymous Coward]

That's not the point of GWT.

GWT is an attempt, as I see it, to create intranet applications where everyone is expect to be running Safari or the latest build of Firefox.

Re:Why GWT Isn't A Good Framework

[Jobe_br]

OK, ignoring the fact that GWT uses Java as its initiation language (it could use Ruby or C++ or PHP) - I still have to disagree on a number of points.

The problem with the GWT and other framworks like it as it ignores the reality that browsers today suck.

Right, which is why something like GWT is nice because you don't really care that the browser sucks, you write your code and it works. Graceful degradation isn't really an issue in this case ... GWT supports a number of browsers identically (i.e. your code will run identically to the end-user). If you're looking for graceful degradation to plain HTML w/o JS, then that's a bit of a pipe dream, since you're not talking the same application. That's analagous to writing a GUI app (on Windows or OS X or Linux/GTK/Qt) and having it gracefully degrade to a console application. Last I checked, anything that's more than a simple app doesn't do anything like that, and for good reasons. Endless backwards compatibility is a case of diminishing returns and while it may be "nice", it isn't practical or economical.

GWT tries to take Java code and translate it into a mish-mash ... and the results are as mangled as one would expect.

Um, no. The results are a web-application that functions as you would expect. It is unknown if Google Calendar or Google Spreadsheet are using GWT, but according to Google, the pain they experienced writing Google Maps & GMail played a part in developing GWT - so those types of applications are certainly on the drawing board for GWT. I wouldn't call those apps mangled or anything along those lines. They're quite possibly best-of-breed.

I also disagree that Google's approach with GWT:

...always leads to bloated masses of code that frustrate users and hog bandwidth.

On the contrary, I think in reality, hand-coding, by the masses of programmers that cannot be experts at JavaScript and Browser Nuances, has already created bloated masses of code that not only frustrate users & hog bandwidth, but are also difficult to maintain, practically impossible to debug effectively, and a huge drain on an organization's resources. Its time to change that and I think GWT takes steps in the right direction. I haven't heard of masses of users being frustrated by Google Maps, Mail, or Calendar ... at least not because its bloated or hogs bandwidth.

Re:Why GWT Isn't A Good Framework

[jrumney]

That's analagous to writing a GUI app (on Windows or OS X or Linux/GTK/Qt) and having it gracefully degrade to a console application. Last I checked, anything that's more than a simple app doesn't do anything like that, and for good reasons.

Are you suggesting that Emacs is a simple app?

Re:Why GWT Isn't A Good Framework

[Jobe_br]

Nope, but I don't think emacs degrades gracefully. Either I launch console emacs, or I launch the X version of emacs (I know there's XEmacs, but that's not the same as the console emacs, I don't think). And to be fair, even the GUI version of emacs is still pretty heavily a console application. I don't see something like Evolution degrade gracefully to pine or mutt.

Re:Why GWT Isn't A Good Framework

[jole]

"there are no frameworks (that I know of) that provide for things like fully semantic code, graceful degradation of capabilities, and full separation of content, behavior, and presentation"

Millstone UI Librarys base philosophy has been since its launch under LGPL in year 2002 to: (1) Program semantic (logical) users interfaces in Java, (2) Fully separate the presentation and behavior layer, (3) Gracefully adapt to "any" browser/terminal. You can create an user interface in Java and then use it with lynx (plain HTML without JavaScript) as well as with Firefox (or other AJAX capable browser) where the actions does not require changing pages. You can even create adapters for complitely different terminals - there has been prototypes for Swing, WAP, J2ME and Personal Java.

See online AJAX demo in http://demo.itmill.com/AJAX/

Re:Why GWT Isn't A Good Framework

[tbmcmullen]

Mish-mash:

<div onclick="doSomething();" style="background-color: pink; border-top: 1px dashed gray;">
<input type="button" value="Argh" onclick="somethingElse();" />
</div>

The above would be valid XHTML, CSS, and Javascript. But that doesn't mean that there is a full separation of content, presentation, and behaviour. The would be accomplished by... roughly...
Content:

<div id="div1">
<input type="button" value="Argh" id="inp1" />
</div>

Behaviour:

<script type="text/javascript">
window.onload {
document.getElementById('div1').onclick = doSomething;
document.getElementById('inp1').onclick = somethingElse;
}
</script>

Presentation:

div#div1 {
background-color: pink;
border-top: 1px dashed gray;
}

Obviously not a big deal in my horrid example, but when your project starts getting large... It matters.

Re:Why GWT Isn't A Good Framework

[jrumney]

Either I launch console emacs, or I launch the X version of emacs

They're the same binary.

even the GUI version of emacs is still pretty heavily a console application.

How do you figure that? It uses an X window, it has menu bars, a toolbar, tooltips, it displays images. What is it in your mind that differentiates a GUI app from a console app?

Re:Why GWT Isn't A Good Framework

[Jobe_br]

X emacs is a console application augmented for GUI interaction, much the same as an xterm is a console augmented for GUI interaction. That, itself, does not make it a GUI application. X emacs is not Word, or Visual Studio, Eclipse, or iTunes, Keynote or Firefox. Certainly, it can perform some element of all of those applications ... but, it is not a GUI application.

Re:Why GWT Isn't A Good Framework

[jrumney]

Here's a screenshot of your console application augmented for GUI interaction. You might be surprised.

Unobtrusive JavaScript

[booch]

I'd prefer to see a toolkit that provides unobtrusive JavaScript. Basically, you'd tag (with a specific class) the HTML elements that you'd want to act as UI widgets. Then include the JavaScript file, and the JavaScript file does all the work. This provides graceful degradation -- if they don't have JavaScript, they just get the original HTML. And it lets you use all your standard HTML tools, so your designers can still handle all the look and feel, without having to deal with anything besides HTML and CSS.

Why I like YUI

[HotButteredHampster]

The two things I like about the Yahoo! UI toolkit are that:

- it is a la carte
- it represents pretty advanced, human-readable Javascript, which has allowed me to learn advanced Javascript techniques

The first, a la carte, means that the entire web application does not need to be dedicated to YUI. Recently I incorporated a YUI DHTML window (Panel, in YUI-speak) into an existing ASP.NET application. It required only a few lines of Javascript and some HTML. Ditto for another application (JSF, this time), where I added an AJAX data lookup to dynamically populate sample values in a dropdown list. I love the DOM and Event libraries: they really clean up the cruddy job of adding small DHTML things to a website, regardless of how it's put together.

The second, that YUI is a learning experience, is also very important to me. I've come late to the DHTML game, and most books and tutorials on Javascript deal with the basics, and stuff like OO programming is either glossed over or omitted entirely. However, Javascript is a language that is suited to OO programming in a unique way, IMHO. By studing how the YUI toolkit works and seeing what Javascript is capable of, it has opened the doors for new ways of tackling problems and reducing the number of lines of JS code I write.

HBH

Re:Why I like YUI

[schon]

I agree with everything you said, but there is one thing about YUI that bugs me: having to include a dozen (or so) separate .js files to make it work.

I wish it was just a single library, rather than one file for each function (which really isn't, because every function I've used doesn't work unless all of the other files are included as well, even if I'm not explicitly using them.)

Re:Why I like YUI

[Anonymous Coward]

have you thought about perhaps...putting the content of the dozen files into one file?

Re:Why I like YUI

[HotButteredHampster]

Since it is all source, you could place all of the code in a single .js file (in the right order), and then just include that. However, when you pick and choose what parts you want to use, you may not need everything. If you're using Panels or the Calendar along with the AJAX stuff, yes, it's pretty likely you'll need it all. But if you just want to use the Event or DOM libraries you only need yahoo.js, event.js and dom.js. I can handle three script tags in my HTML in return for practically cleaning out all of the hand-coded browser-sensitive Javascript. ;-)

I think this came up once or twice on the yui mailing list.

HBH

Re:Mingling of server and client code is "unusual"

[Alexandra Erenhart]

Now I understand why computer science geeks don't "couple". They have a whole different meaning of the word from the rest of the world ;)

XML11 looks more promising

[sproketboy]

Uses java byte code instead of source so it's more stable. http://video.google.com/videoplay?docid=-317158218 7051229467

Re:XML11 looks more promising

[Anonymous Coward]

This does appear to be an all-encompassing solution (XML11) and I'd like to thank you for pointing it out; I never really imagined this sort of portability from Java to JavaScript existed, but it appears it is being done, and done quite well in what is most certainly a spiffy manner.

The amazing part about XML11 is the fact that it is entirely possible to leave all processing logic at the server, while the JS interface simply handles user interaction. In this way, it seems to have the upper hand versus JSP or the likes, just because of the real-time interactivity, which is handled in a fashion very similar to JSP.

XML11 should prove invaluable in my upcoming project, which is more or less your standard database-manipulating setup. Users will be editing a large collection of properties at once, some people possibly editing the same options at once -- using XML11, I should be able to prevent the evils that might occur if it was simply a static HTML page that you POST. This way, people can be aware of who else is editing things real-time, and I can keep database manipulation on the server, rather than contriving some middle step for an applet on the client.

Thanks again!

full separation

[airdrummer]

is terence parr's mantra: http://www.cs.usfca.edu/~parrt/papers/mvc.template s.pdf

i've used his http://stringtemplate.org/ in a webapp with pretty good results...even if stringtemplating is itself a form of programming, at least it keeps java out of html:-)

application development, web interface

[radarsat1]

Interesting, I'm not really a web developer except for a bit of custom javascript DHTML stuff I've done.
(Yes, most of my web experience comes from the days when it was just called DHTML..)

This is the first time I've peeked into a platform like this... it's really interesting how close it is to writing a GUI application, like in SWT or something. (Again, I've only done a little bit of SWT, since I don't prefer Java most of the time, but it definitely has its place.)

But I find it amazing how it seems totally incidental that it happens to use the web for rendering its interface. What it really makes me think of is the possibility of writing multiple back-ends for it. Imagine using it to write applications that can compile to both a GUI environment, using native Win32/GTK/Cocoa elements, and then also be able to easily re-compile to a web application. Not sure there'd be any point to that, come to think of it, but the idea sounds cool for some reason. ;-)

Or imagine writing an application which is totally local, but happens to use a browser for its interface. It could embed a mini HTTP server in it.. well, I know this has been done before, but this is the first time I've seen an API that actually makes the idea somewhat attractive to me. It would solve the multiplatform GUI problem by just using whatever browser the user happens to prefer.

Anyways, now if only I could use GWT from Python instead of Java.. ;-)
(Same goes for SWT by the way.. the PySWT project isn't very useful yet. Sigh..)

Google Web ...

[kompiluj]

Did you say "Google Web Rootkit"?

minus 2, Troll)

[Anonymous Coward]

and executes a shout the loudest Smells worse 7han a e8emplified by

GWT Analysis

[JChrisP82]

A competing framework Thinwire[www.thinwire.com] has another analysis of GWT.
http://www.thinwire.com/thinwire_vs_gwt.html

Re:Mingling of server and client code is "unusual"

[Randolpho]

Couplin done right results in cohesion.

Sticky, sticky cohesion. :D

Re:Mingling of server and client code is "unusual"

[Alexandra Erenhart]

Yay for cohesion! Too bad you require to couple first. That's the hard part.

My sincere apologies

[Anonymous Coward]

I ... will ... try ... to ... remember ... that ... next ... time.

Short answer: Yes

[aCapitalist]

In other words, if you want to make sure your site "just works", GWT isn't a good technology to use. If your management team is paying attention, that should pretty much stick a fork in this technology.

If it's an inhouse app, then there should be no problem. If it's an "app" that's for the public then there should be no problem. If it's a "web site" where the desired goal is to try and be compatible with every possible browser, then the answer is no or serve up different pages upon client detection.

The bottom line is that we live in our browsers so much, that it's very appealing to try and expand the functionality of what can be done on a web page. We'll only see "richer" web pages in the future.

Nope!

[Anonymous Coward]

That feature leaves you in an endless beta :-)

Re:Mingling of server and client code is "unusual"

[Randolpho]

No, that's the *fun* part.

Well, ok, done right, coupling requires a hard part. :D

AJAX

[mwvdlee]

What I don't get is this: Isn't AJAX supposed to require enabling ActiveX support on MSIE browsers? And isn't ActiveX notoriously hacker-friendly? If so then why would anybody want to develop using AJAX?

Re:Mingling of server and client code is "unusual"

[manthrax3]

ASP.NET does not natively do what GWT does. In GWT, you write code in Java and it is converted into JavaScript for the client side. Yes, every AJAX applications will still rely on servlets and yes many of your pages will be rendered on the server: this is where it's similar to ASP.NET. The key is that you don't have to write ANY code in JavaScript unless you need functionality outside the GWT. In fact, they have a very neat interface for "native" JavaScript as well.

In ASP.NET you have to write all your JavaScript in.. well, JavaScript or JScript as MS calls it, which is probably a better name anyway since JavaScript and Java have not very much in common.

GWT is new.

It is a great idea, and it's already been copied in the MS environment, which is good.

GWT Interview

[BigTimOBrien]

Here's an interview with someone in the middle of integrating Google Web Toolkit (GWT) with a Spring MVC application. In the interview Michael Podrazik provides some insight and tips for people interested in starting out with GWT.

Re:Mingling of server and client code is "unusual"

[garaged]

I actually am one of them, and I'm quite productive, I can code way faster than a lot of dreamwaver users I know, and I'm not even an CS graduate or anything related

VI rules, thank you very much