64

I am new to StackExchange, but I figured you would be able to help me.

We're crating a new Java Enterprise application, replacing an legacy JSP solution. Due to many many changes, the UI and parts of the business logic will completely be rethought and reimplemented.

Our first thought was JSF, as it is the standard in Java EE. At first I had a good impression. But now I am trying to implement a functional prototype, and have some really serious concerns about using it.

First of all, it creates the worst, most cluttered invalid pseudo-HTML/CSS/JS mix I've ever seen. It violates every single rule I learned in web-development. Furthermore it throws together, what never should be so tightly coupled: Layout, Design, Logic and Communication with the server. I don't see how I would be able to extend this output comfortably, whether styling with CSS, adding UI candy (like configurable hot-keys, drag-and-drop widgets) or whatever.

Secondly, it is way too complicated. Its complexity is outstanding. If you ask me, it's a poor abstraction of basic web technologies, crippled and useless in the end. What benefits do I have? None, if you think about. Hundreds of components? I see ten-thousands of HTML/CSS snippets, ten-thousands of JavaScript snippets and thousands of jQuery plug-ins in addition. It solves really many problems - we wouldn't have if we wouldn't use JSF. Or the front-controller pattern at all.

And Lastly, I think we will have to start over in, say 2 years. I don't see how I can implement all of our first GUI mock-up (Besides; we have no JSF Expert in our team). Maybe we could hack it together somehow. And then there will be more. I'm sure we could hack our hack. But at some point, we'll be stuck. Due to everything above the service tier is in control of JSF. And we will have to start over.

My suggestion would be to implement a REST api, using JAX-RS. Then create a HTML5/Javascript client with client side MVC. (or some flavor of MVC..) By the way; we will need the REST api anyway, as we are developing a partial Android front-end, too.

I doubt, that JSF is the best solution nowadays. As the Internet is evolving, I really don't see why we should use this 'rake'.

Now, what are pros/cons? How can I emphasize my point to not use JSF? What are strong points to use JSF over my suggestion?

Improve this question
18
  • 24
    That's a well-written question from a new user. Consider leaving a comment when downvoting.
    – ThiefMaster
    Jul 24, 2012 at 13:36
  • 2
    Since you are rewriting everything I'd not only consider not using JSF but consider not using Java at all. Modern scripting languages (i.e. not PHP or Perl) are pretty nice and developer-friendly.
    – ThiefMaster
    Jul 24, 2012 at 13:37
  • 11
    I didn't downvote, but this is not a question, it's a rant. Vain has made up his mind that he hates JSF, now he asks for more reasons not to use it?
    – Michael Borgwardt
    Jul 24, 2012 at 13:58
  • 4
    Java is the best choice if your application is going to be large (either complex and/or scalable) and/or distributed, using many services; if your application does not fit in this category (is not so complex and does not need to be scalable) then Python (Django) or Ruby (Rails) would be better choices. The complexity of JSF, has the benefits of the power it comes with; as alternatives to it you should take a look at other Web Frameworks such as Spring MVC or Struts 2 if Java is mandatory.
    – Random42
    Jul 24, 2012 at 14:17
  • 14
    This is a rant looking for backup, not a question as such.
    – user1249
    Jul 25, 2012 at 12:45

4 Answers 4

Reset to default
26

There is at least one very good reason for considering JSF.

It is a standard part of the Java EE stack, and hence will be available - and working - in ALL Java EE containers for a very, very long time. And maintained too, without you needing to do so if you have adhered strictly to the Java EE specification.

If this is a concern for you, then you should consider it. Most software live longer than their designers think, especially if taken in consideration when being written.

Improve this answer
3
  • 4
    Im not sure about that. For J2EE, the words 'standard' and 'working' are not written in stone, specially when we talk a system that will/should be supported for many years, including changes to the version of j2ee used.
    – magallanes
    Jun 25, 2013 at 12:43
  • 8
    In my (limited) experience with JSF this argument actually does not hold. I have seen applications getting stuck with one version of JSF and no sane migration path to a newer version. Sure the app server still executed it, but that was about all the support you would get if you havn't large amounts of money to burn on overpriced support contracts.
    – Jens Schauder
    Feb 27, 2014 at 8:34
  • @JensSchauder my experience is just that you can write portable applications, migrate and upgrade their version of jsf. This involves to know the spec and to code to it, not to its implementation. It does work, as coding for JPA instead of Hibernate works. Been doing that for years.
    – ymajoros
    Jan 27, 2015 at 16:30
