The Play framework makes it easier to build Web applications with Java

A web app in 10 minutes using Play! from zenexity on Vimeo.

The Play framework is a clean alternative to bloated Enterprise Java stacks. It focuses on developer productivity and targets RESTful architectures. Play is a perfect companion to agile software development.

The Play framework’s goal is to ease web applications development while sticking with Java.

Play framework 1.0.3 documentation

Download Play Framework

Way back in January, I wrote about how my colleagues and I were evaluating Ajax frameworks to build a SOFEA-style architecture. To make our choice, we used the following process:

1. Choose a short list of frameworks to prototype with.
2. Create an application prototype with each framework.
3. Document findings and create a matrix with important criteria.
4. Create presentation to summarize document.
5. Deliver document, presentation and recommendation.

When I wrote that entry, we had just finished step 2 and were starting step 3. I first wrote this blog post a week later, when we delivered step 5. Here is the comparison and conclusion sections of the analysis document we composed.

Framework Comparison
In order to evaluate the different frameworks against important criteria, we created a matrix with weights and ranks for each framework. This matrix shows how our weighting and rankings lead us to the winner for our project. You can view this matrix online or see below for a summary.

Note: Criteria whose values were identical across all candidates were weighted at zero. Charting capability was weighted at zero b/c we decided to use Flash for this.

This matrix indicates that GWT is the best candidate for our team to develop SOFEA-style applications with. In addition to the matrix, below are graphs that illustrate interesting (and possibly meaningless) statistics about each project.

Conclusion
After working with the various frameworks, we believe that all the frameworks were very good and could be used to write applications with. If all weights are equal, these frameworks were almost even when compared against our evaluation criteria. The graph below illustrates this.

Even after applying the weighted criteria, the evenness doesn’t change a whole lot.

Without considering the even or weighted criteria, we believe the decision all comes down to what the developers on the project feel they will be most comfortable with. If you’re developing with Dojo or YUI, chances are you’re dressing up existing HTML and possibly using progressive enhancement to add more rich functionality. On the other hand, Ext JS and GWT are similar to Swing programming where you build the UI with code (JavaScript for Ext JS, Java for GWT).

The tools available for JavaScript development have gotten increasingly better in recent years. IntelliJ IDEA has a JavaScript Editor that provides many of the same features as its Java editor. Aptana Studio also has excellent support for authoring and debugging JavaScript. However, we believe the Java debugging and authoring support in IDEs is much better. Furthermore, we are more familiar with organizing code in Java projects and feel more comfortable in this development environment.

Based on this evaluation, we believe that GWT is the best framework for our team to develop SOFEA-style applications with.

Flash Forward to Today…
The core GWT library from Google doesn’t have a whole lot of widgets, nor do they look good out-of-the-box. So early on, we experimented with two alternative implementations that continue to leverage GWT concepts and tools:

• GXT: a GWT version of Ext JS
• SmartGWT: a GWT version of SmartClient

Unfortunately, over the past few months, we’ve found that both of these implementations are too heavy for our requirements, mostly because of the file size of the generated JavaScript code. For example, a feature I wrote generated a 275K *.cache.html file using GXT. After determining that was too slow to give users the initial “pop”, I re-wrote it without GXT. After a day, we had an application with *.cache.html files of 133K. Yes, that’s over a 50% reduction in size!*

Because of these findings, we are proceeding with the core GWT library from Google and adding in new components as needed. It is cool to know you can make a UI “pop” with GWT, as long as you stick to the core – close-to-the-metal – components. For those applications that can afford an initial “loading…” state, I’d definitely recommend looking at GXT and SmartGWT.

* To make refactoring easier, I copied GXT MVC into our source tree and modified all imports.  (Via RaibleDesigns)

This past week, my colleagues and I have been researching Ajax Frameworks. We’re working on a project that’s following SOFEA-style architecture principles and we want the best framework for our needs. I’m writing this post to see 1) if you, the community, agree with our selection process and 2) to learn about your experiences with the frameworks we’re evaluating. Below is the process we’re following to make our choice.

1. Choose a short list of frameworks to prototype with.
2. Create an application prototype with each framework.
3. Document findings and create a matrix with important criteria.
4. Create presentation to summarize document.
5. Deliver document, presentation (with demos) and recommendation.

For #1, we chose Ext JS, Dojo, YUI and GWT because we feel these Ajax libraries offer the most UI widgets. We also considered Prototype/Scriptaculous, jQuery and MooTools, but decided against them because of their lack of UI widgets.

For #2, we time-boxed ourselves to 3 days of development. In addition to basic functionality, we added several features (i.e. edit in place, drag and drop, calendar widgets, transitions, charts, grid) that might be used in the production application. We all were able to complete most of the functionality of the application. Of course, there’s still some code cleanup as well as styling to make each app look good for the demo. The nice thing about doing this is we’re able to look at each others code and see how the same thing is done in each framework. None of us are experts in any of the frameworks, so it’s possible we could do things better. However, I think it’s good we all started somewhat green because it shows what’s possible for someone relatively new to the frameworks.

For #3, we’re creating a document with the following outline:

Introduction

Ajax Framework Candidates
(intro and explanation)

  Project Information
  (history)
  (license / cost)
  (number of committers)
  (support options)
  (mailing list traffic (nov/dec 2008))

Matrix and Notes

Conclusion

For the Matrix referenced in the outline above, we’re using a table with weights and ranks:

Our strategy for filling in this matrix:

• Customer adjusts the weight for each criteria (removing/adding as needed) so all weights add up to 1.
• We rank each framework with 0, .5 or 1 where 0 = doesn’t satisfy criteria, .5 = partially satisfies, 1 = satisfies.

The list of criteria provided to us by our client is as follows (in no particular order).

• Quality of Documentation/Tutorials/Self Help
• Browser support (most important browsers/versions based on web stats)
• Testability (esp. Selenium compatibility)
• Licensing
• Project health/adoption
• Performance
• Scalability
• Flexibility/extensibility
• Productivity (app dev, web dev)
• Richness of widget/component library
• Charting capability
• Ability to create new widgets
• Match to existing Java team skill-set
• Ease of deployment (on Ops, QA, Users)
• Degree of risk generally
• Ability to integrate with existing site (which includes Prototype)
• Easy to style with CSS
• Validation (esp. marking form elements invalid)
• Component Theme-ing/Decoration
• CDN Availability (i.e. Google’s Ajax Libraries API or Ext CDN)

What do you think? How could this process be improved? Of course, if you have framework answers (0, .5 or 1) for our matrix, we’d love to hear your opinions. (by Matt Raible)

Compass is a first class open source Java Search Engine Framework, enabling the power of Search Engine semantics to your application stack decoratively. Built on top of the amazing Lucene Search Engine, Compass integrates seamlessly to popular development frameworks like Hibernate and Spring. It provides search capability to your application data model and synchronizes changes with the datasource. With Compass: write less code, find data quicker.

As of version 0.8, Compass also provides a Lucene Jdbc Directory implementation, allowing storing Lucene index within a database for both pure Lucene applications and Compass enabled applications. Note, when using Compass, using a database as the index storage requires only updating configuration settings.>>Reference Documentation