How to replace JSF(primefaces)

Question

Java

Hello.
In my last three projects I used primefaces, I had to customize a couple of components, but in general I liked everything and it was written quickly and easily.
I would like to try something new, so that on the server side there is java and on the client side JS.
But so that they would be like in JSF already a set of ready-made components.

Answer 1

Just don't use JSF, JSP and other server side rendering technologies. This is a useless waste of time.
Now there are no problems with the implementation of everything that is needed on the client side using one of the JS frameworks, such as AngularJS for example (see single page web applications). In this case, the Java backend turns into a RESTful service.
The set of available components in JavaScript is obviously richer, and development time is saved very significantly.

Answer 2

I worked with JSF for a couple of years on a couple of projects, the impressions are not the best. JSF is beautiful only in examples, like I wrote a dozen lines - I got a full-featured interface. When you write real applications, you can only throw in a prototype so beautifully, but when it comes to specific little things, and even just complex functionality, everything becomes bad. The code turns into a hodgepodge in which everything is confused: the logic is smeared between pages and server components, part of the logic is on the client, and work with the interface is on the server. The pages themselves are an explosive mixture of html / el / javascript and the devil knows what else. You should always keep in mind the JSF page processing cycle so that, for example, you do not read the same data from the database 7 times at the time of updating a pair of visual elements on the page. You also need to keep in mind some magical rules, in which everything works, and God forbid to use the wrong combination of actions / onclicks / oncompletes, in which everything just stops working, and there are no opportunities for normal debugging. Yes, when ready-made working solutions have already been developed, such as “if it is necessary, when closing the dialog, in addition to executing the action, also update that element over there and tell that bean something, then this is how it is done”, then the main part of the work is done without incomprehensible glitches. But even so, for me personally, drawing each new JSF page causes allergies. still update that element over there, and tell that bean something, then it’s done like this, then the main part of the work is done without incomprehensible glitches. But even so, for me personally, drawing each new JSF page causes allergies. still update that element over there, and tell that bean something, then it’s done like this, then the main part of the work is done without incomprehensible glitches. But even so, for me personally, drawing each new JSF page causes allergies.
I won’t say anything about linking JavaScript frameworks with Java, I haven’t tried it, but I suspect a story similar to JSF - at first something will work easily and beautifully, and then such horror can start to come out that JSF will seem like flowers. I don't want to say that JavaScript frameworks are bad, just that if you try, test something more complicated than demo pages before using it in a serious project.
As far as I know, Java on the web is mostly used in enterprise applications that have a limited number of permanent users. For such cases, GWT is very well suited - it is very convenient to write on it, because. Everything is written in Java. The generated client-side JavaScript usually weighs a lot, but it is downloaded once and is cached in the browser until the next update of your software. And all this time, only pure data goes between the client and the server, and no html wrappers over them. Due to such savings, in a couple of hours of work, the initial download of a large JavaScript is fully compensated. GWT is not very suitable for regular sites on the Internet. there, users are usually fickle (opened the page, looked, left and did not return), and it is expensive for everyone to download large JavaScript. GWT has a ready-made set of core components. There are also frameworks over GWT that provide more complex components, but with them you will again return to the story with JSF - it works great and is quickly developed only for the time being, then the stupor, excavations and scientific poke begin.

Answer 3

We are using the Tapestry framework in the current project . Also component-oriented, like JSF. It has its own tapestry-hibernate library, so you can work right out of the box. Own implementation of CDI. JQuery support: tapestry-Jquery-Components , Ajax and more. Very good documentation, instant-responding community. The only thing that can be confusing after JSF is that tapestry is built not according to jsr, so the annotations are not standard. In general, look through the documentation, see an example , maybe you will like it.

Answer 4

If you definitely need a set of ready-made components - look towards ZK http://www.zkoss.org/zkdemo/getting_started?rfi=1 but keep in mind that it is quite difficult to customize (hello jsf), but it has a flexible binding mechanism and other tasty goodies.

Answer 5

Wicket and Tapestry are based on very sound component-oriented ideas. However, HybridJava implements these ideas in a much cleaner way.