Thursday, May 03, 2007

Choosing a RIA web framework is seriously hard :-(

So, as I have previously said, choosing view technology is a hard job :-)

A couple of days ago, at a client, we were sitting down to choose a new web framework for doing some upcoming Rich Internet Applications (RIA). We listed the contenders and tried to score them against each other on what we found most important. The table below shows the contenders and the score we gave them (1-to-5, 1 is worst, 5 is best). The ones I have made strike-through on failed our conditions:
NameUnit testableFunctional testableQuick devel/build cycleFun factorRIA easinessPlatform independent
Tapestry 5525411
Flex2 (flash)??5455
Open Laszlo (flash)125255
Swing with JWS5?5455
All the DHTML-based ones score about the same on "functional testable" as they all rely on the same kind of tools (watir, selenium, jwebunit, ...) for doing the testing. And they score low, because previous experience have shown us, that this is hard when you get wild with the RIA functionality.

The proprietary runtime ones on the other hand, are even harder. How do you assert if something shows correctly in a flash application after clicking button x? Seems like Adobe/Mercury has something going for flash, but it is closed source/buyware and windows-only.

Quick development/build cycle
We are real tired of having to build and deploy and restart container to be able to see the changes we have made. It takes too long. This is important!

Fun factor
Do not tell your boss about this one, even though it is important too :-) We need to work with this in a long time after deciding on it. It needs to be fun too. I would simply hate writing JSPs to JSF and most probably think about quitting.

Platform independent
By this we mean: "Does the same code look and behave the same in most browsers on most platforms?". It needs to. No other than GWT from the DTHML-based ones score high on this. We feel that google has put a lot of effort in actually testing their components on many platforms. Flash and JVM-based ones score high here.

The ones who did not make it
Here are some short notes on the ones we deemed out and why:
  • As a previously big-time user of tapestry, tapestry5 was really interesting. Sadly, it is not done yet, at all, and we need something now.
  • Struts2 has something going as it predecessor was really successful, but it really didn't score that well on the "fun factor" and RIA-easiness
  • SEAM is, well ... based on the horrible JSF
  • ZK loken very promising, but I had some actual experience with it, and it seemed a bit strange to work with and did not look the same on all platforms and browser
  • OpenLaszlo also looks promising but it is also much the same as flex is, and flex looks more complete and better documented. And, with Adobes latest open-source statements on the next flex, OpenLaszlo has lost some of its appeal to us. Only thing it has got left is its ability to render to multiple runtimes, but we do not need that (and will that ever work for real anyway?)
  • Applet - does anyone ever use this for real applications? If an applet is to work in most browsers on most platforms, the client needs Suns plugin for applets, and with that comes the complete JRE. When the complete JRE is there, Swing with JWS seems more appealing to us
And that leaves
Taking out the ones mentioned above we were left with:
  • GWT
  • Flex/Flash
  • Swing/JWS
Luckily, the current iteration ends today and we are planning on doing a spike in the next, to evaluate these three contenders by doing some development of the upcoming RIA application in each framework. This is going to be interesting!

The left out ones
Of course there are others. In Java-land, there are literally hundreds. We feel we have taken the most interesting ones into consideration, but here is a bit of information on some others, that did not even make it to the list.
  • Echo2 and Wicket: I see them mostly as a special-cases of GWT. Yes, they are different, for instance Echo2 executes a lot of logic on the server-side. But basically, they can help us in the same way as GWT can with producing RIA-applications, and GWT has got google backing
  • JSF: So screaming old-style a way to do web development! Abolutely no innovation in this framework. Only plus-thing is its industry backing and tool support. But that is not enough.
  • Tapestry 4: It is nice, yes. But it would not score high on "RIA easiness" and, it is highly incompatible with the upcoming tapestry5. If one is starting a Tapestry project today, it should be on v5.
  • WebWork: Well, it is struts2 now
  • Spring Web: I think spring should stop doing the complete stack and stick to what it has done well. Simple put!
  • RIFE: Simply too much more than simply a web framework.
Why not rails?
God knows, I love it :-) But, notice the emphazis I put on the "I". Not all love learning a complete new stack and moving to a new platform. Also, I and others have a lot of investment in the Java world. We are chosing a new web framework yes, but it is going to interoperate with a large existing JEE application.


technomage said...

Ever looked at nexaweb? Or are you discounting commercial options?

Per Olesen said...

No, I had not looked at nexaweb. But I just did :-) Thank you for the hint!

I guess we actually are discounting commercial options, unless they really has something interesting going (nexaweb might, I do not know yet). One example is the flash runtime, which is just about anywhere which is nice.

Seems like nexaweb needs Java in the browser. We thought, that if are able to put the burden of a JRE install on our users (which we are not yet sure we can), we might as well go the whole way with Swing and JWS.

Anonymous said...

