GWT is not a thick client, is it? Go to top ] Posted by: Stephen Legge

Posted on: June 06 2006 11:57 EDT

in response to David Heffelfinger GWT applications are served to the client as a single HTML/JavaScript file, containing the entirety of the user interface. The Google Web Toolkit is a thick-client UI technology (applications run on the client) To access business data or perform a business process, a GWT user interface makes a remote procedure call (RPC) from the browser to a Servlet There's something about your explanation of GWT I don't understand. If the client served up to the browser is all HTML/Javascript, how is the application a think client? GWT has some limitations due to the fact that applications are run on the client browser But GWT is all HTML/Javascript -- ther is no "applicaton running in the browser", that is, there's no Applet or thick client. It's just HTML that talks Javascript to Servlets on the server, right? Please elaborate. There's something about your explanation of GWT I don't understand. If the client served up to the browser is all HTML/Javascript, how is the application a think client?But GWT is all HTML/Javascript -- ther is no "applicaton running in the browser", that is, there's no Applet or thick client. It's just HTML that talks Javascript to Servlets on the server, right? Please elaborate. Reply to this Reply to original

Re: GWT is not a thick client, is it? Go to top ] Posted by: Tod Liebeck

Posted on: June 06 2006 17:58 EDT

in response to Stephen Legge A thick client (also known as a fat client or rich client) is a client that performs the bulk of any data processing operations itself, and relies on the server it is associated with primarily for data storage. Although the term usually refers to software, it can also apply to a network computer that has relatively strong processing abilities. A thin client is a minimal client. Thin clients utilize as few resources on the host computer as possible. A thin client's job is generally just to graphically display information provided by an application server, which performs the bulk of any required data processing. With Echo2 the client is being used primarily as a display. The server is contacted when the user performs any event that requires the immediate execution of an application's code. For example, when the user clicks a button, the server is contacted in order to process the button's ActionEvent, as the ActionEvent-handling code exists on the server. (NOTE: operations which do not require immediate execution of server-side user interface code will not result in server contact.) With GWT the Java user interface has been compiled to JavaScript and is actually running on the client. When a user clicks a button, the code to process the resultant event actually exists on the client (as it has been compiled to JavaScript). The server is only contacted when the user interface needs to contact the middle tier to retrieve or manipulate data. Even though GWT is not using Applets or Plugins and all GWT code is HTML and JavaScript--this design falls under the category of thick client. "Thick clients" sometimes have a negative connotation, in that many associate the term with the requirement that IT folks will be installing client software on each workstation (either by pushing installations from a central server or even manually visiting each workstation). Obviously this is not the case with GWT--the client software is automatically "reinstalled" (if necessary) each time you visit a web page containing a GWT application. First let me define "thick client" and "thin client"...or rather let me quote Wikipedia's definition of them:With Echo2 the client is being used primarily as a display. The server is contacted when the user performs any event that requires the immediate execution of an application's code. For example, when the user clicks a button, the server is contacted in order to process the button's ActionEvent, as the ActionEvent-handling code exists on the server. (NOTE: operations which do not requireexecution of server-side user interface code will not result in server contact.) With GWT the Java user interface has been compiled to JavaScript and is actually running on the client. When a user clicks a button, the code to process the resultant event actually exists on the client (as it has been compiled to JavaScript). The server is only contacted when the user interface needs to contact the middle tier to retrieve or manipulate data. Even though GWT is not using Applets or Plugins and all GWT code is HTML and JavaScript--this design falls under the category of thick client. "Thick clients" sometimes have a negative connotation, in that many associate the term with the requirement that IT folks will be installing client software on each workstation (either by pushing installations from a central server or even manually visiting each workstation). Obviously this is not the case with GWT--the client software is automatically "reinstalled" (if necessary) each time you visit a web page containing a GWT application. Reply to this Reply to original

Re: Nice, balanced comparison Go to top ] Posted by: Christian Sell

Posted on: June 06 2006 18:27 EDT

