Raible Designs

Should I change AppFuse's default web framework?

Currently, the default web framework in AppFuse is Struts. It's nothing fancy like Shale or Struts Ti, but rather Struts Classic. Even though Struts is not dead it's a pain in the ass to work with compared to other MVC frameworks like Spring MVC and WebWork. Yesterday, on the AppFuse Mailing List, I kicked off an informal poll about switching to a different default web framework. I think most of the people that choose Struts w/ AppFuse are choosing it b/c it's the default. Making another framework the default would likely same quite a few users a lot of headaches.

So which one should I make the default? Here's my thoughts from the mailing list thread:

I like Spring MVC and WebWork better than Struts, but I believe that WebWork is much easier to understand and develop with. Unfortunately, it's not well documented or marketed, so it's a bit difficult when you run into snags. Of course, if you contact the user community via forums or e-mail, answers flow quickly.
...
I'd like to use the framework that's simplest to understand. Right now, in my eyes, that's WebWork. I think JSF and Tapestry are excellent too (as component-based frameworks), but Tapestry's learning curve is difficult and JSF has a lot of issues (like everything is a post). Hopefully things will get better with JSF 1.2, but it's probably another 6 months before MyFaces supports 1.2 - let alone the app servers.
...
Maybe we should just drop Struts altogether - or replace it with Struts Ti? Unfortunately, it'll probably be a while before it's ready for production (I doubt it's that useable now).

Of course, if a WebWork Book was out - this move would be a lot easier. I did talk to Patrick Lightbody on IM yesterday and he said "it's done" and supposedly he has copies, but I haven't seen anything on the WebWork Blog to prove this.

A related question: how much would it hurt AppFuse if I dropped Struts altogether and went with something like Wicket instead? I'd like to keep that cap at 5 web frameworks. If I dropped Struts and added Wicket, I might lose potential users, which might not be a bad thing.

Posted in Java at Sep 15 2005, 07:32:51 AM MDT 32 Comments

Comments:

Although the book is a little out of date, Webwork is well documented in Java Open Source Programming. It documents other Opensymphony components pretty well also, in a pre-Spring era.

Posted by Mathias Bogaert on September 15, 2005 at 08:16 AM MDT #

Mathias, I agree that Java Open Source Programming is a good intro guide to WebWork. I have the book and recently loaned it to Jim for some tips on how to write a Shopping Cart with WebWork.

Posted by Matt Raible on September 15, 2005 at 08:22 AM MDT #

I think the problem is symptomatic of a general unsurety in the community of the next-gen MVC standard. Struts hasn't been the best framwork for a long time, but it's the oldest, probably still the most mature and certainly the most used. It's hard to see which framework will eventually succeed it in terms of the defacto standard, but it will probably be JSF, right? Perhaps it would be better to frame the debate in terms of "when" should you switch rather than "what to". Either way I'll be very interested in seeing what you decide upon and hope you don't have to switch again too soon after. For all the advantages of multiple competing framework systems, it would be better if Sun had made their eventual offering good enough to standardise on.

Posted by c on September 15, 2005 at 08:30 AM MDT #

C, Yes, that would have been nice, wouldn't it? Unfortunately, Sun went the "Not-Invented-Here" route and decided to create something new, by committee, with the spec lead being the guy who brought you the abomination that is Struts. They didn't bother to talk to those of us who had been building better web app frameworks, and they didn't bother to even learn from those better frameworks (e.g. WebWork's templating system for UI components instead of hand-coding out.println() for renderers). So, they get what they deserve with JSF. Unfortunately, they end up harming a lot of members of the community who still think specs are good in the process... At least until the 5 year cycle comes around and people see JSF as the Entity Beans of the web-tier. Anyway, Matt, the "WebWork in Action" eBook should be out in the next couple days (maybe today?). The print version should be out shortly after.

Posted by Jason Carreira on September 15, 2005 at 09:06 AM MDT #

Just my two cents, but I think that adding a component based framework as an option would be an excellent idea. You're right that Tapestry's high learning curve could be a huge turn off for the "quick start" nature of appfuse. I would definately recommend Wicket instead. The learning curve is much easier than even webwork or spring MVC. *ducks undercover*

I've used all of the web frameworks that you're talking about and webwork _used_ to be my number one choice. Not anymore...

Posted by Ryan Sonnek on September 15, 2005 at 10:17 AM MDT #

