Quali sono i principali svantaggi di Java Server Faces 2.0?

Ieri ho visto una presentazione su Java Server Faces 2.0 che sembrava davvero impressionante, anche se attualmente sono un felice sviluppatore ASP.NET MVC / jQuery. Quello che mi è piaciuto di più di JSF è stata l'enorme quantità di componenti dell'interfaccia utente abilitati per AJAX che sembrano rendere lo sviluppo molto più veloce rispetto a ASP.NET MVC, specialmente su siti pesanti di AJAX. Anche i test di integrazione sembravano molto belli.

Poiché la presentazione ha solo enfatizzato i vantaggi di JSF, mi piacerebbe conoscere anche l'altro lato.

Quindi le mie domande sono:

• Quali sono i principali svantaggi di Java Server Faces 2.0?
• Cosa potrebbe prendere in considerazione uno sviluppatore JSF usando ASP.NET MVC invece di JSF?

Svantaggi di JSF 2.0? Onestamente, a parte la curva di apprendimento ripida relativa quando non si dispone di solide conoscenze di base sullo sviluppo Web di base (HTML / CSS / JS, lato server rispetto lato client, ecc.) E l' API Servlet Java di base (richiesta / risposta / sessione , inoltro / reindirizzamento, ecc.), non vengono in mente svantaggi gravi. JSF nella sua versione attuale ha ancora bisogno di sbarazzarsi dell'immagine negativa che ha acquisito durante i primi anni, durante i quali c'erano diversi svantaggi gravi.

JSF 1.0 (marzo 2004)

Questa era la versione iniziale. È stato ingombro di bug sia nel core che nelle aree delle prestazioni che non vuoi conoscere. La tua applicazione web non ha sempre funzionato come ti aspetteresti intuitivamente. Come sviluppatore scapperesti via piangendo.

JSF 1.1 (maggio 2004)

Questa è stata la versione bugfix. Le prestazioni non erano ancora molto migliorate. C'era anche uno svantaggio principale: non è possibile incorporare perfettamente HTML nella pagina JSF. Tutto il semplice HTML vanilla viene reso prima dell'albero dei componenti JSF. Devi avvolgere tutta la semplice vaniglia nei <f:verbatim>tag in modo che vengano inclusi nell'albero dei componenti JSF. Sebbene questo fosse secondo le specifiche, questo ha ricevuto molte critiche. Vedi anche ao JSF / Facelets: perché non è una buona idea mescolare JSF / Facelets con tag HTML?

JSF 1.2 (maggio 2006)

Questa è stata la prima versione del nuovo team di sviluppo JSF guidato da Ryan Lubke. Il nuovo team ha svolto un ottimo lavoro. Ci sono stati anche cambiamenti nelle specifiche. Il principale cambiamento è stato il miglioramento della gestione della vista. Questo non solo ha rimosso completamente JSF da JSP, quindi si potrebbe usare una tecnologia di visualizzazione diversa da JSP, ma ha anche permesso agli sviluppatori di incorporare un semplice HTML vanilla nella pagina JSF senza problemi con i <f:verbatim>tag. Un altro importante obiettivo del nuovo team è stato il miglioramento delle prestazioni. Durante la vita della Sun JSF Reference Implementation 1.2 (che è stato chiamato in codice Mojarra dalla build 1.2_08, intorno al 2008), praticamente ogni build è stata spedita con (maggiori) miglioramenti delle prestazioni accanto ai soliti (minori) bugfix.

L'unico grave svantaggio di JSF 1.x (incluso 1.2) è la mancanza di un ambito tra l'ambito della richiesta e della sessione , il cosiddetto ambito della conversazione . Ciò ha costretto gli sviluppatori a seccarsi con elementi di input nascosti, query DB non necessarie e / o abusare dell'ambito della sessione ogni volta che si desidera conservare i dati del modello iniziale nella richiesta successiva al fine di elaborare correttamente convalide, conversioni, modifiche al modello e invocazioni di azioni in più applicazioni web complesse. Il dolore potrebbe essere attenuato adottando una libreria di terze parti che conserva i dati necessari nella richiesta successiva come il componente MyFaces Tomahawk <t:saveState> , l' ambito di conversazione JBoss Seam e MyFaces Orchestra quadro di conversazione.

