Stripes is a contender on quality and ease of use, and imho beats all the other mvc frameworks out there in these two areas. It is polished and well documented as well. This should be enough to convince anyone who enjoys the luxury of JDK5 to check it out.
All the other mvc frameworks are either outdated (struts), too verbose (spring mvc), missed their window of opportunity (webwork), or imitators (vraptor, strecks). The only other solution remotely as radical as stripes is Seam, but it is a lot more heavyweight.

*sigh*

Just what we needed. Yet another cheerleading article for Rails. I'll admit it is less hysterical than some, but none the less... it is tiring. The article appears even-handed, but the bias is woven in deftly.

RoR has its uses, sure. But, as you bemoan all the shortcomings of other frameworks you gloss right over the fact that RoR has lots of problems itself.

I also see the same old "java developers who used Rails swear they'll never touch java again because blah blah blah". Maybe the problem isn't java but the developers in question just aren't that good and ended up with poorly designed applications( as a classic example, take the infamous Pet Store by Sun with the horribly overblown EJB approach ).

There is nothing magical about RoR. Everything RoR does can, and has been done already in java. Using the ActiveRecord pattern suddenly makes it new? Been done. Auto-generating code? Been done. Rapid development? So you can scaffold up some canned stuff in 5 minutes. Now you can get busy tying your code to your imposed DB schema, and let it reach right into your HTML. I'll code up an app in a week that adheres to good design, thanks. Ad nauseam....

Hey, RoR is a decent framework and I'm sure it is a great solution for many, but I and others can and do write powerful, lightweight, flexible java applications that have far more going for them than RoR can offer at this time. Will this change? I'm sure RoR will evolve, just like everything else. But all this pooh-poohing of java smacks of bandwagon evangelism from people who never really bothered to learn much about writing good software.

Again, RoR has a lot going for it and I'm glad to see other ideas and approaches being tried, but it is no contender to Java yet.

for those who are transitioning from struts or the traditional request/response models, stripes is definitely worth the look. it's elegant and well documented.

re: El Guapo

Sorry, I didn't realize that you "..and others can and do write powerful, lightweight, flexible java applications that have far more going for them than RoR can offer at this time". That and I also didn't realize that "Everything RoR does can, and has been done already in java."

Re: Ray and Renaud, I don't doubt that Stripes makes perfect sense, the important question is, is there a vibrant community not just of developers but of users and a supporting documentation infrstructure? Are there a wealth of plug-ins? can I look up problems in upteenmillion blogs?

This is what keeps on drawing me back to Rails for front-end development. Someone took the energy and focus out of Java web development, although there are some good alternatives, I just get the sense that few are paying attention.

Tim,

I did not fail to note the word Opinion next to your name at the article heading. You should realize that an opinion article with an opportunity to provide comments will likely result in someone disagreeing, and perhaps even poking at, your viewpoint.

Did my somewhat harsh reponse to your article come off as a troll?

When you write things like:

"Just when we think we've found a good web framework in Java that approximates the ease of Rails, something new comes out - like RJS templates, and seven Java architects jump to approximate its Ruby genius."

It takes away from an otherwise decent commentary on the state of web frameworks, and steps into the realm of RoR fandom that many are frankly sick of.

Btw, the intended sarcasm of your reply misses the point, but hey, it's an opinion article so what does it matter. People can draw there own conclusions. Hopefully, they'll see that most of the time, it isn't the toll that is flawed, but the wielder.

I have also forgot to mention I've written up on some of the ideas regarding rails in java here:

http://saturnism.wordpress.com/2006/05/17/stripes-on-rail/
http://saturnism.wordpress.com/2006/06/16/prototype/

re: El Guapo,

Seriously though, you mentioned RJS, so let's see what's going on with RJS. Follow this, the guy who created Prototype decided to work on RJS templates - have you used them yet? It's pretty compelling. You end up being able to update multiple DOM elements in a single compact piece of ruby code. So get this, instead of using link_to_remote to update a single DIV, you end up being able to script multiple element replacements in one place, and that's not even the most compelling thing, did you know that you can....

...sorry, you already said you were sick of reading more Rails fan mail. So, I'll stop for now, and you can wait until somoene like Gavin King or a Struts developer decides to learn RJS and try to approximate it on top of the J2EE framework.

Hear me now, or believe me later. Contrary to what you might think, there is a subtle shift happening. Rails is innovating first, and Java is playing catch up. Phase Two of the Great Inversion is well under way.

Note that I too use Java to create "lightweight, flexible, and synergistic" web applications. But, the problem I find is that I usually end up trying to approximate what's possible with the Rails framework. And, sure it forces you into some decisions regarding your database schema, but don't tell me Hibernate hasn't had occasion to dictate database structure? Egad, I mean the last few Java applications I wrote baby sat a database, and guess what, the object model had a striking similarity to the database structure. I mean the column names were almost the same as the property names. Yikes, my database was right there affecting my presentation layer. Who knows? maybe I should've just changed my model to make it more Java (read, difficult for the sake of being elegant)

You say you are sick of reading more Rails praise. But, I'm seeing that a lot of Java developers still have this "I'm sticking my fingers in my ears" reaction to Rails. As if it isn't even worth considering because it's got to be all hype.

The Rails Cheerleader

Guapo, you have a plethora (of opinions, most of which I agree with.) Ruby on Rails is not the desert topping and floor polish that everyone makes it out to be. Fun, but not what I'd recommend for a large application at the end of the day.

I don't think that there is as much confusion in the community as you might suggest. I don't think that we should mistake competition amongst Java frameworks as a lack of enthusiasm or following on the part of any one of them.

