What would you go for a back-end web application: Flex, GWT, JQuery?

Question

I should build a web application for back-office purposes and one of the main requisites is a good UI.

On server-side I'll use Java very likely Spring framework, depending on what I'll be using client-side.

I think to basically have 3 choices for client-side:

• a "normal" web application, meaning JSP pages, using JQuery framework. In this case, I will use full Spring's features, complete MVC pattern etc. I've been using Spring and JQuery for 2 years, so I know these techs very well. But I also know that it's quite complicated to realize some effects, much javascript code involved, specially when dealing with ajax calls and dynamic changes of page structure.
• Flex with add-ons such as BlazeDs to integrate with Spring. I have no experience using Flex, I just read some articles and tutorial about it, but I really would like to learn something new :-)
• Google Web Toolkit, maybe with something like gwt-ext. No experience, but I really like to learn. It's plenty of support out there if I need, but I think I will struggle to maintain Spring MVC and GWT in the same project, I read that it's not so easy but there are a couple of patterns to follow.

Do you have any advice?

Thanks in advance

Answer 1

I think you can defer the choice entirely if you partition your app into separate services and a view tier. Get the back end right and you can swap view technologies in and out at will.

As for the choice, choose the one that you and your team know best. The most important consideration is support and maintenance. I'm sure all three can serve your needs with enough effort and polish.

My personal choice would be Flex and Spring BlazeDS. It's sexy.

Answer 2

It all comes down to three things:

1. What type of application are you building?
2. What is the technology skill set you're familiar with and comfortable migrating your skills to if necessary?
3. What are the technology requirements of your infrastructure?

If the application features are driving the technology, then you have to determine whether an enhanced hypertext-based application is suitable for your needs (AJAX, XHTML), or whether a more rich media technology is more suitable, such as the Flash Platform (of which Flex is a part).

No.#2 and #3 are often similar, in that they take into account your teams' existing skillset and infrastructure. If your application requirements are such that the application can be deployed with either technology, then you need to gauge what is the skillset and infrastructure support: if you're already using Java and your team is mainly experienced in AJAX, then go with that; if your team has more experience in Flash/Flex and LCDS/FMS, then use that.

But I think it's a huge misconception that a Flash Platform-based RIA can be built like an AJAX-built RIA with little architectural changes, or that you can "partition your app into separate services and a view tier... and you can swap view technologies in and out at will." That my friends is a recipe for disaster. Building a Flash Platform/Flex application means that the backend is slave to the client-side application, not the other way around, since the application intelligence will for the most part reside on the client. If you build a Flex app like an AJAX app, you're going to wind up with a completely overarchitected mess, I've seen it happen many times. The trick is knowing which parts of the Controller/Services to keep on the client, and which to keep on the server.

So in answer to your question, you have to ask yourself which is driving the development of this app -- the feature set, or the technology you know how to use? Often times people confuse the two, creating unnecessary personal bias in favour of one or the other implementation.

Answer 3

Flex is suitable for your purposes I'd say. Using MXML, it's very easy to create great looking user interfaces with dynamic structure changes and effects. Since you're also in such an early stage of the development, I'd suggest that you consider the benefits of using the upcoming version of Flex, previously code named Gumbo.

Gumbo offers a lot of welcome updates, specifically in the design department. For instance, it is now much more easy to create compelling looking UI's with dynamic skins using FXG, a sort of markup used to textually define graphical shapes. FXG is also a key technology Flash Catalyst, a tool used to transform designs into actual code. While Catalyst may not be usable for production quality code in it's current state, it is most certainly very helpful when creating prototypes.

Naturally, in any design the choice of front-end technology should not be coupled with the back-end, so that you are able to swap the front-end tier.

Answer 4

I have to disagree with Rusty's assessment of Spring. It's continually being updated, and it's got a lot of power.

Having said that, I'm a big fan of GWT. I can't say that it's necessarily better than any other given technology, but I like it.

It kind of depends how much horsepower you need. If you just have a hundred users, it's no big deal, but if you have a large user base, you'll need to think bigger. GWT probably works fine in those situations, but the big projects I've done were with other technologies.

My current hobby project is http://penwag.com. I use GWT for the front-end and back end, and Hibernate+MySQL for persistence. The whole thing runs under tomcat, hosted on a rapidvps.com server boasting (!) 128M guaranteed RAM, and 100MHz CPU.

If you want, you can follow either MVC or MVP patterns using GWT. But, if you're using GWT, might as well take the MVP approach, since it gives you a little better separation of concerns than MVC.

Any guesses on how big your user base might be?

Edit:

Here's a gallery of GWT apps BTW.

Answer 5

This might be the same as duffymo's answer, but it's worth repeating: Keep the client agnostic from the server.

In my current project, we have a JSON REST interface between client and server. This allows us to have as many different client implementations as we like. In face, the server could change completely from Java to .NET and none of the clients would care as long as the data API remained the same.

This kind of environment also can help pure-data testing. You can test both client and server (live and independantly) just by feeding JSON back and forth.