Un altro svantaggio per i puristi HTML / CSS è che JSF utilizza i due punti :come carattere separatore ID per garantire l'univocità dell'elemento idHTML nell'output HTML generato, in particolare quando un componente viene riutilizzato più volte nella vista (template, componenti iteranti, ecc.) . Poiché questo è un personaggio illegale negli identificatori CSS, dovresti usare il \per sfuggire ai due punti nei selettori CSS, risultando in selettori brutti e bizzarri come #formId\:fieldId {}o addirittura #formId\3A fieldId {}. Vedi anche Come utilizzare l'ID elemento HTML generato da JSF con i due punti ":" nei selettori CSS? Tuttavia, se non sei un purista, leggi anche Per impostazione predefinita, JSF genera ID inutilizzabili, che sono incompatibili con la parte CSS degli standard Web .

Inoltre, JSF 1.x non è stato fornito con strutture Ajax fuori dalla scatola. In realtà non è uno svantaggio tecnico, ma a causa della campagna pubblicitaria Web 2.0 durante quel periodo, è diventato uno svantaggio funzionale. Exadel ha introdotto in anticipo Ajax4jsf, che è stato completamente sviluppato nel corso degli anni ed è diventato la parte principale della libreria di componenti JBoss RichFaces . Anche altre librerie di componenti sono state fornite con poteri Ajax incorporati, il noto è ICEfaces .

Circa a metà della vita di JSF 1.2, è stata introdotta una nuova tecnologia di visualizzazione basata su XML: Facelets . Ciò ha offerto enormi vantaggi rispetto a JSP, in particolare nel settore dei modelli.

JSF 2.0 (giugno 2009)

Questa è stata la seconda versione principale, con Ajax come parola d'ordine. Ci sono stati molti cambiamenti tecnici e funzionali. JSP è sostituito da Facelets come tecnologia di visualizzazione predefinita e Facelets è stato ampliato con funzionalità per creare componenti personalizzati utilizzando XML puro (i cosiddetti componenti compositi ). Vedi anche Perché Facelets è preferito su JSP come linguaggio di definizione della vista da JSF2.0 in poi?

I poteri Ajax sono stati introdotti nel sapore del <f:ajax>componente che ha molte somiglianze con Ajax4jsf. Annotazioni e miglioramenti della convenzione sulla configurazione sono stati introdotti per eliminare il faces-config.xmlpiù possibile il file dettagliato . Inoltre, il carattere di separazione ID contenitore contenitore di denominazione predefinito è :diventato configurabile, in modo che i puristi HTML / CSS possano respirare sollevati. Tutto quello che devi fare è definirlo come init-paramnel web.xmlnome javax.faces.SEPARATOR_CHARe assicurarti di non utilizzare il personaggio da solo in nessun punto dell'ID cliente, come ad esempio -.

Ultimo ma non meno importante, è stato introdotto un nuovo ambito, l' ambito della vista . Ha eliminato un altro grave svantaggio di JSF 1.x come descritto in precedenza. È sufficiente dichiarare il bean @ViewScopedper abilitare l'ambito della conversazione senza complicare tutti i modi per conservare i dati nelle successive richieste (conversazionali). Un @ViewScopedbean rimarrà attivo fintanto che successivamente invii e navighi nella stessa vista (indipendentemente dalla scheda / finestra del browser aperta!), In modo sincrono o asincrono (Ajax). Vedi anche Differenza tra ambito View e Request nei bean gestiti e Come scegliere l'ambito bean giusto?

