Yep. Quite interesting.Trust me ... he does :-).
Sorry if its a bit rambling - dont have time to edit it - but heres my 2 cents worth:
The article doesnt mention it but Scioworks is the company behind Camino , a
powerful RAD tool for struts so its a good bet to say that he certainly
knows the technology and the area quite well (unlike many commentators).
Id have to say I agree with the opinion to a certain extent - though in myYep. To have Struts take that long to become "legacy" is actually a compliment to how well it addresses the need area it went after. To have it become the underlying knowledge base of the experts building the "standardized" version of the technology is a compliment to the original developers being pretty much on the right track.
view 3 years is a very long time in IT! ;-)
Yet, the problem that John addresses here (also known as "The Innovator's Dilemna") is very real. You're told to go build something, and put it up on the web yesterday. It's going to be a mission critical for your company, and will itself have a fairly long shelf life, so you want to make sure that the technologies you base your app on are also going to be around. You look at the available standards-based technologies, and don't see what you need. So, what do you do?
Open source developers (at least the good ones) tend to be pretty innovative, and that was certainly the case with Struts folks (yes, that includes me, and I'm very proud of what my little brainchild has grown into :-). It is not unusual to find that there is an open source package out there. But, is that package going to be around for the lifetime of my own app?
Or, to put it another way, how many open source projects are hosted at SourceForge? How many of them have more than a couple of developers playing around in their spare time? How many of them have been downloaded even 100 times (Struts gets ~75,000 downloads per month nowdays)?
I would submit that the supporting ecology around the technologies you choose (be they open source or not) is likely to be more critical to your success than the particular technical features of the package. It was certainly critical to some pretty large scale companies, and conservative industries, that have adopted Struts quite widely.
Yet, it takes a while for that ecology to grow. And, there's no guarantees that it will *ever* happen. And, while the ecology is growing, the technology at the base can't evolve quite as quickly as it could before (ask all the guys who wrote books on the "moving target" that was Struts 1.1 :-).
It's an interesting balancing act.
JSF scratches many of the same itches as struts, only better, and given that:-)
Craig is spec lead for JSF thats hardly a coincidence. Perhaps we could
consider struts the practice run? ;-)
Craig & co. say that there will be a future for struts in the JSFKeep in mind that the existing struts-faces integration library isn't finished yet (since JavaServer Faces isn't finished yet). But it will be.
generation, but Im not sure I fully grok what that future is yet (havent had
a chance to play with the jsf struts integrated stuff yet) but at the least
it should involve an upgrade path for existing struts stuff?
To the broader question, I would definitely say there is a future for Struts. Here's a quick summary of some things on my mind:
* Part of the ecology of a successful open source project is staying up with the times, offerring new things to your existing customers. After all, there are many thousands of Struts based applications aready in existence -- and nobody is going to rewrite them all in the next couple of days, or even the next couple of years. Therefore, Struts needs to continue to support its existing features and functions, and add new ones.
* Particular areas of future growth I'm interested in (other developers have their own thoughts as well):
- Enable existing Struts-based applications to utilize new view technologies (like JavaServer Faces) with zero changes to their back-end business logic (isn't that one of the things we all like about MVC type designs? :-).
- Make Struts equally useful in both a servlet and portlet (JSR-168) environment.
- Refactor the insides of Struts so that the basic principles of "separation of concerns" can be used for "scripting" your back end business logic, interacting with XML data sources and outputs, and so on.
If we were just going to stay where we are, I'd be worried about the future of Struts (although, even if all development stopped tomorrow, there's too many people using it today for such a vacuum to exist for very long -- someone else would take up the gauntlet).
Sadly, I don't have time at the moment to comment further ... maybe later, after putting in some "day job" hours :-).
Craig
I dont really see what the fuss about 'protecting investment' is - its not like struts is rocket science to work with and unlike commercial products you've always got the source to look at if the docs arent clear enough! If the product your maintaining uses struts its still going to be a hell of a lot easier to maintain than one that went with a model 1 approach. After all, when struts was created there simply wasnt a suitable webapp framework standard to plug the gap between the low level servlet api stuff and higher level application oriented patterns, and if we extrapolate from this to other new areas where opensource is paving the way, are we to say that managers shouldnt use such opensource initiatives because they dont comply to standards that have yet to be drafted? What then? Homebrew frameworks? - if its early in the technology these may be the best way of meeting your needs while opensource efforts mature - but usually thats not the case. Ignore the new area till someone comes up with a standard framework? Not really an option given commericial pressures.
At the end of the day its a case of going with whatever framework is available and choosing the one that will cost you the least and give you the most mileage. In hindsight for J2EE webapps that would be struts, and even right this second it would still be struts. JSF isnt ready for general use yet - so unless you want to delay your project till it is what are you going to do?
The answer of course is to choose a framework that will give you the easiest upgrade path as new standards come along. A framework that quickly moves to support standards as they emerge. In the webapp arena this is of course struts - and in the past the upgrade path has always been there - for jstl there were both the struts-el library and of course the fact the jstl and struts play very nice with each other. With JSF I believe that whats been done to integrate struts and JSF will provide a good path. The next (or soon after) version of struts will I gather also play nice with the portlet spec, etc...
Basically what the article is saying is that these are the issues that managers need to consider carefully. Its certainly not saying dont go with struts/opensource, but rather saying that one day they may be obsolete - but its not like theres a real alternative - so pick the one that looks like its going to cost you the least in the long term!
To quote: <snip> Am I suggesting shunning those open-source projects? Not at all. These are solutions you can deliver now, and the lack of support may happen in the future. I believe the value gained from using these open-source technologies outweighs the risk. </snip>
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, 1 October 2003 22:09 To: Struts Users Mailing List Subject: Editorial on Struts' Long Term Future
You may find this editorial on J2EE/JSF/Struts interesting. http://www.sdtimes.com/opinions/guestview_087.htm
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
