Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×

Is the Google Web Toolkit Right For You? 163

Posted by CmdrTaco from the sure-why-not dept.
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? More

Is the Google Web Toolkit Right For You?

Comments Filter:

  • Google takes more ground... (Score:5, Funny)

    by utopianfiat ( 774016 ) on Wednesday June 28, 2006 @10:46AM (#15621014) Journal
    I, for one, welcome our weather-reporting overlords.
    • 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?

  • Mingling of server and client code is "unusual"? (Score:5, Insightful)

    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.

  • Does it have an "I'm feeling lucky" feature? (Score:5, Funny)

    by purpledinoz ( 573045 ) on Wednesday June 28, 2006 @10:49AM (#15621050)
    Does it have a "I'm feeling lucky" feature, where it will deploy your project for the first time without bugs?

  • Short answer: No. (Score:3, Informative)

    by xxxJonBoyxxx ( 565205 ) on Wednesday June 28, 2006 @10:53AM (#15621095)
    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.

    • Accessibility? (Score:5, Interesting)

      by metamatic ( 202216 ) on Wednesday June 28, 2006 @11:12AM (#15621247) Homepage Journal
      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? (Score:5, Informative)

        by xxxJonBoyxxx ( 565205 ) on Wednesday June 28, 2006 @11:24AM (#15621354)
        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
        • 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 l

          • 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.
            • 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.
      • How do loathsome Flash sites get around this? They must run into the same issue, no?
    • Sounds perfect for intranet and extranet sites where you get to dictate the browser users may access the site with.

    • Re:Short answer: No. (Score:2, Interesting)

      by misleb ( 129952 )
      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 thei

      • Re:Short answer: No. (Score:4, Insightful)

        by big_gibbon ( 530793 ) <slashdot.philevans@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
        • 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 read
          • 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 ma
        • 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. (Score:4, Insightful)

        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...

        • 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

    • 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 'n

    • Re:Short answer: No. (Score:2, Insightful)

      by SashaMan ( 263632 )
      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.
    • 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 bo

    •   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
  • I had to stop after the third line... "Level: Advanced"
  • I mean, I tried to make it work, but I couldn't ever get her to give me a callback...

  • haxe (Score:3, Interesting)

    by ncannasse ( 976609 ) on Wednesday June 28, 2006 @11:10AM (#15621226)
    There's been several JS code generators recently. Apart from GWT there's also haXe [haxe.org] 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).
    • ...facilities for Dynamic programming (whereas Java is strongly typed 100% of the time).

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

  • YAHOO UI Toolkit (Score:5, Interesting)

    by Foofoobar ( 318279 ) on Wednesday June 28, 2006 @11:15AM (#15621280)
    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.
    • Google gets the lion's share of publicity, but there are a lot of AJAX toolkits [ajaxlistings.com] 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.

  • Why not learn the tools instead (Score:5, Insightful)

    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".

    • Re:Why not learn the tools instead (Score:5, Insightful)

      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.

    • 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 "t

    • 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 co

  • Article misses the point a bit? (Score:5, Informative)

    by Penguin Programmer ( 241752 ) on Wednesday June 28, 2006 @11:45AM (#15621548) Homepage
    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 [googlepages.com]). 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.
    • 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 Pyth
    • 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).

  • GWT vs. Echo2 (Score:3, Interesting)

    by arigi ( 932824 ) on Wednesday June 28, 2006 @11:47AM (#15621560)
    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 [nextapp.com]. 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.

  • Why GWT Isn't A Good Framework (Score:4, Interesting)

    by WombatControl ( 74685 ) on Wednesday June 28, 2006 @11:58AM (#15621626)

    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 [alistapart.com].) 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 (Score:4, Insightful)

      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.

    • Re:Why GWT Isn't A Good Framework (Score:4, Insightful)

      by Jobe_br ( 27348 ) <bdruth.gmail@com> 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.

  • I'd prefer to see a toolkit that provides unobtrusive JavaScript [adactio.com]. 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.
  • Uses java byte code instead of source so it's more stable. http://video.google.com/videoplay?docid=-317158218 7051229467 [google.com]
  • 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

  • Google Web ... (Score:3, Funny)

    by kompiluj ( 677438 ) on Wednesday June 28, 2006 @02:09PM (#15622761)
    Did you say "Google Web Rootkit"?

Slashdot Top Deals

"If it ain't broke, don't fix it." - Bert Lantz

Close