The Old Joel on Software Forum: Part 4 (of 5)

What's wrong with Struts?

The link to bileblog from "Does good code matter?" thread sent me on a browsing odyssey around blogs and discussions bitching about Jakarta and, in particular, Struts. I even remember seeing a discussion here with lots of negative comments about Struts. What I haven't found in these discussions is a clear explanation of what's wrong with Struts. Sure I've seen complaints about the small stuff like struts-config.xml, and forms have to derive from a specific class, and actions are gloabally scoped. Nothing on this list evokes "Struts is evil" notion, though. It's just normal trade-offs that you deal with writing software every day, moving complexity around to where it's easier to manage.

I've been using Struts for 2.5 years on fairly complex web apps. Before that, I've worked with and on custom web frameworks, as well as, on sites written without a framework at all. Compared to my previous experiences, I found Struts to be generally easy to use and very stable. The app design that struts encourages is reasonably clean and maintainable. We've taken several Stuts apps through a series of releases without a lot of struts-related angst. Is my experience so atypical?

I'd like to hear specific examples of what is fundamentally wrong with Struts. What makes people have such strong distaste for it?

igor
Tuesday, March 16, 2004

It is complicated, and almost completely unneccessary

the artist formerly known as prince
Tuesday, March 16, 2004

I have to agree. After looking at Struts, Maverick, etc. I find it easier to roll my own 'framework' (or none at all) as needed...

GiorgioG
Tuesday, March 16, 2004

What specifically about Struts is complicated? (We're thinking about moving to it from our own home-grown framework...which has its own set of problems/flaws)

Kid Vicious
Tuesday, March 16, 2004

Why does everyone need/want a framework?

Elephant
Tuesday, March 16, 2004

For large applications, struts is very good just don't try to use it for some two page application that will only ever be used / maintained by you.

The primary benefit of using struts, is you can hire people with struts experience and get them up and running quickly. Contrast this with a home-grown framework.

As an example, the bank I used to work for lost its *entire* java web development team in 3 months. Every last one of them has left for the competitor. They have their own home-grown framework that only a few of us truly understood, and now they're hosed. Completely.

At least if the applications were struts *someone* could have figured out what was going on. Instead all the magic, clever optimisations and reflection hacks have become impenetrable.

Koz
Tuesday, March 16, 2004

Basically, for any framework, people's complaints about them come down to the issue of how close the framework matches how the programmer would have solved the problem themselves.

There's always trade-offs, decisions, and style in making a framework (or library or application) and there's always more than one "right" way to do it.

So the people who like struts basically like it because it matches pretty close to how they would have made a java web application framework. The people who don't like it, don't like it because it is noticably different from how they would (or have) made a java web application framework.

Unfortunately, that means that to judge for yourself, you can't go just on reports. You have to try a few to find the one that makes you say "of course it works like that, that's the way I would have done it".

Bill Tomlinson
Tuesday, March 16, 2004

>Why does everyone need/want a framework?

I also find struts over complicated and would prefer
to write my own. Same with jsp and the app server. That
is because i can.

My experience with some other less experienced
people is they like the structure of struts because
it tells them what they need to do. They would
not be capable of making their own libraries
to accomplish the same task. They don't really
understand how the web works nor will they
probably ever. So structure is good in these cases.

My like a very much appreciate structure in my
car repair manual. I am not able to recreate
all the implicit knowledge myself.

son of parnas
Tuesday, March 16, 2004

Regarding "Why does everyone need/want a framework?" - I assume you're fine with using List and Hashtable that come with Java rather than writing your own implementation every time you need it. That's the java collections framework. Same with STL in C++. To me, Struts is a library that handles dispatching web requests and transfering data from HTTP request to an object that's easier to program in Java, and from the object back to html.

I'm starting to agree with Bill Tomlinson that it's more of a matter of opinion rather than hard fact. There's nothing inherently wrong about it. If you're comfortable with the design approach, then it'll work for you.

igor
Tuesday, March 16, 2004

> I assume you're fine with using List and Hashtable that
> come with Java rather than writing your own
> implementation every time you need it.

Yes when I don't care about how they are implemented. As soon as I care how my tree is implemented, I don't use some generic tree class, I code my own. Why? Because, I suddenly care about memory and speed when I choose to put 1.2 Billion elements in it.

Same principle applies to any framework. If you're not writing a serious app where you have to worry about running under high stress conditions, then a framework is fine (provided it doesn't hinder you from accomplishing the goal which is a whole different story).

