[manishsharan]

JSF ? Oh those gullible youngsters !

JSF is the slowest way to do web development for rich client UI: starting stopping J2EE servers is time consuming. HTML templating is difficult; you can't see what you screen looks like until you serve the page from your J2EE server .Also JSF is an unnecessary abstraction over HTML : it is much easier to maintain state on client itself using any of Javascript libraries like React or Backbone or others. You are much better off using REST servlets or REST Spring MVC with your javascript. JSF impedes the growth of features or functionality on a page: as you add more widgets to you page like JQuery plugins , you will be suprised by the amount of backend code you will have to write. Ultimately ,you will eventually resort to hacks and you page state and you JSF state for the page will deverge. Sadly you wont discover this mess until you are waist deep in this pile of muck.

JPA is pretty awesome ; however I have learnt over the years that you need to fine tune your queries using explainplan rather that relying on generated queries; define the views on the db itself and load them with JPA; this way the others frameworks or related application ,like a ASP application or a python web application or reportng application, can also leverage the same data and view.

[smoyer]

JSF isn't the greatest, but it's improved a lot starting with version 2.0. I can indeed see a preview of what my page will look like (with templates applied) right in my IDE. The fact that you called it J2EE makes me think you're talking about the "old" Enterprise Java. I abandoned it for a while back then too - it was no fun to use!

[emsy]

JSF 2.0 improved a lot in comparison to JSF 1.x but is still crap compared to nearly any other Java web framework. I have worked a lot with JSF. At the end of a development cycle of a large app, we decided to start over and evaluated other frameworks. Nearly every problem we had with JSF (which manishsharan listed correctly) were non existent in the other frameworks. Not only that but they were mostly a breeze to work with. Once you start using JSF extensively you know immediately that it's a standardized platform becaue everything is a compromise. Then you hear that everything sucks less with Primefaces until you find out how inconsistent the API is and how unprofessional the code looks (this may have changed now but was definitely a problem 2 years ago).

I can sign manishsharan's approach: just use a REST server and a SPA framework. It makes frontend problems leaking in your backend much less likely to happen (another problem some developers had with JSF at my last job). You are forced to separate UI and backend which is a problem that's not exclusive to JSF. It's also easier to make features of your webapp available as an app where it makes sense.

[manishsharan]

I should have clarified: previewing a page in an IDE is not enough in my use case (banking): I would want to preview my page on different devices' browsers.

[henk53]

>I would want to preview my page on different devices' browsers.

What's stopping you?

With JSF you can write normal HTML that you can load on every device. See http://jdevelopment.nl/jsf-22/#1111 and for the older somewhat less capable version: https://en.wikipedia.org/wiki/Facelets

[marktangotango]

The main differentiator of jsf as a display technology is server side rendering, which you allude to but didn't state explicitly. When used idiomatically, jsf removes a lot of compmexity from the stack; very little or no client side javascript, client side templating, marshalling and unmarshalling data from to json or xml representation. All these things become things the developer doesnt have to deal with.

BUT before i start to sound too much like a fan boy, where jsf fails is when you need to anything off the jsf path. Then you are looking at implementing custom components or tacking on the entire client side js ecosystem.

So, jsf may have a place for rapid implementation if your devs aren't proficient with client side ui imo, but thats about the only time its appropriate, again imo.

[mark_l_watson]

They used two frameworks on top of JSF though. I was never a fan of JSF but years ago I loved using simple servlets and JSPs. Hacking JSPs and later factoring out common code to custom tag libraries was a fast way to prototype with a path later to making code cleaner and more maintainable.

[henk53]

>They used two frameworks on top of JSF though.

The interview mentions OmniFaces and PrimeFaces. These are not frameworks on top of JSF.

PrimeFaces is a component library. The entire purpose of JSF was to make such libraries possible. It introduced a component model with exactly the intend that a marketplace of components would appear.

This indeed happened. There's PrimeFaces, RichFaces, IceFaces, Trinidad, and a few others. They don't "fix problems" in JSF, but are what JSF was created to provide.

OmniFaces is a little different. It's a utility library. It does fixes small inconveniences in the JSF API, but it too is not a framework and makes use of the very extension points that JSF explicitly has provided.

Compare this to Eclipse. It's weird to say that JDT is a framework on top of Eclipse, since Eclipse was specifically made to host plug-ins.

[mark_l_watson]

Thanks for the clarification!

[henk53]

>starting stopping J2EE servers is time consuming.

Starting and stopping j2ee servers indeed takes a long time. But so does booting Windows 9 on an old 386.

Why do you bring up J2EE? The article is about Java EE, which is really, really fast in starting/stopping. On my 3 year old desktop (Ubuntu 14.10, 3.4Ghz i7, 16GB RAM, Samsung 830 SSD), JBoss starts in exactly 1 second. Liberty takes 1.5 orso, GlassFish takes between 2 and 3 seconds.

That's not a LONG time, IFF you need to restart.

For typical JSF you don't need to restart at all. You make a change on the page and reload the browser. That's it.

With a standard JVM you can also make changes inside Java code, as long as those changes are inside a method. The IDE will hot deploy only the changed code and the JVM will hot reload it. If you want to structurally modify classes (add/remove methods, add new base class) then you can still hot reload them, but you need to install JRebel. This has little to do with JSF, and more with Java in general.

>you can't see what you screen looks like until you serve the page from your J2EE server

Not true. JSF lets you create pages using normal HTML, which can be previewed from their source.

>Also JSF is an unnecessary abstraction over HTML : it is much easier to maintain state on client itself using any of Javascript libraries like React or Backbone or others.

What's easier is perhaps personal, but I don't think the abstraction is unnecessary. First of all when using normal HTML to create pages there's not much abstraction in the first place, it's normal HTML. Then the advantage is that you can VERY EASILY bind input/output to the server. Client-to-server data binding is JSF's strong point.

And it's not just easy, you also get validation thrown in there for very little cost and JSF is aware of what it has rendered when processing data that's being send back. This allows it to mitigate certain attack vectors, like the mass attribute assignment vulnerability in RoR.

>you will be suprised by the amount of backend code you will have to write.

Funny, how my backing beans are always really small and simple, despite the pages being of arbitrary complexity.

>Ultimately ,you will eventually resort to hacks and you page state and you JSF state for the page will deverge.

Rarely an issue if you half know what you're doing. Client side JSF can make all the changes it wants, and when it's time to update to the server you send that data to the server. Where's the problem?

In every client-server architecture there are sync issues to be aware of. With a js client and JAX-RS the server can also be out of sync if other pages or other clients made changes. This is not unique to JSF.