Discussions

Web tier: servlets, JSP, Web frameworks: Web Frameworks Smackdown at JavaOne 2005

  1. Leads of major web-frameworks were put on panel and given a chance to battle other solutions defend their own.

    The frameworks presented were: Java Server Faces, Shale, Tapestry, Wicket, Webworks.

    Interestingly enough, nobody really argued that Struts is the Past. Audience (many Struts developers among them) were quite agreeing on that except some minority.

    One thing was strikingly odd, though - Spring MVC was not on the panel, even though it seemed much better candidate than Wicket - largely unknown framework with a handful of production installations, mostly - clients of the creator's company and released in 1.0 just few days before the conference. God knows how it ended up on the panel and why Spring did not.

    WebWorks tried to depend its strikingly obsolete approach of request/response-based MVC by pointing that it is one of the most mature frameworks and a lot of customers are using it, for example as part of Confluence and Jira installations. That argument is a little bit shaky as Jira and Confluence installations, typically, do not get much traffic, are used internally and from my own experience - the only nice thing about them is that they use Velocity templating, which is not really something unique to WebWorks.

    JSF felt quite comfortable on the panel, as they are backed-up by being a Standard. Even more - from other sessions about JSF at the conference (a looot of them) it is quite obvious that JSF will transform into an integral part of Java EE standard (vs. being a separate spec). Tools support to JSF is, also undoubtedly superior. No surprise there - tools vendors were the guys who participated in the creatoin of JSF.

    The strongest argument in support of JSF, however, seemed to be that JSF is the framework most compliant with the Portlets spec. From another session about JSF: you can just develop your application in JSF and then write portlets.xml, do 20-minutes worth of cleaning-up and deploy it as a valid portlet, without much trouble.

    Howard Lewis Ship tried to argue that the same is true for Tapestry. However, that still remains to be proven as the current Tapestry documentation does not have anything about wrapping a Tapestry application as a portlet. Neither is it in his book (Tapestry in Action) so there is no way to check if what he said is valid and more importantly - to what extent?

    Shale's only argument was that it is "better JSF". Shale is built on JSF, is its valid extension and just makes it better. I think, this argument will have more ground if Shale extensions will be incorporated into the main specification's future versions. In any case, it's better to have Shale, than not.

    Wicket is too raw and new. They claimed that it is a zero-configuration framework, easiest to learn and develop in. That sounds as a bold statement and usually such frameworks end-up in being rather primitive than "simple and easy". Almost zero community adoption and low maturity, so far, is a serious factor that may prevent people from using it, yet.

    All in all, very arguable and subjective impression (based not only on the impressions from the conference, but my experience from JSF and Tapestry) is that - Tapestry is the most innovative, mature, has been around for a very long time, is components-based, hence - the future and can show a proven record of being high-load-ready (TheServerSide is running it, no need to go far for examples).

    Unfortunately, it is not Tapestry that is standard and being supported by Portlets spec or Tools vendors. That, as we know, can play a significant negative role and eventually kill Tapestry... or else... or else - Hibernate story.

    Arguably, you can see Tapestry vs JSF as Hibernate vs EJB2 persistence, a year ago. Hibernate was this cool thing, non-standard, not supported but it proved itself so much - EJB3 persistence is almost a direct child of Hibernate approaches.

    So, turning around to a better solution can happen even in JCP. But the same to happen with Tapestry
    1) it needs luck, everything is about luck
    2) Tapestry needs documentation as good as Hibernate had
    3) arguably, Gavin was able to really pull-off Hibernate after it went to JBoss. Will Howard, alone, be able to achieve the same?

    I asked him this question. His answer about the strategy was that he tries to partner with training and consulting companies and promote Tapestry through them. Is that, alone, enough?

    All in all, the healthy-spirit conclusion from the smackdown can be that - Java community is a lucky one to have such a variety of nice frameworks to chose from.

    Threaded Messages (22)

  2. Thanks for this, I was hoping someone would write about what happened at this panel!

    Tapestry will have portal support in the next version, 4.0, which is currently in beta. The docs have been updated for 4.0 and Portlet support is described here
    http://jakarta.apache.org/tapestry/tapestry-portlet

    Howard has said the beta period will concentrate on documentation, which is a weak point of Tapestry if you discount the book.

    Tapestry is looking even leaner and meaner than it was before, the annotations and IoC support are taking it in a direction of even less code. I'm very interested to see how it will look when 4.0 is released.
  3. Thanks, this is very helpful.

    The book is very nice. Unfortunately it does focus on Tapestry3, so it would be very cool to have good docs for Tapestry4 (and maybe a section about migration from 3 to 4), would make things much easier

    As I understand Tapestry 4 has many important changes and would make it easier for people who already use ver. 3
  4. One thing was strikingly odd, though - Spring MVC was not on the panel, even though it seemed much better candidate than Wicket - largely unknown framework with a handful of production installations, mostly - clients of the creator's company and released in 1.0 just few days before the conference. God knows how it ended up on the panel and why Spring did not.

    Maybe because MVC is not so hot anymore? MVC frameworks are going to be a thing of the past, being part of Spring or not. This Smackdown was all about component frameworks (and one might argue why WebWork was on the board, instead of Echo).
    Wicket is too raw and new. They claimed that it is a zero-configuration framework, easiest to learn and develop in. That sounds as a bold statement and usually such frameworks end-up in being rather primitive than "simple and easy".

    I find this remark very strange considering you haven't checked the framework out. I would reconsider labeling Wicket as primitive! Many of our users claim that Wicket IS the easiest framework (to learn and to develop in). Read the serverside discussion on Wicket 1.0. Check our mailing list, read some blogs. All claim that Wicket is the currently most easy to develop with framework.
    Almost zero community adoption and low maturity, so far, is a serious factor that may prevent people from using it, yet.

    At the very least the community adoption is gaining at great speed and Wicket has currently a lot of momentum. We purposely didn't attract too much attention for Wicket, as we wanted the framework to mature into a stable 1.0 release. As you may have noticed, now we have reached that milestone, we are announcing the framework around the world.

    We tried to avoid the groovy/maven syndrome where these projects attracted too much attention to themselves before they were mature enough to sustain a large user base.
    All in all, the healthy-spirit conclusion from the smackdown can be that - Java community is a lucky one to have such a variety of nice frameworks to chose from.

    I second this thought. We hope that the open source component based frameworks (JSF, Tapestry and Wicket) will drive web application development further and keep it healthy for the next five years.
  5. Wicket[ Go to top ]

    First, I want to say that I'm not one of wicket developers. I'm merely a user. I have worked with MVC frameworks for some time (Maverick, Struts and Spring MVC). After I looked at wicket's examples and tried to develop simple web application I was astonished. I couldn't believe how easy it was. The initial application was very easy to extend. Never before I've felt so productive.
    Developing wicket components is very easy and intuitive. And they can be really reusable with virtually no additional effort.
    The mailing list is fine. The community may not be the largest (wicket is a young project after all) but the questions gets answered from core developers and in quite short time. The developers are trying really hard to help users solve their problems.
    Implying that wicket is primitive without event first trying it deserves no further comment.
    I want to thank wicket developers, they are doing excelent job.
  6. Maybe because MVC is not so hot anymore? MVC frameworks are going to be a thing of the past, being part of Spring or not. This Smackdown was all about component frameworks (and one might argue why WebWork was on the board, instead of Echo).
    I would greatly appreciate if you clarify how components-based web-frameworks are not MVC? I _hope_ you meant request/response driven frameworks (Struts, WebWorks etc) vs components-based frameworks. JSF is an MVC framework and so is Tapestry.

    No, the smackdown was about web-frameworks, not just component frameworks so while I may be agreeing that for certain, large portion of web applications component frameworks are handier, I do not think it is right to declare something that is simply untrue.

    On a more general note, if you were there and noticed - Wicket got quite a cold reception from the audience at the Smackdown. Do you know why? Because developer community (more so - open-source one) is a community, in the first place and community values humbleness. Arrogance does not go too far.

    I truly and honestly wish you guys all the best and hope Wicket will really be as good as you apparently see it and want it, but until then - be humble. There is no way Wicket can match Tapestry in production, right now - maybe just in ideas and intentions, but in production - you have long way ahead.
  7. I would greatly appreciate if you clarify how components-based web-frameworks are not MVC? I _hope_ you meant request/response driven frameworks (Struts, WebWorks etc) vs components-based frameworks.

    You are right ofcourse. It is just that the term MVC got very popular for frameworks that really aren not MVC in the classical sense (which is why they are more officially called 'Web MVC' or 'Model 2').
    No, the smackdown was about web-frameworks, not just component frameworks so while I may be agreeing that for certain, large portion of web applications component frameworks are handier, I do not think it is right to declare something that is simply untrue.

    One thing I hope the audience noticed is the fact that four of the five panel members agreed on 'web mvc' being old skool technology. It is not about being cool or something, or about solving very specific problems. Component based development is about solving developer needs better than the web mvc frameworks are able to. I think I'll write an article about why that is shortly, but if you attended Howard's session, I think he made an excellent point explaining that.
    On a more general note, if you were there and noticed - Wicket got quite a cold reception from the audience at the Smackdown.

    Did we? The only 'cold' remarks we got had to do with Wicket being the new kid on the block and everything that follows from that fact. Furthermore, we got offers for more talks, writing of articles and are currently negotiating about writing a book on Wicket. JavaOne has been pretty good for us, especially considering Wicket is this young.
    Do you know why? Because developer community (more so - open-source one) is a community, in the first place and community values humbleness. Arrogance does not go too far.I truly and honestly wish you guys all the best and hope Wicket will really be as good as you apparently see it and want it, but until then - be humble.

    I am sorry you feel the Wicket advocates are arrogant. I feel that I am not, though we don't have to keep sitting in a quit corner until someone of the big boys gets us out, right?
    There is no way Wicket can match Tapestry in production, right now - maybe just in ideas and intentions, but in production - you have long way ahead.

    True again. Unfortunately, arguments like these allways seem to be the ones that prevail. Industry support, number of books, installs, etc. All valid arguments from a management point of view, but not nescesarily a technician's. Personally, I never had problems using technologies that weren't the main thing. My boss wants me to solve problems in the most efficient way while guarding quality, and - rightfully - gives me a lot of freedom making technical choices. We adopted Hibernate when everything was still about EJB's, and I never felt sorry about that decission!

    Furthermore, it is not Wickets goal to 'take over the market place'. Primarily, Wicket is out there to provide an alternative. About one year ago, trying to find an answer for the problems we (company that I work for) had with web mvc frameworks, I stumbled on Wicket, and immediately liked the concepts which, other than our competition, focusses on clean Java and HTML as much as possible, and has models as first class citizens instead of just the glue.
  8. I would greatly appreciate if you clarify how components-based web-frameworks are not MVC? I _hope_ you meant request/response driven frameworks (Struts, WebWorks etc) vs components-based frameworks.

    Of course you are right, I merely used the common idiom for referring to Struts, Spring MVC, Maverick, and (according to David Geary) WebWork.
    No, the smackdown was about web-frameworks, not just component frameworks so while I may be agreeing that for certain, large portion of web applications component frameworks are handier, I do not think it is right to declare something that is simply untrue.

    I think the Smackdown was about frameworks that will define the future of web development. Again the whole panel agreed that the Model2 frameworks (Struts et co.), have served their purpose and that the future of web development will be shaped by the component based frameworks. Model2 frameworks were a necessary step in the evolution of web application development and one can build perfect applications with them, but they aren't suited for the complexities web application development is facing.
    On a more general note, if you were there and noticed - Wicket got quite a cold reception from the audience at the Smackdown.
    I was there and I didn't notice that. The audience was being entertained by all five members of the panel, and as far as I read on the blogs, all frameworks came out equally, with JSF coming out the strongest (but with a small margin) and WebWork coming out the lowest (also with a small margin).
    Because developer community (more so - open-source one) is a community, in the first place and community values humbleness.
    I think we are pretty aware of our position as a small framework, that is why we are trying to attract some attention, how else should we grow? Being silent has gotten us not too far.

    That said, we are also aware of the strengths of Wicket and we wish to let the world know what those strenghts are. If anyone doesn't like Wicket, then by all means, let him use Tapestry, JSF, Echo or Struts Shale. I am still convinced that Model2 frameworks didn't have a place on that panel.
    Arrogance does not go too far.
    If I come across arrogant, then I appologize, that is not my intention. However, I am not going to sit and wait until the big boys allow us to come over and play. I am convinced that Wicket has grown and matured enough to earn a place in the web application framework playground, and I am striving for that place to be large enough to play ball.

    And on a side note, how does your (in my opinion, unfounded!) statement: 'usually such frameworks end-up in being rather primitive than "simple and easy"' not sound arrogant? Doesn't the community value informed and founded opinions? How do you expect Wicket developers to react to such a (bold) statement?
    I truly and honestly wish you guys all the best and hope Wicket will really be as good as you apparently see it and want it, but until then - be humble. There is no way Wicket can match Tapestry in production, right now - maybe just in ideas and intentions, but in production - you have long way ahead.
    At the risk of sounding arrogant :-), I already think we are as good as we want it. I thank you for your wishes and hope that someday when you try out our little framework you will be come as enthousiastic about it as us and our users.
  9. Wicket[ Go to top ]

    I think that the Wicket developers dug themselves a bit of a hole by calling Wicket "simple" and "easy" and other terms like that. We are in a world were things like EJB become popular merely because they are complicated. Calling your framework "easy to understand" makes it sound like a toy plastic mallet to people who like to use jackhammers every day all day.

    The fact is, Wicket doesn't limit you to anything. That's what makes it simple and what makes it powerful. If the Java language can do it, so can you. You're not restricted to what you can do with OGNL/XML from inside your html/config file.

    And yes, there's a small user base, but it's growing pretty rapidly. The mailing list, for one, is getting more and more posts/day all the time, especially recently. Every project has to start out with a small user base.
  10. Maybe because MVC is not so hot anymore? MVC frameworks are going to be a thing of the past, being part of Spring or not. This Smackdown was all about component frameworks (and one might argue why WebWork was on the board, instead of Echo).
    It all depends on your definition of a component. Front Controller-based frameworks can do components too.
    I _hope_ you meant request/response driven frameworks (Struts, WebWorks etc) vs components-based frameworks.
    Are not Wicket or JSF or Tapestry web frameworks? How come, they are not driven by request/response?
    I truly and honestly wish you guys all the best and hope Wicket will really be as good as you apparently see it and want it, but until then - be humble.
    Yeah, the statements of Wicket developers sound a little "in your face". But judging by this thread, you are not much better, nor am I ;)
    Wicket is too raw and new. They claimed that it is a zero-configuration framework, easiest to learn and develop in. That sounds as a bold statement and usually such frameworks end-up in being rather primitive than "simple and easy".
    Wicket does not have full docs, it is the hardest part, to do the docs. But the ideas it is based on are great.
  11. Too complicated[ Go to top ]

    I can't help but feel that all these frameworks are going the wrong way.

    In ye olde days, you wrote some HTML, the webserver sent the file to the browser, the browser displayed the content. The only thing you had to learn in order to give your cat a homepage was this new, mildly cryptic but fairly simple language called HTML. Pretty soon everyone on earth was a "web application developer".

    Of course, those pages got boring fast so we needed to figure out how to make the content dynamic. Here is where the programmers took over from the SGML documentation people and wrecked everything.

    The first step was CGI - obviously a programmer invention ("look! we can printf html!"). The second step was ASP and JSP ("look! the entire page is a printf!"), which wasn't much better. Then came Struts and MVC, which at least created the idea of a boundary between code and content and therefore let nonprogrammers do something useful. But of course, creating a page still requires a programmer first.

    I don't quite know what to make of this newest trend, epitomized by JSF, which seems to be centered around making web development as tedious, time consuming, and errorprone as fat client development. In 1995 everyone and their dog had a web page, not an MFC application. HTML is easy, fat client programming is hard. Why on earth would you want to make UI design more like programming?

    I think the JSP custom tag people fundamentally have it right. A better solution is to keep a document-oriented model but accept that the document author is going to have to deal with something that is slightly more compliciated than HTML.

    If you get rid of the front-controller approach, JSP and JSTL provide a respectable balance between the linear, document-oriented HTML that Joe Webby is used to and the dynamic world of code. Not an ideal balance but at least it allows nonprogrammers to create a page and "pull" the data into it, rather than relying on a programmer to feed them what they want. The only question is, how does the document author get the data they want without writing code?

    Here's my suggestion: I whipped up the world's simplest Java webapp framework with about 500 lines of code. There are no servlets and no xml files (in fact, no config files of any kind). It's just a simple custom JSP tag that instantiates an Action object and makes it available for JSTL expressions.

    http://tagonist.tigris.org/

    I even threw in a couple sample applications, including a port of the Friendbook from Maverick.
  12. Too complicated[ Go to top ]

    A simple solution is good for simple cases. However, when you want true reuse, work with large teams, have complex pages and have model interactions, plain vanilla JSP and taglibs does not suffice. Component based frameworks try to get the kind of productivity we had in the client server area back in the web area. True, fat client development can be hard. But needs evolve more and more to web applications that emulate fat clients, so we need the tools for that. For simple stuff, I absolutely agree: just take the lightest tools that do the job.

    Personally I don't think JSP is a good idea in a serious web application /ever/. I have yet to see the first JSP based application that doesn't have that horrible cut 'n paste and/ or ad-hoc java snippets in them. And custom taglibs, all with their own scoping and nesting issues? Bad, bad idea.
  13. Too complicated[ Go to top ]

    "A simple solution is good for simple cases"... I would phrase it "software should be as simple as possible to solve the problem, but no simpler".

    Going back to the HTML analogy:

    In fact, a webserver is actually a fairly complicated piece of software. However, all the programming complexity (parsing HTTP, socket I/O, filesystems, caching) was hidden from the "application developer". Reasonably nontechnical people could take a paradigm that they understood, the document, enhance it with a little bit of technical knowledge (the syntax of HTML), and produce something useful.

    Where would the web be if instead of HTML files, people had to write CGI code (or HTTP servers!) to produce content? It never would have left the academic environment.

    So as a guiding principle, webapp frameworks should cater as much as is reasonably possible to nontechnical folks, the same people that made the web useful in the first place.

    "The fact that everyone and their brother can't write a quality web application is no reason to say that they're [webapp frameworks] bad"

    Umm, yeah, it is. Rephrasing that: To the extent that webapp frameworks empower everyone and their brother to write a quality web application, the framework is good. This is why the document paradigmn shouldn't be abandoned.

    I'm not "devaluaing the work of programmers", I'm just saying they should not be the core audience. A good presentation framework should:

    * Look mostly like HTML.
    * Allow anyone to create a page just by adding a file.
    * Require a minimum amount of extra learning in order to add dynamic data.
    * Allow the page author to decide which dynamic data to put on the page.

    JSP, for all its historical faults, today offers most of this. With JSTL and the expression language, page authors can start with basic HTML and tiptoe into the dynamic world. The only trick is to figure out how to get data (generated by code) onto the page in a usable form.

    That's where Tagonist comes in. There are no scoping or nesting issues, it's effectively just one tag.

    If you've never seen a pretty JSP application, look at this:

    http://tagonist.tigris.org/source/browse/tagonist/trunk/examples/demo/content/bookmarks.jsp?rev=5&view=auto&content-type=text/vnd.viewcvs-markup

    Jeff Schnitzer
    jeff@voodoodyne.com
  14. Too complicated[ Go to top ]

    A good presentation framework should:...
    I guess that's where the confusion is coming from you're talking about a presentation framework. If you're just looking to show some information to a limited audience then that's fine. But I think that once you start dealing with more complex user interactions, more complex objects and more complex work flows, a simple presentation framework just doesn't cut it. I think you're taking the simplicity route a bit too far and ignoring that more complex problems exist and those problems sometimes take complex systems to solve.

    HTML is nothing more than a formatting protocol, and a sloppy one at that. Developers and architects are trained to recognize the complexities in systems and the potential problems that can occur. Allow those people the opportunity to make something more complex so long as it works.
    Umm, yeah, it is. Rephrasing that: To the extent that webapp frameworks empower everyone and their brother to write a quality web application, the framework is good. This is why the document paradigmn shouldn't be abandoned.
    Perhaps we have different definitions of good in relation to web frameworks. You're defining good as easy enough for anyone to use. Once you bring it down to that level you're bound to lose functionality. I would prefer to think of good in this situation as, allowing me to accomplish a lot. Not to say that the two definitions are mutually exclusive, but when you consider the amount of time that web application frameworks have been around, I think there's been some pretty impressive progress.
  15. Too complicated[ Go to top ]

    The fact that using plain vanilla JSPs (with taglibs or not) do not scale with large web applications that have to be maintainable is pretty much a regconized fact by now.

    There was a time when I would have agreed with you, but since then things have changed.

    For one, JSP has gotten a lot better. The expression language and basic logic constructs in JSP2.0 and JSTL now make JSP just as easy to use as Velocity. The tag file feature makes it really easy to build the types of layouts that you used to use tiles for. It's fairly easy to make pages "scriptless", so your developers can't cheat and use scriptlets even if they wanted to.

    For another, I've changed. I spent a couple years working on what is probably the largest publicly visible online java system in existance, along with about 50 engineers and half that again in web developers. Believe me, I have a good idea what works and doesn't work in a large-scale environment. Here are a couple things I learned:

    * Engineers don't create web pages, producers do. Production decides what pages are needed and what they look like - and if they can be empowered to create their own pages, they will be much happier than if they have to start filing engineering requests. Engineers should only need to be involved if the application has to do something new.

    * 90% of every web application is simply data rendering. Complicated flows are the exception, not the rule. Take a look at TSS, for instance. There's barely any form processing.
    Yes, components proved their usefullness in all areas /except/ the web layer. So what it is you say? Components are great everywhere except for 'presentation'? By using the term 'presentation' I think you deliberately downgrade the web layer.

    I'm not opposing the philosophical goal of modularizing or componentizing web page design. Obviously nobody wants to cut-and-paste HTML/JSP across a dozen different pages. However, I think the "component model" should be based on document-oriented concepts rather than programmer-oriented concepts. Web developers understand compositional tools like includes and macros, and the new JSP tag files make it fairly easy for them to build these components by themselves without programmer help.

    If your framework requires that in order to create a page (or a presentation component), a programmer must first create a Java class, you've made web development too "hard".

    If you think that this complexity is required, pick an example (one of the wicket examples?) and I'll create the (much, much simpler) Tagonist example.

    Jeff Schnitzer
    Voodoodyne Inc.
  16. Too complicated[ Go to top ]

    For one, JSP has gotten a lot better.
    I think one of the largest additions was display tag. Still, I believe my arguments against JSP stand firm.
    If you think that this complexity is required, pick an example (one of the wicket examples?) and I'll create the ...

    Haha, that's fair enough. But an example without the context wouldn't illustrate the difference enough though (the context being that large team en page interaction for which I don't have time now). An example of the kind of systems the company I work for build is a general practicioners system, which actually /has/ a lot of model interaction.
    Take a look at TSS, for instance.
    Yes, sites like TSS is not like the sites I am building. But even so, TSS developed with Wicket wouldn't be much more complex than build with JSP + Tagonist. It would be a fun challenge to prove this! TSS being so document oriented, I can imagine Wicket vs JSP + Tagish ending in a close draw when it comes to productivity. It would probably result in a taste debate.

    So, maybe we could conclude that for applications/ sites that have characteristics like '90% is data rendering', and that are document oriented, JSPs (+ Tagonist) might actually work out fine. My next question then is, why not use JSF then? Using JSF without tooling is much more complicated than JSP + Tagonist for sure, but - having your 'producers' in mind - they can create pages with even less programming knowledge when having the right tools.

    Furthermore, a way to turn this discussion around is to say that with Wicket and Tapestry, your 'producers' can mock up pages without any programming knowlegde /at all/. They can use Dreamweaver, GoLive, etc to create the pages, and just need programmers to 'wire' them. Even in your case you need programmers. A big difference is that you need to create an 'API'/ context beforehand for the page authors to use, and that with Wicket and Tapestry, the programming of the web layer can be done afterwards.

    Now about reuse. Reuse should go further than the ability to inlude JSP (fragments). Reusable components in Wicket can be anything, from a textfield, to a panel to a whole page. You can reuse a component like a date picker without having to know anything about it's javascript and css requirements, and without having to include the needed resources in your page (and synchronizing them when you refactor pages). Furthermore, you reuse the /whole/ component, including any model interactions and inter-component dependencies. I wouldn't say your 'reuse' model wouldn't work in many cases - in fact it would probably work better than with model 2 frameworks in which even reuse by including can be a daunting task - but I do say that reuse in a component oriented framework like Wicket is more complete and abstracted.
  17. Too complicated[ Go to top ]

    I agree with Jeff.

    I've been looking at various web frameworks over the past week asking myself why I should use any of them instead of just writing tag libraries, which is what I've always done in the past.

    I can't think of a good reason, but I can think of a lot of reasons to stick with tag libraries: the most important one being that I can pass off a good taglib to my HTML developer and have him use it as he sees fit in his web pages, without having to configure a bunch of XML saying which actions map to which views, etc.

    HTML developers understand links between pages, not MVC. They don't want to come running back to their Java developer every time they decide to move a piece of functionality around to a different page.

    Another advantage to taglibs is that you can combine two or more different tags or even different libraries on the same page without setting up some kind of complex mapping in an XML file. Just drop the tag where you want it.

    Can anyone tell me what you really gain by having a front controller?

    Frank
  18. Too complicated[ Go to top ]

    I've been looking at various web frameworks over the past week asking myself why I should use any of them instead of just writing tag libraries, which is what I've always done in the past. ... Can anyone tell me what you really gain by having a front controller?
    Are you comparing pure JSP to Wicket or to Struts?
  19. Too complicated[ Go to top ]

    No,

    I think the comparison would be with Tag libraries, which is what I have come to prefer. Before I used taglibs, I would generally instantiate an object with the "useBean" directive and call methods on it.

    Obviously you don't want to write business logic into the JSP page, but I see nothing wrong with using the JSP to script things out at a high level, leaving the graphic designer free to decide which components provided by the developer will appear where. They key, I think, is that the components provided by the taglib (or the bean) have to be high level enough that the page designer can't produce invalid results by using them incorrectly.
    Are you comparing pure JSP to Wicket or to Struts?
  20. Too complicated[ Go to top ]

    HTML developers understand links between pages, not MVC. They don't want to come running back to their Java developer every time they decide to move a piece of functionality around to a different page.Another advantage to taglibs is that you can combine two or more different tags or even different libraries on the same page without setting up some kind of complex mapping in an XML file. Just drop the tag where you want it.Can anyone tell me what you really gain by having a front controller?

    Yeah, the 'web mvc' models are a thing of the past in my book. The front controller is part of that 'web mvc'/ 'model 2' paradigm. However, we were also discussing component based frameworks (Wicket, JSF, Tapestry and Echo), which are quite different from front controller frameworks.
  21. Component frameworks[ Go to top ]

    One other thing... why create a whole component framework for the web? There are already several great component frameworks, such as EJB or Spring. What's needed is a presentation framework, just some little bit of glue between the world of HTML and the world of code.

    That little bit of glue should be as simple as possible. The fat client UI-widget model is about as complicated as possible. What does it get you, besides scaring off all the nonprogrammers?

    Jeff Schnitzer
    jeff@infohazard.org
  22. Component frameworks[ Go to top ]

    One other thing... why create a whole component framework for the web? There are already several great component frameworks, such as EJB or Spring. What's needed is a presentation framework, just some little bit of glue between the world of HTML and the world of code.That little bit of glue should be as simple as possible. The fat client UI-widget model is about as complicated as possible. What does it get you, besides scaring off all the nonprogrammers?

    Yes, components proved their usefullness in all areas /except/ the web layer. So what it is you say? Components are great everywhere except for 'presentation'? By using the term 'presentation' I think you deliberately downgrade the web layer.

    The fact that using plain vanilla JSPs (with taglibs or not) do not scale with large web applications that have to be maintainable is pretty much a regconized fact by now. If I would use plain JSPs for the systems I am working on today, I would drag myself in copy paste hell, would end up with a monolithic layer of utility modules and I would have a serious problem writing complex pages (pages with trees, multiple lists and forms that all have to be synchronized, some of these 'components' over the span of multiple pages).

    So, I need statefull components to help me reduce complexity (when I put a tree on a page, I wont have to worry about synchronizing its state when I put more components on the page). And I need reusable components to avoid copy paste code, and to help me do my projects more efficient over time.

    And my point in my little JSP rant is not that your taglib solution has scoping problems or whatever, but that you /can/ embed java code, you /can/ mix taglibs and have scoping problems with JSP. A good API minimizes accessibility and shields developers from doing things that are considered bad practice. In that line, I think you could call JSP a bad API. Just the fact that all these bad practice short cuts are readily available, will result in them being used.
    What does it get you, besides scaring off all the nonprogrammers?

    I am not targetting nonprogrammers. Nonprogrammers can use plain JSPs, PHP, or any drag n drop tool they like. Luckily, coporate systems are developed by programmers. And they need the right tools for the right job.
  23. Too complicated[ Go to top ]

    Well, that certainly seems a bit naive and arrogant all in one post. Saying that everything about the web was better in 1995 because everyone could do it is hardly a qualification for going back. Everyone can still make a home page for their cat in HTML but there's definitely a need for something more robust when you're talking about Amazon.com.

    The fact that everyone and their brother can't write a quality web application is no reason to say that they're bad. Yes its more complicated, yes its more error prone. But beyond that, there's also a lot more functionality and a lot more drive.

    How about this, if you would like the simplicity of HTML when writing a fat client remove all of the language constructs and libraries that make life so easy for the rest of us. Limit yourself to only a few simple commands that are easy to understand. Now you're writing in assembler. I wouldn't want to try to build MS Word in assembler and I wouldn't want to write a full-fledged web application that supports a large business without the niceties of programming constructs.

    Bringing non-technical designers in for a front end is usually good. To completely devalue the work of the developers behind the page for the sake of "simplicity" borders on the absurd. Please try to provide a cogent argument for replacing existing frameworks with the framework you wrote.