If you must get rid of Struts Classic, I'd vote for WebWork. You are correct saying Struts Ti isn't ready for "prime time", but it is usable now and even has several sample applications, one of which shows JSF as the view layer. Since Struts Ti is built on WebWork, it will be easier for Appfuse users to learn Struts Ti down the road if Appfuse promoted WebWork. I even heard the rumor that Google chose WebWork for all its Java web apps... Speaking of Appfuse, Van gave a great Appfuse demo at our Silicon Valley Web Developer JUG last week that was my first taste of Appfuse. I particularly liked your "clone" capability and instant, working application. When we get more of the internals of Struts Ti nailed down, I want to talk with you about integrating some of Appfuse features into Struts Ti as I think our goals are quite similar - make it easier to develop web apps.

Posted by Don Brown on September 15, 2005 at 11:04 AM MDT #

Dang these math problems are hard. Good think I can copy/paste into Google search to get an answer!

Anyway, Matt, as you might remember I said I'd been letting everyone at my company know about AppFuse. Well, they finally laid out the criteria they wanted in such a tool, had a shootout with various tools, including yours, and they ended up selecting JAG. Part of it was they felt the result of running AppFuse was too bulky and prescriptive (not as flexible for non-supported stuff, which I think that was Hani's rant). They seemed to think that JAG was easier to customize using templates so they could add in home-grown stuff easily to get generated along with the OSS parts. I wasn't part of the shootout so I hope to perform my own later this year and see if I agree with their choice and also understand how to use the tools better.

So I guess if I were to recommend anything, maybe it would be to slim down AppFuse, possibly by breaking it up into discrete pieces that are easily integratable but not automatically integrated, then allow lots of room for other stuff to get plugged in. A working app at the end is great, but a little bit of wiring after generation isn't bad if it buys more room for one-off flexibility and for users to write their own plug-ins. That might make the web framework issue more manageable.

I guess there's really three things - a code generation framework, code generation components, code generators that uses the framework - that make up the whole. The framework is probably the most important piece for you to maintain, but opening up the components and generators for others to maintain/contribute would make it more useful. Then Don or Jason or whomever can come in and do their own component for their web framework, which a) means you spend less time on it, and b) the framework experts (read:authors) can do a high-quality job writing/maintaining/upgrading components, probably quicker than you could.

Posted by gerryg on September 15, 2005 at 11:47 AM MDT #

I'd like to see Wicket in, Struts out. As far as "Default" goes, I'd say Spring - just for it's popularity. My two cents on the last post "possibly by breaking it up into discrete pieces that are easily integratable but not automatically integrated" is that I'd rather have all the components already in. Appfuse is a big solution - that is what's great about it. There are other small solutions that are great too. I really enjoy Rails because of the out-of-the-gate completeness, not the options.

Posted by D. Jung on September 15, 2005 at 01:56 PM MDT #

I too would vote for wicket as replacement for struts. Keep up the good work!

Posted by Emiel van der Herberg on September 15, 2005 at 02:15 PM MDT #

D - I wasn't suggesting that the components not all be part of the same package and not be ready to run. The and components would be wrapped in a generator that does what AppFuse does today. But re-engineering a bit to have a framework that better supports user-written components and and/or generators. Then you wouldn't have to wait for Matt to implement Wicket -- you'd just go write that component yourself and offer it up, and the end-user just takes and swaps it in as an option in the AppFuse generator or into their own custom generator. Or wait until the Wicket authors write a component. The whole idea is to spread the work out so there's more options and the options are completed faster (and hopefully of high quality). In my opinion there shouldn't be a 'default'. You pick what you want in it and that's that.

But I was also trying to get across the point that while AppFuse is pretty much a 80% solution for out-of-the-gate webapps, it could be more. It's up to Matt whether he goes for another 10%. And whether the option of mostly-complete generated webapps are OK, too, in the cases where something new or unusual needs to be supported and an all-or-nothing approach won't cut it.

Posted by gerryg on September 15, 2005 at 02:32 PM MDT #

The WWIA e-book is available to purchase now. I just did.

Posted by Jason on September 15, 2005 at 03:21 PM MDT #

Webwork! ;-D

Posted by Bruce Snyder on September 15, 2005 at 04:37 PM MDT #

