Enterprise Java Community: News : Comparing the Google Web Toolkit to Echo2

Comparing the Google Web Toolkit to Echo2
Posted by:Tod Liebeck on ?? 06, 2006
TheGoogleWebToolkit (GWT)isbeingcomparedtoEcho2quitefrequently. 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 asubset 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 replies
· Comparing the Google Web Toolkit to Echo2 byTod Liebeck on Tue Jun 06 06:50:09 EDT 2006
· Nice, balanced comparison byDavid Heffelfinger on Tue Jun 06 09:22:48 EDT 2006
· GWT is not a thick client, is it? byStephen Legge on Tue Jun 06 11:57:20 EDT 2006
· Re: GWT is not a thick client, is it? byTod Liebeck on Tue Jun 06 17:58:45 EDT 2006
· Echo 2 demo byGeorge Coller on Tue Jun 06 17:43:47 EDT 2006
· Re: Nice, balanced comparison byChristian Sell on Tue Jun 06 18:27:37 EDT 2006
· Anybody planning to shelve JSF bassed approach for GWT bybad mASH on Thu Jun 08 13:44:23 EDT 2006
· Re: Anybody planning to shelve JSF bassed approach for GWT byThomas Meeks on Thu Jun 08 16:16:23 EDT 2006
· RE: bysteeven lee on Sat Jun 17 04:25:22 EDT 2006
· why not? bygeoff hendrey on Tue Jun 06 12:08:24 EDT 2006
· Re: Comparing the Google Web Toolkit to Echo2 byDilip Ranganathan on Tue Jun 06 14:00:06 EDT 2006
· Advantages and Disadvantages byThomas Meeks on Tue Jun 06 16:35:16 EDT 2006
· Response to GWT comments byShane Witbeck on Tue Jun 06 19:16:50 EDT 2006
· Re: Response to GWT comments byTod Liebeck on Wed Jun 07 07:28:16 EDT 2006
· How about Java interpreter and markup language byAburo Baize on Wed Jun 07 00:41:29 EDT 2006
· Some usefull links on gwt byjelmer kuperus on Wed Jun 07 01:51:30 EDT 2006
· GWT + Echo2 together? Maybe the Best of both worlds byLuca Garulli on Wed Jun 07 04:39:08 EDT 2006
· Testing and spring support byMachiel Groeneveld on Thu Jun 08 02:20:42 EDT 2006
· Re: Testing and spring support byPatrik A on Thu Jun 08 07:55:47 EDT 2006
· JS Spring? byChris Kerns on Thu Jun 08 09:12:58 EDT 2006
· Re: Testing and spring support byMark Allen on Thu Jun 08 10:26:55 EDT 2006
· Comparison byDattesh Patel on Thu Jun 08 13:38:25 EDT 2006
 Message #210725Post reply Post reply Post replyGo to top Go to top Go to top

Nice, balanced comparison
Posted by:David Heffelfinger on ?? 06, 2006 in response toMessage #210709
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 theonline 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.
 Message #210756Post reply Post reply Post replyGo to top Go to top Go to top

GWT is not a thick client, is it?
Posted by:Stephen Legge on ?? 06, 2006 in response toMessage #210725
> 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.
 Message #210757Post reply Post reply Post replyGo to top Go to top Go to top

why not?
Posted by:geoff hendrey on ?? 06, 2006 in response toMessage #210709
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
 Message #210769Post reply Post reply Post replyGo to top Go to top Go to top

Re: Comparing the Google Web Toolkit to Echo2
Posted by:Dilip Ranganathan on ?? 06, 2006 in response toMessage #210709
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
 Message #210790Post reply Post reply Post replyGo to top Go to top Go to top

Advantages and Disadvantages
Posted by:Thomas Meeks on ?? 06, 2006 in response toMessage #210709
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.
 Message #210797Post reply Post reply Post replyGo to top Go to top Go to top

Echo 2 demo
Posted by:George Coller on ?? 06, 2006 in response toMessage #210725
Wow, that Echo 2 demo is pretty impressive.
 Message #210799Post reply Post reply Post replyGo to top Go to top Go to top