Take a look at thinwire when you get a chance....

Anyway, in similar boat as you. Have a largish enterprise application (struts/servlet/jsp) and need to ADD some rich functionality for a certain key function that is currently represented by a win32 C++ app (that communicates with java back-end via SOAP). Getting tired of PC/Windows issues. While we can't replace ALL the Windows app functionality (needs to talk to device drivers to talk to a non-TWAIN/SANE scanner), we hope to move most of the rest of the app to a rich web-based replacement so we dont have to deploy new win32 app updates to hundreds (thousands) of customers all the time. Needs to be able to stream images to it (https, so caching in browser not an option) and have a 'desktop-app speed' interface for data entry, lookups, etc.

Was pretty high on GWT for a while until I saw a dearth of real functional and good looking resulting apps from it. Don't get me wrong, Google has provided a nice framework, but it's really a skeleton. You have to do a LOT of prettying up and custom components to get a good desktop-style app. Plus I've heard 'bad' things about the resulting compiled javascript code cross-browser compatibility (even though that is touted as a feature).

Thinwire intrigued me because EVERYTHING is done server side and just UI updates are sent to client. The client piece is just a display engine that once written for various browsers, probably won't change too much...and compatibility issues will probably be minimal. It's still a young framework and is missing some key functionality that I would want/need (acquiring images from somewhere OTHER than a file, access to servlet session so signon to web app could 'transfer' over to the thinwire piece, etc)

Still looking myself...thanks for the post!!

Geert said...

I'm not entirely sure that your assessments and expectations of OpenLaszlo are correct. First of all, they don't intend to be Write Once Run Anywhere like Java. The multiple runtimes however allow you to have exactly the same architecture for building different applications or different parts of the same application. Some things are better done in DHTML (localization, native feel, font rendering, execution performance, memory footprint) and others are better done in Flash (video, music, multimedia, rotated fonts, high amount of animations, ...). You can reuse a lot of your code and most of it does work across runtimes, which is a nice benefit. You should really try out OpenLaszlo's DHTML engine, it's quite impressive even at this first stable release status.

Now about testing, did you see this page in the developer guide: ? Besides that, on the server-side you can write your code in a RESTful way and test the hell out of that any way you want. I'm also wondering why OpenLaszlo scores so low on you fun factor? I've worked with it for quite a while now and I really like it. I had a problem with the XML approach at first, until I started really working with it. Now I wouldn't want anything else. It allows for some pretty neat class libraries and even in some applications I generate the Laszlo XML through XSLT from a data model, pretty powerful. Also, I much prefer Laszlo's Javascript than Flex's Actionscript. It is a lot closer to what you write using DHTML and just feels consistent and right.

Finally, I found it strange to only find such a brief mention of RIFE and such an easy dismissal. The fact that it's a full stack framework that gives you immense maintainability and productivity benefits, doesn't mean that you have to use everything in the stack. People often use it with Hibernate or iBatis instead of RIFE's DB layer. Spring integration also is used a lot. The other way 'round is true too, there have been people that only use the RIFE DB layer inside other frameworks, as well as the templates, mail queue, etc etc. If you're looking for a server-side solution that is great for creating RESTful services for RIA integration, I think you should give RIFE a bit more credit and have a closer look. It's quite easy to do this since there's a full example RIA application that works with OpenLaszlo available as open-source:

Take care,


Geert said...

Btw, also don't forget that Flex only works with Flash 9, OpenLaszlo has support for Flash 7, 8 and 9.

Stefan Hansel said...

As mentioned above I'd give a look on thinwire as well.

Furthermore don't miss From a technical point it's equal to thinwire and seems to be equally 'full-featured' (when it comes to widget-support and platform-idependentness), though it's not production ready yet.
Futhermore testability is really great - start it from within eclipse and it's 'up' whithin a second - in production it can be deployed as usual as a war.

Anyway - progress there is really steady and if you don't need all the eclipse-stuff like the workbench layout/behaviour they are working on right now it's already useable now and VERY promising.
The only drawback is that you have to dig in all that OSGI and Equinox stuff if you are not familiar with it (so far - we got it running at least ;-) )

We are currently starting to do scalability tests and then see whether thinwire or eclipse RAP will be our strategic solution for a RIA framework.
Since all our programmers used to build GUIs with swing all other frameworks are no competitors for us.

Per Olesen said...

Hi all,

Thanks for all the comments!

I have had a short look at RIFE this week-end, and I will definitely give it a second-look by looking at the blabla list source.

Also, the link to OpenLaszlo testing is most helpful.

And will have to give thinwire a look too.

With respect to eclipse/rap I'm not that big a fan. I've done a little eclipse plugin development myself, but am just a novice.

Ooh, we have so much to choose from in the Java OSS jungle :-)

Jason Kratz said...

