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
