Raible Designs

Comparing Web Frameworks Book

A publisher recently sent me an e-mail asking some advice. They received a proposal for a book that compares CakePHP, Symfony, Zend, TurboGears, Django, Struts, RoR. Here's a quote from the proposal:

We would like to compare a couple of frameworks and present their advantages and disadvantages in various applications.

Obviously, that kind of manual would be very useful for readers who are starting their 'adventures' with web applications, as it would facilitate their choosing the best framework for their particular application. The manuscript would offer a comparison of the most popular solutions (CakePHP, Symfony, Zend Framework, TurboGears, Django, Struts, Ruby on Rails) and demonstrate the main differences between each.

Therefore, the target audience would mainly be project managers, responsible for deciding on the technologies to be used for in-house projects, as well as less experienced, web application beginners.

Another purpose of the book would be to present 'good practices' in various frameworks, such as code re-factoring, design patterns and application security. From this point of view, it could become a valuable asset for experienced and learner programmers alike.

Since I got a lot of feedback from my tweet on this subject, I figured I'd ask it here.

What do you think of such a book?

Here's my response:

How do PHP books do these days? Of the list of frameworks (CakePHP, Symfony, Zend Framework, TurboGears, Django, Struts, Ruby on Rails), I think there's interest in Django and Rails, but not so much the others. And Struts sucks, so having that as a comparison is obviously going to make it look bad. I wouldn't buy it, but I'm a Java guy that's mostly interested in web frameworks that make developing SOFEA-based applications easier. In my mind, these are Flex and GWT.

The book I'd like to see would cover developing RESTful backends and SOFEA front-ends. RoR, Grails or Django could be used to develop the backend and Flex, GWT and X could be for the front-end. In reality, this is probably a tough book to write b/c things move so fast. If you decide to do it, I'd keep it short and sweet so you can get it to market and update it quickly.

AppFuse Light converted to Maven modules, upgraded to Tapestry 5 and Stripes 1.5

This past week, I stayed up a couple of late nights to do some of the AppFuse Light work I wrote about in October. I converted all web frameworks to Maven modules, as well as made them inherit from the appfuse-web project. Below is what the new module structure looks like:

At this point, the project is ready to import into AppFuse's SVN project. Here's a list of other changes I made:

• Modules now depend on AppFuse's backend and allow you to use Hibernate, JPA or iBATIS as the persistence framework. Implementations for Spring JDBC, OJB and JDO have been removed.
• Upgraded to JWebUnit 2.1, which now uses HtmlUnit under the hood and has much better JavaScript support. It also has Selenium support, but I've yet to try it.
• Ajaxified Body integrated into all frameworks. You can easily turn it off by modifying the global.js file.
• Prototype and Scriptaculous loaded from Google's Ajax Libraries CDN.
• Upgraded to Tapestry 5. Mad props to Serge Eby and his tapestry5-appfuse project for showing me how to do this. Serge became a committer on AppFuse recently, so hopefully we'll continue to see great things from the Tapestry 5 support. I really like the clean URLs and minimum configuration required in Tapestry 5. It's testing framework is nice too, but I believe it could be improved.
• Upgraded to Stripes 1.5. This was easy and painless. I'm definitely a fan of Stripes and look forward to reading the Stripes book on my bookshelf.
• Dropped support for: Struts 1.x, WebWork, Spring MVC + Velocity.

If you want to try any of these applications, you can create archetypes using the following commands:

svn co https://appfuse-light.dev.java.net/svn/appfuse-light/trunk appfuse-light
cd appfuse-light/preferred-web-framework
mvn archetype:create-from-project
cd target/generated-sources/archetype
mvn install
cd ~/dev
mvn archetype:generate # The new archetype should show up as an option

Next steps include figuring out a way to flatten the inherited dependencies and plugins so archetype:create-from-project can create truly standalone projects. Please let me know if you have any questions.

Dojo/Comet support in Java Web Frameworks

This week I'm doing a research project for a client. The main purpose of the project is to find out which Java-based web framework works best with Dojo and Comet. Here's the key requirement from the client:

