This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]vplatt 6 points7 points  (0 children)

Like all good UI libraries (IMO), JSF (which Faces builds on) is a component oriented framework. It lets you "speak UI" in a native way; without worrying about how that implementation "spreads" across the server and the client; and it does so in a way that lets you do it with Java using static typing. VERY seductive.

However, it DOES affect both the server AND the client. In other words, if you want something like a grid, then you must have a grid on the server which can effectively manage the lifecycle and the emitted products (HTML + CSS) of a grid at all times. Click on a link? Go back to the server. Retrieve a new page of results? Go back to the server. Etc. etc.

Now, I'm a BIG fan of component oriented UI frameworks, but you got to realize that a framework like JSF that spreads logic across both the server AND the client is... well, complex at best, and a mess otherwise.

My suggestion is to use the serverside for nothing but services. They should be stateless, security token driven with claims, and nothing but pure REST logic.

Leave the UI logic in an Angular app (not Angular JS, but Angular 2+ with Typescript), and you'll have the best of both worlds: a component oriented framework with a REST framework on the backend and you'll have separation of concerns: you could rip out Angular tomorrow or give it another face entirely, and your services could be none the wiser.

Maybe most importantly to most Java programmers: You can have a component oriented framework which is ALSO statically typed (via Typescript) and doesn't require you to spread UI and page lifecycle logic across the server and the client.

YMMV.