For example, but my cursory look at the struts community shows me that they are very active, and for the most part very excited about the integration with WebWork, and, trolling aside, all behind the Struts 2.x releases as the future of the product.

What framework will win? IMHO, I think that there is a huge following in the Struts community that will just pick up the next version because of the ease of knowledge transition... that's what I would do :)

Again, just another opinion.

re: Hefe, Hefe is right, Struts Ti (Titanium) will probably be the next ruler of the Java web application, but should it win? That's the more interesting question. Hightower makes a really compelling sales pitch for Faces in the Developerworks series linked to above.

Well, that is an interesting question. I think that in a meritocracy, the best framework would win. What makes a framework the best?

The ease of development and maintenance for the far-sighted crowd costs less and therefore is most beneficial. For each organization, that merit may be found in any one of the frameworks mentioned, due to the ease of development due to elegance of design, ample documentation, easy development semantics, or sheer knowledge of the platform.

Familiarity is a strong argument for ease, and there are a lot of Java devs and architects out there that will find that the "best" framework is the one they know the best.

Which framework has the most merit? It depends on you, your knowledge, your organization, and most importantly, your customer's needs. For me and my current projects, I'd probably go with Struts. But, unlike the techno-vangelists out there, I don't think that everyone has to convert to my favorite web app framework.

re: Hefe,

Agree with a lot of what you said, I'd argue that the concept of "best" framework doesn't exist - this is a mostly subjective judgement call informed by specific situations.

> But, unlike the techno-vangelists out there, I don't think
> that everyone has to convert to my favorite web app framework.

No, clearly. Popularity of a framework doesn't correlate to quality - again Struts 1.x was (still is) the ruler of Java web applications. It is far from ideal, and it got to where it was because of real absence of MVC solutions back in 2000-2001.

Not everyone has to flock to your framework of choice.....but, if they do, you'd benefit from healthy dynamic community. You'd be able to hire people that knew how to write apps in framework "X", and you would be constantly benefiting from people writing how-tos and documentation. There would be a really huge collection of plugins available, and you'd be able to gain from the experience of others.

Sure, you could go ahead and use a framework that no one else uses, but as soon as you do that, you stop benefitting from the network effect of community. That's my central point - at this point, there are so many choices in the Java web landscape, it is difficult for me to direct an organization to "the community" that is going to succeed. I think the jury is still out on Struts.

