Hey, the founder of PrimeFaces here. The tech got old but still gets the job done. We'll do a significant update to PrimeFaces this year with new demos, documentation and new slick UI theme.
Oh, I have a long overdue thanks I should address to you. The project I used PrimeFaces on was completed like five years ago, but it saved us a lot of headache. So, thanks! :D
Hi, I was involved with JSF from the beginning, and I am happy to report it is still evolving. A new release of JSF will be in Jakarta EE 11, for example. As for big sites that still use it, I just checked and this still works:
1. sign in to irs.gov.
2. go to the page where you get a tax transcript.
3. on the landing page for the transcript feature, do **View Source**.
4. look for javax.faces.
So, that's a pretty big site.
If you don’t like or don’t absolutely want to build a single page application I also think introducing an API just for the sake of an API is overengineered. Server side rendering has a bit of a renaissance so if you want I can recommend Spring Boot with Thymeleaf and htmx plus some nice styling (I personally like material design but I am usually happy with a console UI so your experience might differ. Spring plus Thymeleaf for the server side rendering, htmx for a bit of dynamic frontend stuff.
JSF with PrimeFaces is still valid, but mainly because server-side rendering has experienced a renaissance. With good design, you could even expose APIs using Jakarta RS, if your customers want to do system-to-system integrations rather than using your UI.
"With good design, you could even expose APIs using Jakarta RS." The assumption is that you have a well-designed architecture that encapsulates business logic so that it can be used both by JSF and exposed as an API.
After 7 years of react and angular, 90% of the applications I have implemented could have been done with JSF in a fraction of the time. JSF is a superior technology for most applications... By far. Special mention for wicket.
JSP is just a way to produce HTML while evaluating expression to produce values or include optional sections.
Thymeleaf does the same kind of thing and is much more elegant and support components. htmx with Thymeleaf is an elegant way to create pages with dynamic front end behaviour while delivering a website and not an application.
The fundamental idea of JSP was to provide a nicer way to write servlets. The JSP markup is translated to a servlet. One big downside of this approach is the coupling to servlets. You could not easily use it to render a mail for example. Unit testing is also hardly possible. I'd prefer any other template engine (freemarker, velocity, thymeleaf, rythm, ...).
But I've the vague feeling that the days of server-side Java templates engines are mostly over. Even if you want to go back to server side rendering, there would probably be better choices based on Node.js these days. With "better" I mean better integrated with the rest of the modern front-end stack (see Next.js).
I 100,000 percent prefer straight JSP over Thymeleaf or similar and JSF for more complex UI's. /u/Distinct_Meringue_76 is spot on that React and Angular are overkill most of the time.
Pivotal needs to get on the ball and stop trying to quietly relegate JSP to the back burner.
whats bad about thymleaf? note, that this is coming from someone who has never used jsp but appreciates the "natural template" approach to design first
Thymeleaf offers nothing compelling over JSP from my perspective while JSP lets me code in HTML or when needed, interface easily and flexibly with the backend. JSP and JSF are first class Java web.
React is a deeply superior tech if you're writing an *application* that happens to be delivered via a web browser. If all you're trying to do is write a webpage, it's the wrong tool.
It is tempting to start PrimeFaces quarkus project
[https://docs.quarkiverse.io/quarkus-primefaces/dev/](https://docs.quarkiverse.io/quarkus-primefaces/dev/)
JSF with PrimeFaces is still crazy productive for admin UIs. But you can just use any server-side rendering engine you are familiar with. It would make little sense to split your application (into frontend and backend) just for the sake of it. If you used Spring alot, what about Spring MVC?
Full server rendering in spring boot with a good template engine JTE. ( Has a great intillij idea plugin) Using this for multiple projects it's very productive
I would go with [https://quarkus.io/](https://quarkus.io/) for new projects in java instead.
Everything else i've seen is plagued with boilerplate and dumb enterprise decisions which almosted doomed java's future.
Try this stack: Apache Myfaces + OpenWebBeans and with or without JUEL... see this link [https://struberg.wordpress.com/2012/03/20/why-is-openwebbeans-so-fast/](https://struberg.wordpress.com/2012/03/20/why-is-openwebbeans-so-fast/) About use/ jsf popular search on [https://www.google.com/search?q=inurl%3A%2Ffaces%2Findex](https://www.google.com/search?q=inurl%3A%2Ffaces%2Findex)
Since you are used with Spring-boot, why not JoinFaces\[1\]?
\[1\] [http://joinfaces.org/](http://joinfaces.org/) | [https://github.com/joinfaces/joinfaces](https://github.com/joinfaces/joinfaces)
well, I don’t know, vaadin might be good for this kind of use case, but I hear a lot that it gets problematic for complex GUI… but this is Vaadin from around 2010.. interesting question, anyway :)
Tried Vaadin once and not touching it with a 10ft pole ever again. Makes easy chores trivial and anything even a bit complex a nightmare, exactly what I don't need a framework to do.
I had a good time with Wicket, but what was really hard then, was using it together with client-side JavaScript. I don't know how it is today, but it was one reason to move away from it.
this is an important point. it eliminates a certain class of bugs. we had one, where a model class was not annotated with session scope but defaulted to singleton. fun times after a while in prod
If you do not like Angular/Vue/React but still prefer SPA then take a look on GWT. For some cases it can be an option. But you will need a good set of components and here I can recommend [https://smartclient.com/smartgwt/showcase/#main](https://smartclient.com/smartgwt/showcase/#main) - if you preffer swing approach of development, or [https://dominokit.com/solutions/domino-ui/v2/docs/getting-started](https://dominokit.com/solutions/domino-ui/v2/docs/getting-started) for material design components and more react like coding.
It's in a weird state where most of the world thinks it's defunct, but the people maintaining say it's not dead yet. But, truth be told, they're not keeping up with the changes in java (GWT transpiles java to javscript, and they're only supporting newer java languages features up to java 14). This indicates to me it's a dying project.
(I was wrong, they're up to language level 11, and are currently working on supporting to language level 17).
Personally I can't decide if the concept of transpiling to javascript is dead or the way to go. Google won't let the concept go either, they've just moved on from GWT's transpiler to their newer j2cl. Typescript is just a transpiler and that's very popular.
If transpilation is a legit path, then GWT just needs attention.
The whole workflow of source code transpilation causes so many problems and also solves so many problems. It's a conundrum.
Transpilation is indeed quite common (TypeScript is the best example, as you've already pointed out). Maybe the technical approach in GWT is just dated. It might be better if it were on a more fundamental level like Kotlin does with Kotlin/JS. But then again I think that transpiling to JavaScript is only an intermediate step and will eventually be replaced by webassembly.
Why do you think that Kotlin/Js is better than GWT. It's worse or same (kotlin is less popular than Java on JVM platform). Much better and much more democratic approach is [https://teavm.org/](https://teavm.org/) because it can transpile any JVM byte code (i.e. kotlin/java or even scala).
My thought was mostly the layer where each tool works. With Kotlin (at least with the new K2 compiler) you'd have the exact same compiler front-end used with a different backend, e.g. JVM or WASM. This a much more generic and flexible approach than integrating a Java to JavaScript compiler into a specific web framework like GWT. The approach of TeaVM looks good in principle, but I expect to be slower than a direct compilation approach as with Kotlin/WASM. In principle Oracle could the same for Java, since they already have a JavaScript compiler front-end in GraalVM, but for some reason there is no WASM target right now.
I think Bootify.io could be a good option for you. No frontend JavaScript Framework, but pure Spring Boot with Thymeleaf, the standard template engine. Crud stuff can also be generated.
I'd recommend using a [template engine](https://github.com/akullpp/awesome-java?tab=readme-ov-file#template-engine) like [jte](https://jte.gg/) or [Thymeleaf](https://www.thymeleaf.org/) over JSF. Because it's a bit more ergonomic, but JSF is also fine.
JSF is a different technology than temple based rendering. The state of the UI is kept on the server. A traditional UI is separated between server and frontend.
If it is basically a CRUD, have a look at JHipster. It will generate both front and back ends, there's a number of frameworks supported. That would be more productive than using JSF.
I have as much trouble fighting your issues in my Java projects as much as I do in JavaScript and React. I’d recommend throwing Typescript on top of a supported JavaScript SPA library and avoid JSF. Typescript makes everything better for most developers but especially better for JavaScript developers or other OO trained developers
All SPA projects I have developed have been done with typescript. In fact I took a course when I started with Angular. The issue for me is that for small to medium projects with a single developer, I think it's a lot of work. Besides, you have to deal with the ecosystem and tools like node where you install a library and tomorrow it's deprecated hahahahaha. Not to mention the security issues of SPA applications.
I think Node manages dependencies and security issues at least as well as Java. I keep my project up to date and I’d take that task any day over keeping our Java services secure. I didn’t at first because I started in a Java world but I’d pick npm over gradle any day.
Unless your applications are going to be so small and component libraries so full featured, then I think there’s always going to be JavaScript.
Writing one application (one UI!) in two separate languages kind of sounds insane to me. How do you even unit test that? How do you reasonably deal with CSS that only has one scope: the global scope? Stick with single page applications.
You might not be very experienced if these are your concerns, honestly. Try and have a look outside of JS world, you have been in that bubble for too long my friend.
Hey, the founder of PrimeFaces here. The tech got old but still gets the job done. We'll do a significant update to PrimeFaces this year with new demos, documentation and new slick UI theme.
Oh, I have a long overdue thanks I should address to you. The project I used PrimeFaces on was completed like five years ago, but it saved us a lot of headache. So, thanks! :D
Hi, I was involved with JSF from the beginning, and I am happy to report it is still evolving. A new release of JSF will be in Jakarta EE 11, for example. As for big sites that still use it, I just checked and this still works: 1. sign in to irs.gov. 2. go to the page where you get a tax transcript. 3. on the landing page for the transcript feature, do **View Source**. 4. look for javax.faces. So, that's a pretty big site.
Good to see you here boss!
And congratz to Prime for the amazing products you develop
Respect, gratitude!
Man, if you look closely React with Next.js is basically JSF, so go with your soul
If you don’t like or don’t absolutely want to build a single page application I also think introducing an API just for the sake of an API is overengineered. Server side rendering has a bit of a renaissance so if you want I can recommend Spring Boot with Thymeleaf and htmx plus some nice styling (I personally like material design but I am usually happy with a console UI so your experience might differ. Spring plus Thymeleaf for the server side rendering, htmx for a bit of dynamic frontend stuff.
JSF with PrimeFaces is still valid, but mainly because server-side rendering has experienced a renaissance. With good design, you could even expose APIs using Jakarta RS, if your customers want to do system-to-system integrations rather than using your UI.
But JSF as such wouldn't expose very useful HTTP interfaces. You'd need to develop *separate* interfaces with Jakarta RS.
"With good design, you could even expose APIs using Jakarta RS." The assumption is that you have a well-designed architecture that encapsulates business logic so that it can be used both by JSF and exposed as an API.
Now I get your point. I read it as if JSF would help in any way in providing REST APIs.
JSF with Primefaces is a totally valid choice. It's simple and easy! Can recommend it.
I second vaadin.
Have you tried using HTMX? Paired with some template engine like JTE or Rocker?
Nop, i will take a look on HTMX.
lmk if you need help
I'm doing that, but with thymeleaf.
After 7 years of react and angular, 90% of the applications I have implemented could have been done with JSF in a fraction of the time. JSF is a superior technology for most applications... By far. Special mention for wicket.
JSP not an option? (I know it differs from jsf)
JSP is just a way to produce HTML while evaluating expression to produce values or include optional sections. Thymeleaf does the same kind of thing and is much more elegant and support components. htmx with Thymeleaf is an elegant way to create pages with dynamic front end behaviour while delivering a website and not an application.
The fundamental idea of JSP was to provide a nicer way to write servlets. The JSP markup is translated to a servlet. One big downside of this approach is the coupling to servlets. You could not easily use it to render a mail for example. Unit testing is also hardly possible. I'd prefer any other template engine (freemarker, velocity, thymeleaf, rythm, ...). But I've the vague feeling that the days of server-side Java templates engines are mostly over. Even if you want to go back to server side rendering, there would probably be better choices based on Node.js these days. With "better" I mean better integrated with the rest of the modern front-end stack (see Next.js).
I 100,000 percent prefer straight JSP over Thymeleaf or similar and JSF for more complex UI's. /u/Distinct_Meringue_76 is spot on that React and Angular are overkill most of the time. Pivotal needs to get on the ball and stop trying to quietly relegate JSP to the back burner.
whats bad about thymleaf? note, that this is coming from someone who has never used jsp but appreciates the "natural template" approach to design first
Thymeleaf offers nothing compelling over JSP from my perspective while JSP lets me code in HTML or when needed, interface easily and flexibly with the backend. JSP and JSF are first class Java web.
React is a deeply superior tech if you're writing an *application* that happens to be delivered via a web browser. If all you're trying to do is write a webpage, it's the wrong tool.
Vaadin 24 is quite simple framework and does not require knowledge of JavaScript.
It is tempting to start PrimeFaces quarkus project [https://docs.quarkiverse.io/quarkus-primefaces/dev/](https://docs.quarkiverse.io/quarkus-primefaces/dev/)
JSF with PrimeFaces is still crazy productive for admin UIs. But you can just use any server-side rendering engine you are familiar with. It would make little sense to split your application (into frontend and backend) just for the sake of it. If you used Spring alot, what about Spring MVC?
i have experience developing REST API and things with Spring Batch, Kafka, etc. lot of backend side. Never tried with Spring MVC with template engines
Full server rendering in spring boot with a good template engine JTE. ( Has a great intillij idea plugin) Using this for multiple projects it's very productive
all my success projects including startup-s and internal admin tools based on jsf/primefaces
I'm still using jsf with prime faces, doesn't exist any better and faster to develop
It was crazy then, I don't even know how to qualify it nowadays
I would go with [https://quarkus.io/](https://quarkus.io/) for new projects in java instead. Everything else i've seen is plagued with boilerplate and dumb enterprise decisions which almosted doomed java's future.
Sure, now i'm playing with Quarkusfaces
Try this stack: Apache Myfaces + OpenWebBeans and with or without JUEL... see this link [https://struberg.wordpress.com/2012/03/20/why-is-openwebbeans-so-fast/](https://struberg.wordpress.com/2012/03/20/why-is-openwebbeans-so-fast/) About use/ jsf popular search on [https://www.google.com/search?q=inurl%3A%2Ffaces%2Findex](https://www.google.com/search?q=inurl%3A%2Ffaces%2Findex)
Since you are used with Spring-boot, why not JoinFaces\[1\]? \[1\] [http://joinfaces.org/](http://joinfaces.org/) | [https://github.com/joinfaces/joinfaces](https://github.com/joinfaces/joinfaces)
Thank's I'm trying to "fit" a Primefaces template with Joinfaces
well, I don’t know, vaadin might be good for this kind of use case, but I hear a lot that it gets problematic for complex GUI… but this is Vaadin from around 2010.. interesting question, anyway :)
Tried Vaadin once and not touching it with a 10ft pole ever again. Makes easy chores trivial and anything even a bit complex a nightmare, exactly what I don't need a framework to do.
that's the thing with Vaadin. And it's expensive too if you want enterprise features
You could also try [Apache Wicket](https://wicket.apache.org).
I had a good time with Wicket, but what was really hard then, was using it together with client-side JavaScript. I don't know how it is today, but it was one reason to move away from it.
I would use Bootstrap and jQuery for admin system. But if you don't like Javascript, just use what you are familiar with.
Today almost every interaction between front and back is stateless, mainly for scalability. But for an admin application it is fine.
this is an important point. it eliminates a certain class of bugs. we had one, where a model class was not annotated with session scope but defaulted to singleton. fun times after a while in prod
Lol... Fun times 😂😂😅😭😭
Thank you for all your advices, you're been very kind
If you're doing it all yourself, go with what you like. In the end it'll be your most productive framework
If you do not like Angular/Vue/React but still prefer SPA then take a look on GWT. For some cases it can be an option. But you will need a good set of components and here I can recommend [https://smartclient.com/smartgwt/showcase/#main](https://smartclient.com/smartgwt/showcase/#main) - if you preffer swing approach of development, or [https://dominokit.com/solutions/domino-ui/v2/docs/getting-started](https://dominokit.com/solutions/domino-ui/v2/docs/getting-started) for material design components and more react like coding.
GWT is a good choice....about 15 years ago.
Thank's for the response. I'll check GWT, is not in my radar
It's in a weird state where most of the world thinks it's defunct, but the people maintaining say it's not dead yet. But, truth be told, they're not keeping up with the changes in java (GWT transpiles java to javscript, and they're only supporting newer java languages features up to java 14). This indicates to me it's a dying project. (I was wrong, they're up to language level 11, and are currently working on supporting to language level 17).
It is probably hard for the maintainers to let go a loved one.
Personally I can't decide if the concept of transpiling to javascript is dead or the way to go. Google won't let the concept go either, they've just moved on from GWT's transpiler to their newer j2cl. Typescript is just a transpiler and that's very popular. If transpilation is a legit path, then GWT just needs attention. The whole workflow of source code transpilation causes so many problems and also solves so many problems. It's a conundrum.
Transpilation is indeed quite common (TypeScript is the best example, as you've already pointed out). Maybe the technical approach in GWT is just dated. It might be better if it were on a more fundamental level like Kotlin does with Kotlin/JS. But then again I think that transpiling to JavaScript is only an intermediate step and will eventually be replaced by webassembly.
Why do you think that Kotlin/Js is better than GWT. It's worse or same (kotlin is less popular than Java on JVM platform). Much better and much more democratic approach is [https://teavm.org/](https://teavm.org/) because it can transpile any JVM byte code (i.e. kotlin/java or even scala).
My thought was mostly the layer where each tool works. With Kotlin (at least with the new K2 compiler) you'd have the exact same compiler front-end used with a different backend, e.g. JVM or WASM. This a much more generic and flexible approach than integrating a Java to JavaScript compiler into a specific web framework like GWT. The approach of TeaVM looks good in principle, but I expect to be slower than a direct compilation approach as with Kotlin/WASM. In principle Oracle could the same for Java, since they already have a JavaScript compiler front-end in GraalVM, but for some reason there is no WASM target right now.
crazy? maybe, i can’t judge. masochistic? absolutely
I think Bootify.io could be a good option for you. No frontend JavaScript Framework, but pure Spring Boot with Thymeleaf, the standard template engine. Crud stuff can also be generated.
I'd recommend using a [template engine](https://github.com/akullpp/awesome-java?tab=readme-ov-file#template-engine) like [jte](https://jte.gg/) or [Thymeleaf](https://www.thymeleaf.org/) over JSF. Because it's a bit more ergonomic, but JSF is also fine.
JSF is a different technology than temple based rendering. The state of the UI is kept on the server. A traditional UI is separated between server and frontend.
Use Spring Boot. Use Thymeleaf for templating.
If you don't have 1000000 views, why not?
If it is basically a CRUD, have a look at JHipster. It will generate both front and back ends, there's a number of frameworks supported. That would be more productive than using JSF.
That was my first try. I develop a demo with Jhipster, and it's really nice. But when i try to change the UI was painfull.
I have as much trouble fighting your issues in my Java projects as much as I do in JavaScript and React. I’d recommend throwing Typescript on top of a supported JavaScript SPA library and avoid JSF. Typescript makes everything better for most developers but especially better for JavaScript developers or other OO trained developers
All SPA projects I have developed have been done with typescript. In fact I took a course when I started with Angular. The issue for me is that for small to medium projects with a single developer, I think it's a lot of work. Besides, you have to deal with the ecosystem and tools like node where you install a library and tomorrow it's deprecated hahahahaha. Not to mention the security issues of SPA applications.
I think Node manages dependencies and security issues at least as well as Java. I keep my project up to date and I’d take that task any day over keeping our Java services secure. I didn’t at first because I started in a Java world but I’d pick npm over gradle any day.
Unless your applications are going to be so small and component libraries so full featured, then I think there’s always going to be JavaScript. Writing one application (one UI!) in two separate languages kind of sounds insane to me. How do you even unit test that? How do you reasonably deal with CSS that only has one scope: the global scope? Stick with single page applications.
You might not be very experienced if these are your concerns, honestly. Try and have a look outside of JS world, you have been in that bubble for too long my friend.
Man go ahead JSF with Primefaces is productive