Sebbene praticamente tutti gli svantaggi di JSF 1.x siano stati eliminati, ci sono bug specifici di JSF 2.0 che potrebbero diventare uno spettacolo. Il @ViewScopedfallisce nei gestori dei tag a causa di un problema di pollo uova nel risparmio dello stato parziale. Questo problema è stato risolto in JSF 2.2 e backportato in Mojarra 2.1.18. Anche il passaggio di attributi personalizzati come HTML5data-xxx non è supportato. Questo problema è stato risolto in JSF 2.2 dalla nuova funzione passthrough elements / Attributes. Inoltre l'implementazione di JSF Mojarra ha una sua serie di problemi . Relativamente molti di questi sono legati al comportamento<ui:repeat> a volte non intuitivo di , la nuova implementazione di risparmio parziale dello stato e l' ambito flash mal implementato . La maggior parte di essi è stata risolta in una versione Mojarra 2.2.x.

Intorno al periodo JSF 2.0, è stato introdotto PrimeFaces , basato sull'interfaccia utente di jQuery e jQuery. È diventata la libreria di componenti JSF più popolare.

JSF 2.2 (maggio 2013)

Con l'introduzione di JSF 2.2, HTML5 è stato usato come parola d'ordine anche se tecnicamente era supportato solo in tutte le versioni precedenti di JSF. Vedi anche JavaServer Faces 2.2 e supporto HTML5, perché viene ancora utilizzato XHTML . La nuova funzionalità più importante di JSF 2.2 è il supporto per gli attributi dei componenti personalizzati, aprendo così un mondo di possibilità, come i gruppi di pulsanti di opzione personalizzati senza tablatura .

A parte i bug specifici dell'implementazione e alcune "piccole cose fastidiose" come l'incapacità di iniettare un bean in un validatore / convertitore (già risolto in JSF 2.3), non ci sono davvero svantaggi nella specifica JSF 2.2.

MVC basato su componenti vs MVC basato su richiesta

Alcuni potrebbero ritenere che il principale svantaggio di JSF sia che consente un controllo molto limitato sul HTML / CSS / JS generato. Non è di proprietà di JSF, solo perché è un framework MVC basato su componenti , non un framework MVC basato su richiesta (azione) . Se un alto grado di controllo di HTML / CSS / JS è il tuo requisito principale quando si considera un framework MVC, allora non dovresti già guardare a un framework MVC basato su componenti, ma a un framework MVC basato su richiesta come Spring MVC . Devi solo tener conto del fatto che dovrai scrivere tu stesso tutto quel codice HTML / CSS / JS. Vedi anche Differenza tra MVC richiesta e MVC componente .

Guarda anche:

