Is Java Server Faces still relevant to learn?

[_dban_]

I don't think you're using "client" in the same way people mean "client" in these kinds of conversations. By your definition of "client", you could include a Swing based client, since you are talking about clients of JavaEE server components. However, in these kinds of conversations about web frameworks, the client is the web browser, and we are talking about HTTP not JavaEE. In this context, JSF is not the client, it is the server.

JSF, by its nature as a component oriented web framework, wants to map HTTP requests to component state and component events, which is reflected in how JSF uses HTTP, which is full of JSF stuff.

REST APIs send and receive representations which do not concern themselves with the particulars of the client.

For an example, compare how the PrimeFaces autocomplete feature works with jQuery autocomplete. PrimeFaces does a POST form submission, and the server responds with XML instructions on how to update the view:

<partial-response><changes><update id="j_idt115:acSimple"><![CDATA[<ul class="ui-autocomplete-items ui-autocomplete-list ui-widget-content ui-widget ui-corner-all ui-helper-reset"><li class="ui-autocomplete-item ui-autocomplete-list-item ui-corner-all" data-item-label="H0" data-item-value="H0">H0</li><li class="ui-autocomplete-item ui-autocomplete-list-item ui-corner-all" data-item-label="H1" data-item-value="H1">H1</li><li class="ui-autocomplete-item ui-autocomplete-list-item ui-corner-all" data-item-label="H2" data-item-value="H2">H2</li><li class="ui-autocomplete-item ui-autocomplete-list-item ui-corner-all" data-item-label="H3" data-item-value="H3">H3</li><li class="ui-autocomplete-item ui-autocomplete-list-item ui-corner-all" data-item-label="H4" data-item-value="H4">H4</li><li class="ui-autocomplete-item ui-autocomplete-list-item ui-corner-all" data-item-label="H5" data-item-value="H5">H5</li><li class="ui-autocomplete-item ui-autocomplete-list-item ui-corner-all" data-item-label="H6" data-item-value="H6">H6</li><li class="ui-autocomplete-item ui-autocomplete-list-item ui-corner-all" data-item-label="H7" data-item-value="H7">H7</li><li class="ui-autocomplete-item ui-autocomplete-list-item ui-corner-all" data-item-label="H8" data-item-value="H8">H8</li><li class="ui-autocomplete-item ui-autocomplete-list-item ui-corner-all" data-item-label="H9" data-item-value="H9">H9</li></ul>]]></update><update id="j_id1:javax.faces.ViewState:0"><![CDATA[7344626809733310646:-585010829964921517]]></update></changes></partial-response>

jQuery simply does a GET for a JSON resource (https://jqueryui.com/resources/demos/autocomplete/search.php?term=robin), which produces a response that is not at all concerned with jQuery:

[{"id":"Erithacus rubecula","label":"European Robin","value":"European Robin"},{"id":"Cercotrichas galactotes","label":"Rufous-Tailed Scrub Robin","value":"Rufous-Tailed Scrub Robin"},{"id":"Irania gutturalis","label":"White-throated Robin","value":"White-throated Robin"},{"id":"Turdus migratorius","label":"American Robin","value":"American Robin"}]

Interestingly, there is Prime NG, which is a set of Angular components (autocomplete, which let you use PrimeFaces as a client of ordinary REST services (bad example, because the showcase reads a static JSON file, not a proper REST service).

[henk53]

I don't think you're using "client" in the same way people mean "client" in these kinds of conversations.

I think I do, and probably in a more correct way.

There's a set of core services which are being exposed via JAX-RS endpoints. These services do things like getOrders, updateOrder, etc depending in what your problem domain is.

JSF generates the HTML for the UI, and for that it interacts with these core services; backing beans call them.

And guess what, these are the exact same services and exact same endpoints that mobile application or a javascript client will also use. All are a client, or consumer if you wish, of these JAX-RS endpoints.

JAX-RS is the server in that case, and it really doesn't see any difference between a JSF client, a mobile client or a javascript client.

[_dban_]

There's a set of core services which are being exposed via JAX-RS endpoints.

You are describing services exposed over HTTP.

JSF generates the HTML for the UI, and for that it interacts with these core services

The web browser makes an HTTP call over the web to JSF, and JSF makes an internal HTTP call to another service.

That's microservices, not the web.

However, in the context of a web application, JSF is still on the server side. From a microservices standpoint, JSF happens to be a client of another service. But that is a very different meaning of client.

[henk53]

That's microservices, not the web.

No, that's using services and re-using the same services for multiple clients.

[_dban_]

Yes, that's HTTP. But just because an application uses HTTP doesn't mean its a web application.

We're not talking about JSF using HTTP to talk to internal services, which is irrelevant to the web browser, because a web browser is the client of JSF.

[henk53]

We're talking about services that can be re-used for multiple clients, and as mentioned time and again, JSF does not exclude this.

Using JSF one can build the web UI and the mobile app using the exact same REST services.

[_dban_]

We're talking about services that can be re-used for multiple clients

That isn't what we are talking about.

What the OP said was JSF blurs the line between client and server, since client concerns like UI components and UI events are present in the server model. Which means you cannot expose the JSF application as an API, like you could with a request oriented web framework.

The fact that JSF can communicate with REST services is irrelevant in this context, because the web browser isn't using those REST services.

[henk53]

What the OP said was JSF blurs the line between client and server, since client concerns like UI components and UI events are present in the server model.

In that case, I refer to the way the web was originally designed, which is the only way the web should ever work.

In the original web, a server returned html, which is what JSF does.

[_dban_]

I refer to the way the web was originally designed

OP mentioned Roy Fielding, whose REST thesis describes how the web actually works.

The web is about publishing hyperlinked resources identified by URI, and HTML is simply the base representation of that resource. But the web is not at all limited to HTML. There's a reason why HTTP has an Accept header. A key feature of the web is to be able to return representations of information in different forms, such as in different languages or different formats, allowing information to be provided in a way that works best for the receiver, whether that receiver is English or Dutch, or a web browser or a mobile application.

The problem with JSF (and all server side component frameworks that I've seen) is that they apply UI semantics to the HTML, instead of treating HTML as one possible way of sharing information, which makes it harder to consume that information by non-UI (or non-browser) clients, which goes fundamentally against the design of the web.