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?
18
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.
3
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.
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 :-).
4
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.