The strong point for JSF is that your in-house or dedicated Java developers don’t need to know everything about frontend to do frontend stuff. However, over time, JSF projects become too complex to maintain, even if your team consists of 100% senior engineers. You're always days behind schedule when you require a use case that isn't provided with existing widgets/features. Developers are forced to create monstrosities of code trying to use JSF to work around the lack of some critical functionalities (like simple REST services). Switching from JSF to client-side frontend frameworks like Angular, React or Vue.js greatly improves developers' efficiency, makes state management much easier and code testing much more streamlined. You don’t need to move your entire JSF-based app at once, break it down and do it in pieces.
JSF is a server-side framework for building the front end of Java-based web applications. Angular is a client-side framework by default for building user interfaces of web applications with any backend including Java. Moreover, with tools such as Angular Universal, you can make Angular work as a server-side UI framework.
Angular is a widely-used framework and platform for building Single Page Applications (SPAs), developed and supported by Google. SPA web applications don't reload for each user's click. That's why such apps get positive user feedback and became mainstream in web building.
“JSF has an overhead on the server side compared to JS frameworks like Angular. JSF needs to create a ViewRoot for each request for rendering, executing ajax events, and so on. That's much more CPU usage on the server side. I would always build web applications with JSF but nothing social, which expects millions of users a day. It better fits something like intranet, enterprise, backend applications” , states Thomas Andraschko, PrimeFaces Core Developer (25 Feb 2021).
Is JSF obsoleted?
The last "relevant" tutorial at Youtube on JSF was released years ago...
Numerous complaints about JSF are mostly related to old versions and some of them are now outdated. However, companies may still use JSF 1.0, first realized 15 years ago (or, at best, JSF 2.0) with a lot of ad-hoc programming.
As Arjan Tijms, a project lead for JSF, stated in his article on Oracle blog “Java for the enterprise: What to expect in Jakarta EE 10”:
The next version of JSF will be JSF 4.0. Its own major theme will be removing legacy functionality that has already been deprecated. Plus, legacy features that haven’t been deprecated before will be deprecated and likely removed in a future release. Support for Jakarta Server Pages (JSP) as a view declaration language will be removed as well. As for bigger features, a prototype is currently in the works to add a simple REST lifecycle to JSF. This is not intended as a full-featured REST framework.
In this regard, migration is absolutely necessary whether it will be to a newer JSF version or to another UI framework for Java web applications.
The question is when to do this: if not today, it may be more costly to make it tomorrow if you plan to improve your software application.
Ihatejsf.com, a platform to share the frustrations with using JSF.