With the coming addition of JSF into the landscape of Web frameworks, I'm really concern with the future of Tapestry. I get to learn of Tapestry from using AppFuse, and I've been using it for development for a few months now. I really think Tapestry is the best Web framework mainly because it's component-based, and it's clean HTML templating system. Matt, I certainly hope you'll consider having Tapestry as the default, although I know it's unlikely. However, I do think that as user base gets large like more developer adopting through AppFuse, Tapestry shall continue to have an important role in the equation. Thank you for AppFuse, Matt, and thank you for AppFuse+Tapestry.

Posted by Vui Lo on September 15, 2005 at 05:55 PM MDT #

I would go with spring mvc for the default. It would also be nice to see spring web flow in appfuse so others can get an idea how it works. I also agree that wicket would be nice for a demo .. not the default. My 2 cents

Posted by serge on September 15, 2005 at 06:40 PM MDT #

hi matt,

i would vote for tapestry. compared to JSF, it's been around longer. sure, the learning curve is higher but recently, we've started seeing more components come up. having components is good and if more tapestry components are added, appfuse's value will start increasing without you having to do anything!!

my second vote is for JSF -- if you want to bet for the long term since there will be more than 100 JSF components in a year's time(at the least!).

BR,
~A

Posted by anjan bacchu on September 16, 2005 at 01:23 AM MDT #

I would go with Stripes... It looks extremly simple

Posted by 85.18.136.92 on September 16, 2005 at 03:28 AM MDT #

I am betting on WebWork and Wicket ;-). :alex |.::the_mindstorm::.|

Posted by Alexandru Popescu on September 16, 2005 at 07:26 AM MDT #

+1 Tapestry

Posted by Ryan on September 16, 2005 at 07:31 AM MDT #

I think Spring MVC should be default due to the capability to provide the best "compromise" with regard to flexibility, learning curve and production readiness (meaning that it is proven in the context of enterprise or relatively complex applications). I would also like to see Wicket included due to the huge potential and the ease of getting started with it. Downgrading Struts definitely makes sense, but I would rather keep Struts as the "fifth" option and would get rid of the "niche" players like e.g. WebWork. So my recommendation is: > Default: Spring MVC > Options: Wicket, Tapestry, Struts, JSF Just my two cents, Christian

Posted by Christian Kählig on September 16, 2005 at 07:49 AM MDT #

I'm going to throw my vote in for Spring MVC as the default. My reasoning is that it's well documented, easy to use, and because it's well integrated and part of Spring (which AppFuse uses heavily for IoC and DAO abstraction) it's one less system for users to have to figure out integration issues with. I think it makes AppFuse easier to learn because as users go looking up Spring IoC documentation or hitting the forums, they'll also know where to go for docs/help on the MVC framework side. Plus if a user can write Spring IoC config files they can write Spring MVC config files. There's something to be said for using fewer libraries/vendors in a solution when they integrate well and solve the problem at hand.

Posted by Todd Huss on September 16, 2005 at 11:14 AM MDT #

Isn't appfuse dead? If not, then why not just have one framework - whatever the latest and greatest flavour of the month is. You could change it every year and always have the bragging rights on the best toys.

If it is dead, then stick with Struts and the large number of people who are quietly using it day in, day out to do a job. Don't worry about the vocal minority of techno-snobs who feel the need to bile anything thats not in their vested interest. Most people care more about getting the job done, rather than pointless pi**ing contests in the ether.

The real issue is what percentage of your users are you going to screw by dropping struts? If its the least of the five frameworks then you should. Problem will be finding that out, its always the -ve drones re-spouting the rubbish of the hallowed gurus who shout the loudest.

Anyway, who cares - pick the nicest toy and long live appfuse!

Posted by Niall on September 16, 2005 at 05:55 PM MDT #

Wicket seems the most interesting to me if they continue their ajax dev - Ryan's recent ajax additions were very nice. Tapestry seemed to be a more complex framework to get up and running with - but it also has more interesting ajax components (tacos) at the moment (trees, progress bars, etc.). They also seem to have more flexibility in plugging in dojo/prototype/rico, etc.. So if I were to choose today, it would be tapestry - but luckily I can wait another month or so for my app. We'll see what happens. I'm unclear where something like DWR would fit into this mix though - I know you have mentioned this project in the past - is DWR something wicket would make use of directly in their Ajax implementation and therefore not be a component of Appfuse?