It's all about Comet, we want Comet everywhere we can put it, but we want to isolate the icky bits of fiddling with pages with JavaScript. We're kind of wed to the Dojo implementation of the client-side bit, so we may as well use more of the Dojo widgets for a richer UI. For us, "works best with" needs to pay a certain amount of consideration to "fits naturally with", if you understand what I mean. I know that any framework that lets you spit out raw HTML will let you hand code in your Dojo / Comet, but that's certain to become very tiresome very quickly.

The candidate frameworks they asked me to look at are Wicket and Tapestry 5. They're willing to upgrade to Struts 2 since they're already using Struts 1. However, they don't feel that action-based frameworks naturally lead to rich UIs, so they'd prefer a component-based framework. They're currently using Seam for an administration-type application and feel it's too heavy for their customer-facing application.

Here's what I've found so far in my research. Please let me know if anything is incorrect.

• Tapestry 5 doesn't have Dojo or Comet support (Prototype and Scriptaculous are the baked-in Ajax frameworks).
• Struts 2 has old (version 0.4.3) and somewhat deprecated Dojo support. The developers seem to be in favor of removing it and promoting people hand-code Dojo instead. Struts 2 doesn't have support for Comet.
• Wicket has support for Dojo 1.1 that includes Comet support. This was written by Stefan Fußenegger and posted to the mailing list last month. I e-mailed Stefan and asked him about documentation. His response: "I lost my ambition to document it properly since I didn't receive any feedback on the mailing list. :)"

At this point, it seems that if the client really wants to use Dojo, they should use Wicket, and possibly pay Stefan to document it properly. However, they're willing to consider other options, as long as they have Comet support.

One option I thought of is to use DWR and its Reverse Ajax/Comet support. Another option would be to add better Dojo support to Tapestry 5. However, I don't think this is possible since the Prototype/Scriptaculous code is generated by the framework and would likely require a changes to switch it to Dojo.

Are there any other Java-based web frameworks that support easily creating Dojo widgets and working with Comet? Keith Donald tweeted that Spring MVC has Dojo support. However, I believe it's only for widgets and it still requires you to write JavaScript. If your framework doesn't have Dojo/Comet support, how hard would it be to add it?

Update: I also posted this question on LinkedIn. Make sure and check my question for additional thoughts from folks.

What's Next

It's been three weeks since I joined the realm of the unemployed. Fortunately, I didn't stay unemployed for long. In fact, after writing the aforementioned post, I received 5 offers the next day. Of the opportunities I received, the most interesting ones were those from companies interested in hiring the whole team. Not only that, but LinkedIn hired me back as a contractor through the end of the year. The goal of the LinkedIn contract: finish up projects that my team had started in the previous months.

At the end of the first week after the LinkedIn layoffs, we all had individual opportunities, but we also had two team opportunities. The following week (last week), I flew to NYC to meet with one potential client while the other potential client flew to Denver to meet with the rest of the team. After flying to NYC, I traveled to Mountain View to do some on-site work at LinkedIn. At the end of the week, it seemed like most of the remaining tasks at LinkedIn could be done by someone else. I told them I thought it was best that I move onto other things, while staying available for support questions. On the way to the airport, I spoke with both our team opportunities. Following those conversations, I was very pumped about both projects and confident about pending offers. You can imagine my disappointment when my flight was delayed for 5 hours.

After a fun weekend with Abbie, Jack and friends, I woke up Monday morning without a job and it felt great. However, things changed quickly. Monday morning many opportunities landed in my inbox: a 3-day gig this week (helping write open-source training), a 1-week gig in December (evaluating how well Tapestry 5, Wicket and Struts 2 integrate with Dojo/Comet for a client in Europe), a 1-week training gig in Europe next year and a 3-month gig for the whole team. I accepted all these opportunities and am very happy I'll get to work with Jimbo, Country and Scotty again next year. The 3-month gig should be a lot of fun. We're helping build a SOFEA-based architecture that leverages appropriate client technologies (to be determined) to build a kick-ass web application. I look forward to talking about the technologies we use and things we learn along the way.

