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?

Community
  • 1
Bruno Schäpper
  • 1,916
  • 2
  • 14
  • 24
  • 24
    That's a well-written question from a new user. Consider leaving a comment when downvoting. – ThiefMaster Jul 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. – ThiefMaster Jul 24 '12 at 13:37
  • 1
    @ThiefMaster: Thanks for your Support. A comment would indeed be appropriate when downvoting. Java wouldn't be my first choice, but is somewhat fixed. – Bruno Schäpper Jul 24 '12 at 13:43
  • 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 '12 at 13:58
  • 1
    @Michael Borgwardt: I tried to add some thoughts to my criticism. But; there must be a reason for using JSF. It is a standard, after all. However, I can't imagine why. So.. Why SHOULD we use it? – Bruno Schäpper Jul 24 '12 at 14:02
  • 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 '12 at 14:17
  • @VainFellowman You've already summed up most of what's wrong with JSF. Perhaps you should be asking in what case should one use it, to understand it from both sides. – Kshitiz Sharma Jul 24 '12 at 14:30
  • 14
    This is a rant looking for backup, not a question as such. –  Jul 25 '12 at 12:45
  • @Thorbjørn Ravn Andersen: It's somwhat a rant.. Looking for backup. And really strong arguments to use it. But as mentioned, I liked it at first.. But found some real problems (for me). I did a lot of research and I am actually trying to use it as we speak. So it's not just a rant out of hate and misunderstanding. – Bruno Schäpper Jul 25 '12 at 13:10
  • 1
    @VainFellowman the learning curve of JSF is steep. You will find that there are many good JSF questions and corresponding answers on SO - consider reading those now. –  Jul 25 '12 at 13:45
  • 2
    @ThorbjørnRavnAndersen: Every question about "how can I get my company to buy-in to *x* technology?" is the same question, but in reverse. We answer all of those and leave them open... – Steven Evers Jul 25 '12 at 23:51
  • 1
    @VainFellowman As Thorbjørn has already stated, the learning curve is steep. I am an avid web developer and never have I used such a powerful and robust component based web framework. I am more productive with it than anything else I have ever used. On that note I have seen fellow junior developers seriously struggle with it so certainly the difficulty to learn and the expertise needed is a serious drawback. – maple_shaft Jul 26 '12 at 02:10
  • @SnOrfus I disagree - the "I want my company to use X because it looks interesting. Give me arguments" is different from "I absolutely despise X. Give me arguments". –  Jul 26 '12 at 03:17
  • @maple_shaft: No doubt you are productive with it. As I can see it myself, you can create something acceptable in a relatively short time. But seriously; As a web developer - if you were to create a web framework, would you come up with something like JSF? What would you do in an other way? And why? – Bruno Schäpper Jul 26 '12 at 05:53
  • 1
    @VainFellowman Before I started doing JSF web development I was using ASP.NET or Struts. Even then I was thinking, "Wouldn't it be great to have a component based framework like ASP.NET without all of the pain and other problems?" Turns out JSF2 was exactly what I hoped for. My company has customers where if it took us over 5 months to write a webapp we would be out of business next year. If a framework can help us create something of moderate quality very quickly then it is perfect for us. If it becomes insanely popular then we can worry about rewriting with better web standards in mind. – maple_shaft Jul 26 '12 at 11:02
  • @ maple_shaft Sounds perspicuous. But arguable for a new project, with great UX, cloud-integration and a REST api for an Android app ready. Wouldn't it be better, to have the same api for multiple UIs? – Bruno Schäpper Jul 26 '12 at 11:17
  • Huh. If you can't handle JSF, what will you use? JSF is the lightweight, *easy* way to do things on the web (which is why I use it... I don't have time to learn all the stuff to do it the other ways mentioned!). As far as the output stuff, the only complaint I ever hear is about the use of tables. And in that regard the new thinking is that they're just fine. The old school way was to avoid tables at all costs, due to the way they were abused, but time has reversed that "best practice". – Brian Knoblauch Apr 08 '13 at 15:26
  • The questions of course is about reasons to USE JSF. – Dima Dec 11 '13 at 05:23

4 Answers4

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.

  • 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 '13 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 '14 at 08: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 '15 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.

Michael Borgwardt
  • 51,037
  • 13
  • 124
  • 176
  • Thank you for your input. It's actually the PrimeFaces library, that produces invalid output. I have close to nothing in the prototype yet (3 widgets), but 19 Errors and 2 Warnings. – Bruno Schäpper Jul 25 '12 at 06:10
  • @Vain: well, it's been 2 years since I used PrimeFaces, so things may have changed, and my memory is vague. I remember having some validation errors, but they were all of the same 1 or 2 types, which I was able to fix through configuration changes (something having to do with generated element IDs?) – Michael Borgwardt Jul 25 '12 at 07:16
  • 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 '12 at 07: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 '12 at 07: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? –  Jul 25 '12 at 12:54
  • @VainFellowman so your problem is not with JSF but with PrimeFaces? –  Jul 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äpper Jul 25 '12 at 13:02
  • @VainFellowman then don't blame JSF, blame PrimeFaces. If you want a recommendation what ot use instead of PrimeFaces open a new question. –  Jul 25 '12 at 13:41
  • 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 07 '13 at 07: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 :-).

Martijn Verburg
  • 22,006
  • 1
  • 49
  • 81
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.

jqa
  • 1,410
  • 10
  • 13