Bummer. What looked like a good summary, or breaking news article about Java Frameworks (as it's from OnJava: The independant source for enterprise JAVA), becomes a bloody sales pitch for Ruby. The subject should have read "What Web Application framework should you use? Ruby. Read why ..." Then, I could have ignored the article, and gone back to doing work for which I can invoice.
I think the big looser here in OnJava, as I'm a bit less likely to believe any future articles are going to be anything more than a waste of time. Perhaps I'll just get rid of my RSS feed. (Anyone know of a better source for Java news?)

You might wanna take a look at RSF. We tried to use JSF a couple of times and kept hitting brick walls, so in typical java fashion we created yet another framework. It really is quite nice though; RSF stands for Reasonable Server Faces and that's what it sets out to be: Reasonable, because if there was one thing that JSF is it's unreasonable.

1. RSF is based on Spring, and has Spring as it's container. It's IOC from the start.
2. RSF has a pure HTML templating system, (You need to mark rsf:id's in the template, but it's much purer than Tapestry or the like; the db won't leak up to the HTML.)
3. RSF has been built to obey the HTTP standard: GETs and POSTs mean different things
4. It's been designed to reduce Server load, so by default there is no server state. It does this without closing the door to such but it doesn't force you to do so. (unlike JSF!)

and more... (http://www2.caret.cam.ac.uk/rsfwiki)

If you use RSF you need never see another HTTPServletRequest, or another HTML tag in your code. Your Business Logic will be free of framework dependency (No more damned JSF DataModel!)

It's also fast.

re: cyklyzt,

How is integrating Rails with Java via JRuby any different than "coding a web service with Groovy" or "Integrating JPython with Spring". Maybe the difference here is that there is something about Ruby on Rails winning the web dev fight that just gets under your skin. If there is one thing I've noticed lately, it's that "Enterprise Java Developers" get bothered whenever someone brings up Rails. I think there's a good reason for this - it's a threat to an entrench power structure. :-)

re: Andrew Thorton, intriguing....RSF - that's the first interesting thing I've read all day. Well that and the relatively positive posts about Stripes.

The (probably) best webframwork ever? Does it exist? Since I tried Google's new webtoolkit I am convinced that GWT is the way to go. That's probably the big winner. Even Ruby on Rails looks outdated if you ask me. In fact the Google Webtoolkit makes any other webframework look like a Neanderthal-webframework. Additionally GWT brings Swing- or desktop-developer to the table.

Tim, stop hyping RoR and start hyping GWT. I mean your guys need a new hype every month, right?

http://rails.techno-weenie.net/question/2006/6/19/populate_a_form_based_on_a_dropdown_select_input_with_rjs

This looks like a revolution to you? I find it incredibly non-compelling. I might as well be coding in pure JSP.

re: Ulrich Weber,

Did you reall say, "Additionally GWT brings Swing- or desktop-developer to the table."

Swing? Wait a minute, it brings Swing to the table. Maybe it's time to bring poll functionality back to the O'Reilly network, but I'm pretty certain that the answer to the question: "Should web development be more like Swing?" would be a resounding no.

GWT, "it's as easy as Swing".

re: Ivan,

Sure, go ahead and code all of your Javascript straight in JSP - that's what Java developers end up doing anyway (except if they've decided to learn about the newer MyFaces components)

Here's an idea Ivan. Maybe you could write a Java API that abstracts a given page. Then you could wirte some methods that let you do things like insert HTML or markup into certain locations, replace DIVs etc. Then, you could write some sort of translation layer that takes calls to this abstraction and translates it to JavaScript. On the Javascript side, you would just need something that can execute that arbitrary Javascript against a given page.

So, Ivan, this way, you would be writing all of your page manipulation logic in Java. Everything would be separated - no Javascript or Java in your JSPs. That should solve the problem. Good separation of concerns, modular approach to the problem.

But, guess what? That's exactly what RJS does. :-)

If Rails is your thing but you can't quite drop java, you could look at Grails, the Rails port to Groovy. Coding by convention coupled with access to your java libs. I've had a play with it and though I'm nt sure it provides everything Rails has, it provides similar light-bulb moments.

Just thought I'd weigh in with a few words with RSF, since this "frameworks" issue is perpetually interesting.

RSF takes the view that "every framework is an insult to its users", and therefore tries to be the smallest possible insult. I wrote it primarily because I got extremely fed up with frameworks perpetually getting in the way of my writing code, and found that Spring was the first framework that had the conceptual coherence to get out of the way fast enough.

That said, I found there were a few genuinely new and productive ideas in JSF that had been missed by other frameworks - in particular I find SpringMVC problematic since although it is sensible so far as it goes, it is the way it is because it is designed to cater to the "lowest common denominator" of webapp frameworks, which is currently very low. RSF is what a Spring webapp framework would be, if one abandoned the Spring credo of "working with what is there already" and started from the ground up.

Given the current conversations about Rails and ORM solutions, I think RSF's approach to ORM (nicknamed "OTP") is very interesting - you might think of it as a little analogous to Rails since it aims to make access to storage idiomatic and transparent, but goes further in that it not an "implementation" and only an "idiom" - hence it can be layered on top of whatever ORM you happen to like using at the moment. What most people like using at the moment in the Java world is Hibernate, so RSF ORM enables you to use Hibernate ORM without seeing any Hibernate dependence in your code.

Similarly RSF enables you to write a portlet without seeing any portlet code, or indeed an "X" without any "X" code in general - for want of a better label this is the "Spring" philosophy of "invisible frameworks", but RSF takes traditional IoC further by allowing request-scope IoC using a lightweight Spring clone, RSAC to "clean the areas Spring cannot reach". I think request-scope IoC is one of the great ideas in (web) programming that is simply waiting for enough people to have experience of it - note that request scoping has been slipped into the upcoming Spring 2.0 release (as of RC4) but the implementation will probably be too slow to be practical.

Much like Spring itself, request-scope IoC is one of those things that you just have to take the plunge on in order to appreciate the kinds of problems that it solves, but it is key to RSF's easy and transparent portability and integration (Hibernate, Coccoon, JSR-168, Sakai). I'm also planning a SpringMVC integration in the next couple of weeks, but largely for "philosophical" purposes...

In terms of the "next years" I think 3 years is far too short a time for this mess to be sorted out, but I hope (actually I'm sure) that no such heavyweight JSF-based or JSF-alike (read Seam, Shale &c) will gather hearts & minds because anything based on the heavy clay of JSF is just going to crumble.

In terms of Rails itself, I think it is a fundamentally wrongly-arranged solution to its problem (loosely-speaking, that of ORM) since it tips a design on its head to be based on its storage (read, schema), rather than simply "allowing" storage to be one of the functional possibilities. This TSS article I think makes the key point by asking the question (in Rails) "What fields does this object have? You have to look at the database schema". This is the wrong answer to such a question.

Just a final word re AJAX - since RSF features pure (that is REALLY pure, not just "generally parsing pure" as in Tapestry) HTML templating, any existing AJAX/HTML component, with just the lightest packaging, is automatically an RSF component. It's this that I see key to RSF's adoption in the long-term, since peddlers of Java frameworks (especially Sun) fail to see that Java frameworks as a whole, let alone their particular framework, are *always* going to be a very small part of the complete web programming community, and so the "interoperability" promised by swapping "components" for their framework amongst their developers and users is always going to be proportionally tiny. Java is a reasonably good language, but developers have to appreciate that they will *always* be inhabiting a world with other sorts of technology, and there's no arena that more regularly rubs one's nose in this than web programming. If you follow my RSF thread on TSS I explain there why Wicket and other "heavy component" frameworks are improper inhabitants of this heterogeneous community.

As for Stripes, it is based on JSPs. 'Nuff said.

Here's my opinion:

http://raibledesigns.com/page/rd?entry=re_what_web_application_framework

re: Antranig Basman,

Awesome. Great comment, your response to this blog entry actually adds something to the debate. Clearly RSF is something much more interesting that "just another web application framework", and the separation of idiom and implementation comments re: ORM are reasons enough to investigate.

The one point I'd disagree is that, for maybe 95% of the applications I've worked on the answer to "What's properties are in the Object?" is very similar to "What's columns are in the Table?" Sure there are execeptions, but they are few and far between.

Antranig Basman:

"As for Stripes, it is based on JSPs. 'Nuff said."

If you're going to sling mud, at least please be accurate. All the Stripes examples use JSP because it is by far and away the most widely known templating/view technology in Java. But Stripes works equally well with Freemarker (several people are already using Stripes+Freemarker), and can work with any view technology.

Honestly, I think anyone who is still bashing JSP in this day and age needs to go and get a refresher. JSP 2.0 has come a long way. Even proponents of alternative templating languages tend to now admit that it's quite a resonable and viable alternative, even if it is still rather little verbose. Will you refuse to use EJB3.0 or JPA persistence because EJB 1.x and 2.x were a debacle?

Personally, I am really tired of all this RSF bashing Wicket. If you read the thread on TSS you will see Antranig is preaching "objects are nothing, dependency is everything" - I find it really funny that a person who thinks that way uses a language that emphasizes OO which just happens to be about...well...objects. Take a look at this RSF wiki page: http://www2.caret.cam.ac.uk/rsfwiki/Wiki.jsp?page=Wicket

The two biggest failings of wicket listed are:
[quote]Server-heavy - Wicket components (the controller layer) are "heavy" in that they have both behaviour and state...[/quote] OH NO!!! BOTH BEHAVIOR AND STRATE!!! NO!!! That must be SUPER BAD!!! Oh wait, isn't that what OOP is all about? Hmm...what was the definition of an object again...? Wicket has succeeded, where others have failed, in bring true OOP model to the web frameworks area. Tapestry comes pretty close, but you still have to take extra care in marking what state is and how it should be saved. In wicket you can create a component using the java extends keyword (you remember that one dont you guys? the one used to create new classes...).

[quote]Devoid of IoC - this is probably the most serious failing[/quote] Uhmm... I missed the lecture where it was proven that all frameworks must be based on IOC and not doing so will earn you a failing grade. Wicket is a web ui framework, not the kitchen sink. It doesnt force spring, or any other ioc container, on you whether you want it or not. Integrate it with whatever you want: spring, ejb3, hivemind, blah blah blah.

What have java web developers turned into? Drones who chant "ioc ioc ioc" and dont know the first thing about OOP because that skill has been lost in this space? Its really sad.

Sorry to vent here Timothy, but I think this needed to be said.

To Tim - Apologies, I get annoyed enough with people who criticise aspects of RSF from only a cursory glance at its website, so sorry if I may have done the same. To be fair to myself I don't find any mention of Freemarker or Velocity on your site, so perhaps I could be forgiven for believing these are not "first class" idioms in Stripes? Every example on your site is in JSPs.

I have also to say that I am not bashing JSPs and EJBs primarily because they are "old" but primarily because they are "bad". (Not that I had bashed EJBs yet in this thread but would be happy to do so :P). In particular what I see in Stripes is use of either taglibs or (given you mention Freemarker) "front-led" templating systems, i.e. ones which encode view logic in the template structure, which is undesirable coupling. Your view layer should really be full of pure view - in RSF, HTML templates can simply be handed to any designer armed with Dreamweaver, with the worst results possible that they hand back something that doesn't display all parts of the view, rather than one which can corrupt state. OR WORSE, a template which needs to be modified when the business model of your app changes. Of the "other" web frameworks out there, currently only Wicket allows this, with RIFE allowed as a bare outsider assuming you have designers happy to be told "don't mess with these strange-looking comments before and after significant things".

The other aspect which marks Stripes as an "old-generation" framework is the intrusion of framework dependencies such as "ActionBean" and "ActionBeanContext" on what should be the business level of the app. RSF preserves from JSF the system of pure "value bindings" and "method bindings" which promised to return your business model to being *your* business model, rather than some fake mockup of your business model invented to satisfy some blasted framework. Unfortunately in JSF through various serious structural problems (not least its handling of tables) this promise couldn't be realised.

>Sorry to vent here Timothy, but I think this needed to be said.

No need to apologize, finally a good discussion of relative merits. (outside of the bitchfest that is TSS :-) )

Two things:

1. No one has broached the topic of IoC overload. I think that Javaland has been on a heavy diet of Spring lately, and while it's a good thing (I haven't seen a Singleton in about two years), it is also creating a situation whereby people tend to knee jerk IoC - interface plus single implementation pattern far too often. Not that Spring is bad, please don't take that the wrong way

