Java Server Faces e Thoughtworks

Thoughtworks pubblica mensilmente una specie di radar delle tecnologie, in cui descrive quali sono le tecnologie da tenre sott'occhio e quali sono le tecnologie che stanno diventando ormai obsolete.
Nel technology radar di Gennaio 2014, Thoughtworks scrive:

We continue to see teams run into trouble using JSF-- JavaServer Faces -- and are recommending you avoid this technology.
Teams seem to choose JSF because it is a J2EE standard without really evaluating whether the programming model suits them.
We think JSF is flawed because it tries to abstract away HTML, CSS and HTTP, exactly the reverse of what modern web frameworks do.
JSF , like ASP.NET webforms, attempts to create statefulness on top of the stateless protocol HTTP and ends up causing a whole host of problems involving shared server-side state.
We are aware of the improvements in JSF 2.0, but think the model is fundamentally broken.
We recommend teams use simple frameworks and embrace andunderstand web technologies including HTTP, HTML and CSS.

A questa critica, è arrivata una risposta dal blog ufficiale di PrimeFaces. PrimeFaces è una delle più recenti implementazioni dello standard Java Server Pages. La risposta si concentra sul fatto che Java Server Faces ha avuto diversi miglioramenti che ne hanno aumentato le prestazioni:

Regarding state, JSF is a stateful framework by nature and state makes web applications easy to develop with. With improved state management techniques introduced in JSF 2.0+ (e.g. stateless mode, partial state saving), JSF can scale as well.

E' nata una diatriba interna al JUG ed il commento di Fabio Mitrano è stato:

la diatriba è sul modo in cui JSF memorizza lo stato dei componenti. Lo stato di essi come di qualsiasi sessione web generica puo' essere mantenuta interamente lato client (quindi stateless lato server), lato server (stateful) o in modo misto.

Voi criticate JSF per una sua gestione della sessione e dello stato dei componenti prettamente lato server che incide sulle prestazioni e sulla scalabilità di esso.

Fatto sta non vedo ancora perchè certi framework MVC a componenti che permettano di astrarre dalle tecnologie  client e server specifiche siano del tutto da buttare. E' sufficiente che specifiche e implementazioni MVC future tengano conto di tale necessità sullo stateless delle applicazioni web. Il livello di astrazione superiore rimane sempre un vantaggio.

Il commento di Ugo Landini è stato:

Quello che può sulla carta fare JSF ora, in risposta alle critiche del passato, è irrilevante. Le comunità fanno altro, è una tecnologia che è stata selezionata darwinianamente per l'estinzione (in buona compagnia con molte altre, per carità: Portlet, JavaFX, ecc)

Come spesso succede in informatica, si è arrivati ad essere tutti d'accordo sul fatto che "dipende". L'intervento di Francesco Ioli che ha trovato consenso è stato:

Per cosa tifo allora? Per il concetto: the right tool for the right job!

Dove il "tool" è quello "right" non solo in relazione al  particolare "job" in questione, ma anche per le situazioni al contorno in cui ci si trova...

Ossia: in teoria magari sarebbe piu' adatta ed e' migliore una data tecnolgia, ma in pratica invece mi conviene usarne un altra..

E JSF potrebbe in alcuni casi essere "the right tool".

Per chi è giàregistrato alla mailing list, ecco i link alla discussione:
https://groups.yahoo.com/neo/groups/jug-roma/conversations/topics/13396
https://groups.yahoo.com/neo/groups/jug-roma/conversations/topics/13598