I totally agree with Andrew. Remember we said COBOL should be dead by now (that's what I said over 12 years ago)?
To me, the most important thing is to deliver to my clients what works. With all the Struts users out there, I bet you it will have a life far longer than any one of us would imagine. Also I personally belived that JSF might not get adopted as quickly as everybody believes. Remember that JSF models after event listeners (which somehow reminds me of SWING). I uses event listeners, but not in the context of user interface. I simply has a bad taste seeing JSF is event driven (personal feeling without technical merit). Bottom line - 1) Developers picks up what he/she felt most comfortable with. There are lots of frameworks out there, Struts is very closely tied to the HTTP servlet specifications and therefore make sense to lots of developers coming from the CGI era. So long term commitment is not going to be a problem unless the JCP decides that we need to throw out all the existing servlet APIs and breaks all the web application out there. 2) The open source aspect further ensures that good and working technology (like Struts and others) will not get thrown out of the window simply because a company wanted to change directions to enhance their market (or for whatever the reason they so choose). 3) We need to work with technologies that works "now", not 2 months from now, not 1 year from now. I remembers that I work with Struts a couple of years ago and it works out from the box (and it has been working since then). Since struts has been very stable with lots of developers supporting it, it wins hands down. That's just my 2 cents personally. -----Original Message----- From: Andrew Hill [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 01, 2003 11:02 AM To: Struts Users Mailing List Subject: RE: Editorial on Struts' Long Term Future Yep. Quite interesting. 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 my view 3 years is a very long time in IT! ;-) 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 JSF 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? 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]