2. A criticism of everything that requires code. (re: server-heavy)

Just a quick point - my previous comment was to Tim F., not to Tim O'B (probably clear), and now to Tim O'B "people tend to knee jerk IoC - interface plus single implementation pattern far too often", actually one of the key points behind Spring is that it enables interface-free IoC, without which it really wouldn't be much good (cf. Avalon and other older-generation IoC).

Antranig:

You're right that the Stripes site doesn't mention Freemarker, Velocity et al - there's only so much time in the day and the large majority of developers these days are happy with JSP2.0. Those who want Freemarker or Velocity tend to know the tool well enough to know the 2-3 steps necessary to substitute it in.

[quote]The other aspect which marks Stripes as an "old-generation" framework is the intrusion of framework dependencies such as "ActionBean" and "ActionBeanContext"[/quote]

Well, if things like having a couple of framework classes in your import statement bother you, I guess you're right. Stripes is developed with simplicity and ease of use forefront. For example, implementing the ActionBean interface (with two trivial methods) means that the framework can auto-discover and auto-configure all the beans (backing beans, actions, whatever you want to call them). Unless you have another way of identifying said classes (without a code dependency such as an interface or annotation) you can't do this, which means you have to configure more stuff.

I'm not going to argue what the "best architecture" for a web framework, which seems to be where you want to go. For me the best is simple what helps me put together an application the quickets and doesn't cause maintenance problems etc. If you're business model is such that you can invoke it directly from the framework without any glue code (which appears to be what you're suggesting), then really all you have is a tight coupling that is completely undocumented. Are you not then imposing structural patterns or conventions on your "business model" that are specific to your presentation tier? To me that's more problematic.