in response to David Heffelfinger I would probably go with Echo2, simply because it does not limit what Java classes and libraries can be used to develop the application. that statement makes me really question your understanding of GWT. What GWT provides is the possibility to move parts of your application logic, together with the display logic, to the client in the form of JavaScript, where it is both obvious and completely desirable to not have every conceivable library available. If you need access to, say, hibernate, then, please, delegate back to the server. After all, we're writing a rich - not fat or thick - client. This is by no means a limitation but an architectural feature. I dont think Echo can really compete in that space (although I dont deny it can create slick and highly interactive web apps) that statement makes me really question your understanding of GWT. What GWT provides is theto move parts of your application logic, together with the display logic, to the client in the form of JavaScript, where it is both obvious and completely desirable tohave every conceivable library available. If you need access to, say, hibernate, then, please, delegate back to the server. After all, we're writing a rich - not fat or thick - client. This is by no means a limitation but an architectural feature. I dont think Echo can really compete in that space (although I dont deny it can create slick and highly interactive web apps) Reply to this Reply to original

Re: Anybody planning to shelve JSF bassed approach for GWT Go to top ] Posted by: Thomas Meeks

Posted on: June 08 2006 16:16 EDT

in response to bad mASH I'm in the process of creating a rather large website with GWT. It was timed pretty well with the start of my project. My reasons for choosing GWT: - I have a lot to do, and basically 0 time to be fooling around in javascript, GWT seems to do the best job of taking care of it for me - I know I can scale GWT out without worry, and failing over to another server is very easy - It is fairly quick (relative to other javascript-hiding frameworks) - If I need the power of java, it is but a RPC call away -- and I can generally get away with doing it infrequently enough that it isn't a problem - Full event system, that isn't slowed down by having to communicate with the server - The vast majority of what I need in the GUI is buildable with the blocks GWT provides, the rest is worked around easily enough - I am not a fan of building GUI's from markup languages, or any of the more conventional Java web frameworks The application will be large in size, fairly small in load, and will require high standards for both security and reliability. So there's at least one company out there actively developing an app based on GWT. :) And for what it is worth, if GWT hadn't come out, I would be building the app in Echo 2. Reply to this Reply to original

RE: Go to top ] Posted by: steeven lee

Posted on: June 17 2006 04:25 EDT

in response to Thomas Meeks I'd like to use ECHO2 for intranet application and choose GWT for internet application. for gwt can integrate with existing html, some tranditional web design tools can benifts for it. for example, use dreamweaver template to maintain overall style. echo looks more like swing, for it is a PURE java app, app will be reliable. compiling time check, refactor, and so on... echo runs a little far from HTML, it will be easier for swing developer. gwt api is flexible, html block can be set as a link text. on the other hand, echo2 may reder output's to flash, or xaml in the future. maybe gwt add some mechanism to let controls work like a server side control. for now, I believe Echo/GWT will lead the future web devlopement. Reply to this Reply to original

IDE Go to top ] Posted by: no no

Posted on: December 20 2007 10:27 EST

in response to Neeme Praks What is the best combination of an WYSIWYG IDE + debugger ? IDEA is having its own UI designer, which is pretty neat for a Swing, all what it does it automatically generates XML layout for you components and bind them to Swing classes with proprietary Layout managers all these is simple and easy, also event listeners. But echo2 has its own set of classes, libraries - One might really question the quality of that product it might be good, but by taking a look at it at glance maybe not perfect - too java oriented. For ex, I could not really instal Eclipse plugin for echo2, some tiny things didnt work etc. You cannot go to production with such a library .. can you? there are other frameworks like opelazzo, etc, they are TOOOO xml oriented. Doesnt anybody want to code everying in XML ?? heh ? even control flow? In echo2 why have a set of parallel classes of swing ?? why not to do some BCEL to existing Swing classes? and provide a decent support for a couple of layout managers as in IDEA. and translate them to Javascript or whatever during the build transparently .. I dont want to work with parallel classes honestly.. So in the end what is the best tool to do UI designs WYSIWYG and have very simple java binding in web preferably from the same product suite? to have really COST cost effective/ high testability/ fully debugged/ application? ANY commercial products that worth money? hey gooruuus? Reply to this Reply to original

why not? Go to top ] Posted by: geoff hendrey

Posted on: June 06 2006 12:08 EDT

in response to Tod Liebeck The best thing would be if Swing could access an "HTML layout manager", so that real Java code could replace JavaScript on the client. I'd like to see some discussion, on this thread, of the various barriers to this architecture. I mean, isn't what we all want to be able to do "just write java code" on the client. Well, we can do that with an applet, but the applet can't interact with the browser the same way Javascript can. So, what would have to be done to make it possible? Here are some wacky possibilities: 1)Java interpreter ships with the browser, allowing Java to be executed like a script. HTML "layout manager" interface is provided by browser's java interpreter, and you can access the layout manager via standard "import" statement. 2)Java-to-Javascript bridge allows standard Java class, in an applet, to execute Javascript calls. Would again require some support in the browser. Somebody implements an HTML layout manager on top of the bridge. 3)A Java-centric browser. I really think it's time to try this again! So when is Google's web browser going to be released? -geoff Reply to this Reply to original

