Discussions

News: Opinion: Will Google Web Toolkit Matter?

  1. Opinion: Will Google Web Toolkit Matter? (35 messages)

    Editor's note: Mr. Kabanov submitted this to TSS' news queue in its entirety. The original post is available at "Will Google Web Toolkit Matter?" from the Aranea Blog. Edits were only for formatting purposes. Google Web Toolkit has captured the minds of many a web programmer around the globe with its promise to make AJAX web development easy. But how well does it deliver, and, more importantly, how much do we need that? First of all a disclaimer -- I find the Google Web Toolkit (GWT) sexy both as a developer and a framework architect. It's a great piece of software, made by very talented people. The trouble is that sex appeal matters little in the field of enterprise software development. I mean custom-made software that has hundreds or thousands of use cases with complex interconnected business and GUI logic. This is the software that matters to the most of the programmers out there, as it is responsible for the most of the job places. And this is the kind of web application development I am going to talk about. Let's begin by summing up the innovation that GWT brought to the (Java) web development community:
    • A Java-To-Javascript compiler with a java.lang API implementation -- although the idea is great it is not exactly a new one. At least one more project (J2S) provides similar features and in fact provides a more advanced JavaScript generation facilities.
    • A widget library that allows building UI without HTML. There are several similar efforts including Dojo, and the same J2S/RIA. Additionally there are several server-side frameworks that aim to provide the same functionality (e.g. Echo2, wingS)
    • An RPC-over-HTTP implementation, which was available among others via DWR.
    • A container that allows debugging the application in Java. J2S doesn't really need it as it translates SWT/RCP code, which runs natively as a desktop application.
    • Project kickoff scripts inspired by (or at least similar to) Ruby on Rails.
    So Google basically went to this enormous trouble to reimplement all those available projects. Of course one can argue that they implemented a better designed, better working and better documented code (which frequently makes the difference between a successful and a failing project). But why didn't they join the Eclipse project like countless others and lead the RCP/RIA stack? My answer to this question is simple enough -- Google wanted to solve their own problems. To understand GWT we need to understand Google motives in creating it. Google does not make business software -- they make desktop software and put it on the web (e.g. GMail, Base, Spreadsheet, Calendar, etc). Such software has relatively few use cases, which usually are complex and must be very responsive. Google needed a way to develop new applications for the web that would be:
    1. Highly responsive
    2. Developed quickly
    3. Sexy :)
    The obstacle to the second goal was that to achieve a highly responsive GUI in web one needs to resort to a lot of hacks, and, what's worse, to different hacks in different browsers. It is this issue that makes the development of an AJAX application cost much more than a usual one. An obvious solution to this problem was to encapsulate the hacks behind a clean interface. A less obvious solution was to also encapsulate it in a statically typed language with a host of IDEs and debuggers and try to avoid JavaScript alltogether in the application itself. So GWT is a perfect solution to quickly develop AJAX desktop-like applications that will run on majority of browsers with considerably less testing. But what about the rest of us (especially those who write large business applications)? My opinion is that it would be a great view technology, if it wasn't based 100% on JavaScript. The problem with HTML and JavaScript is that there are at least 4 large incompatible implementations of the platform in the wild. We are talking about a language having 4 virtual machines that loosely correspond to a hindsight standard -- James Gosling's nightmare come true. One of the main reason web is used so much for business applications is because it delivered on the Java promise to Write Once Run Anywhere (as web platform is much simpler than Java and less dependent on the client environment). And it also gave us the possibility of easy mashup, integration, retrofitting design, etc. But JavaScript makes this promise moot, browsers have:
    • Restrictions on the size of the script
    • Restrictions on the script memory consumption
    • Restrictions on the running time of the script
    • Cross domain access restrictions
    • And a horde of other arbitrary restrictions, bugs and incompatibilities sent by Satan to torture web programmers
    All of this means that you can only encapsulate so much -- sooner or later some more resilient bug will crawl up or you'll need to do more than possible with the standard toolkit and you'll have to resort to JavaScript hacking. In fact I can almost promise that in any sufficiently large and complex application this will be rather sooner than later (and I mean bugs like memory leaks, which are next to impossible to debug on this platform). Indeed, HTML and HTTP were never meant for applications, they were developed to share knowledge among scientists. And although later the dynamic DOM, CSS, XML and other abbreviations were added on top of it they fit almost as well as a saddle on a cow -- one can ride, but one doesn't get very far. Now let's switch for a moment from AJAX to the business applications themselves. A typical large enterprise application has different UI requirements than a typical desktop one. Business application GUIs have large complex workflows, but only small part of them need to be highly responsive (typically some kind of lookup or searching). These requirements are easily satisfied with HTML and a little browser independent JavaScript slapped on. In fact if we examine what business customers want it is the software that:
    • Fits their needs
    • Can be made quickly and for a reasonably price
    • Does not tie them to a single vendor or partner
    • Can be integrated with other software easily
    It is badly analyzed software that plagues the business world, not the non-AJAX one. And it is high productivity and integration that is first of all needed from a web framework -- perhaps this is one of the reasons why Struts is still so popular (the main being of course tons of legacy code written in it). And AJAX, if anything, makes integration harder and decreases productivity. But does that mean that I am propagating simple web applications forever? Of course, not! I just think that simulating the desktop while depending on Intenet Exporer is something that a business client just can't afford. Make already a normal rich GUI platform and I'll be the first one to get on that train. Get Eclipse RCP polished or compile Java to Adobe Flash (which is at least a stable platform), perhaps even get Avalon to run on Linux. Just give me something that lets me write code in Java and doesn't give me more trouble than web and I'll sign on without another question. So will Google Web Toolkit matter for the next years? I sure hope not, since this would mean that we build our next-generation applications on an intrinsically sabotaged platform. And no matter for my bias, I really want to see a better platform before the end of this decade. Message was edited by: joeo@enigmastation.com

    Threaded Messages (35)

  2. Yeah, it'll matter and continue to matter for as long as people think the benefits outweigh the costs of what is fundamentally a broken platform for RIAs. I wouldn't count on anything changing in any meaningful way on vanilla browsers though as long as IE has a majority market share. And the W3C seems to be bogged down in their own stagnation anyway. The only thing new I see in the near term to be thrown into the mix is WPF/E, which will have Windows, Mac, and Linux clients, as well as the ability to send up XAML/Javascript or .NET bytecode. Adobe seems to have a decent platform with Flash 9 and Flex2, but it would be interesting if someone did write a Java to Flash compiler. And of course there is always webstart and applets. I guess the real complaint by this guy is that the browser sucks as an application platform. I can't really disagree there.
  3. I guess the real complaint by this guy is that the browser sucks as an application platform. I can't really disagree there.
    Actually my real complaint is that browser is fine for business application, just don't start building a full-scale fat client on it. Just because it works for Google doesn't mean it will work for all the rest of us :)
  4. Actually my real complaint is that browser is fine for business application, just don't start building a full-scale fat client on it. Just because it works for Google doesn't mean it will work for all the rest of us :)
    Business applications today are almost unimaginable without rich and snappy UI. HTML/HTTP/JavaScript/DHTML/AJAX/AAST(Any Other Sexy Technology) based UI will never (by definition) be as rich and snappy as native UI with windowing toolkith. Business Applications' UI should communicate with the server by sending and receiving DATA and NOT HTML/JS. So, the option for business applications is Java Web Start, Applets, Click Once.
  5. I do agree with you that the main problem is the HTML platform. But you forgot that another solution already exists: XUL. You have a complete plateform with XUL+XForms+javascript to send web service calls or REST calls with validated values. The difference with XAML is that it really exists! The other big difference is that it is based on standards. To me Xul should be the future: a way to avoid ajax and proprietary solutions. And it is already more mature than many other solutions.
  6. I do agree with you that the main problem is the HTML platform. But you forgot that another solution already exists: XUL.
    You have a complete plateform with XUL+XForms+javascript to send web service calls or REST calls with validated values.
    The difference with XAML is that it really exists! The other big difference is that it is based on standards.
    To me Xul should be the future: a way to avoid ajax and proprietary solutions. And it is already more mature than many other solutions.
    The main block to all these solutions of course is teh dreaded IE, which is the reason the web (especially it's interface) has barely moved forward in the last 7 years. The quantum leaps will come when IE is dead or bypassed.
  7. I wonder if this thread will end up flamebait?
    And then two messages down...
    The main block to all these solutions of course is teh dreaded IE, which is the reason the web (especially it's interface) has barely moved forward in the last 7 years. The quantum leaps will come when IE is dead or bypassed.
    Well, if you want to be correct and flamebaity you can also blame Netscape for being absolutely incompetent in their browser endeavors and letting IE actually surpass it, but I guess it's easier to regress into slashdweeb mode.
  8. Whoops, thanks for pointing that out Frank, my opinions got the better of me :-)
  9. I do agree with you that the main problem is the HTML platform. But you forgot that another solution already exists: XUL.
    You have a complete plateform with XUL+XForms+javascript to send web service calls or REST calls with validated values.
    The difference with XAML is that it really exists! The other big difference is that it is based on standards.
    To me Xul should be the future: a way to avoid ajax and proprietary solutions. And it is already more mature than many other solutions.


    The main block to all these solutions of course is teh dreaded IE, which is the reason the web (especially it's interface) has barely moved forward in the last 7 years. The quantum leaps will come when IE is dead or bypassed.
    That's also why we should not be waiting too much for microsoft solution to replace microsoft main internet plateform. Unless you want to create ajax apps... I do not think that xul could be seen as a replacement for html internet apps but one should think to this solution for intranets and usual webapps you find in enterprises. to declare its internet plateform as obsolete.
  10. I do agree with you that the main problem is the HTML platform. But you forgot that another solution already exists: XUL.
    XUL itself is a fine solution, but it again makes me program in a dynamic language that has no types, no tools and no community (at least it didn't have, now situation seems to be improving). Not to recognize the ingenuity of the language itself (Ruby is just polished Javascript with a normal VM), but so far the experience of actually ptogramming in it is far from pleasure.
  11. Is it performance matter?[ Go to top ]

    Hi Jevgeni, I think I get your point. Is it that you put too much weigh on the performance when choosing a framework or toolkit library? Browser' HTML/CSS widgets, Dojo, GWT, J2S' SWT/RIA, Eclipse SWT/RCP, Applet, Java Web Start, Flash, XUL and others domain in different programming languages or different VMs, which have different performances. Some of these toolkits perform somewhat poorly (or very poorly) but can be widely distributed, like Dojo, GWT, J2S SWT/RIA. While some have good performances but required extra VM installed or required specific browser, like Eclipse SWT/RCP , Applet, Java Web Start and XUL. It seems that Flash is the right one that is well-distributed and good-performed. But in my opinion, I do not like Flash. Maybe Flash started targeting not as RIA but as advertisement-publish-tool or animation-cartoon-viewer. For enterprise-level RIA, I think Eclipse RCP would be the best choice. OK, I think we could see Eclipse RCP as a specific-designed browser (Not HTML based but maybe XML based). But this kind of browser will never be popular as IE and Firefox. To balance development cost, performance and distributing-density (or distributing mantainment) is a must job for any given project requirement. So I think GWT should have its optional space in RIA development, and so is J2S' SWT/RIA. By the way, the programming language may also be an important factor for you. Java is an excellent language. JavaScript is also an excellent dynamic language even though it's hard to debug or mantain. Progamming in dynamic languages does give you much programming freedom as the helps you received from strong-typed language and related tools.
  12. Re: Is it performance matter?[ Go to top ]

    JavaScript is also an excellent dynamic language even though it's hard to debug or mantain.
    That's a straight contradiction, and since, in my experience, it is hard to debug or maintain, I have to reject the first part: JavaScript is not an excellent dynamic language.
  13. Re: Is it performance matter?[ Go to top ]

    JavaScript is also an excellent dynamic language even though it's hard to debug or mantain.


    That's a straight contradiction, and since, in my experience, it is hard to debug or maintain, I have to reject the first part: JavaScript is not an excellent dynamic language.
    +1 May JavaScript disappear for ever. However compiling from Java to JavaScript reduces massively time spent debugging since the Java compiler is able to spot many errors and restricts behaviour. So it is a good bridge.
  14. Re: Re: Is it performance matter?[ Go to top ]

    JavaScript is also an excellent dynamic language even though it's hard to debug or mantain.


    That's a straight contradiction, and since, in my experience, it is hard to debug or maintain, I have to reject the first part: JavaScript is not an excellent dynamic language.
    I just meant being hard to debug or to maintain does not eclipse the excellence of JavaScript as being a dynamic language. The free syntax of JavaScript give the programmer enough freedom to do whatever easily. By the way, lacking debugging or maintaining tools for JavaScript is getting better these days.
  15. Re: Re: Is it performance matter?[ Go to top ]

    Hi Josson I think the poster was making the point that 'good language' and 'hard to maintain/debug' are contradictory (sorry if I'm paraphrasing a little.). Sometimes this is not seen to be the case and a language which is quick to code in but hard to maintain gains popularity (temporarily). JavaScript is one of them.
    The free syntax of JavaScript give the programmer enough freedom to do whatever easily.
    Including hanging themselves (as in enough rope to hange themselves). I too like not having restraints when coding - but I also like safety nets and I don't find JS to have many safety nets. Kind regards Neil
  16. Not to recognize the ingenuity of the language itself (Ruby is just polished Javascript with a normal VM)
    There's no formal relation between XUL and Ruby, it all depends on your XUL interpreter. To comment your take on XUL, I once did a pretty big XUL project and yes, there is absolutely no community, even more so when combining Java & XUL (I should say outside Mozilla actually). About GWT, even if it builds on sand (insert IE or ECMAscript implementation joke here), it still comes from a company that has a strong following and that has a very responsive dev team. It has created a lot of momentum, and even though lots of followers aren't that skilled, it seems to move at a quite fast pace. Furthermore, by looking at the generated JS, it doesn't look that hackish. Anyway, for the downsides: it isn't suited for sites that aim at maximum searchbots' indexability, and loading times at startup seem linear with the code amount. As for the architectural problems, the main thing is that it doesn't seem to promote good design at first sight, but with some thought can be fitted in a standard J2EE architecture in a nice way (we're talking SpringMVC, SOA, classic views' design using wysiwyg HTML authoring tools and so on). To sum it up, if it is a "bridge" technology, then I personally think this is going to be a long bridge to a brighter full-standards SVG-SMIL-XUL-SomeOtherTech, so better use GWT till then. -- Pierre Queinnec Zenika
  17. I do agree with you that the main problem is the HTML platform.
    And isn't it just amazing how far people have managed to push this awkward and fundamentally limited platform? Talk about silk purses and sows' ears. ;-) Peace, Cameron Purdy Tangosol Coherence: Clustered Shared Memory for Java
  18. Oh My God, does nobody remember NetDynamics!!!! The enormously large unsuccessful application server that SUN killed off in 2002. They called it w3spider (the spider in the web) it was equally flawed and limited.
  19. GUI's are notoriously customized and application specific. IMO they are at the heart of user service, because one mans "great feature" is anothers "unnecessary burden." Google's done a great job of providing a toolkit, but anything they've done is one of many options out there on the web. Others might be dragging and dropping from a Dreamweaver Extension, directly using a Scriptaculous widget, Echo2, ZKLib, or any number of zillion other options which are currently marginalized and/or not invented yet. Just look at how there wasn't a single solution to the GUI toolkit in the entirety of the desktop software. There was no clear winner! You only have to look as far as history to tell you that the same diversity will manifest itself again on the web.
  20. On the other hand many development environments (enterprise included) restrict the types of client that may be deployed and AJAX clients are the nearest to rich clients we can produce. For example we are pretty much banned/restricted from Applets and Swing where I am currently working. I want GWT to succeed so that we can see where we need to go next. GWT is a bridging technology, and my goodness I hope IE dies a death so that a new rich client standard can appear - but until then it bridges a gap. Pragmatically speaking I am frequently in environments where Java Web Start, Applets, Swing etc. are restricted so this is a nice development for me personally. I understand where Jevgeni is coming from and I take the point about latent bugs, but we do need a bridge until the next generation arrives. I wonder if this thread will end up flamebait? Kind regards Neil
  21. For example we are pretty much banned/restricted from Applets and Swing where I am currently working.
    So am I, but this is not the point. I have nothing against AJAX, we support it ourselves in our framework I I wholeheartidly support projects like Dojo and Behaviour. But I'm afraid that with advent of GWT-like frameworks another mass hysteria will begin and customers will want their applications in AJAX, only AJAX and nothing but AJAX. In my opinion (supported by real-life applications) you can program very usable applications by programming them in HTML and throwing AJAX in only where really needed.
    I wonder if this thread will end up flamebait
    I sincerely hope not :)
  22. I sincerely hope not :)
    Sorry I've just come off another dumb Digg topic and I was beginning too think that any hope of a sensible discussion has now come to an end. (I thought giving people the vote on whether articles are junk or not would help, then I realised there was a reason why so many articles become flamebait ... and now those very folk are voting for more flamebait too ... children should be seen but not aloud to post ;-) ) Anyway I digress ....
    But I'm afraid that with advent of GWT-like frameworks another mass hysteria will begin and customers will want their applications in AJAX, only AJAX and nothing but AJAX.
    Ah-ha, I understand your point better. Fair enough that is a valid point, but then this is the inevitable hypecurve isn't it? In terms of raw AJAX or GWT, well GWT does hide the details which means my code is a lot less (read a hell of a lot less) vulnerable to JS bugs now. This has been my experience so far with GWT. And RPC without GWT, I have done this once and once only and I wouldn't rush to do it again. I'm using a mixture of conventional framework and GWT. GWT is in use for the admin interface and a conventional framework for the user display mainly because I currently view GWT as a high risk - but invaluable - solution. I'm quite curious to hear how other people are using it and what the reality has been for them. Of course this product is more Alpha than Beta at the mo. Of course if the dominant browser had a decent implementation of a decent client side language with a proper debugger as standard we'd have never got into this mess in the first place, sigh.
  23. The XUL is not a complete platform either. The XUL offers few more built-in GUI Components and canvas to organize them. However it cannot overcome many fundamental that are limiting the HTML to match desktop applications. On the other hand SVG+XUL could offer complete solution. I hope Mozilla support full SVG as soon as possible. Neither HTML nor XUL can help us building many custom components. I agree with the argument given in the following web page: http://www.cbsdf.com/misc_docs/gui-api-brief.htm To build Rich Internet Applications we need GUI-API that is simpler to use than Windows GUI-API. The GWT is nice idea but fall short of complex components, such as, Charts and Trees. We cannot include JDBS to access data and initialize the components at server, as it is possible for these GUI Classes: http://www.cbsdf.com/developer-guide.htm The GWT’s GUI Components are initialized only after the web page is sent to the Client. The JavaScript code makes Ajax call to get data from database. Isn’t it bit inconvenient, if we need to write multiple JSP files, where one JSP to initialize each GUI Component. I feel, XUL alone doesn’t after any significant advantage over HTML. I humble request to Mozilla team to accelerate the SVG implementation. I know this is too much to ask those who are working hard for free.
  24. Saddle on a cow?[ Go to top ]

    HTML and HTTP were never meant for applications, they were developed to share knowledge among scientists. And although later the dynamic DOM, CSS, XML and other abbreviations were added on top of it they fit almost as well as a saddle on a cow.
    CSS is a natural extension to HTML, it allows to create semantic HTML, something that was lost starting with HTML 2.0 release. The ability to load and parse XML and to be able to process it with client-side XSLT pushes the idea of semantic Web with flexible presentation even further. It is pretty short-sighted to think of CSS and XML/XSLT as of just bells and whistles. I might agree that DOM is less important for document-oriented full-page-load scenarios.
    A typical large enterprise application has different UI requirements than a typical desktop one.
    Well, what IS an enterprise application? Does it have to have terminal-based UI instead of windows/forms/panels running on the desktop?
    compile Java to Adobe Flash
    I have yet to see a Flash-based site that does not make me puke. Hope your idea will not come true in the large scale. I was disgusted when I was signing up for Mazda Zoom-Zoom Live event, but I did not have a choice, they don't have a non-Flash site version at all. So they have fixed size 760x500 Flash window, with loads for about 20 seconds on my cable-connected machine. Aside from regular Flash bling-bling it does not allow to resize the Flash canvas, nor to resize fonts and does not allow to select/copy text into clipboard. The whole idea of using Flash instead of regular HTML in that particular case is pretty stupid.
    My real complaint is that browser is fine for business application, just don't start building a full-scale fat client on it. Just because it works for Google doesn't mean it will work for all the rest of us :)
    I would say that Google Mail or Google Maps or Google Finance or Google Analytics are REAL enterprise applications, and this enterprise is huge and vastly distributed.
  25. Re: Saddle on a cow?[ Go to top ]

    CSS is a natural extension to HTML, it allows to create semantic HTML, something that was lost starting with HTML 2.0 release. The ability to load and parse XML and to be able to process it with client-side XSLT pushes the idea of semantic Web with flexible presentation even further. It is pretty short-sighted to think of CSS and XML/XSLT as of just bells and whistles.

    I might agree that DOM is less important for document-oriented full-page-load scenarios.
    Bah, today everything with an XML in it seems a mistery. The semantic web is basically the MVC pattern (database -> transformer -> renderer) plus a common way to represent metadata, XSLT is a rather inflexible functional language with no efficient implementation, CSS and DOM are very natural extensions to HTML to make it a bit more flexible and dynamic. I am as of yet to see the real value behind the semantic web hype. The so-called Web 2.0 happened largely behind the back of the people promoting it and I can bet the next big thing will also come from elsewhere.
  26. GWT has the potential to remain relevant for some time to come. It is entirely possible for Google to write another compiler for whatever the next great web UI that comes along. Keep the GWT api the same, use a different compiler. The idea being that your java code that used to compile into javascript will now compile into SVG + some other scripting language / XUL / whatever. Yes, there would likely be some conversion issues, but it is possible. Now will that actually happen? I do not know. Will depend a bunch on if Google is still using a lot of Java at the time, if Google is still around, etc. But it is a way to keep GWT viable.
  27. It will matter.[ Go to top ]

    Google didn't create this tool for "Highly responsive" and "Develop quickly" reasons (not sure about "sexy" thing). These things could be done with the approach that you're suggested for your "complex" Enterprise UI: These requirements are easily satisfied with HTML and a little browser independent JavaScript slapped on Google created this tool to make html/javascript/css creation and development becomes maintainable, testable, OOO-able, and human-readable. Ajax is just one of features of this tool. With any other tool of technology, learn its capability and use it to build a better project. So will Google Web Toolkit matter for the next years? Yes, it will matter as long as internet will be a customer choice to run their application. Yes it will matter as long as Google matters in web presence. What doesn't matter are Java compiled to Adobe Flash because regular or enterprise customers not all have Adobe Flash installed. Struts won't matter that much too; any new web apps still going to use Struts? Eclipse RCP and Avalon won't matter that much either, are they ready? are they here yet? Are customers ready to switch to Swing-like/Desktop UI as Eclipse RCP is? It doesn't seem matter now or next years.
  28. It surprises me that nobody has mentioned JavaServer Faces (JSF) as an alternative for GWT. Although GWT is very easy to work with, the API is specific to Google. JSF is implemented by multiple vendors, is also easy to use, and some implementations offer very good AJAX support. The IDEs for some of these JSF implementation are based on Eclipse, so that's also very standards-based. Full disclosure: I work for Backbase (http://www.backbase.com), one of the commercial AJAX/JSF vendors
  29. It surprises me that nobody has mentioned JavaServer Faces (JSF) as an alternative for GWT.

    Full disclosure: I work for Backbase (http://www.backbase.com), one of the commercial AJAX/JSF vendors
    Well, I personally think that JSF sucks beyond a reasonable doubt. If I would mention something it would be Wicket or, of course, Aranea. Full disclosure: I am the lead developer of Aranea and we plan to integrate with both Struts and JSF.
  30. Well, I personally think that JSF sucks beyond a reasonable doubt.
    That's a strong opinion. Can you please explain why? And if JSF sucks, why integrate with Aranea?
  31. Well, I personally think that JSF sucks beyond a reasonable doubt.


    That's a strong opinion. Can you please explain why? And if JSF sucks, why integrate with Aranea?
    Sorry, late night post :) Frankly my main reason is that JSF is not very well designed and making new components (unless they are simple enough to be made with Facelets' tags) is way too challenging task. Reuse should be simple, only then it will actually happen. Plus it takes too much logic into View and makes writing highly dynamic applications (where GUI depends on state) quite hard. Not to mention the smaller problems like isolated state handling, procedural controller, a lot of untyped code, ... The reason I would like to integrate Aranea with JSF is because we plan to integrate with every framework (at least every major one). Personal opinions don't matter on this scale, since there is enough people who do not agree with me. Our vision (besides other things) is to provide the interoperability layer between disparate frameworks and allow the components from one to run in another.
  32. Well, I personally think that JSF sucks beyond a reasonable doubt.
    Thanks for the thoughtful contribution. Unfortunately, I am unable to follow your considered line of reasoning. Perhaps you can enlighten us as to just how you come to this conclusion.
  33. I see too many things about "replacements" GWT and Struts, JSF or other, like : "It surprises me that nobody has mentioned JavaServer Faces (JSF) as an alternative for GWT." But, if You compare features of JSF and GWT, you don't find any common points. Since, I succesfully use GWT as Client-side "rendering" technology for JSF components ( and, by other hand - JSF as server-side backend for GWT widgets ). As a result, I have Junit testing and syntax checking for client-side code, dont't switch between different languages for parts of application etc. And, re-using of google wigets made very simple - put one jar into application and place tag on page :-) For other hand, we can be sure that clients for good technologies, such as Flex, XUL, etc. will not be installed for ALL computers at least many years - for both home and corporate environments ( espesially for corporate. Any of experienced IT departments will block to install any such software without full testing and organisation of controlled migration ), since, we really don't have alternative for HTML client in web applications.
  34. It doesnt matter[ Go to top ]

    You know we can all argue and speculate about what framework is good or bad or what should or shouldn't be in a web application, but it all doesn't really matter. In the end as a user (yes, even though I'm developer), what I want is an application that works, efficient, intuitive, looks nice and comprehensive. It needs to use AJAX to achive that or Flash or plain html? I dont care. If the webpage takes seconds to load up on a fast broadband connection than its not acceptable (I dont care if its because of all the javascript it has to download or big-arse flash or the tons of hi-res images). If the web application requires me to click 10 times to do a simple 1 click function, then its not efficient. If the application requires me to read a ton of manual and help files before doing anything productive, then its not acceptable. See as an end-user, I could care less what technology it uses, heck it can be php or even ASP.net and I could care less. So, the point is, why waste time trying to justify what framework/technology you think would benefit the user. In the end, most users could care less about the technology you use. Each tecnology if used correctly can provide a pleasant or un-pleasant user experience. Of course as a developer or software company, you would want to choose a technology that can give you the end result that will make the users happy. Now arguably, some frameworks would be better off than some. However, it also depends on the experience of the developers. A novice in a good/popular framework will still churn out crap compared to an expert in some obscure/bad framework. Evangelise your preferred framework all you want, but sometimes its not whether how complete or efficient or robust a framework is that determines whether it stands out to a software company. Other factors like the availability of experienced developers, portability of legacy products, the rate of adoption in the surrounding regional area, etc that determines it.
  35. The biggest problem with GWT is that it flat-out requires programmers. How many years now have we been striving for the ideal that you could have page designers and graphics artists handling the UI with little more than simple markup, and then the hardcore programmers backing that up? GWT goes the exact opposite direction as that. Now, I've often wondered how many shops out there actually achieve that ideal anyway? My guess is not as many as we'd like to think. Even still, does that make the fundamental concept flawed? I don't believe so. Another point: you have to have liked Java GUI programming to like GWT. I for one never have. It's always seemed like way more work that it needs to be for relatibely little benefit. Either way, GWT is a neat piece of engineering, and I certainly appreciate the ideas. But I for one can't get behind it in any meaningful way.
  36. The biggest problem with GWT is that it flat-out requires programmers.

    How many years now have we been striving for the ideal that you could have page designers and graphics artists handling the UI with little more than simple markup, and then the hardcore programmers backing that up? GWT goes the exact opposite direction as that.
    Untrue. It *can* also be used in the way you want it to be, ie legacy HTML pages fresh from the design agency. You just need to have what we call here an enhancement phase, where the HTML fragment you're fetching is processed clientside and updated with dynamic behaviour (well, listeners). Actually, in the (big) project we're doing right now, we're using GWT as a pure enhancement tool and not as a complete graphical toolkit. I do agree that according to the googlegroup, it seems that nobody went this way. It just works remarkably well here. -- Pierre Queinnec - CTO Zenika