But I'll also say that I don't know that I've ever developed an application which fits into the "80% of application which just read/write objects from a database" which everyone seems to talk about. Almost everything I've every done is a complex business app, where there is nothing like a direct mapping between persistence tier and screens, so maybe that's coloring my perspective.

@Tim O:
ioc: I love spring, I think its the kind of framework that solves real problems, but most importantly imo its the best of breed in its niche. What troubles me is that a lot of developers out there are zealots: everything must be a bean, everything must be based on ioc, separate state from implementation, blah blah. Why is it bad to use the new keyword to instantiate an object yourself? If you ask them that they have no good answer, they just spew ioc slogans in your face failing to make sense or produce a valid argument. Taking wicket for example: we have a great way to integrate with spring:

class UserLabel extends Label { @SpringBean private UserManager um; ...}

Now whevenever you create a UserLabel the user manager dependency will be injected for you from the spring context by a mechanism built into wicket. This is all it takes, easy right? Apparently not, there are plenty of discussions on our mailing list saying that this is not "true" ioc and therefore not a good solution. Why isnt it? Well, its because the component is not a bean, because it doesnt have setters for dependencies, because it is not the container itself performing the injection, because, because, because. Sad. We have a great solution that works very well and people are whining because it doesnt follow some idiom to the letter.

code: Dont even get me started on this one. My favorite so far has been the pageflow argument: wicket is adhoc because navigation is performed in code and not via externalized xml pageflow definition. Some people freak out because wicket doesnt require any xml, they dont even know how to begin to approach it because they are so used to those thousand line xml files they have in struts, etc. Of course the big argument is that it is not configurable between deployments - another example of zealotism. How many times was there an actual requirement to have pages be configurable between deployments? Does it apply to ALL the pages in your application? If there is a specific requirement that that minor portion of the configuration be externalized, but if not WHY DO IT FOR EVERYTHING? Just for the sake of it? What a waste of time.

What attracted me to wicket was the fact that it concentrated on code instead of configuration. I am a java developer, I like and am payed to write java code. I dont like configuration unless there is a requirement to have functionality configurable, I dont like following idioms to the letter if it sacrifices code style and functionality. Am I alone?

To Tim F:
What you say is quite true, that no insulation can come completely "for free". The RSF goals were to make the framework as easy as possible to use *subject to* making no unnecessary compromises on the insulation levels between model, view and controller. In little projects a lack of insulation just looks like a "a couple of import statements" but as architectures grow larger becomes a fatal flaw which can bring down the whole edifice.

In terms of "structural patterns and conventions on the business model" RSF imposes nothing beyond what Spring does - it should consist of a set of (configured) beans with some kind of sensible dependence structure. In fact with the use of request-scope IoC, RSF actually considerably *relaxes* Spring conventions in that it allows you to do (formerly) wacky things like addressing Hibernate-managed entities directly as part of the business model.

There is indeed a (semantic) coupling there, but it is as light as it could possibly be, and certainly better than a physical one. This actually arose not *entirely* by initial plan, but actually from the sheer necessity of accommodating Hibernate's slightly "wacked" conception of what POJO semantics were :P

In terms of the general context of the discussion, yes, I accept Tim O'B's initial point that Java frameworks, in usability, are still playing "catchup" to people across the fence, and in fact the RSF "Hibernate Cookbook" sample app was directly stolen from the equivalent "Rolling with Ruby on Rails" version primarily to prove that all of this stuff just needn't be so hard :P There is an "all-XML" version of the app that is *entirely code-free* (which is primarily suitable for auto-generation strategies that we are working on - much like the Ruby "scaffold" system it would be attractive to just drop in a .hbm file, turn the handle and get out a basic CRUD app for free, but unattractive initially to generate this app as Java), and also a Java-only version which I argue is as straightforward a CRUD app as anything out there (especially for one using Hibernate), and considerably more straightforward than many.

To catch up on a back-point of Tim O'B who said "for maybe 95% of the applications I've worked on the answer to "What's properties are in the Object?" is very similar to "What's columns are in the Table?"" yes, this is quite true, but I don't think it's sufficient argument to invert your architecture, even if were true for 99% of cases :P Actually RSF aims to solve this problem via tools rather than through "convention". The basic workflow I envisage is

i) design your app schema in whatever design tool you like (we actually use Enterprise Architect which spits out a .xmi file)
ii) Convert this schema into a .hbm file (using an XSL we have written)
iii) Run the standard Hibernate hbm2java task to create a standard set of POJOs mirroring the schema
iv) Point RSF at the resulting SessionFactory, and there you go. Your entire data model is exported as an EL-addressible namespace of beans.

The end result is a data model that is "in sync" with an arbitrarily bulky schema, but, like the equivalent Rails model didn't force you to go through the drudgery of fiddling with it by hand. And further, with a completely transparent process under your control to explain where it came from. For, as you say Tim, the 5% of cases where you have state not directly (or obviously) derivable from the schema you can lightly season the model with a few hand-crafted classes.
The further point is that your schema is defined in an environment suitably rich, yet portable enough to hold it (hbm/xmi as opposed to SQL). And yet not in an environment "too rich" as to allow virtually anything (i.e. Java). The key is everywhere to use the appropriate receptacle for the appropriate ball...

