JavaOne: Google Web Toolkit vs. JSF
XMLHttpRequests.
The GWT enables you to call back to the server via a simple RPC mechanism. Dust off your DTO and Session Facade patterns, folks. You can even step through your Java code with a debugger while running in the browser!
For the majority of intents and purposes, GWT invalidates JSF. Both frameworks seek to isolate web developers from HTTP, but due to the fact that Google built GWT from the ground up with AJAX in mind, GWT offers a cleaner abstraction, better type safety, and a lower learning curve. When it comes to AJAX and JSF, you're at the mercy of which functionality your JSF components offer. You must write anything beyond that (including your business logic) in Javascript. With GWT, you can stick to 100% Java.
Now, on one end of the spectrum we have request/response, action-based frameworks such as Struts Action 2 and Rails which work great for traditional web applications, and on the other we have GWT which enables you to build rich, component-based AJAX applications. By comparison, JSF seems to awkwardly fall somewhere in the middle. You might argue that JSF is meant for any view technology, not just AJAX, but does anyone really use it for anything else? I don't see myself writing JSF code once and then sharing it between my web site, mobile phone XHTML web site and Swing application. I'm perfectly content to push common functionality down into the service layer.
Disclaimer: If you're a regular reader, you probably already know I work for Google (but, much to my chagrin, not on GWT). I do work on Struts Action 2.
30 Comments:
One of the good things the JSF guys did was to provide hooks for building tools(IDE). Thats the reason we see IDE(s) which provide drag-drop development of JSF based UI from many vendors. GWT seems to loose out on this front. Developers will have to wait for Google to come out with a IDE plugin for GWT based UI development.
Ha ha, nice try. First, the important parts of GWT are Open Source, so everyone already has what they need to build a WYSIWYG builder. Think how easy it would be to create a visual builder using GWT itself... you could reuse java.beans!
[quote on]
When it comes to AJAX and JSF, you're at the mercy of which functionality your JSF components offer. You must write anything beyond that (including your business logic) in Javascript. With GWT, you can stick to 100% Java.[quote off]
I must to say that I disagree with both your statements.
1. JSF is a server side technology. So, it does not assume or required to write business logic with Javascript. Even, we are speaking about AJAX, it is still true.
2. GWT produces the client-side Javascript widgets. The server side is really barren. At least, for the current version. It does not matter how you write the code, it is more important what you have in the result. In the result, GWT generates Javascript and Javascript works in the production.
1. JSF runs your Java code on the server because it had no other choice up until now; we didn't know of a better way to do it. GWT turned this assumption on its head by enabling us to run our Java code on the client.
2. Have you tried GWT? What more do you think you'll need on the server side? You implement Java services. That's it. You don't need a server side web framework anymore beyond GWT's RPC mechanism.
> You don't need a server side web framework anymore beyond GWT's RPC mechanism.
It seems like quite a dangerous thing to do, but it's just MHO. Not just auto-generating RPC (that's relatively straightforward) but rather the call granularity and SLA levels. Am I missing the point? Please, do comment.
You define the service API, so the granularity is up to you.
Might have missed it. Really? :-0) In the ancient EJB world, the granularity was pretty much prescribed by the API and the service component model. What about the SLA? Honestly Bob, I feel uncomfortable without an API, and I feel like I am not in control any more. Am I wrong?
How does the EJB API prescribe the granularity of the services you implement with it? GWT is very similar to EJB in this respect. By SLA do you mean what happens when it fails? You should probably try it...
GWT is interesting, but implemented horribly. It should've taken example from the likes of JSP to make deployment modular and instantaneous, instead of this monolithic JavaScript file. The restrictive programming set is enough that you can't really say this is a golden hammer for development. If you do need to make a request/rpc to the server to gain the full business features of the JEE stack, the opposite of GWT (such as RJS) provides an API to manipulate the client by pushing JS in the response for evaluation.
Horribly implemented? Come on. I think you're a little biased, and you're comparing apples and oranges.
When you say you want GWT deployment to be instantaneous like JSP, do you mean you want to be able to make changes and reload? You can do this if you run in hosted mode. You can't say the same for JSF components. Have you tried GWT?
Instead of a moderately sized "monolithic Javascript file," are you saying you want lots of small Javascript files? Have you ever tried this? The browser has to make a round trip for each file which slows down page load time.
What do you mean by "restrictive programming set?" The out of the box functionality? If that's not enough you can easily extend the API with native Javascript.
Are you seriously suggesting that a low-level, procedural DSL (RJS) is better than GWT's simple RPC mechanism? I'll take RMI over a DSL which manipulates browser DOMs any day.
The fact is your approach to Ajax with JSF may be cleaner than those that came before it, but it still leaks Javascript into the API and fails to componentize the UI as cleanly as GWT.
If you are looking to compare it with JSF, lets take a look at what JSF's component model offers for pluggability: rendering, decoding, validation, updating, and method invocation, all backed by a flexible data binding API in the new EL.
Now, when you look at GWT, yeah, it's fantastic and should be continued to be developed, but at the same time, it shouldn't fall into the same deficiencies as regular Swing. Swing is only now ramping up to support application-related concerns with a new JSR (I think 296).
GWT solves connectivity issues and rendering problems, but what about supplementing validation, or declarative databinding? This is why the Widget API should've taken a feather from JSF and provided composite MVC concerns in the UI around being able to attach validators, converters, etc within a localized event system on the client. That's what JSF offers, but on the server (with the associated overhead of the network). I'd like to see this functionality on the client.
As for the compilation, I did start to play around with it last week and have been reading forum posts and comments from other developers. The compilation isn't so much of an issue itself, but the fact that it's difficult for the end environment (the page) to integrate back into the compiled JS. Flex had this problem but has since corrected it with their FABridge(?).
I do hope that GWT continues to be developed, I adore the concept, but as an application framework developer, it falls short like swing for functionality that other frameworks come standard with.
To summarize, you won't use GWT because it doesn't offer declarative validation and declarative data binding?
We have to look at the big picture. Those two features pale in comparison to the design and scalability benefits, not to mention the fact that I prefer plain Java to declarative (i.e. XML-based) approaches.
No no, I do want to use something like GWT, but I'd rather work with a Widget API such that I can build a form in Java and locally validate it and have listeners associated that report/update values, assign models and have converters take care of monetary formatting, etc. These are the kinds of things that supplement JSF development via declarative component UIs.
Basically, I think it'd be cool to have a widget foundation that I could grab the FormWidget and fire 'formWidget.validate();' and have it cascade events through its children, even go as far as to have 'formWidget.update();' which will post the bound state to the server via EL standardizations of some sort.
One advantage that JSF does have in this regard with the AJAX solutions proposed at JavaOne was that each widget (or component) does have this behavior, so if I did want to validate a single component, I can just make a single AJAX request to the server to pick out that one component or pick out a parent form and have that event cascaded to its children within the full Java API/Model.
Sorry Bob, I am not a blogger, so it might be a little hard to correlate the messages.
Here's the thing. The *business* API in the old EJB pretty much dictated when you should use DTO. There was no checklist, but it was fairly straightforward. As to SLA, it's about transaction requirements and "what happens when it fails...", yes. Once the data binding is mentioned, that's what I want to hear next. Just MHO.
There is nothing wrong with EJB, it's just not enough, even if written in Javascript. I might be wrong, though. Unfortunately I don't have any constructive ideas at this point.
Jacob, I need to play with GWT more before I can say how it supports validation out of the box, but to me, this is the trivial stuff; converting Java to Javascript and enabling debugging was the hard part. The important thing is with GWT you can write these validations in Java and run them on the client. With JSF you can write these validations in Java, but as you said, you must hit the server every time you want to run one.
"EL standardizations" don't make sense in this context. Why would you throw away type safety when you don't have to anymore (in JSF you don't have type safety anyway because you're interacting w/ HTTP and JSP)? Use plain, type safe Java end to end. Go in with a Swing not a JSF mindset.
Anonymous, EJB didn't say anything about DTO. DTO is a pattern you use when you want to pass a minimal amount of data over the wire. Use it with any type of RPC framework (RMI, GWT RPC, EJB, web service, etc.).
As for SLA, no framework supports transactions in the web browser nor should they, so I'm not sure what you're worried about. At least with GWT there's less of a chance of failure because there are fewer server round trips. Make your services idempotent and forget about it. ;)
Bob,
You are missing a fundamental point of JSF. There is a common misconception about writing an application and then reusing it on another type of device. Frankly, the way you design the application from a page flow perspective is not the same (sizing, etc).
Instead it is about targeting multiple types of devices using the same exact programming model. So, while I may have totally different screens for my phone, i write them using the same tools, and calling classes that I can share with the screens for the other device types. This is a huge advantage in productivity.
Thanks for identifying yourself. Yes, I would rather use a lowest common denominator tool over the best tool for the job; that's why I still code Java in vim (sarcasm).
I think you're the one who is missing a fundamental point. If I want to write AJAX with JSF beyond what my components provide (wiring them together, business logic, etc.) without invoking the server ever 2 seconds, I must write Javascript code which isn't easily reusable in any other context. With GWT on the other hand, I can write plain Java which I can reuse in any other context.
"What more do you think you'll need on the server side? You implement Java services. That's it. You don't need a server side web framework anymore beyond GWT's RPC mechanism."
[disclaimer: I haven't tried GWT yet]
JSF provides both page control and an abstraction for rendering (the default render kit being jsp). It sounds like GWT provides an interesting way to enable page rendering, but what about page flow. JSF can define navigation rules, and better yet, with a tool like SEAM I can use a BPM tool (jBPM) to control page flow.
If GWT does support some type of page flow management, I assume it would run on the client. This raises some questions about security. Do you really want your users to be able to parse through some javascript code and figure out the success and failure navigation cases? I wouldn't.
In fact, exposing my business tier methods to the client in general makes me raise an eyebrow. The typical corporation would not imaging exposing their business methods outside of their firewall. (Hence, I've spent many an hour putting Apache in the DMZ point to Tomcat/JBoss/Websphere/etc. behind the firewall).
I would have to come up with some clever routing through a software or hardware load-balancer to make sure that people aren't making direct RMI calls to my EJB server (or however you run your business code).
I think GWT sounds interesting, and I will definitely give it a try, but I'm not so sure that it provides an overall replacement for JSF. In fact I see the marriage of the two as a great thing. GWT sounds like it would be a great render kit for JSF.
The more I thought about this the more I realized that you don't need "page flow" when you essentially have a GUI client running inside of a browser. In fact, I pulled up my Google calendar and then unplugged my network cable to see how much calendar navigation I could do without having to hit the server. To my surprise, I can do quite a bit in Google calendar without hitting the server. I can move forward in my Calendar at least 5-6 months (I didn't push the limit), I can pull up the setting window, I can switch views, etc.
The only time you have to hit the server is to do something transactional (create/delete a calendar event), or when the view changes entirely (if you have a large app with multiple views).
Are BPM/workflow tools useful? Yes. Are they useful in traditional dynamic Web app with server-based page rendering and page flow management? Yes. Are they necessary in GUI clients? Not necessarily, I've developed several GUI clients without using a workflow tool.
What about security? I have to think about it more.
So I guess I just argued against almost all of my own points and into liking GWT without having a chance to even try it yet. :)
'Page flow' is a knee-jerk reaction that doesn't solve any real problems
Will google make its calendar open source. There a lot of companies looking at implementing similar calendar functionality
same question as vivmenon will google make its calendar open- source. And compatable with GWT ? ( In my dream !!! )
Hi Bob,
I am novice to GWT/AJAX. I have a very basic question about GWT widgets.
How Can i integrate these widgets within my existing jsp page?
I am new to GWT and AJAX as well but what amuses me is the paradigm shift GWT forces What the industry has done over the recent years is moved thick clients, where the application ran on the client and maybe used data services from a centralized server, to thin client where presentation was left on the client and everything else was moved to the central server. Now GWT seems to be moving everything back to the thick client model.
Having said that, I am all about finding a better drag and drop WYSIWYG, Java GUI development environment, especially for the web. But I'd rather not see all my client applications running in one process space be it Firefox or IE.
Here is a nice article which compare JSF and Flex technologies:
http://tinyurl.com/2fc7gf
I see tremendous benefit in the GWT in terms of creating a highly usable client environment as well as having a comfortable and efficient development environment that doesn't depend on a huge technology stack. However, I have worked in a JSP/MVC environment for the past 7 years (4 with a roll your own and 3 with Struts) and I can't readily see how I can use the GWT to implement an MVC pattern. I do like what I see in terms of moving the validation, interaction and processing down to the client. I do not see how the GWT will deal with the System flow. In a complex system the flow is dictated by events beyond the client. For example, the role of the user may dictate a different path through a series of pages. Not all systems fall into a convenient bag so that I only need a calendar thing, map app or whatever.
So does that mean that the MVC was a bad idea or is there some other framework/pattern that I can use with the GWT. I like how the documentation suggests to view the RPC layer as a lightweight gateway but where does the GWT leave the whole navigation aspect. Can I still submit pages to a Controller Servlet?
Doesn't need to request "dynamic" page to controller Servlet.
Crazy era from static html to dynamic DOM is over with GWT.
I wait around this tool at least 10 years.
No pages any more. One dynamic page with panels and widgets. Just do remove and add them.
Thanks Google !!! and do improvements.
We are waiting for 1.5!
The biggest problem with GWT is that GTW-based sites are not indexed by Google. So you develop a site but no one can see it. Some argue that you only use GWT to develop the interaction portion of the site which means that you would a framework like JSF to provide all views rendering. Google really needs to figure out how to index AJAX (or more specifically GWT-based) sites.
Here is an article talks about how to add server side validation to GWT: http://longsystemit.com/javablog
Hi Bob,
I am glad I found this blog :)
I got really interested in GWT and especially GWT-EXT.
I have been working using MySQL Tomcat and JSPs for some time now with in house developed MVC framework. Because this is an old application using different approaches across its lifetime, there are different mechanisms involved in how the requests are handled:
1) via web.xml mapping to specialized controller for specific URL mapping - 2 different servlets for two old technologies. Those specialized controllers are forwarding requests to appropriate controllers and then to appropriate views.
2) via filter for JSPs doing the same described above
Now my question is: comparing to the above classic MVC pattern, what is the design model for building "middle big" web application ? The point is that I am so used to MVC pattern, that when it comes to implement new functionality I am thinking in categories: where to hook it up - am I going to be using the same logic flow or any special handling ? Is it going to be running on one JVM ? etc. And when I do that I am thinking in terms of web.xml, specialized request dispatchers, filters etc. Now I don't think it is useful with GWT development as those things are dealt with using different approach - via RPC - am I right ? If so, that would require quite a big paradigm shift in the way I see "building" web apps. Is there sort of "policy of good web design pattern for bigger GWT apps to follow" ? ;)
Thanks a lot.
Post a Comment
<< Home