Home

News: Comparing the Google Web Toolkit to Echo2

  1. Comparing the Google Web Toolkit to Echo2 (27 messages)

    The Google Web Toolkit (GWT) is being compared to Echo2 quite frequently. Some of these comparisons have been fairly accurate, while others contain bits of misinformation. This article, written by the lead developer of Echo2, discusses the similarities and differences between these two frameworks. Overview The Google Web Toolkit and Echo2 definitely make for an interesting comparison. Both of these frameworks take a non-traditional approach toward web application development, even considering the latest crop of "AJAX-based frameworks" available today. The most obvious similarity between GWT and Echo2 is that they both enable the developer to create dynamic, AJAX-driven web user interfaces using only Java. In both projects, UIs are developed in a fashion similar to SWT or Swing: by assembling hierarchies of components and registering event handlers. Neither project requires the developer to work with HTML, JavaScript, or XML. The most obvious difference between GWT and Echo2 is that all of your GWT code is executed on the client, whereas your Echo2 code is executed on the server. There are advantages and disadvantages to both of these approaches, which will be highlighted throughout the article. GWT's defining attribute is the Java-to-JavaScript compiler. This compiler allows you to develop the web interface to your application in Java, then compile it to JavaScript. GWT limits the developer to a subset of the Java 1.4 libraries. GWT applications can be served by any web server, such as Apache, without the need for server-side processing. Echo2 applications are compiled to Java byte code and run on a Java server. Their Java code is executed by Echo2's "Web Application Container" layer, which sits atop a Java Servlet. On the web browser, the Echo2 "Client Engine" communicates user input to the Web Application Container via AJAX requests, with the server responding with directives to perform incremental updates to the state of the client web browser. User Interface Performance With GWT, all of your user interface code exists on the client browser. In operations that do not require server communication--that is, that do not require retrieving data from the middle tier--this configuration results in response times that are not dependent on the server. When data must be retrieved from the application's middle tier or business logic layer, the response time is subject to the same criteria as any other AJAX application, i.e., network latency, bandwidth, and server performance. Echo2 application code is run on the server, so for each user interaction that requires a call to the middle tier or immediate execution of the application's Java code, an AJAX connection is made to the server. Echo2 components are designed to minimize the client/server communication as much as is possible, limiting it to times when the server must be notified immediately of events. For example, simple events such as user input to a TextField component will not result in server contact. The server's response is the minimum set of instructions to incrementally update the client to reflect the new screen state. GWT applications are served to the client as a single HTML/JavaScript file, containing the entirety of the user interface. The size of this file will be proportional to the size of your user interface code and the toolkit libraries used by your application. Echo2 JavaScript modules are lazy-loaded to the client, and thereafter cached. A module will be retrieved when a component first appears on-screen that requires it. Application code is never sent to the client, only the state of the user interface. Middle Tier / Data Retrieval 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. GWT provides a mechanism to make the RPC invocation transparent to the developer, allowing the developer to build the application with "Plain Old Java Objects" (POJOs). However, any application that provides an RPC capability is a distributed application -- even when the RPC is accomplished transparently to the developer. Distributed applications in businesses and enterprises usually have security considerations and the remote objects serving the GWT clients must be designed with a focus on security to deflect attacks from imitated or hostile client applications. Echo2 applications support, but do not require, the use of distributed application logic or a Service Oriented Architecture (SOA). Alternatively, Echo2 applications can be built to run entirely within a single JVM instance, backed by a POJO-based middle tier. This allows Echo2 developers to build applications without the security concerns of distributed application logic -- and leverage the many strong frameworks built around POJO development such as the Spring Framework and Hibernate. Echo2 accomplishes this by keeping the state of a user's web interface on the server so that no remote objects need to be exposed. Performance Under Load The Google Web Toolkit is a thick-client UI technology (applications run on the client), whereas Echo2 is a thin-client UI technology (applications run on the server). A thick-client will inherently place less load on the server as the number of simultaneous users increases. This advantage of GWT is most pronounced in cases where applications are simple and data store access is limited, and less so with more complex applications that require more frequent inquiries to the data store. In a typical environment though, either framework will saturate available network bandwidth before server resource utilization, i.e. processing power and memory, becomes an issue. Run-time Environment GWT has some limitations due to the fact that applications are run on the client browser. First, GWT applications are limited to using a subset of the core Java class libraries, consisting of 27 classes, 11 interfaces, and 18 exception types found in the java.util and java.lang packages (as of GWT 1.0.21). This limitation prevents GWT applications from linking to most existing Java libraries. Additionally, all Java code must be compliant with the Java 1.4 specification; 1.5 is not supported. Localization-related portions of the Java API are not provided. Debugging GWT provides an alternate deployment environment for applications to facilitate debugging. The environment, called "Hosted Mode", allows a GWT application to be run as Java byte code in a local JVM, to which an IDE's debugger can be connected. In this mode, the application's user interface is displayed in a special web browser (a Mozilla/Firefox derivative). Echo2 applications may be debugged in the conventional manner, by connecting an IDE's debugger to a JVM running a Servlet container. Licensing The primary component of GWT, the Java-to-JavaScript cross-compiler, is proprietary, binary-only software. The Java API libraries are open source software, distributed under the Apache License. The API libraries have essentially no value without the proprietary compiler. The (non-critical) hosted-mode browser is also under the proprietary license. GWT is provided free of charge. Echo2 is open source software, licensed under the Mozilla Public License, and provided free of charge. Applicability GWT can be used as a means of creating AJAX components to embed in traditional web applications (or even in static web pages) as well as for creating complete application user interfaces. 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. The lack of localization and full Java API support also presents a problem for larger solutions. Echo2 is practical for creating web applications of any size. It is however not intended to scale downward to function as a platform for simply creating AJAX components in traditional web frameworks (or static web sites). More Information Google Web Toolkit: Home Page, Example Applications, Getting Started Guide, Developer Guide Echo2: Home Page, Example Applications, Tutorial

    Threaded Messages (27)

  2. Nice, balanced comparison[ Go to top ]

    Nice comparison of GWT vs Echo2. Although I have no experience with GWT, and very little experience with Echo2, if I needed to pick one versus the other for a project, I would probably go with Echo2, simply because it does not limit what Java classes and libraries can be used to develop the application. The fact that the online Echo2 demo is very impressive doesn't hurt, either. A couple of Echo2 reviews can be found at: A Review of the Echo2 Framework and A Closer Look at the Echo2 Framework Disclaimer: I wrote both of the above reviews.
  3. 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.
  4. First let me define "thick client" and "thin client"...or rather let me quote Wikipedia's definition of them:
    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.
  5. Echo 2 demo[ Go to top ]

    Wow, that Echo 2 demo is pretty impressive.
  6. 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)
  7. I would like to hear from early adopters of GWT ? Any plans of pushing GWT into actual projects ? JSF has a steep learning curve . But I am yet to find productivity gains. GWT concepts, on the other hand, is familiar to anyone who has ever written a "hello world" Swing application.
  8. 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.
  9. RE:[ Go to top ]

    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.
  10. on the other hand, echo2 may reder output's to flash, or xaml in the future.
    Why "may render in the future"? You can do that now with http://www.openlaszlo.org/
  11. IDE[ Go to top ]

    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?
  12. why not?[ Go to top ]

    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
  13. GWT's defining attribute is the Java-to-JavaScript compiler. This compiler allows you to develop the web interface to your application in Java, then compile it to JavaScript
    Something similar exists in the .NET land in addition to Atlas (http://atlas.asp.net/). Its called Script#. Just like GWT, it compiles C# code to JavaScript. Some links of interest: http://www.nikhilk.net/ScriptSharpIntro.aspx On the off-chance people on this list want to commit blasphemy by actually downloading the bits, it can be found here: http://www.nikhilk.net/Content/Samples/ScriptSharp.zip
  14. Advantages and Disadvantages[ Go to top ]

    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.
  15. Response to GWT comments[ Go to top ]

    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.
    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:
    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.
    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.
  16. Re: Response to GWT comments[ Go to top ]

    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 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.
  17. Programming UI in Java is great, but can we do it in a markup language like ZK and Backbase. IMHO, there are two kind of architectures: client-based and server-based. GWT, DOJO, DWR and Backbase are all client-based. Echo2 and ZK are server-based. Client-based has better control of the browser, but easy to become fat-client as replicate app codes at the server. Server-based are easy to develop and communicate with backend, but hard to fail-over. When coming to programming language, there are three approaches: JavaScript, Java and markup language. DOJO is JavaScript. GWT and Echo2 are all-Java. Backbase supports markup language. ZK is the most interesting (actually we are using it to develop an inhouse project): it supports pure-Java, markup language and event, scripting in Java (with BeanShell). With markup language and scripting, we can store UI in database! ZK Demo: http://www.potix.com/zkdemo/userguide/ Nowadays, all Ajax demo, unless immature, are impressive!
  18. Some usefull links on gwt[ Go to top ]

    building your own components - http://jroller.com/page/glongman?entry=gwt_autocompleter Scriptaculous Effect Wrapper - http://roberthanson.blogspot.com/2006/05/announce-gwt-widget-library.html Spring integration - http://jelmer.jteam.nl/?p=5 components date pickers etc - http://gwt.components.googlepages.com/
  19. Roma Framework (http://www.romaframework.org) is a metaframework with the main aim to build cross-framework application. Current version allow to generate Ajax web application with database and CRUDs in less than one hour. Now the unique rendering plugin available is for Echo2. Echo2 acts very well and using additional components (NextApp's Extras and EchoPoint NG) allow to write very complex web application without write one HTML tag... A new Feature Request in Roma is to support the GWT along with the current Echo2 and decide by configuration what POJO to render with GWT (client-side only) or by Echo2 (client+server side). bye, Luca Garulli Blogging on: http://zion-city.blogspot.com http://www.RomaFramework.org - The new way to build applications http://www.Pro-Netics.com (member of Orixo.com - The XML business alliance) http://www.OrienTechnologies.com - Light ODBMS, All in one JDO solution
  20. Testing and spring support[ Go to top ]

    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. The other thing I would like to know is how easy it is to write unit tests using these toolkits.
  21. What's wrong with just plain old using Spring? What integration is needed?
  22. JS Spring?[ Go to top ]

    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
  23. 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 here, since most of the other techniques I've seen so far for Spring/GWT integration have a 'workaround' feel to them.
  24. Re: Testing and spring support[ Go to top ]

    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.
    Mark, did you figure out how to modify Eclipse .launch file to debug GWT + Spring in hosted mode? Valery
  25. Comparison[ Go to top ]

    Both frameworks have their merit, however, I like the Echo2 model. You can debug your GWT app while developing in Java.. but how about debugging your app when it's running in the browser, in Javascript? Seems that there would be less overall Javascript, and browser compatability issues with Echo2. The framework also looks more complete in terms of the number of components, etc. D Pat Digital Vastoo - For All Your iPod Needs http://www.digitalvastoo.com
  26. Re: Comparison[ Go to top ]

    +1 I'm just starting out to learn about both Echo2 and GWT, and I am leaning towards this same observation. Anyone know of an "autocomplete" implementation in Echo2? That appears to be a component that is fast becoming a "standard" requirement for UI frameworks, but I did not find it in the demo.
  27. Re: Comparison[ Go to top ]

    Both frameworks have their merit, however, I
    like the Echo2 model.

    You can debug your GWT app while developing
    in Java.. but how about debugging your app
    when it's running in the browser, in Javascript?

    Seems that there would be less overall Javascript,
    and browser compatability issues with Echo2.
    The framework also looks more complete in terms
    of the number of components, etc.

    D Pat
    Digital Vastoo - For All Your iPod Needs
    http://www.digitalvastoo.com
    +1 I'm just starting out to learn about both Echo2 and GWT, and I am leaning towards this same observation. Anyone know of an "autocomplete" implementation in Echo2? That appears to be a component that is fast becoming a "standard" requirement for UI frameworks, but I did not find it in the demo.
  28. IT Mill Toolkit[ Go to top ]

    Besides Echo2 and GWT mentioned in the article, you should also look at IT Mill Toolkit when comparing "Code in Java" Ajax frameworks: demo, manual, download, features, more info