I think what is missed historically is that more than anything the success of Java is owing to the extremely rich *tool chain* that it has allowed to grow up around it (generally as a result of its fairly straightforward structure), more than any particular merits it has as an O-O language, and I think (hope) this is key to its direction of future growth. Unless Java continues to capitalise on its strengths of being a tool-friendly environment we will indeed start to fall behind the folks over the fence.

I'm with you Tim. I think that Rails will see a huge bump in usage when there is a clean integration of Rails and Java. Certainly today you could write a very clean Rails app that taps into a Java backend via web services, but if you don't need to add the complexity/overhead of adding a web service, you might not want to.

Rails alone is perfect and awesome if you are building a new web-based product. But it is hard to bring Rails into an existing corporate environment where Java is pervasive. Corporate environments tend to be slow moving; developing and deploying Java apps is currently a known beast.

The current cauldron of Java web frameworks is indeed overwhelming and frustrating. Competition is healthy, for example the Netbeans vs. Eclipse battle is a great thing; both products have improved tremendously, and that probably would not have happened if they didn't have each other to compete against. If we just had the "standard" way to do things, JSF, vs. the alternate way to do things, Tapestry for example, things would be a lot easier. But the current JSF(and its many implementations) vs. Tapestry vs. Stripes vs. Wicket vs. Spring MVC vs. Struts/Shale/Struts Action vs. Rife vs. Seam vs. Rails-knockoffs-such-as-Grails-and-Trails hurts my head and makes me want to chug the Rails Kool-Aid ( I'll be at RailsConf BTW :) ).

Like many programmers, I like new toys. Every new project is a chance to be blown away by the smartness of a fellow programmer. I like Ruby a lot, though I wouldn't use it on large projects just because it is a scripting language and it has a lot of immaturities that Java doesn't have. But after letting RoR sink in a bit... Well, it has a bunch of neat tricks which everyone that makes a framework can learn from. But at the end of the day, it doesn't have the qualities that would make me happy as a coder. Besides letting you do the trick, a framework - just like a language - should provide for some elegance in that too. I just don't see a lot of elegance in RoR besides that the code is short. GWT is an example of a framework that is innovative, helps you do the job and also seems elegant in its use.

I haven't used Rails, so will offer that disclaimer up front. However, it strikes me as one-eyed to complain about changing to another java framework ("investing the time it takes to become an expert and train others in Faces still doesn't sound like an efficient use of time") but to not state the same drawback of learning _an_entire_new_language_. Yes, I have dabbled in Ruby, it is nice, it is clean, but it is still a new language. The APIs I know and use daily need to be relearnt, and from a professional viewpoint (as opposed to someone interested in learning a new toy), I am a long way off from using Ruby based solely on the fact that finding Java Developers is a _lot_ easier than finding Ruby developers.

One Java framework that I'm looking into atm is Stripes - it is a very easy transition from struts, but removes many of the pains that we know in struts. I am still looking, and like all the new frameworks it is still under development, but it shows a lot of promise and is advanced enough to use for production use in its current state.

all the Java guyzz should understand that for WEB solutions go PHP...

You didn't mention WebObjects. WebObjects is even better than Rails and it is pure Java. It doesn't have the buzz word popularity of other technologies, but it is really one of the best web application frameworks out there.

I consider Stripes to be the best Java based web framework available today. We have looked at many other frameworks, but Stripes excels in its lightweight, great documentation, reduction of boilerplate code, easy of use, and cleanliness. Things that required you to jump through hoops in Struts are handled with incredible simplicity with Stripes. Plus, as opposed to mostly all of the other frameworks, Stripes requires no XML files to be configured, which can become a pain in the neck to modify for big projects.

well,
spring and spring mvc meets my need... RoR was fun... RoR made my development really simple... but i can produce managable code only in java project... it is fact in my case...

There is a lot of discussion here about Java & Rails, and which framework is best and which is usable. A point that I would like to raise is which framework is being adopted(or experiemented with) the most at the enterprise level (Note "enterprise level", and not "open-source based projects"). That is a point often missed. I'm talking about co-existence with legacy, existing apps, ERP's, EAI's, and so on..

Struts was the predominant framework when it came to enterprise adoption. What next? I have seen JSF and Webwork(along with Spring & Hibernate), as the technologies most used in the current applications being built in the enterprise.

What frameworks are being adopted in other places? Does rails have a place in the enterprise? (Remember co-existence with legacy, existing apps, ERP's, EAI's, and so on..)

- Yogi
http://theyogi.blogspot.com

Excellent discussion!

Thank you, Tim O'B, Tim F, Antranig, et al, for a very lively and informative discussion. I've been surveying all frameworks, all languages, for the past few months, and this is one of the best discussion/overviews I've seen. I'm about to begin building a new n-faced app (web + mobile), and I want to be sure I've looked high and low for the "best" framework/language combination before I start. I'll most likely have to live with any messes I make for the next few years, so really need to avoid any serious mistakes. Anything I work on will be built using typically-chaotic XP methods, so the base platform has to promote code that is maintainable, reliable, reusable, very flexible. My clients generally don't care what technologies I use, as long as it does what they want, is rock-solid stable, and it's easy/fast to make changes.

I've been a Java developer for 10 years now, so Java is "home" these days, just as C++ and C were "home" in the years before that. As a professional developer (and consultant) I have an obligation (to myself and to my clients) to remain open-minded, pondering whether it's time to abandon Java. If I stagnate, then I deserve the professional death that will surely follow. (Hopefully I'll get rich soon, and I can stop holding onto this tiger's tail!)