So the good news is I've entered The Golden Period. The Golden Period is when you don't have a job, but you do have a start date. Unemployment is absolutely blissful during this time. The Golden Period exists a couple times for me over the next 6 weeks.

I'll be traveling to Costa Rica tomorrow for a best friend's wedding. I'm leaving both my laptop and my iPhone at home. Next week, I'll be loving life with my parents in Costa Rica and Panama. The following week, I'll be working on AppFuse all week and hope to make great progress on developing 2.1. Then I have the 1-week Web Framework Analysis gig, followed by 2 weeks of vacation in Oregon. My Golden Period begins this afternoon (for 3 weeks) and happens again over Christmas (for 2 weeks).

Yeah, life is good. Damn good.

AppFuse Light » AppFuse, Maven Archetypes and Shared Web Assets

Last night, I stayed up into the wee hours of the morning working on something I've been wanting to do for a long time. It wasn't until I was trouncing around the woods in Montana that I realized how easy it would be. The something I've wanted to do was to modify AppFuse Light to use AppFuse's core modules (service and dao). It only took me a few hours to make it happen and it inspired additional ideas.

I believe the major mistake we made in AppFuse 2.x was making it easy for user's to upgrade their applications. We currently use the maven-war-plugin and our own maven-warpath-plugin to make it possible to include AppFuse classes and assets in your project. You can easily start a new project w/o having a whole bunch of files in your project. The problem is, you can't easily use "mvn jetty:run" to work on your project. Of course, you can use "mvn appfuse:full-source" to solve this, but I'm starting to think more and more that "full-source" should be the default. This is what we did in 1.x and it seems to be the more natural pattern for folks using AppFuse.

That hard part about moving to "full-source" by default is coming up with a way to share common assets and classes among wars and war projects. Sure, I can copy all the shared images, css and js into each project - but that could become a maintenance nightmare. Subversion 1.5 with relative svn:externals might solve this, but it still seems kinda hacky. I don't want to use the maven-war-plugin because the overlay is kinda hokey and I think it's easier for users to understand when everything is in their project. AppFuse's current directory structure in SVN looks as follows. I've added indicators of what is in each directory.