• Qual è la differenza tra JSF, Servlet e JSP? (solo per capire le basi)
• Utilizzo di JSF per sviluppare layout CSS senza tablature (un altro mito su JSF)
• JSF vs HTML / CSS / JS / jQuery (quando JSF è la scelta sbagliata)
• Modelli di progettazione in applicazioni Web (illustra l'ideologia alla base di MVC)

Dopo 5 anni di lavoro con JSF, penso di poter aggiungere i miei 2 centesimi.

Due principali svantaggi di JSF :

1. Grande curva di apprendimento. JSF è complesso, è proprio vero.
2. La sua natura componente . Il framework basato sui componenti cerca di nascondere la vera natura del Web, che presenta un'enorme quantità di complicazioni e disastri (come non supportare GET in JSF entro quasi 5 anni).
   Nascondere la richiesta / risposta HTTP dallo sviluppatore IMHO è un errore enorme. Dalla mia esperienza, ogni framework basato su componenti aggiunge astrazione allo sviluppo Web e tale astrazione si traduce in spese generali non necessarie e maggiore complessità.

E piccoli inconvenienti che mi vengono in mente:

1. Per impostazione predefinita, l'ID dell'oggetto è composto dagli ID dei suoi genitori, ad esempio form1: button1.
2. Nessun modo semplice per commentare il frammento di pagina errato. Il tag <ui:remove>richiede un contenuto sintatticamente corretto che viene comunque analizzato.
3. Componenti di terze parti di bassa qualità che, ad esempio, non controllano il metodo isRendered()interno processXxx()prima di continuare.
4. Incorporare LESS & Sencha è difficile.
5. Non gioca bene con REST.
6. Non è così facile per i progettisti di UX, perché i componenti pronti all'uso hanno i loro stili CSS, che devono essere sovrascritti.

Non fraintendetemi. Come componente JSF nella versione 2 è davvero buono, ma è ancora basato sui componenti e sarà sempre ...

Dai un'occhiata alla bassa popolarità di Tapestry, Wicket e al basso entusiasmo degli sviluppatori JSF esperti (ciò che è ancora più significativo). E per contrasto, dai un'occhiata al successo di Rails, Grails, Django, Play! Framework: sono tutti basati sull'azione e non cercano di nascondere al programmatore la vera richiesta / risposta e la natura senza stato del web.

Per me è un grosso svantaggio di JSF. IMHO JSF può adattarsi ad alcuni tipi di applicazioni (intranet, ad alta intensità di moduli), ma per le applicazioni web nella vita reale non è una buona strada da percorrere.

Spero che aiuti qualcuno con le sue scelte per quanto riguarda il front-end.

Alcuni inconvenienti che mi vengono in mente:

1. JSF è un framework basato su componenti. Ciò ha delle limitazioni intrinseche che hanno a che fare con l'obbedienza al modello-componente.
2. AFAIK JSF supporta solo POST, quindi se vuoi un GET da qualche parte devi fare un semplice servlet / JSP.
3. La maggior parte dei componenti tenta di fornire astrazioni su domini come database relazionali e JavaScript front-end, e molte volte queste astrazioni sono "trapelate" e molto difficili da eseguire il debug.
4. Queste astrazioni potrebbero essere un buon punto di partenza per uno sviluppatore junior o qualcuno che non si sente a proprio agio con un determinato dominio (ad esempio JavaScript front-end), ma sono molto difficili da ottimizzare per le prestazioni, poiché sono coinvolti diversi livelli e la maggior parte delle persone che li usano avere poca comprensione di ciò che sta accadendo sotto il cofano.
5. I meccanismi di modellazione che di solito vengono utilizzati con JSF non hanno nulla a che fare con il funzionamento dei desigers del web. Gli editor WYSIWYG per JSF sono primitivi e, in ogni caso, il tuo designer ti fornirà HTML / CSS che dovrai impiegare per convertire anni.
6. Cose come le espressioni EL non vengono verificate staticamente e sia il compilatore che gli IDE non stanno facendo un buon lavoro nella ricerca degli errori, quindi si finiranno con gli errori che dovrete rilevare in fase di esecuzione. Questo potrebbe andare bene per un linguaggio tipizzato in modo dinamico come Ruby o PHP, ma se devo resistere al gonfiore dell'ecosistema Java, chiedo di digitare per i miei modelli.

Per riassumere: il tempo che risparmierai con JSF, evitando di scrivere il codice boilerplate JSP / servlet / bean, lo avrai speso x10 per ridimensionarlo e fare esattamente quello che vuoi che faccia.

Per me il più grande svantaggio di JSF 2.0 è la curva di apprendimento non solo di JSF, ma le librerie dei componenti che devi usare per farlo fare un lavoro utile. Considera il numero impressionante di specifiche e standard che hai a che fare per essere veramente competente:

• HTML nelle varie incarnazioni. Non far finta di non aver bisogno di saperlo.
• HTTP: quando non riesci a capire cosa sta succedendo devi aprire Firebug e vedere. Per questo è necessario saperlo.
• CSS - Piaccia o no. Non è poi così male e ci sono almeno alcuni strumenti carini là fuori.
• XML - JSF sarà probabilmente il primo posto in cui usi gli spazi dei nomi a questo livello.
• Specifica servlet. Prima o poi entrerai nei metodi di chiamata in questo pacchetto. A parte questo, devi sapere come i tuoi Facelets vengono trasformati in XHTML o altro.
• JSP (principalmente per sapere perché non ne hai bisogno in JSF)
• JSTL (di nuovo, principalmente per far fronte al framework legacy)
• Expression Language (EL) nelle sue varie forme.
• ECMAScript, JavaScript o qualsiasi altra cosa tu voglia chiamarlo.
• JSON: dovresti saperlo anche se non lo usi.
• AJAX. Direi che JSF 2.0 fa un buon lavoro nel nasconderti, ma devi comunque sapere cosa sta succedendo.
• Il DOM. E come lo utilizza un browser. Vedi ECMAScript.
• Eventi DOM: un argomento tutto da solo.
• Java Persistence Architecture (JPA), ovvero se si desidera che l'app disponga di un database di back-end.
• Java stesso.
• JSEE mentre ci sei.
• La specifica di Context Dependency Injection (CDI) e il modo in cui si scontra con e viene utilizzato con JSF 2.0
• JQuery - Mi piacerebbe vederti andare d'accordo senza di essa.

Ora, una volta terminato, puoi andare avanti con le specifiche proprietarie, vale a dire le librerie dei componenti e le librerie dei provider che raccoglierai lungo il percorso:

• PrimeFaces (la mia libreria di componenti di scelta)
• RichFaces
• MyFaces
• ICEfaces
• EclipseLink (il mio provider JPA)
• Hibernate
• saldare

E non dimenticare il contenitore! E tutti quei file di configurazione:

• GlassFish (2, 3, ecc.)
• JBoss
• micio

Quindi - QUESTO LO RENDE FACILE? Certo, JSF 2.0 è "facile" fintanto che tutto ciò che si desidera fare sono le pagine Web di base con le interazioni più semplici.

In poche parole, JSF 2.0 è il miscuglio più complicato e ingombrante delle tecnologie incollate come esiste oggi nell'universo software. E non riesco a pensare a qualcosa che preferirei usare.

1. Gli sviluppatori inesperti di solito creano applicazioni dolorosamente lente e il codice sarà davvero brutto e difficile da mantenere. È ingannevolmente semplice da avviare, ma in realtà richiede alcuni investimenti nell'apprendimento se si desidera scrivere buoni programmi.
2. Almeno all'inizio spesso ti "bloccherai" su qualche problema e passerai più tempo a leggere post su Balusc su Internet che a lavorare davvero :) Dopo un po 'sarà sempre meno, ma può ancora essere fastidioso.
3. Ancora più fastidioso quando scopri che il problema non è dovuto alla tua mancanza di conoscenza / errore ma in realtà a un bug. Mojarra era (è?) Piuttosto difettoso e un altro strato di componenti aggiunge ancora più problemi. Richfaces è stato il più grande software di merda mai scritto :) Non so come sia ora nella versione 4. Abbiamo Primefaces che è meglio, ma continuerai a riscontrare bug o mancanza di funzionalità soprattutto con componenti più esotici. E ora dovrai pagare per gli aggiornamenti Primefaces. Quindi direi che è buggy ma sta migliorando soprattutto dopo la versione 2.2 risolto alcuni problemi con le specifiche. Il quadro diventa più maturo ma tutt'altro che perfetto (forse le mie facce sono migliori?).
4. Non lo trovo particolarmente flessibile. Spesso se hai bisogno di qualcosa di molto molto personalizzato e non ci sono componenti che lo fanno, sarà un po 'doloroso. Ancora una volta parlo dal punto di vista dello sviluppatore medio - quello con scadenze, tutorial di lettura rapida e ricerca di stackoverflow quando rimani bloccato perché non c'è tempo per imparare come funziona davvero :) Spesso alcuni componenti sembrano avere "quasi" ciò di cui hai bisogno, ma non esattamente ea volte potresti dedicare troppo tempo per farlo fare quello che vuoi :) Devi fare attenzione nel valutare se è meglio creare il tuo componente o torturare il componente esistente. In realtà, se stai creando qualcosa di veramente unico, non consiglierei JSF.