There are certainly some viable alternative languages (Python, Ruby, PHP, Groovy, to name a few) and they each have fairly good platforms (e.g., Zope/Plone, Rails, PHP-Nuke), so they deserve to be examined carefully. Each has it's strengths and weaknesses, and the same can be said for every Java-based solution I've seen or worked with. My job is to stay informed about the best-of-breed in every class of solution, and choose the right tools/methods when starting on a new project.

My current thinking is that I'll go with a hybrid solution that includes a little of everything. For the system plumbing it's pretty hard to beat JBoss. The built-in features provide a solid, feature-rich framework that handles scaling from laptop-dev, to simple two-tier, to small clusters, to massive multi-DC farms. I could go with other app-server platforms, of course, but a JBoss backbone is reasonably mature, at least as stable as it's commercial competitors, and the price/TCO are pretty hard to beat. That takes care of the plumbing, persistence (Hibernate or EJB3), and gives me a good place to hang my business logic.

The real fun starts when I look at the presentation tier, which is what most of this discussion has been about. Given that I'll be building on a Java foundation, the most obvious choice would be a Java web framework (e.g., Struts, SpringMVC, Stripes, etc.). Alternatively, the Java-based scripting environments like Jython and Groovy (maybe BSF or JRuby), along with their attendant frameworks, are definitely worth considering carefully. That would give me easy integration with the back-end, as well as the dev-time flexibility of a scripting environment. (The lack of deep integration with the Java plumbing make it pretty hard to justify PHP or Ruby.)

For page-generation, the reality is that I want it all - ease-of-use, power, flexibility, and a rich component set. I guess what I want is a flexible portal-like framework with:

easy page/sub-page layout/skinning/themes
a minimum of archane markup
AJAX-style user interaction and display refresh
very loose inter-component coupling (but enough that it can be done!)
quick-turn component development with little or no framework dependency
enough maturity that it's not brittle (I'm a rambunctuous guy)

FYI - I've looked at most of the Java-based portal frameworks out there (Jetspeed2, LifeRay, JBoss Portal, etc.), and they don't pass the last test yet. There are other webapp frameworks, obviously, but they tend to lack the flexibility I'm looking for.

A lot to ask for, I know, but it's what I want. Anyone have any opinions or suggestions? :::grabbing umbrella:::

Its funny with all this talk of web frameworks no one even
thinks to mention asp.net. Its a framework that is flexable,easy to use, but expandable if needed into 3 tier. I know everyone has been on a hate fest with Microsoft but come on. There .NET framework is a great piece of technology. Plus you can do it all in C#. Which is very close to java. Plus they have there very easy to use Atlas framework for AJAX enabling your site. If your running your site on Apache its no big deal. Just use Mono to run it on any Linux distro. I just cann't believe it hasn't come up. Why mess with these other languages that aren't fully OOP or take to long to master. I think the .NET Framework is the best bang for your buck.

I've actually seriously considered using .NET, for precisely the reasons you've cited. I'm not a religious zealot, and I consider Windows XP to be a perfectly adequate OS. It's my primarly desktop OS, and I find it to be at least as stable as it's competitors. I just need to avoid creating OS-specific dependencies in my code, primarily because many of my clients aren't as open-minded as I am. They tend to specify Linux for their production platform, so that's what I give them.

It's really nice to be able to develop on Windows XP and MacOS (my desktops and laptops), and then deploy to any of the available server platforms (Win, Mac, Xnix) with little or no platform-dependency. I can get that from Java, Python, Perl, PHP, Ruby, etc., but I'm not aware of any fully-compatibile .NET implementations for MacOS, Linux, or Unix. (Admittedly, I have not looked very hard.)

- ks

http://www.mono-project.com

ASP.NET? Give us a break please. I thought it was good until I actually did projects with it. Now I would rather seek another employer than having to use VS and ASP.NET again. It's heavy, buggy, limited, I regularly had to fall back on a text editor because VS couldn't handle the preview, viewstate vs page properties are confusing, the 'HTML' is an incredible mess of tag soup (just like JSF), etc, etc, etc.

I've given ASP.NET a chance lately. In fact, I purchased a professional copy of VS.NET - it's a good product, the framework is well thought out, and there is a lot going for the .NET framework and C# if your organization has standardized on running Windows in production. I will have to say that the .NET reporting services is a great piece of code, very easy to create reports, etc. .NET has a great take on things like display tables of data, and once ou've sunk the time it takes to learn ADO.NET, you can do great things with ASP.NET.

But, I'm unwilling to use a platform that dictates OS selection in my production network - period. I don't trust the Mono project to run my .NET applications, and, even if I did, it alwasy feels like Mono is a little bit behind Microsoft in terms of the latest greatest.

All of that being said, if your organization can suffer through a 100% Microsoft platform, then ASP.NET makes a lot of sense, but, at least for all of the projects I work on, Windows in the production network is a non-starter (and I agree with that decision).

What an enlightment this has been. The diversification of POV and experiences that have be ratified is intoxicating as it is informative. Thank you for cracking opening such an important topic. Considering my limited knowledge of web frameworks and all, this dicussion has been a real eye opener and has made me think alot more about the constant irregularlity over what is considered best of breed web frameworks v's the [quote] With great knowledge comes and great power and with great power comes great responsiblity [/quote]. In a nutshell what I meant to say is; if we dont stop to smell the roses once in a while we may all end up in serious trouble in the future of the internet. I suspect that small and large corporate giants that rely on these frameworks to generate income should be under no illusions that one day, there will be a web framework bubble burst where far too many disparant technologies will exist and be glued together, which will cause a massive technology overload and gridlock etc... and the people who long started these technologies will be long gone and probably dead. What then? The programmers of the day will have to clean up the mess and continue to tack on bits and peices etc. From all my proding around web forums, blogs, podcasts and so on it looks to me like we need a 'Universal Standard Common Web Language' platform etc. Like Adobe has for PDF, as has HTML for the Web etc. Please don't misunderstand what I am trying to get at here. Whilst there are so many great things and some bad ones going on right now in this domain, it is imperative that for the futures of our children and grand children we owe it to these generations to make sure that the foundation on which we build these technologies is rooted in concrete and to be as fundamentally as accepting the precise makeup and understanding of DNA will ond day led to cures of all diseases for all species. May be I am rambling on too much here and trying to be a visionary or something, but please for godsake stop back stabbing each other about which is the best of the best and start thinking about what we build now is to shape the world in the years to come...

