Thoughts about web frameworks


Web tier: servlets, JSP, Web frameworks: Thoughts about web frameworks

  1. Thoughts about web frameworks (1 messages)

    Hello, peace and happy holidays to all. Now, in this (somehow) silent times, I had the time to reflect on my projects in 2007. And even if I want it or not, I mostly end up reflecting, how well I could defend the use of certain webframework for a specified task. The battles seem to get tougher lately. (Damn wicket ;) Recently, a friend who came over from long years of php pondered, that all that famous Java-Frameworks (Struts[2], JSF, Wicket, Tapestry etc.) he tried have some sort of ugly-ness, missing polish in details, way-to-complex object models, heavy learning curves for 'more complete' frameworks vs. simple entry in frameworks that leave 50% of the work for you etc. Or "Why is there always a longterm refactoring project 'version something' on the roadmap of framework X?" I honestly don't have simple answers. He had that "simple example" for me. He wanted to implement a navigation "component" for a webapplication. Following logic will be applied: a) Dynamic Creation of the List of Navigation Items Means you don't know in Advance how many items you have, they might come from different 'sources' b) Location-Affinity: the item "availability" is depending on the location within other pages and entry-points c) Role-Affinity: enable/disable/show/not show certain items d) Style-Affinity: full control of appearance/"active selection" of any item, even override able by user e) Caching-Concept: depending on memory vs. speed, you might cache the output of the navigation so you don't have to recreate it everytime. Especially when you only have only a certain amount of roles, you might even create the nav-items out as a static html component (this seems not to be a uncommon practice on high load php sites). ... I know to do this in two or three frameworks with a little bit of thinking. But I must confess: I couldn't recommend any of the modern frameworks to-do that EASILY in terms of "take this, the models and the high level concepts are all there, documented, just snap in!" Sometimes you need to wade in _knee-deep_ to solve that list above. (And don't talk about menu items("trees"), that load stuff dynamical. There you go into the twilight zone of Java and AJAX ;-x Even I don't like it to go there without a reason). All the mailing lists of any web-framework is full with questions like: "How can I turn this or that on/off? How to dynamically add a check if...? How can I $ยง%$% this?" Most of the time, the people who question never get a _satisfying_ answer. They tell you "You have to get the extension package and the override following three functions and then start tomcat with a secret undocumented switch". But you never hear: WHY it must be so complex; why you have to jump through so many holes. I, personally, don't care. If JSF is a complex mess which can only be fixed by downloading endless (AJAX)components from to "component gallery 1000" where some uberbrain has teared half of his hair out to make it work in IE6/7/Firefox/Opera - i'm ok with that. "That's business." The "problem" is, that I can't explain anybody WHY this seem to be "better" than going back to my own buggy-but-fast taglibs or pimping up that old framework from that Guy from Bangalore which I met in a project and which looks strangely like a mix of portlets and velocity templates - and still drives a high load zillon dollar portal.. ;-x Surely, I can explain why JSF is a standard and why it does so much magic that every web-page made with alot of components loads upto 100% slower in contrast to a hand tuned jsp page. Business people, mostly non developers, understand the "wider issues": internationalisation, standards, snap-in components, etc. blabla. Normal people say "It loads 100% slower. At least!" Uh. But again, this is part of the business I select to work in. In one of the last projects, we had some people who never did webdevelopment, but where excellent Java developers. I just dropped them cold on Tapestry and they loved it. Until the customer comes in with some very strange requirements, then you try to migrate to JSF (because of "plugin components") just to experience that this "components" make very heavy use of JavaScript and the server isn't and will not be able to take the new-learned-by-experience-not-by-half-assed-assumption extra-load... It's my job to fix this issues. But to be honest, for those outsiders it looks more and more like a crazy fireman extinguishing the fires he sparked himself. And the "explanations" never FEEL LIKE the iPhone advertisements... more like "mumbo jumbo". Plus there is always that rescue pod "Hey, there is a new version/redesign/refactoring project of framwork X on the roadmap. We can use...THAT!" ;[=] I don't want to start a flame war about my subjective views of way too many frameworks - I would prefer to hear how other generally decide for a webframework. And how they sell it a) to themselves and b) to others, who might not understand ANY of that magic you will soon able to perform. thanks -Holger
  2. Re: Thoughts about web frameworks[ Go to top ]

    Hey Holger, I agree with most of your arguments, and I admit that I was new-framework-fanatic once. I've been thinking latelly about how to choose between web frameworks and I think it's a good idea to see beyond the basic CRUD examples in that case. Most of my problems with frameworks involve a lack of control that you have in it's behavior, because even if most of the development involves CRUD functionality, the excentric functionalities takes the longest time to be developed, and that kind of functionality requires control about your framework's behavior. When you think about it, that kind of functionality isn't that rare. Renan