Rather than using AppFuse's current (manual) archetype-creation process, I'd like to move to a more automated creation process using the maven-archetype-plugin's create-from-project feature. I'd like to figure out a way where I can have the source code and assets from web/common included in each of the other web/* projects (both when using "jetty:run" and "archetype:create-from-project"). One idea I thought of is to make Jetty/Maven aware of multiple src/war directories for "jetty:run" and "package" and then somehow hook into the archetype plugin at creation time to pull in the shared resources. I don't know if something like this is possible. If you know of a good solution to this shared web assets issue, I'd love to hear about it.

Back to AppFuse Light. If I can figure out how to solve shared resources in web modules, I can use this in AppFuse Light to move to a modular SVN structure vs. its current "use Ant to create different combinations" setup. If a modular structure (like appfuse/web/*) is possible for AppFuse Light, I believe it makes sense to move its source into AppFuse's SVN repository. Below is how the directory structure might look after this move.

With this addition and "archetype:create-from-project", we should be able to create all the basic and light archetypes automatically. We'll probably still need a manual archetype-creation process for modular archetypes, but I'm OK with that.

The last thing I'm struggling with is figuring out the best way to create archetypes for something like AppFuse. In the past, we've used dependencies to allow users to inherit dependencies and their versions. This works, but it results in a lot of duplicate XML (in projects and archetypes) for developers. Last night, I tried using a parent project instead of dependencies and it seems to work much better. Not only do you inherit dependencies, but you also inherit plugins, profiles and properties. If you inherit, you can override, which is slick.

If you're an AppFuse user, how would you feel about having an AppFuse module as your project's parent? Would you prefer that, dependencies on AppFuse or full-source with no dependencies on AppFuse? Regardless of parent vs. dependencies, I think running "appfuse:full-source" should allow you to de-couple your project from AppFuse.

Xebia RIA Framework Contest

Last year, I blogged about the Xebia Web Framework Contest where Struts 2, GWT, Wicket and MyFaces (JSF) were all used to develop the same applications. It seems they've done it again this year, comparing RIA frameworks (English translation) this time.

The winner? Flex - which doesn't surprise me a whole lot.

After this day, the Flex team, has clearly demarcated from its competitors. After two sprints of development and ownership, it could devote the third and final sprint to get rich quick and easy application, focusing only on the features and user experience. It is thanks to the wealth of high-level components, the wealth of documentation available and a maturity framework that the team has made the Flex application's most successful.

Good stuff - thanks Xebia!

What's wrong with JSF

The developers of Seam have come up with a list of major issues with JSF. I'm assuming many of these issues are fixed by Seam, but it's interesting to note how they've somewhat admitted that JSF has many flaws. Note that there's a lot of references to Struts and WebWork.

Hopefully many of these will be fixed in JSF 2. If REST support is an important feature for web frameworks, it'll be be interesting to see how the component frameworks handle it. It'd be great if they provided native support. Oh wait, then they'd be action-based frameworks.

Maven Plugin for Running Integration Tests against Multiple Containers

Don Brown has created a pretty cool Maven plugin that allows you to run integration tests on multiple containers in one go. I learned about it on the Struts 2 Dev List:

I've started adding functional tests to Struts 2 by adding a few to the REST showcase application, running against Tomcat 5.x, Jetty 6.x, JBoss 4.2.x, and Resin 3.x. The magic happens through a new Maven 2 plugin I developed called maven-itblast-plugin, which enables multiple integration test runs against multiple containers in one go. For more info, see http://github.com/mrdon/maven-itblast-plugin/wikis/home.

You might notice that this plugin is hosted on GitHub. If you want to learn how to use GitHub with Maven, you might want to see Don's entry on Maven-enabled project hosting with GitHub. Thanks Don - good stuff.

Update: Don has posted more information about this plugin on his blog.

RE: Which is the Hottest Java Web Framework?

The "Break it Down" Blog has a lengthy post on Which is the Hottest Java Web Framework? Or Maybe Not Java? Comparing Java Web Frameworks is hard because so many people are passionate about the framework they know best. Add a couple more like Flex and Ruby on Rails and its downright difficult. Nevertheless, this post is good in that it contains a lot of pretty trend graphs and it looks like the author has done some good research. It's likely the folks that will scream foul are the ones that did poor in the comparison (Tapestry and Stripes, I'm talking about you).

Surprising among the top Java Web Frameworks is the rise of Struts 2:

To quote:

Which is much more interesting I think is how Wicket adoption has stayed almost flat while Struts 2 adoption has spiked. Spring MVC/WebFlow seems to be going no where fast and racing JBoss Seam there.

The popularity of Struts 2 really caught me off guard with it being quite a bit different from Struts 1, I figured it got thrown into the "just another web framework" category, but I guess there is something in a name and it's doing quite well.

Regardless of what you think of the post and trends, you have to appreciate the amount of time the author put into it.

What's a good RIA to develop in 20 hours?

In less than two months, I'm making my annual trek to Portland, Oregon to speak at OSCON. To prepare for my talk, I'd like to develop the same application with two different combinations: Flex + Rails and GWT + Grails.

As luck would have it, I'm having a hard time coming up with a good application to write. I'd like to time-box it so I only spend 10 hours on the backend (for each) and 10 hours on the front-end, for a total of 40 hours for both applications.

Can you think of any good applications that would warrant a rich front-end and wouldn't take too long to create? I'd like to put both applications in production and generate enough traffic to be faced with scalability issues.

Over the next several weeks, I hope to start creating the applications and blog about what I've learned along the way. At some point, I hope to post an outline and a rough draft. With your help, I believe this can be an excellent presentation. If the presentation and applications are as good as I hope they'll be, it's likely I'll open source them for everyone to use.

Thanks in advance for any advice.

Update: Thanks for all the great feedback. I've posted a survey to narrow the choices.