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?

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
If this question can be reworded to fit the rules in the help center, please edit the question.

19

That's a well-written question from a new user. Consider leaving a comment when downvoting.
–
ThiefMasterJul 24 '12 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.
–
ThiefMasterJul 24 '12 at 13:37

8

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 BorgwardtJul 24 '12 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.
–
m3th0dmanJul 24 '12 at 14:17

12

This is a rant looking for backup, not a question as such.
–
user1249Jul 25 '12 at 12:45

4 Answers
4

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.

+1 That's the first real reason I can accept.
–
Bruno SchäpperJul 25 '12 at 13:04

3

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.
–
magallanesJun 25 '13 at 12:43

4

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 SchauderFeb 27 '14 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.
–
ymajorosJan 27 at 16:30

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.

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äpperJul 25 '12 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 BorgwardtJul 25 '12 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?
–
user1249Jul 25 '12 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äpperJul 25 '12 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äpperFeb 7 '13 at 7:41

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 :-).

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 TijmsJul 29 '12 at 18:47

Fair point Arjan, I guess I've just seen to many stateful uses.
–
Martijn VerburgJul 30 '12 at 8:53

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.