Again I must say that this is one of the most important discussions on this side of the web I have seen a very long time. Only the efforts of you and others will make this a truly wonderfull place to work. Let the future be now!

Despite some of your critics on this one Tim, I thought this was a very well written article. As much as some don't want to hear it, you are right in that Ruby IS innovating first and Java is following. I think the question of integrating Rails and Java is a good one for many organizations, but at some point, I see organizations migrating completely off of Java.

re: Anonymous

"it is imperative that for the futures of our children and grand children we owe it to these generations to make sure that the foundation on which we build these technologies is rooted in concrete and to be as fundamentally as accepting the precise makeup and understanding of DNA will ond day led to cures of all diseases for all species."

uhhhhh... dude, are you okay? It's just code, man, take it easy.

What are the criteria for choosing a framework? What are the comparative advantages and disadvantages you alluded to?

I wish there was a repository of frameworks each having talking points to consistent criteria... Then we can begin to compare apples with apples and choose the best framework for our application development needs...

Hi,

If you plan to develop a "back office" web application like callcenter, CRM, trobel ticket system,..than Open-jACOB is the right tool.

see on: Open-jACOB

greetings

Andreas

I need to use xml tag to apply for any of the vb script

Tim, is it possible to use RoR for front end and Java for back end?

Visit Ehr Implementation

Visit Nyc Subway Map

Visit Pyromania

Visit Ancient Egyptian Hieroglyphics

Visit Leann Rimes Life Goes On

Visit Free Wicca Spells

Visit Free Wicca Spells

Not much on my mind right now, but it's not important. I've just been letting everything happen without me. I just don't have anything to say right now.

For those who hate programming and database designing, Nenest (http://www.nenest.com) might be a good choice.

Not excited about any Java web application framework these days? Join the club. The reality few want to acknowledge is that many “enterprises” are running along with Struts 1.x applications and they haven’t really started to contemplate what comes next. Or, they’ve thought about what comes next, and the answer hasn’t revealed itself yet. JavaOne might have had the highest attendence on record, but the community is fractured and the energy is unfocused. The answer to “what web framework should we use” is far from clear. Read on, if you are interested in exploring this confusion…
I do not agree. Go to http://www.jobzworld.info/inglorious_Germany/exophthalmic_Hessen/irreversible_Frankfurt%20am%20Main_1.html

Not excited about any Java web application framework these days? Join the club. The reality few want to acknowledge is that many “enterprises” are running along with Struts 1.x applications and they haven’t really started to contemplate what comes next. Or, they’ve thought about what comes next, and the answer hasn’t revealed itself yet. JavaOne might have had the highest attendence on record, but the community is fractured and the energy is unfocused. The answer to “what web framework should we use” is far from clear. Read on, if you are interested in exploring this confusion…
I do not agree. Go to http://www.globaltasks.info/facilitate_France/asyndetic_Ile%20de%20France/bamboo_Paris_1.html

What about Hamlets? Hamlets is the name of an open source system (BSD license) for generating dynamic web pages. A Hamlet is a servlet extension that reads XHTML template files containing presentation using SAX and dynamically adds content on the fly to those places in the template which are marked with special tags and IDs using a small set of callback functions. A template compiler can be used to accelerate Hamlets. Hamlets provide an easy-to-use, easy-to-understand (less than 1/2 hour), lightweight, small-footprint, servlet-based content creation framework that facilitates the development of web-based applications. The Hamlets framework not only supports but also enforces the separation of content and presentation. With Hamlets you write your web applications in Java, so you can leverage your entire Java skills.

What a relief that someone out there in Javaland is acknowledging the confusing array of java web dev stuff out there. Lots of great stuff (...I think) but what to use and how to bundle together all of the pieces that you'll need? Making them actually work together just for your classic HelloWorld ... arrrg! Man, I'd love to have it any other way, but the bar to entry is raised so darned high that it is no wonder that folks run back in droves to IIS and ASP.Net.

@Ken, I don't see people running away from Java to ASP.NET because of an abundance of choice. I see the reverse.

I've just found the CLICK framework a week ago and have been playing with it for a week now. It's open source at sourceforge.

to date this is the simplest/lightest framework I've come across. I've used struts and tapestry over the years and am currently using JSF. I was able to migrate one of my project tracking tool, I worked on in the past, to CLICK in a week.

I like it because it uses plain java and velocity which are both mature technologies.

I am going to use CLICK from now on.
web site is http://click.sourceforge.net/

anyways just my 2 cents.

Take a look at ztemplates on http://www.ztemplates.org/JSPWiki

* new and unique action processing module
* clean, technology agnostic urls
* fully JSP, Velocity and AJAX compatible
* state-free
* invisible to the web-client
* convention over configuration
* extensible
* small and modular

hfhdjfh jdfsh dfh