Advantages and Disadvantages Go to top ] Posted by: Thomas Meeks

Posted on: June 06 2006 16:35 EDT

in response to Tod Liebeck I have done a bit of work with both frameworks, both are very well thought out and tackle the same problem in very different ways. It really comes down to which one has limitations that irk you the most :-) Echo 2 has two large limitations as I have discovered. One is events. Since the framework runs entirely on the server, the client side script will only send events to the server under very specific circumstances. For example, the click of a button. Meaning that if you want to create something like an auto-complete form field, or have something occur on a mouseover, you have to make custom components. Which is a pain. The second large limitation is server affinity -- which makes echo2 much harder to scale out in very large programs. Though this is a limitation Echo 2 shares with almost every other Java web framework. Echo 2 compares favorably to GWT in terms of having the entire power of java available and a *lot* more components available at the moment. GWT has its share of big limitations as well. Your client code can't make use of reflection, java.text, regular expressions, and a few other utility classes I have found to be very useful in GUI programming. On the other hand, it has a much better event system (events happen on the client, you can hook up to just about anything), better support for custom javascript, and can do rather crazy amounts of scaling. All said, I think both frameworks are better than pretty much everything else I have seen for java. But between the two it just depends on what you need more. Reply to this Reply to original

Response to GWT comments Go to top ] Posted by: Shane Witbeck

Posted on: June 06 2006 19:16 EDT

in response to Tod Liebeck all of your GWT code is executed on the client This is very misleading. Yes, GWT takes care of translating your client-centric Java code to HTML, JS, and CSS but you still use your existing server-side code (think Spring, Hibernate, business logic, etc) to drive the client code. Google has done a great job of making GWT flexible enough where you can write a full blown client with GWT or a simple "widget" placed in an existing HTML page with the addition of a div tag. GWT limits the developer to a subset of the Java 1.4 libraries Again, this is somewhat misleading and not entirely true. I was able to write a GWT app using Java 1.5. The only limitation is that the client portion of the GWT code must use 1.4 conventions. You can still use Java 1.5 for most of your service/middle tier. There are some issues to using it for the creation of large applications, where downloading an entire application to a client web browser in one shot would not be practical. I don't think this is a limitation of GWT but calls into question how you design the application. Having several "entry points" to the application may be an option. I found GWT to be a refreshing change to the AJAX library landscape where there are tons of small and some useful (Prototype) libraries: GWT provides a nice abstraction which most Java developers can pick up quickly. This abstraction also promotes reuse so you can easily use a "widget" from one app in another with minimal effort. This alone is huge in the AJAX space and lowers the barrier to developers that haven't been able to effectively incorporate AJAX into their apps. Enabling the development cycle to happen using Java byte code is also huge. I would guess that this would reduce the development time of the app a minimum of 30%. No more app server restarts (for client-related code) and debug your client code using your favorite debugger. BTW, I'm not a Google employee but...shameless plug coming...I do have a little website called When GWT was first released, I spent a solid week investigating it and writing a small application. I'd like to response to a couple of the points made here based on my experience.This is very misleading. Yes, GWT takes care of translating your client-centric Java code to HTML, JS, and CSS but you still use your existing server-side code (think Spring, Hibernate, business logic, etc) to drive the client code. Google has done a great job of making GWT flexible enough where you can write a full blown client with GWT or a simple "widget" placed in an existing HTML page with the addition of a div tag.Again, this is somewhat misleading and not entirely true. I was able to write a GWT app using Java 1.5. The only limitation is that the client portion of the GWT code must use 1.4 conventions. You can still use Java 1.5 for most of your service/middle tier.I don't think this is a limitation of GWT but calls into question how you design the application. Having several "entry points" to the application may be an option. I found GWT to be a refreshing change to the AJAX library landscape where there are tons of small and some useful (Prototype) libraries:BTW, I'm not a Google employee but...shameless plug coming...I do have a little website called AJAX Matters for more information on GWT and other AJAX resources. Reply to this Reply to original

Re: Response to GWT comments Go to top ] Posted by: Tod Liebeck

Posted on: June 07 2006 07:28 EDT