14

Now, what are pros/cons? How can I emphasize my point to not use JSF? What are strong points to use JSF over my suggestion?

You already seem to have made upt your mind about the cons, and I have to a gree with some of them (it does not separate layout and logic enough, and the resulting HTML is often atrocious), but disagree on others (if you use Facelets, which I would very much recommend, then the output should definitely be valid).

So here's some pros:

  • There are some very powerful component libraries like PrimceFaces or RichFaces that offer a lot of functionality out of the box. These can save you a lot of work if they cover your requirements (not so much if you have non-negotiable requirements not covered by them).
  • Composite Components offer a very clean way to modularize your pages
  • JSF integrates very well with the rest of Java EE
  • AJAX via component re-rendering is really easy and convenient

But certainly none of these advantages are so big that you should use JSF over some other framework that your team already has experience with.

Improve this answer
9
  • 1
    It's not the IDs, it's invalid attributes. Like "role" and "aria-expanded" in the tab view. Do you know how to fix this?
    – Bruno Schäpper
    Jul 25, 2012 at 7:27
  • 1
    @Vain: nope, seems to be a different issue, perhaps with a component that I did not use or which is new. It's possible to change the HTML output of JSF components by specifying an alternative renderer (which ideally just overrides one or two methods of the default renderer), but of course this is not something you should have to do just to get valid markup.
    – Michael Borgwardt
    Jul 25, 2012 at 7:41
  • 1
    The atrocious HTML is due to the implementation used. It is my understanding that the debug mode of the reference JSF implementation is especially bad at this. Would you know of better settings to produce better HTML?
    – user1249
    Jul 25, 2012 at 12:54
  • 1
    @Thorbjørn Ravn Andersen Yes, the problem with invalid HTML is actually a problem of PrimeFaces. We use it because it's build on jQuery-UI. What is your advice; should I use an other library? I really like valid HTML. For me it's simply a MUST.
    – Bruno Schäpper
    Jul 25, 2012 at 13:02
  • 1
    Revisiting my first question here, I would like to share some experience about your pros: We are working with JSF, and with that experience we wouldn't choose it again. Barely anything works as expected and out of the box. Yes, there are powerful Libraries. But we ended up doing all our components ourselves, because they wouldn't work quite as we needed it. It's stunning how fast we had our own 'DataTable' with lazy loading while scrolling. Composite Components didn't work for us, I can't tell you why, they are buggy I guess. AJAX re-rendering is actually a pain for client side JS.
    – Bruno Schäpper
    Feb 7, 2013 at 7:41
9

JSF is adequate stateful web framework for Java that is a standard which means its supported out of the box by many major vendors (including FOSS ones). It has strong 3rd party library support (PrimeFaces, IceFaces etc). However, it does fundamentally 'break the web' due to its stateful nature (and a bunch of other things). See Matt Raible's comparison of JVM based web frameworks, JSF usually comes close to last.

Edit - with JSF 2.2 - you can begin to argue that it doesn't break the web as much as it once did. In fact it's HTML5 integration is not all terrible :-).

Improve this answer
4
  • 1
    It 'breaks the web', indeed.. And thanks for Matt Raible's comparison, didn't know that.
    – Bruno Schäpper
    Jul 25, 2012 at 6:02
  • 3
    Note that JSF is not necessarily stateful. I agree it often is, but there's pretty good support for stateless GET based requests and if you don't use a form then there's no state at all.
    – Arjan Tijms
    Jul 29, 2012 at 18:47
  • Fair point Arjan, I guess I've just seen to many stateful uses.
    – Martijn Verburg
    Jul 30, 2012 at 8:53
  • Link to Raible's presentation: slideshare.net/mraible/…
    – zaidaus
    Jun 10, 2013 at 12:48
6

We had a legacy JSP/Struts 1.0 application. We skipped Struts 2, JSF and everything else that has happened since Struts 1 and jumped in to Spring 3.0. It has support (and an active community) for our wish list - Eclipse IDE, MVC and REST. Plus we ditched our vintage homegrown Javascript/ajax for jquery.

YMMV but Spring has been a smooth migration for us.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.