Quindi in breve i miei svantaggi sarebbero: Complessità, Progresso dello sviluppo non molto regolare, buggy, inflessibile.

Naturalmente ci sono anche dei vantaggi, ma non è quello che hai chiesto. Ad ogni modo, questa è la mia esperienza con il framework che altri potrebbero avere opinioni diverse, quindi il modo migliore è provarlo per un po 'per vedere se è per te (solo qualcosa di più complesso - non esempi ingenui - JSF brilla davvero lì :) JSF è applicazioni aziendali, come i CRM ecc ...

"JSF genererà HTML e JavaScript a livello di visualizzazione che non è possibile controllare o modificare senza accedere al codice del controller."

In realtà JSF ti offre la flessibilità, puoi utilizzare componenti standard / di terze parti o crearne di tuoi che hai il pieno controllo su ciò che viene reso. È solo un xhtml necessario per creare i componenti personalizzati con JSF 2.0.

Non sono affatto un esperto di Java Server Faces. Ma IMHO lo svantaggio principale è che è lato server. Sono stanco di apprendere e utilizzare i framework del livello di presentazione web lato server come ASP.NET Web Form, ASP.NET MVC, Java Server Faces, Struts, php framework e ruby ​​on rails framework. Ho salutato tutti quanti e ho salutato Angularjs e TypeScript. Il mio livello di presentazione viene eseguito sul browser. Non importa se è servito da Windows IIS con php o ASP.NET o se è servito da un web server Apache su Linux. Devo solo imparare un solo framework che funziona ovunque.