In fairness, webwork is the one framework I have not reviewed. One reason is that I could not find any examples/demos with ready made ajax/components wired. Even if it is 'superior' - I go with whoever gets me up and running quicker, and that means 'code by example'. I know ajax is the cool new buzzword, but the semantics of our domains are so large we have to have some of these components - a web client would have not even been an option for us a year ago. We intend to contract most of the web layer out to some of the devs on one of these frameworks - but I don't want to be paying them to catch up to another framework unless there is a good reason.

For the railers. Many of the api's we need are only found in Java, otherwise I would be looking a lot closer at rails - since a lot of what I need is already wired up in rails. Nitro may ease some of my concerns with the active record setup, because of the complexity of our persistence - but I have not looked into it enough yet. Luckily, I'm no longer bound by the Java only mantra anymore.

My two cents - and to be quite honest, I'm still learning.

Posted by ian on September 16, 2005 at 06:30 PM MDT #

Put me down as a vote for webwork... being the framework that requires the least amount of code makes it a winner in my books - not to mention it is easy to use and flexibile to work with. (I still don't understand why ww hasn't had greater adoption - is it just documentation that is holding the OS guys back from taking first place as most popular framework for new projects?)

Posted by Cammm on September 17, 2005 at 09:52 PM MDT #

I guess there are 2 or 3 reasons here: 1/ documentation was to spread through the wiki; even if it covers most of the things; 2/ the guys haven't done a marketting war; 3/ lack of a book on subject. Afaik at this moment they are heavily improving 1/ and 3/ is already out on the market. That's why my previous vote went to WW ;-). ./alex -- .the_mindstorm.

Posted by Alexandru Popescu on September 18, 2005 at 05:57 AM MDT #

My vote is for springMVC and would like to see RIFE as part of framework. Is to possible to have a few CRUD controllers based on pattern(I have seen that approach in https://workeffort.dev.java.net) regards, Ravi

Posted by Ravi on September 18, 2005 at 10:34 AM MDT #

My vote is for JSF, but only when it is mature enough to replace current functionality provided by Struts. To me the debate of web frameworks is similar to something like VHS vs. Beta. Beta was the better technology in every aspect, but VHS got the most backing from the heavy hitters and gained the greatest foothold in the marketplace. JSF, while not being the superior framework, is backed by Sun and has the most attention of the tool developers and business analysts. Its shortcomings will be ironed out and feature set improved. AppFuse will have greater legitimacy and serve the largest community if it continues with Struts for a while and then transitions to JSF. Maybe Equinox, being lighter to begin with, would be a good match with Wicket or Webwork.

Posted by Bron on September 19, 2005 at 10:20 AM MDT #

The Betamax and VHS argument does not quite fit here. While the initial versions of EJB was accepted by the "heavy hitters" its acceptance was abysmal to say the least and it morphed to look like an Hibernate in EJB3 because people chose Hibernate instead. So forget about what the ivory tower heavy hitters might back. Its up to the folks in the trenches. JSF will win but will do so only when it starts taking care of what we the developers want not by merely shoving a "standard" to folks.

Posted by Sib on September 20, 2005 at 10:57 AM MDT #

i vote for spring mvc as the default. this will tend to decouple the middle tier from the front end, imho, a good thing.

Posted by Ray Tayek on September 25, 2005 at 04:43 PM MDT #

Hi Matt, +1 for webwork!

Posted by Ricardo on September 29, 2005 at 11:25 AM MDT #

Wicket has made web development fun again. You should definitely go with it.

Posted by Dan G on October 02, 2005 at 04:50 AM MDT #

You might also want to consider Echo 2 (http://www.nextapp.com/products/echo2/) It's probably the closest thing I've seen to a true component-based web UI layer. Its basic premise is to provide a Swing-like API for web applications. I wouldn't build an eCommerce site with it, but it looks interesting for small to medium size intranet apps.

Posted by Percy Wegmann on October 03, 2005 at 08:44 AM MDT #

I would say Spring MVC should be the default - I started using Spring recently and it has been a big eye opener to me. Working with Spring is so refreshing. Also consider Echo2 and Google GWT as the UI tier. Those two are really cool.

Posted by Hari on June 13, 2006 at 05:17 PM MDT #

10+ YEARS

TWITTER

RECENT ENTRIES

Tag Cloud

Should I change AppFuse's default web framework?