As soon as the word "scale" comes into the picture (and I mean seriously scaling an application) a framework is probably not your best choice. You are better off rolling your own. It's like that article that Joel has lying somwehere around here that you always need to be one level of abstraction lower than your bread and butter. Why do you think Google rolls their own web server?

Elephant
Tuesday, March 16, 2004

Elephant, it sounds like you're getting very close to the old saying that premature optimization is the root of all evil.

Yes, if you are absolutely sure that wringing every last molecule of speed from a given system is crucial, then go ahead. But trying to guess before hand where to optimize for speed is a sure way to waste time working on the wrong things.

And I have difficultly believing that the web application framework is the bottleneck in most web applications (and my personal experience supports this). So I say, go with a well know, well supported third-party framework that matches your style until you're able to prove with a profiler that the framework is the bottleneck.

Bill Tomlinson
Tuesday, March 16, 2004

Elephant, I like the spirit of your post, but I think it can go both ways. I've seen team's "homegrown" framework perform just fine, until--uh oh, scaling time. Then they spend 3x as long getting it to do what some other framework already does. Yes, a lot of frameworks are a pain in the ass to set up, and you have to do useless stuff in the beginning. Mostly because they try to be everything to everyone. Well, later on, when you start doing x and y and z, instead of just x, all that hard work can pay off.

vince
Tuesday, March 16, 2004

Very true. If you botch up your own implementation, then it does go both ways. Then again, I've seen groups botch up the use of a framework so that it didn't scale. Everything with a grain of salt I suppose. Meaning, if your team just can't get anything right, then I guess it doesn't matter what you do; it's going to suck.

Elephant
Tuesday, March 16, 2004

I think there is nothing esencially wrong with Struts. It's all about context.
In many situations is just needless complexity. Why? Well, Struts adds an indirection level and sometimes the cost exceeds the benefits. You are forced to create some classes that implements interfaces and may be there is a simpler solution, but you can't use it. The framework imposes some restrictions and when you fullfill it, the design may suffer.
In some way, when you use Struts, you resing some design decisions. So, you lose some freedom but you gain code reuse. Like always, there are tradeoffs. The key is decide what is most convenient for *your* situation.

Gabriel Zurita [www.gabrielzurita.com.ar]
Tuesday, March 16, 2004

The problem I had with Struts whilst I was learning it was that because of the way the framework evolved, it doesn't always use the most intuitive names for things. Its authors have admitted as much. For example, I would have called the "name" attribute in the tag libraries, "bean".

John Topley (www.johntopley.com)
Wednesday, March 17, 2004

I never used Struts, but I have looked into it, and I use another, somewhat similar (though not Java) framework on a daily basis.

From the documentation, it seems like a classical example of an overly-academical solution, out of touch with the real world. Such frameworks tend to require insane overheads and learning curves for the limited benefits they offer.

Reading through the docs, I couldn't imagine that anyone with considerable experience building web applications could have invented such a thing. Wannabe techological evangelists could.

Egor Shipovalov
Wednesday, March 17, 2004

"The primary benefit of using struts, is you can hire people with struts experience and get them up and running quickly."

That's also a liability of Struts. If you hire people without Struts experience, you'll have to be patient while they go up the learning curve. But if you rolled your own minimalist framework, anybody could learn it and get up to speed in a day.

T. Norman
Wednesday, March 17, 2004

"But if you rolled your own minimalist framework, anybody could learn it and get up to speed in a day"

crikey, that is so minimal! Please open source it immediately!!!

joking

i like i
Wednesday, March 17, 2004

We used Struts for the first time when we needed to design a product in-house in 3 months. It enabled us to streamline most of the work without having to worry about who coded the data accessor pool or how do I get my errors to display on a screen.

In 2 weeks, we already had a working prototype. Is Struts complicated? Not even close. If you don't understand Struts, then you might ask yourselves if you even know Java. Struts was designed to use the Model-View-Controller pattern, that lets you have html designers designing HTML, without them knowing diddly about JSP, Servlets, or Java. That goes for everything else.

Yes, you can write your own framework, but we have close to 45 Java developers here and having them understand a home-grown framework only is great if you that's all you will ever use. Once they leave, that framework does them no good since most companies own the rights to that framework. Struts can be used anywhere by anyone. That's the idea behind Struts.

pjd
Thursday, April 1, 2004

My biggest problem with struts is the lack of feedback when something goes wrong. I think it would be nice if there were some classes written in the struts framework that you can run from your build script that would do some validation of the struts-config.xml and tiles-defs.xml files at least. On a big project these files can get pretty filled up, and become combersome to maintain.

Mike N
Friday, April 9, 2004