Spring MVC might not give you the 'whiz-bang' factor but it is a solid web framework so I'm not sure I understand your comment about the Spring team sticking to what it's done well. They've done a good job on pretty much everything. I'd argue that most of your list aren't 'RIA web frameworks'...they're just web frameworks.

It also appears that part of what is making choosing a framework hard is that you aren't evaluating every framework you're looking at (RIFE for example).

Gwyn Evans said...

I think you would do well to have a closer look at Wicket - Your post seems to imply you class it alongside Echo2, whereas I'd suggest that that's a mistake.

Wicket is a web framework that is "Just Java" - it doesn't need any special tools or IDE plugins but does try & ensure that you can control the markup. Incidently, Wicket has a very active community contributing "libraries and components" as well as support.

D Holton said...

Two other options just appeared:

Microsoft Silverlight - but of course that is not open source and doesn't work on linux

JavaFX - Search for F3 demos (which use webstart). I think that might be better (funner) than java with webstart, at least. Unless you want to use generics perhaps.

Scott Sauyet said...

I'd second gwyn's suggestion that you give Wicket another look. It may or may not meet your criteria, but you have it misclassified. It is much closer to Tapestry than to Echo.

Many of the ones you have (and Wicket too) are not really RIA frameworks, just plain web frameworks. They are all integrating AJAX now somehow, but the client-side richness needs to be added with a separate JS library, so some of the comparisons seem strained.

Per Olesen said...

I really appreciate your comments on this post. I'll try and give some feedback too:

To Jason Kratz: You are properly right, that my comment about spring sticking to what it is good at doesn't add anything interesting. What I ment was that, in my eyes, the real value of spring has come not from delivering a complete stack but from offering a framework with the key benefits from EJBs but in a lightweight development and deployment style AND at the same time provide good integrations to other technologies which have already been done well (ex: JMS and WS-calls). Of course, that doesn't mean that Spring web is uninteresting. Its just, ... it seems like "just another action-based web framework", but I guess you can say that about some of the others on my list too.

To Gwyn and Scott Sauyet. Yeah, I have misjudged wicket. And I will give that a look too. Thanks.

To D Holton about Silverlight, Apollo, JavaFX... I think all of them are too new for us. We are going to deliver within months. What flash really has for it is its penetration on clients out there. Today.

To those of you, who mentions that many frameworks on the list are not RIA-frameworks: You are right. They are not. We wanted to give them a chance. After all, they might have interesting components/taglibs/... that would make RIA possible through AJAX. But, they didn't.

Anonymous said...

When choosing a RIA framework you should really have a look at UltraLightClient.

CARFIELD said...

Look like you miss wicket, with is a very cool framework

Eugene Kaganovich said...

I think Stripes is pretty cool as fart as web frameworks go. Also, if you like Rails but want to stick with JRE, maybe try Grails?

Jonathan said...

Even if I do say so myself, I'd give Wicket a 5 on fun factor as well as a 5 on rapid development. We're moving very fast at my work - rolling out a major feature every week or less - and it's still fun. One thing you don't think of right off that contributes to both is that Wicket is regular Java and regular HTML. On the Java side, this means that everything you learned about OO is applicable and every line of your Wicket code is refactorable using your normal IDE tools.

Uysal KARA said...

It isn't entirely true that JSF implementations are totally uncool.
Take a look at Icefaces

With its direct-to-dom technology, you can be using ajax techniques without even noticing it. It has a bright future in my book.

Wicket is cool too.

But my current favourite is ExtJS
It produces clean, slick applications by default.

check mygwt, gwt-ext,

By using something like extjs on the client, server side frameworks importance diminishes to being able to serve json data. Even Struts 1 is ok in this task.

Spring mvc, struts 2 with their pluggable view resolvers (json views) are perfect candidates to be used with extjs too..

Anonymous said...

Well, I stumbled on your blog and looked at your comments. I think that you hugely misunderstood ZK Direct RIA. I did, at first. I've been doing the same sort of comparisons for myself.

ZK is Direct RIA meaning that the code runs largely on the server side with some Marshalling of communications between the client and server. Hence, since everything that is running is Java it is absolutely unit testable and highly functionally testable.

The development and build cycle is tremendously fast and I could show you some really slick desktop-like applications that I have built with ZK.

The fun factor you show as a 1 but who couldn't find fun in being able to code a completely functional UI in minutes and see it working on the web just through ZK's own website without any dev tools and then just as easily within Eclipse as well.

As far as RIA easiness I think that Flex may be the only technology out there that compares in terms of ease of building rich interactive UI capabilities, but you are constrained to the flash player within the browser.

ZK is rather platform independent. But I agree that there is some variation between how it renders under IE vs. Firefox vs. Chrome

I'd like to see you update this comparison based on what you have learned in the past two years and how these technologies have evolved during that time.