Solo i miei due centesimi.

Abbiamo sviluppato un progetto di esempio con JSF (è stata una ricerca di tre settimane, quindi potremmo aver perso alcune cose!)

Proviamo a usare core jsf, se è necessario un componente abbiamo usato PrimeFaces.

Il progetto era un sito web con navigazione. Ogni pagina deve essere caricata tramite Ajax quando si fa clic sul menu.

Il sito ha due casi d'uso:

1. Una pagina con una griglia. La griglia viene caricata tramite Ajax e dovrebbe supportare l'ordinamento e il paging
2. Una pagina della procedura guidata in tre passaggi. Ogni pagina ha una convalida lato client (per convalide semplici) e una convalida base Ajax lato server (per convalide complesse). Qualsiasi eccezione del server (dal livello di servizio) deve essere visualizzata nella stessa pagina della procedura guidata senza passare alla pagina successiva.

L'abbiamo trovato:

1. È necessario utilizzare alcuni hack di omniFaces per rendere fisso lo stato di visualizzazione JSF. Lo stato JSF verrà danneggiato quando si includono pagine via ajax l'una nell'altra. Questo sembra un bug in JSF e potrebbe essere risolto nelle versioni successive (non in 2.3).
2. JSF Flow non funziona correttamente con ajax (o non siamo riusciti a farlo funzionare!) Proviamo invece a utilizzare il componente della procedura guidata primeface ma la convalida del client sembra non supportata e significa che non era lo standard di flusso JSF standard.
3. Quando si utilizzano alcuni componenti jQuery come jqGird e è necessario caricare i risultati JSON, quindi si consiglia di utilizzare servlet puro, JSF non farà nulla per voi. Quindi, se usi questo tipo di componenti, il tuo design non si adatterà a JSF.
4. Proviamo a fare alcuni script client quando ajax è completato ajaxCompletee abbiamo scoperto che PF 4 ha implementato i suoi eventi ajax. Avevamo alcuni componenti jQuery e dobbiamo cambiare il loro codice.

Se cambi l'esempio sopra in un progetto non Ajax (o almeno in un progetto ajax) non dovrai affrontare molti dei problemi sopra.

Riassumiamo la nostra ricerca come:

JSF non funziona bene in un sito Web di base completamente Ajax.

Naturalmente in JSF troviamo molte belle funzioni che possono essere molto utili in alcuni progetti, quindi considera le tue esigenze.

Consultare i documenti tecnici JSF per esaminare i vantaggi di JSF e, a mio avviso, il più grande vantaggio di JSF è il supporto COMPLETO E ENORME di @BalusC ;-)

