This years JavaOne was filled with JSF, Ajax and even more the combination of the two. On the Pavilion several commmercial vendors were selling their ajax enriched jsf components. The blueprint team showed us the petstore. Oracle showed us how to build custom ajax enabled jsf components. And so on.
In my previous post I noted the Google Web Toolkit hadn’t landed yet completely in my java wasted brain. After four days of conference my brain is still completely wasted with java (two very positive exceptions, I saw the Ruby on Rails framework running on a java VM using JRuby! and I saw some really Groovy things a java programmer can only dream about) but I found some spare time to play with google’s new toy. While the conference only had one presentation about GWT (compare it with all those ajax and jsf sessions) the rumours/facts (find out yourself) on the internet are spreading. And somehow nobody seems to write something really interesting about JSF.
Is there a reason. Yes ofcourse. First it is the hype. GWT is new so GWT should be cool! Second, al the Ajax/JSF things are actually well known already (otherwise it would be impossible to have such a huge coverage on the conference). But between the rumours/facts I could not find out when to use JSF and when to use GWT?
Using GWT you will run into two major drawbacks. The amount of javascript that need to be downloaded will increase (lineair?) with the complexity of the interface. The KitchenSink example application is relative simple but already needs a 100kb of (compiled/generated) code. The other drawback is that your UI is fully (and I really mean fully) decoupled from your server logic. It’s like a Swing or Flash app making RPC calls. And altough very beautiful (designwise) not always as handy and productive as wanted.
GWT also has a lot of advantages. And they are obvious. No more javascript hackery. No more browser problems. All is taken care of by the toolkit. Another major advantage will be the usage of bandwidth after the application has been loaded. It will be minimized to the necessary RPC calls in order to add business functionality to the application. Which at the end will increase user experience. Using this approach state can be managed on the client (and/or in the database). And finally, the support for browser history works wonderful well.
But the biggest advantage is the fact it is a one stop shop. And here the biggest disadvantage of JSF had been mentioned. JSF is just like GWT (and Echo2 and several others) a component oriented approach for building rich web applications but it will allow you to combine several techniques together. It gives you the possibility to mix javascript library x with library y. It’s like combining Swing and SWT on the desktop. Javascript libraries are becoming the assembly languages of the web. And combining assembly languages does not feel right. (By the way, using Tapestry or Wicket this same problem can occur)
So when to use JSF and when to use GWT? I can’t answer this question. When all those beautiful JSF components provided by one and the same component vendor are being used and nothing more (not even self written ones!) JSF still seems a good choice. But if you can accept the drawbacks of GWT, I probably would recommend to at least investigate the possibilities GWT is opening up. (Or take a serious look at Echo2!)
May 20th, 2006 at 10:40 am
The major question with GWT is IMHO why Google is doing this? I cannot find an answer why we should use GWT. I have not tried GWT yet but it just do not feel good. Echo2 has nice tooling support and does the job wel so why dive into GWT.. I might as well use the DoJo framework.. The question still stands what is Googles intention in releasing GWT?
May 20th, 2006 at 3:51 pm
Yep…. why is GWT doing this, especially if you realise that they only gave away a tip of the iceberg!!!!…. as they have much more… but it’s not new what they do, have a look at: http://j2s.sourceforge.net/
I do like the Echo 2 approach: the way they set up their ajax client engine is very strong. GWT still has to learn from that!! (concerning your remark: the linear impact on the client by GWT). Echo also has a nice eclipse plugin (costs $500), generates “clean” code and speeds up your development a lot in assigning properties/events to your (Ajax)components. Tried, Played with it, got the tshirt….. and Echo works very nice if you come out of the SWT/Swing evironment, even event methods are named the same
I am still playing with combi’s: wicket/Dojo, Bindows or qooxdo and wicket/lazlo.
) model and to keep maintenable code!!!
I am partically interested in building SPI (new hype: Single Page Interface
Wicket filosofy: “we focus on one thing and do our best to let that work perfect”. In forums you find that they are bascially not interested in HTML, so you have to do some work yourself and setup your own rich Ajax environment!! And that’s nice about Echo 2, they also contain a rich toolbox of Ajax enabled components which work pretty good I have to admit
I mean…. like you mentioned: it doesn’t feel right to go and mix a Dojo/Prototype/qooxdo etc… yourself and get all messy interfaces working parallel….:(
May 20th, 2006 at 9:12 pm
Fogot to mention this nice overview of current Ajax frameworks
Cheers
May 22nd, 2006 at 3:27 am
Unlike Echo, GWT does not go back to the server for every user interface interaction — it only sends messages back to the server when it is told to, via RPC or some other mechanism. All of the samples shipped with the download run perfectly with no server in sight….
May 22nd, 2006 at 9:14 am
How about Adobe Flex 2.0?
When you accept the fact that your UI logic is completely decoupled from your application logic (as with GWT, which imho is not a major drawback), I think this is a very productive option. I haven’t played with it lately, but (as you know) we used it on our internal RADRace and I was very impressed with what is in their beta release.
May 22nd, 2006 at 9:31 am
Indeed, why is Google releasing GWT? What are their intentions and is there a founded reason to be suspecious (or not)? About Echo2 vs. GWT: When you do not care about session load, echo2 is indeed a very nice choice. When session load is an issue (for example when dealing with a public website), Echo2 can be killing and GWT seems a good candidate.
May 22nd, 2006 at 9:46 am
About flex: the nice thing about GWT is you don’t have to learn another xml dialect. Instead it is all plain java. And ofcourse with flex there is a licencing issue. But you’re right, Both flex and GWT are fully decoupled user interfaces. By the way, there can be a (major) drawback. Namely, for every (and I mean really every) client server interaction you need to setup RPC facilities. When comparing this with the Echo approach, a client server interaction is nothing more than an event handler declared the Swing-way.
May 22nd, 2006 at 3:09 pm
Did any of you had the oportunity to play with ZK?: http://zk1.sourceforge.net/, looks pretty cool and has the “thing” of doing your layout yourself in markup language instead doing it “swing-way” as in echo 2…
May 22nd, 2006 at 4:12 pm
I’ve looked briefly at ZK but I’m not very charmed of XUL alike solutions. Why describe your user interface using a distinct xml notation (which by the way can be extended using some kind of javascript based event handlers)? The power of both GWT and Echo is their 100% java syntax. But as said, I only looked briefly so maybe I missed some unique features. Or maybe I’m just missing the ‘thing’ at all
May 26th, 2006 at 8:21 am
Re Ed on Wicket:
Why do you think users/ devs from Wicket are not interested in HTML? What do you mean? Wicket’s mission is to be a framework for enabling component-oriented, programmatic manipulation of markup, where you can read markup as HTML. Whether you prefer Echo 2 (which I think is a nice framework btw) or Wicket for most people comes down to whether they like to work directly with the markup (Wicket) or with layout managers (Echo, but also GWT). I think there is something to say for both, and as I usually work with seperate HTML producing designers, Wicket’s approach works well for me. Otoh, a good layout manager might take a lot of the tedious work off your hands, and may make sure your pages are properly accesible etc.
Re Ajax (and Wicket). I think Wicket has pretty good support for Ajax. In fact, you don’t have to do any javascript yourself nor have to look for other js libs. Wicket comes with ajax support out-of-the-box, and it let’s you do things like re-render and update multiple components pretty transparently. If you’re interested, please check out wicket-examples, or e.g. see http://wicketframework.org/ExampleAjaxCounter.html
My opinion about GWT is that it is a nice framework. The idea is not that new, but it seems to be executed well. IMO, the decoupling from the server is both a weakness (less elegant programming model) and a strenght (forces you to program to how the deployment actually works). GWT allows it’s users to program in an object oriented fashion (yes, with behavior AND data/state) while hardly having an impact on the options for scalability. GWT is pretty new now, but Google has the chance to make it big if they want. They got the brain power and the name. Though if they don’t open up quickly (cvs/ svn access, an issue tracker that is open for submitting to everyone, source code of the generation tools) I doubt they will gain the momentum to be the real framework killer. I hope it will get big, as I think it’s much better than many of the alteratives out there.
One of the things that limits it’s use is that it is ajax only. The apps I’m working on now have to work without JavaScript too. GWT does not provide a fallback scenario, something that a framework like Wicket does. That may or may not be a problem for you.
May 26th, 2006 at 8:49 am
To clarify a bit more on what Eelco said:
Wicket provides all the necessary javascript to allow you to submit data via ajax with a get and a post, this means you can have an ajax link pass data back as well as submit a form via ajax. This is all out of the box, and requires no javascript writing from the framework user. Wicket also provides the javascript for parsing an xml markup envelope returned to the ajax request that can update multiple tags on the page, this means you can update multiple components on the page in one go also without writing javascript.
So what you get is the ability to interact with your application completely via ajax and have that interaction update any parts of the ui. An interesting thing wicket also provides are a few ajax “fallback” components, these components utilize ajax when it is available, and use a regular request when ajax is not supported or javascript is turned off. From the developer’s point of view the code is identical with the exception that you need to specify which components need to be updated if ajax was used, so this is a very nice and easy way to write applications that degrade gracefully.
What wicket does not provide is javascript for effects, drag-and-drop (which we hope to have soon), and other bells and whistles. Tihs is where integration with third party libs such as dojo/scriptaculous is necessary. But I would imagine the same would be needed for GWT, JSF, or any other framework that does not provide the javascript you need.
What you can do in wicket (with a little collab from component authors) is to make sure that these libs are only included once in the header, so multiple components can reuse libs already included by other components which makes life easier.
May 26th, 2006 at 3:55 pm
Hellu,
“Wicket Don’t care about HTML”.
They have a well defined focus which is just a part of the full development stack (in their introduction).
They don’t care about HTML, they care about rendereing engines, which are just sub projects. They care about Markup languages, but not in particular HTML (discussion between their main developers in the wicket developers forum).
Yep, Wicket has a nice Ajax support, I know their examles: build with it, tried it and got the tshirt
… Buttttt… like Igor said: they don’t have all nice bling blings… YET… and that you can find in other frameworks like Echo… Like Okke mentioned earlier… I don’t like combining all kind of javascript engines. I prefer having one ajax engines that coordinates everyting to the backend instead of combining all kind of exotic ajax libraries……. and if you want your designers do the html … have a look at ZK or indeed wicket… because Echo might not be right choice then.
Yepp.. I agreee: it depends what you want (the project you do)… of what you choice is: wicket.. echo… etc… I mean: Echo is nice… but you give a lot of control out of your hands… while with Wicket you still have to do a bit more yourself … like setting up the Ajax communications…etcc… … Ofcourse it depends what you want…and that will be probably be different everytime… The nice thing of Echo: it handles a LOT for you… and don’t be afraid: if you want it different, Open source comes to the rescue
….
Have a nice wet weekend
June 3rd, 2006 at 12:05 pm
[Sorry, only now catching up on this threath.]
> And ofcourse with flex there is a licencing issue
Dit you know that the Flex 2 Framework will be available for free? For free you’ll get the entire sourcecode for the UI framework and a free compiler to build GUIs using MXML and ActionScript 3. This way you can build full blown Rich Internet Apps for free whilst consuming regular webservices or HTTPRequests.
You will only be paying for the Eclipse plugin if you’d like to have better development options, or for the J2EE server component for advanced backend integration (remote java objects, messaging infrastructure, Spring and Hybernate adaptors or JMS integration).
> the nice thing about GWT is you don’t have to learn another xml dialect. Instead it is all plain java
I wonder, without having played with GWT, how ‘plain’ this really will be. At the end you are programming in a language that was created for a JVM and we all know that a browser is far from a JVM. So how easy will it be to adjust your Java programming skills to adhere to the limitations that a browser has? I’d rather just program in the native language that was written for a specific Virtual Machine, or an XML abstraction layer on top of that.
Anyway, I’ll be at J-Spring next week so would love to catch up with you on any Flex questions that you might have.
August 18th, 2006 at 10:03 pm
probably way too late to add but…
Strikes me as a fundamental issue as to whether one should have a client side only presentation architecture or a distributed presentation layer where the MVC is spread across the browser and the backend with a protocol coordinating and syncing in between.
The Echo2 demo I tried was killer. Since I practically have forgotten how to anything but code Java - that aspect was attractive. But when I tried test harness
http://demo.nextapp.com/InteractiveTest/ia?debug
which traces the XML protocol between the client side AJAX Engine and the server…it reminded me of trussing a socket between an XWindow client and server. So my question is whether this is good or bad? The comment was made above that a big chunk of JS/CSS comes down to the browser in GWT. Fair enough but bandwidth is not instantaneous consideration. How much bandwidth over time does a distributed client server syncing solution take? Simply excellent point was above above that the distributed solution is a “sessioned” architecture. If you have dealt with the realities of deployment, production operations and any case for scale this is a considerable point.
Not mentioned thus far is the perspective on REST and the value of decoupling the view from the data and business logic. As a gut reaction, it seems better to have a presentation layer totally isolated on the client an rely on discrete RESTful services for data and biz-logic.
Perhaps pathological, but when I see these “protocols” operating between the AJAX Engines and the server (like what you see above with Echo2) it strikes me that these solutions are punching open generic access mechanisms which can be exploited or misused. At the very least, a backend application may face codepaths which were never intended. Are these distributed presentation solutions exposing a middleware on the web? On the other hand if only the intended discrete data and biz-logic services were exposed these form a concrete interface which can be no more and no less than what they are. And there is no session.
Does anyone know - does the scale and richness for something like GMail fall into either of these classifications?