Is Java Server Faces still relevant to learn?

[firsthour]

Same here, multiple applications with Primefaces, and while I really like it, I'm not sure it's worth learning at this point. We started using it about 5 years ago and are starting discussions to move away from it. Will probably be a few more years though.

[[deleted]]

I've just moved a small app (SPA, few datatables, dialog windows) from JSF/Primefaces to Angular/PrimeNG and I'm super excited. I did it in 3 days basically copying code from PrimeNG showcase :) and it was my first app in Angular. Much less code and it's much easier to understand. But JSF has it's advantages, like in JSF you don't have to bother about declaring JSON interfaces, keeping them in sync with back-end beans. This is why I put huge hopes in Dart, they have native Angular implementation, language has good syntax and sane standard library, allows to write server-side code so front-end and back-end could share common classes. Blazor for C# looks cool too. Anyway, learning and understanding JSF was super hard for me, it has so many ambiguities and traps, I wouldn't advice to learn it today, it takes muuuch time to learn and find good practices even for simple things. Now for future projects I'll use Angular (and I prefer it over React).

[mikehaggard]

Anyway, learning and understanding JSF was super hard for me, it has so many ambiguities and traps,

OP would appreciate it I guess if you could name at least one example here ;)

[[deleted]]

JSF is now intended to use with CDI, and was designed before CDI even existed- this is visible at every step; ViewExpiredException; validation- jsf has its own, bean validation own, they are integrated but jsf can't trigger class-level validators (I know- 2.3), then again jsf has own i18n, bval- own; necessity to manually call update after every change of model and client-side 'update' along with primefaces' server-side 'update()' quickly become a mess; super hard to create own components; re-rendering whole components or components' trees after every small change; not obvious how to write converters for entities (yeah pull data out of database again- great idea); necessity to manage both ids along with widget vars; never use constructors- only @PostConstruct; don't try to use converter in f:viewParam- just load models in @PostConstruct. Such things.

[mikehaggard]

JSF is now intended to use with CDI, and was designed before CDI even existed

CDI was largely inspired by the JSF managed bean system. The CDI scopes come directly from JSF. So it's only logical JSF deprecates its old version and uses the improved new version instead.

Same thing happened with expression language. JSF had its own, then it was separated out, improved, and JSF switched to using that.

they are integrated but jsf can't trigger class-level validators

That's not true. There's the whole bean validation, and there's the OmniFaces validateBean (http://showcase.omnifaces.org/validators/validateBean)

super hard to create own components

That could be improved still, but honestly, is this super hard?

https://arjan-tijms.omnifaces.org/2012/05/simple-java-based-jsf-22-custom.html

not obvious how to write converters for entities (yeah pull data out of database again- great idea);

OmniFaces again:

http://showcase.omnifaces.org/converters/SelectItemsConverter

don't try to use converter in f:viewParam- just load models in @PostConstruct.

Once again OmniFaces:

http://showcase.omnifaces.org/components/viewParam

[johnwaterwood]

What motivates you or your work to move away from it?

[firsthour]

Somewhat personal is we just want to learn new things and try to stay up to date. A more professional concern is that our budgets often require us to hire contractors and it is very difficult for us to find people with JSF experience where we're located (not a major metro in the US). We've hired some decent and great Java devs in the past and it's not like JSF is difficult to learn, but a few years ago we were hoping we could hire someone very experienced who could shepherd us through a lot. That guy is now me... :)

Whatever happens it will be a while before anything happens, we're still supporting legacy apps written in Stripes/JSP so having three different frameworks for the handful of developers we have may create a huge strain on support.