Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×

Is the Google Web Toolkit Right For You? 163

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."
This discussion has been archived. No new comments can be posted.

Is the Google Web Toolkit Right For You?

Comments Filter:
  • by xxxJonBoyxxx ( 565205 ) on Wednesday June 28, 2006 @10:47AM (#15621025)
    "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.

  • by Serapth ( 643581 ) on Wednesday June 28, 2006 @10:56AM (#15621118)
    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.
  • by Doctor Memory ( 6336 ) on Wednesday June 28, 2006 @11:09AM (#15621213)
    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...
  • by frantzdb ( 22281 ) on Wednesday June 28, 2006 @11:32AM (#15621441) Homepage
    What do you think when you hear "Code Generator?"

    When I hear "code generator", I think compiler.
  • by Anonymous Coward on Wednesday June 28, 2006 @11:33AM (#15621445)
    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".
  • by richdun ( 672214 ) on Wednesday June 28, 2006 @11:44AM (#15621534)
    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.
  • by morgan_greywolf ( 835522 ) on Wednesday June 28, 2006 @11:45AM (#15621543) Homepage Journal


            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.

  • by big_gibbon ( 530793 ) <slashdot AT philevans DOT com> on Wednesday June 28, 2006 @11:59AM (#15621633) Homepage
    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
  • by kevin_conaway ( 585204 ) on Wednesday June 28, 2006 @12:51PM (#15622058) Homepage
    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.

  • by SashaMan ( 263632 ) on Wednesday June 28, 2006 @12:53PM (#15622074)
    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.
  • by Steffan ( 126616 ) on Wednesday June 28, 2006 @01:02PM (#15622144)
    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...
  • by Rogerio Gatto ( 967932 ) on Wednesday June 28, 2006 @01:51PM (#15622590)
    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.
  • by Jobe_br ( 27348 ) <bdruth@gmail . c om> on Wednesday June 28, 2006 @03:50PM (#15623474)

    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.

If God had not given us sticky tape, it would have been necessary to invent it.

Working...