Too much help... Too many solutions


Web tier: servlets, JSP, Web frameworks: Too much help... Too many solutions

  1. Too much help... Too many solutions (3 messages)

    I am not a fan of JSF. It is at best half a framework, providing little value anywhere but the presentation tier. The little value it does provides is focused on forms which, at best, are a small percentage of what makes up most web applications. It tends to encourage you to create heavy sessions and hit the server for the most inane reasons. It defies common sense by placing edit functionality that should be done on the client and business tier on the presentation tier. It abstracts you away from skills that are common and well understood (html, XML, CSS, JavaScript, DHTML) to tag libraries of components designed by gnomes with proprietary event handling that no one understands under the guise of making web development easier. Yes, I understand that the intent of Mr. McClanahan was that folks would develop frameworks on top of JSF that would hook into it and provide more comprehensive functionality. This, in my opinion, is adding insult to injury, taking something that is too complex (cumbersome) and making it more so. I am not a fan of struts. It is at best… well, after dumping on the JSF love fest maybe I shouldn’t alienate everyone. So I’ll pass on the struts critique. What I’m really not a fan of is having to re-learn and re-work our architecture everytime there is a new ‘flavor of the month’ framework or a new version ‘much improved’ that I must incorporate. Keeping up with the hot, new and improved frameworks is time consuming and expensive. We are beginning to turn the corner from library sharing being a benefit, to being a burden. Struts, a large, comprehensive framework led to JSF, an abstracted confusing little framework that addressed many of the so-called the weaknesses of struts. But since it didn’t work with struts we were in a one step forward, two steps back scenario. It still puzzles me how the same person could have written both without hooking them together. It also points out how disjointed this community is on how best to grow. Enter Spring, which by all accounts is great. I mean who doesn’t want dependency injection? You can add it to the stack of all of the other technologies you are probably using to make up for whichever framework you’ve adopted. What about ORM and persistence, you’ve got to have a tool for that right? So, how many people in your company really understand the stack of technologies you have brought in to make your job easier and you more productive. One? Two? Are they the ones doing the work daily? Has the project turn-around time improved? Probably not. Unless you work at technology company that bills expertise by the hour, I bet you’re not really seeing the value you thought would be there when you adopted J2EE. I work in an insurance company where my users care more about turning around projects, whether we have implemented the latest craze. The typical programmer does not have the time or desire to stay up to speed on the myriad of technologies that potentially could be placed on our stack. They don’t know what dependency injection is and don’t care. If it is easy for them to understand and helps turn out product faster, it is good. Otherwise, it’s a hassle. This is a flat rejection of cool, sophisticated implementations of patterns that add little or no value to the typical web page. If 95% of your pages do not have a Form, then centering your development around a framework that focuses on forms, but provides little else, makes no sense. So, what do I like? J2EE. Yup, plan old J2EE… let me explain. Web development does not need to be difficult or confusing. Web development does not need phases, phase listeners, backing beans or designer components. Web development can be as simple as getting the data (xml), applying a stylesheet (XSL to generate HTML) and using JavaScript to handle events. Or, how about creating a simple MVC II framework using a controller that manages requests and passes them to processes, and then to a simple, every day JSP. Too simplistic? Maybe, but both are free of dependencies on the framework creation industry. Both are easily staffed with developers that have the expertise to do the job and both have excellent turn around. More importantly, both handle about 90% of what we need to do daily. Which leaves 10% to be handled by that ever growing, and hard to manage stack of technologies we’ve brought in to help us be more productive. Let’s see what’s next … Shale? Isn’t that a brittle rock of some kind? Or Struts 2, yes that’s the one that comes before Struts 3 and 4 and solved all of the JSF vs. Struts vs. Spring vs. everything issues. I guess I’m questioning whether, in the end, buying into all of the hoopla over server side frameworks really helps. I agree that some of it is pretty cool, but the question of value seems questionable. From what I’ve seen the value of each tool is divided by each tool on the stack, not enhanced; and the complexity of the environment is squared by each tool added. That home grown MVC J2EE framework that only does what I need and is simple enough for anyone is looking pretty darn good…
  2. +1 Wow! You are my guru!
  3. Lots of valid criticisms here, certainly. It'll be interesting to see what kind of comments you get from those who love JSF and/or Struts. You might as well have said, "I'm not a fan of puppies" because it's the same thing to a certain segment of the TSS readership. The comments here may explode into a "framework XYZ rocks because . . ." There's certainly something to be said for simplification and I'd definitely agree that there seems to be an alphabet soup of frameworks around for web development that there didn't used to be. Heck, you didn't even mention ASP.NET or Ruby but could have. Lots of these same sentiments are echoed in Beyond Java. If you ignore the shameless Ruby promotion (and the kayaking stories), Tate does a good job in it pointing out that Java used to be about low barriers for entry but now you have to download a long list of pieces to glue together properly before you can get started. The one thing I would say in support of frameworks, though, is that it forces a separation of logic that a typical monolithic approach doesn't help you with. The approach mentioned at the end here hardly guarantees doom and you can certainly write a poorly architected Struts webapp, for example, but if nothing else these things tend to limit The Spaghetti Effect. Provoking thoughts either way. Great post. ---Pete
  4. Glad it's not just me![ Go to top ]

    Couldn't agree more. I posted about my views on JSF a month ago in "a totally unproductive day".