Re: GWT is not a thick client, is it?
Posted by:Tod Liebeck on ?? 06, 2006 in response toMessage #210756
First let me define "thick client" and "thin client"...or rather let me quoteWikipedia‘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.
 Message #210803Post reply Post reply Post replyGo to top Go to top Go to top

Re: Nice, balanced comparison
Posted by:Christian Sell on ?? 06, 2006 in response toMessage #210725
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)
 Message #210821Post reply Post reply Post replyGo to top Go to top Go to top

Response to GWT comments
Posted by:Shane Witbeck on ?? 06, 2006 in response toMessage #210709
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:
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 calledAJAX Matters for more information on GWT and other AJAX resources.
 Message #210842Post reply Post reply Post replyGo to top Go to top Go to top

How about Java interpreter and markup language
Posted by:Aburo Baize on ?? 07, 2006 in response toMessage #210709
Programming UI in Java is great, but can we do it in a markup language likeZK andBackbase.
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!
 Message #210845Post reply Post reply Post replyGo to top Go to top Go to top

Some usefull links on gwt
Posted by:jelmer kuperus on ?? 07, 2006 in response toMessage #210709
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/
 Message #210858Post reply Post reply Post replyGo to top Go to top Go to top

GWT + Echo2 together? Maybe the Best of both worlds
Posted by:Luca Garulli on ?? 07, 2006 in response toMessage #210709
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
 Message #210872Post reply Post reply Post replyGo to top Go to top Go to top

Re: Response to GWT comments
Posted by:Tod Liebeck on ?? 07, 2006 in response toMessage #210821
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.
 Message #210940Post reply Post reply Post replyGo to top Go to top Go to top

Testing and spring support
Posted by:Machiel Groeneveld on ?? 08, 2006 in response toMessage #210709
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.
 Message #210946Post reply Post reply Post replyGo to top Go to top Go to top

Re: Testing and spring support
Posted by:Patrik A on ?? 08, 2006 in response toMessage #210940
What‘s wrong with just plain old using Spring? What integration is needed?
 Message #210950Post reply Post reply Post replyGo to top Go to top Go to top

JS Spring?
Posted by:Chris Kerns on ?? 08, 2006 in response toMessage #210940
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/ is no problem.
Chris
 Message #210963Post reply Post reply Post replyGo to top Go to top Go to top

Re: Testing and spring support
Posted by:Mark Allen on ?? 08, 2006 in response toMessage #210940
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 processhere, since most of the other techniques I‘ve seen so far for Spring/GWT integration have a ‘workaround‘ feel to them.
 Message #210977Post reply Post reply Post replyGo to top Go to top Go to top

Comparison
Posted by:Dattesh Patel on ?? 08, 2006 in response toMessage #210709
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
 Message #210978Post reply Post reply Post replyGo to top Go to top Go to top

Anybody planning to shelve JSF bassed approach for GWT
Posted by:bad mASH on ?? 08, 2006 in response toMessage #210725
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.

 Message #210988Post reply Post reply Post replyGo to top Go to top Go to top

Re: Anybody planning to shelve JSF bassed approach for GWT
Posted by:Thomas Meeks on ?? 08, 2006 in response toMessage #210978
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.
 Message #211599Post reply Post reply Post replyGo to top Go to top Go to top

RE:
Posted by:steeven lee on ?? 17, 2006 in response toMessage #210988
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.
Related LinksRelated LinksRelated Links

Ads by Google
XML-based configuration
XML-based on-device management software
www.tail-f.com
Sample AJAX Application
See AJAX technology in action with telerik HelpDesk – Free download
www.telerik.com/HelpDesk
Migrate Mainframe Apps
INFINITE zSERIES migrates Mainframe apps to Windows, Unix or Linux
www.californiasoftware.com
Read & Write Excel files
Write 956000 rows/second Java XLS component.
www.activexls.com
User Interface Design
101 database form examples & form design & layout recommendations.
www.BlueClaw-DB.com
_xyz