Per me il più grande difetto di JSF è lo scarso supporto per le pagine generate in modo programmatico (dinamico).
Se vuoi costruire la tua pagina (crea un modello di componente di pagina) in modo dinamico dal codice java. Ad esempio, se stai lavorando sul costruttore di pagine Web WYSIWYG. Una documentazione adeguata di questo caso d'uso non è generalmente disponibile. Ci sono molti punti in cui devi sperimentare e lo sviluppo è abbastanza lento. Molte cose semplicemente non funzionano come ti aspetteresti. Ma generalmente è possibile hackerarlo in qualche modo.
La cosa buona è che non è un problema nella filosofia o nell'architettura di JSF. Semplicemente non è abbastanza elaborato (per quanto ne so).

JSF 2 ha portato i componenti compositi che dovrebbero facilitare lo sviluppo dei componenti, ma il loro supporto per la costruzione dinamica (programmatica) è molto scarso. Se si supera un processo complicato e quasi non documentato di costruzione dinamica di componenti compositi, si scoprirà che se si annidano alcuni componenti compositi un po 'più a fondo, smettono di funzionare, generando alcune eccezioni.

Ma sembra che la comunità JSF sia consapevole di queste carenze. Ci stanno lavorando come puoi vedere da questi due bug
http://java.net/jira/browse/JAVASERVERFACES-1309
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-599

La situazione dovrebbe essere migliore con JSF 2.2 almeno se stiamo parlando di specifiche.

Commentando i miei ultimi mesi di esperienza con Primefaces / JSF:

• Se riesci a utilizzare componenti "pronti all'uso", immagino non sia terribile.
• Tuttavia, non funziona bene non appena esci e hai bisogno di interfacce utente personalizzate. - Ad esempio, dovevamo utilizzare il bootstrap di Twitter per il nostro progetto. (Non bootstrap primefaces).
  • Ora le nostre pagine funzionano come segue:
    • Pagina caricata.
    • L'utente interagisce con un Primefaces che ha la funzionalità Ajax
    • Le associazioni javascript di Bootstrap si rompono
    • Eseguiamo javascript extra per ricollegare tutto

La promessa di JSF di evitare di scrivere javascript si è trasformata in scrivere più javascript di quanto avremmo se non avessimo usato Primefaces - e quel javascript è quello di risolvere ciò che Primefaces rompe.

È una perdita di tempo, a meno che tu non usi di nuovo roba "off the shelf". Anche veramente brutto (Primefaces) quando si deve lavorare con Selenium. Tutto può essere fatto - ma ancora una volta - c'è solo così tanto tempo.

Sicuramente evitatelo se stai lavorando con un UX / team di progettazione e hai bisogno di iterare rapidamente sull'interfaccia utente - puoi risparmiare tempo imparando jquery / scrivendo HTML direttamente - o osservando reattivo / angolare.

JSF ha molti vantaggi, la domanda essendo in svantaggio mi consente di aggiungere un paio di punti su di esso.

In uno scenario pratico di implementazione di un progetto Web con un intervallo di tempo, è necessario tenere d'occhio i seguenti fattori.

• Hai abbastanza membri senior nella tua squadra che possono suggerire i migliori controlli adatti a ogni scenario?

• Hai la larghezza di banda per adattarsi alla curva di apprendimento iniziale?

• Hai abbastanza esperienza nel tuo team che può rivedere le
  cose prodotte da JSF dagli sviluppatori?

Se la tua risposta è "No" per le domande, potresti finire in una base di codice non gestibile.

JSF ha solo uno svantaggio: prima di iniziare lo sviluppo di "JSF" dovresti capire chiaramente lo sviluppo web, il core java e l'architettura front-end.

Al giorno d'oggi "nuovi" framework JavaScript provano a copiare / incollare il modello basato su componenti "JSF".

Tra tutti i framework "mainstream" come Spring MVC, Wicket, Tapestry, ecc., Il JSF di Java EE con i suoi componenti compositi è lo strato di presentazione più elaborato e la tecnologia orientata ai componenti fornita. È un po 'ingombrante e incompleto rispetto alle soluzioni fornite da HybridJava.