Announcement Announcement Module
Collapse
No announcement yet.
What is your experience with JSF? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • What is your experience with JSF?

    Good day gents!
    First, some quotes:
    Java Server Faces has been hyped as the next big thing in J2EE web development for more than two years and is now taking shape. In its current incarnation, JSF is a JSPcentric affair that is heavily targeted toward GUI builder tools, resulting in code that gathers all sorts of concerns in the web page. There is no notion of view-agnostic controller and model, and no concept of pluggable views. With this programming model, JSF is well-suited for attracting .NET and other RAD developers, but not for becoming the de-facto standard web MVC framework in the Java world.

    We expect to see a massive vendor marketing push behind JSF. However, we are not convinced that JSF will represent a real advance on existing open source solutions such as Tapestry, WebWork, and Spring web MVC.
    p. 408

    Expert One-on-One
    J2EE Development without EJB
    Copyright В 2004 by Rod Johnson and Juergen Hoeller.
    Published by Wiley Publishing,

    JSF - needs to listen to developers to see what they want instead of tools vendors.
    Mat Raible
    Comparing Web Frameworks Struts, Spring MVC, WebWork, Tapestry & JSF
    В 2005, Virtuas
    JSF is not mature and has not proven in the scalability arena.
    Craig Conover , Staff Engineer, Developer Tools, Sun
    http://developers.sun.com/prodtech/j...une242004.html

    Once upon a time (long time ago actually) I was developing using VBA. So genetically speaking I find JSF a really appealing choice. Especially, when I am confronting a task of creating a local thingy like interface to MySQL (though, frankly speaking, I would rather go for the boiler-plate PHP solutions like phpMyAdmin) or a more challenging endeavor - Uncle Joe Convenience Store Web Site. Why? Because I know that uncle Joe will run the server on his one and only one computer. But should his enlightened grandchild squeak 'We wanna cluster! It's so kool!' My enthusiasm towards JSF most certainly would be dampened - wait a minute, session replication! So my experience with JSF in enterprise environment is equal to null. But Spring supports JSF as web layer technology (hey, not all applications are supposed to be scalable) and I found a number of FSF related threads in this forum. That begs the question what is your experience with JSF in enterprise environment? Does it perform in a cluster on its own or with the Spring or crawls like a tortoise. Would you advise to bet on JSF instead of Spring MVC in something more challenging then Uncle Joe Convenience Store Web Site?

    Cheers,
    Arno

  • #2
    I like JSF. I have written a simple application using it and I don't want to go back to Struts now (or any action oriented frameworks) but I have to admit that I still need to experiment a bit with it.

    First of all, you have to realize that when you use JSF, you don't have as easily the control over the generated XHTML as when you use an action-oriented web framework since it is a component oriented framework. In fact, on your first project, you'll probably need to develop a couple of new renderers and that a extra cost you have to be willing to pay. But after having finished a couple of projects using JSF, you should have a corporation standard set of renderers and this shouldn't be a problem anymore. It's kind of similar to Hibernate in which you don't fully control the SQL outputed by the framework. Some people find it annoying, some people find it more productive. Depend of your organization I guess and the W3C standards you need to respect.

    Also, JSF components are stateful by default. It's a very nice feature to have in my opinion but it can have a big impact on performances (especially memory consumption) so you should do some testing before going down the JSF road (or any components oriented framework for that matter).

    Finally, the biggest complain against JSF is the JSP integration and it's true, it totally sucks (might have to do that JSP is by itself a bad technology). I recommend to use Facelets to avoid a lot of pain associated with working with JSP. Plus, you'll get a layout manager la Tiles out of the box.

    Hope it helps!

    Comment


    • #3
      Thank you, madtree, for your input.
      I like JSF. I have written a simple application using it and I don't want to go back to Struts now
      True. I've been playing with Sun Studio Creator 2 and it is mostly enjoyable experience in terms of creating JSF GUI and page navigation.

      JSF components are stateful by default
      Yep, so it begs the question, have you tried to run you JSF-based application in clustered environment? I am concerned about session replication between the main and back-up server. Does JSF perform according to your experience in a cluster?

      Comment


      • #4
        I personally would like to see more organic support for AJAX in JSF before jumping on board - from the standardization body, the tool vendors, and the component vendors. .Net 2.0 added that support with Atlas, and JSF again needs to play catch-up in this field, IMO.

        Another practical factor I'd take into account is the current developer skill set - most of the developers today are too comfortable with classical request/response-oriented frameworks to migrate to JSF. Of course that leads to the same old "chicken egg" situation...

        Comment


        • #5
          Originally posted by manifoldronin
          I personally would like to see more organic support for AJAX in JSF before jumping on board - from the standardization body, the tool vendors, and the component vendors. .Net 2.0 added that support with Atlas,
          Oh, they did? Good! Greasemonkey, get'em! get'em!
          Greasemonkey lets you mash-up websites.
          It lets you extend and script websites and integrate that script right into the original site as
          if the designers had intended it to be there. It lets you use their web site, their data, their servers,
          their work to serve your purpose and function. There will soon be an army of hackers enhancing every site you use.
          Whether that site likes it or not.
          http://www.nivi.com/blog/article/gre...siness-models/
          For me AJAX is by hackers for hackers. I'd rather stay away. Yeah, and JavaScript maintenance nightmare...

          Originally posted by manifoldronin
          Another practical factor I'd take into account is the current developer skill set - most of the developers today are too comfortable with classical request/response-oriented frameworks to migrate to JSF.
          I think, this part is easy. Sun Studio Creator makes it a fly. Yet, again, security model. Every bloody jsp at the context root. I love Spring MVC for its policy of sticking everything behind WEB-INF.

          Comment


          • #6
            Originally posted by Arno Werr
            For me AJAX is by hackers for hackers. I'd rather stay away. Yeah, and JavaScript maintenance nightmare...
            Well, that was what I thought of javascript also, until having worked on an ajax application for the past year. I realized that two factors have changed since the last time I had to work with javascript (5 years ago) - 1. browsers now have much better and consistent support for javascript, and yes, even IE. 2. a lot of 3rd party libraries, e.g., prototype, scriptaculous, and YUI, are mature enough to shield application developers even further away from the nuisances.

            You are still right in that overly complex javascript code can be a maintenance nightmare. However I see that as just one more reason to enforce design/coding displines, rather than a downright showstopper. After all, it's the same price we pay for using any dynamic script languages - the more flexible it is and/or the less displined the developers are, the easier it is to write messed-up code.

            Originally posted by Arno Werr
            I think, this part is easy. Sun Studio Creator makes it a fly.
            See, that's the part that might not be so easy. Is Sun Studio Creator 2 fantastic in building JSF pages and even the whole web tier? Absolutely. But I'm building an entire application, and there is lots of other non-JSF code I'm going to need to write, and I would really like to do it in the IDE I'm comfortable with - e.g., Eclipse or IntelliJ. Now if I have a team of 10 developers who have been using IntelliJ for the past 2-3 years, with the dev environment all rigged around that IDE, then the cost of migration has to be taken into consideration.

            Please understand that I'm by no means bashing JSF or saying it won't make it. I'm merely pointing out the things that I would like to see resolved/remediated before I can comfortably commit the project(s) I'm reasponsible or going to be responsible for to JSF.

            Comment


            • #7
              Thank you manifoldronin
              About AJAX. Once I've heard about recent U.S and U.K. legislation cracking down on companies producing inaccessible cites. AJAX means lots and lots of JavaScript, and JavaScript is a surething of making a cite unusable for people with modern and not so modern browsing devices (text-based browsers, audio-browsers, hendhelds without JS etc.). How are you dealing with a scenario that you might be helping a would-be disgruntled employee to bring a class suite against your current customer because that employee could not access all available web content using his/her favorite Lynx? AJAX, AJAX...

              Comment


              • #8
                Originally posted by Arno Werr
                Thank you manifoldronin
                Enjoyable discussion for me too.

                Originally posted by Arno Werr
                About AJAX. Once I've heard about recent U.S and U.K. legislation cracking down on companies producing inaccessible cites.
                The libertarian in me is bellowing "Remeber, remember, the Fifth of November" - but this isn't yro.slashdot.org and I digress.

                Originally posted by Arno Werr
                AJAX means lots and lots of JavaScript, and JavaScript is a surething of making a cite unusable for people with modern and not so modern browsing devices (text-based browsers, audio-browsers, hendhelds without JS etc.). How are you dealing with a scenario that you might be helping a would-be disgruntled employee to bring a class suite against your current customer because that employee could not access all available web content using his/her favorite Lynx? AJAX, AJAX...
                That's a fair point, but then lots of web sites that don't use any javascripts are not Section 508 certified either. Heck, many sites can't even withstand increasing browser font size to maximum, how much accessible do you supposed they are for the vision impaired?

                Comment


                • #9
                  Ajax, Javascript and Maintenance Nightmare

                  Originally posted by Arno Werr
                  For me AJAX is by hackers for hackers. I'd rather stay away. Yeah, and JavaScript maintenance nightmare...
                  Think Google, think GWT ! No more messing around with Javascript. BTW the modern Ajax libraries like DOJO, Prototype etc. also do a nice job of abstracting the cross-browser idiosyncracies ..

                  Comment


                  • #10
                    Any advances in how not to show my application code (I am not talking about HTML, I mean JS here) to anybody in the Universe willing to click 'View Page Source'? I cannot vouch for the browsers but I'm still keeping my personal idiosyncrasy called paranoia for application security. You could hardly find more notorious technology in terms of security holes as JavaScript. A dream language for hackers. They did not break into Google yet? Long live FreeBSD!!!

                    Comment


                    • #11
                      Originally posted by Arno Werr
                      You could hardly find more notorious technology in terms of security holes as JavaScript. A dream language for hackers.
                      I know we are like ten thousand miles OT by now but I just couldn't resist the bait - well IMHO the alleged security holes in javascripts are not really in javascript as a language itself, but rather come from developers knowing too little and assuming too much. Check out thedailywtf and you'll see incompetent people can actually be quite competent at finding ways to screw up their system security, with or without javascript - e.g., by relying on client-side security checking, or by injecting cookie values into SQL statements.

                      Comment


                      • #12
                        The idea of JSF being easy and extendible is the biggest mistake that someone can make actually..

                        On the surface the technology seems to be fine...but as soon as you try to do things like custom components or try to do something like central exception handling without forcing the developers to deal with runtime exceptions in their mananged bean code, you run against a wall...

                        JSF is one of the few specs in java that are surely unfinished and one of the technologies that just ignore a lot of the best practices in software development ....

                        Try to do form based validations where certain fields have a condition to another field in the form etc...

                        Component based validation is no problem at all but if you want to write a custom validator that should validate a form instead of a component...you're screwed etc..

                        Just search the net for reviews and you will see that JSF is for sure not the way to go for big projects....

                        Comment


                        • #13
                          What are you talking about here? Nobody uses pure JSF these days. None of your mentioned problems is a problem anymore.

                          Comment


                          • #14
                            we're using the IBM JSF implementation....

                            They're solved? Could you explain me in detail how exception handling is solved with runtime exceptions? (No sorry, im working in a portlet environment....web.xml error-page directive wont work for me)

                            How do you do form based validations with your custom validators?

                            Im just curious

                            Comment

                            Working...
                            X