in response to Shane Witbeck entire application, but rather to the application's user interface layer. The same applies with regard to the statement that GWT is limited to a "subset of the Java 1.4 libraries." Additionally, after reading your complaint, I now believe this last statement could have been better termed a "subset of the Java 1.4 API specification". I don't think this is a limitation of GWT but calls into question how you design the application. Having several "entry points" to the application may be an option. I do not believe the large-application-problem is a show-stopper. I do think this is rightly called an "issue" though, as it does create additional work for the developer. As an example, take the case where those multiple entry points need to share information at the UI level. It can most certainly be done, but it does require more work than if one were able to create a single "application" unit. I found GWT to be a refreshing change to the AJAX library landscape where there are tons of small and some useful (Prototype) libraries: 1. GWT provides a nice abstraction which most Java developers can pick up quickly. 2. This abstraction also promotes reuse so you can easily use a "widget" from one app in another with minimal effort. This alone is huge in the AJAX space and lowers the barrier to developers that haven't been able to effectively incorporate AJAX into their apps. 3. Enabling the development cycle to happen using Java byte code is also huge. I would guess that this would reduce the development time of the app a minimum of 30%. No more app server restarts (for client-related code) and debug your client code using your favorite debugger. The numbered points here apply equally to Echo2. Please don't read me wrong here, I'm not trying to knock GWT--I actually think it's pretty cool. Both frameworks have their advantages and disadvantages though. Upon hearing your concerns, I think I need to provide a bit more clarity with regard to these statements. The terms "your GWT code" and "your Echo2 code" are not referring to the, but rather to the application's. The same applies with regard to the statement that GWT is limited to a "subset of the Java 1.4 libraries." Additionally, after reading your complaint, I now believe this last statement could have been better termed a "subset of the Java 1.4 API specification".I do not believe the large-application-problem is a show-stopper. I do think this is rightly called an "issue" though, as it does create additional work for the developer. As an example, take the case where those multiple entry points need to share information at the UI level. It can most certainly be done, but it does require more work than if one were able to create a single "application" unit.The numbered points here apply equally to Echo2. Please don't read me wrong here, I'm not trying to knock GWT--I actually think it's pretty cool. Both frameworks have their advantages and disadvantages though. Reply to this Reply to original

JS Spring? Go to top ] Posted by: Chris Kerns

Posted on: June 08 2006 09:12 EDT

in response to Machiel Groeneveld What I'm missing from this comparison is the support for Spring. I tried Echo2, but it lacks spring support and I can't find the right place to integrate spring. What? You want Spring in your JavaScript now, too? You know, I don't have any issues with Spring or DI, but the number of developers that blindly throw it in to every little bit of code they write is quite disturbing. As far a GWT goes, I imagine most users will implement the true business logic on the server and expose it as services. In that regrard, all you are really doing is writing a servlet, so using Spring/Hibernate/<insert favorite framework/library here> is no problem. Chris What? You want Spring in your JavaScript now, too? You know, I don't have any issues with Spring or DI, but the number of developers that blindly throw it in to every little bit of code they write is quite disturbing. As far a GWT goes, I imagine most users will implement the true business logic on the server and expose it as services. In that regrard, all you are really doing is writing a servlet, so using Spring/Hibernate/ is no problem. Chris Reply to this Reply to original

Re: Testing and spring support Go to top ] Posted by: Mark Allen

Posted on: June 08 2006 10:26 EDT

in response to Machiel Groeneveld What I'm missing from this comparison is the support for Spring. I tried Echo2, but it lacks spring support and I can't find the right place to integrate spring. I can't speak to Echo2, but Spring 2.0 integration with GWT can be done in much the same way as the AspectJ 'dependency inject your domain model' technique. GWT creates its RPC endpoints internally based on the classnames you supply in an XML file, so it's easy to write a simple aspect that performs DI on advised objects and apply it after the constructors for relevant GWT-managed classes execute. I've written a bit more in-depth about the process I can't speak to Echo2, but Spring 2.0 integration with GWT can be done in much the same way as the AspectJ 'dependency inject your domain model' technique. GWT creates its RPC endpoints internally based on the classnames you supply in an XML file, so it's easy to write a simple aspect that performs DI on advised objects and apply it after the constructors for relevant GWT-managed classes execute. I've written a bit more in-depth about the process here , since most of the other techniques I've seen so far for Spring/GWT integration have a 'workaround' feel to them. Reply to this Reply to original