Motivi per NON utilizzare JSF [chiuso]

64

Sono nuovo di StackExchange, ma ho pensato che saresti stato in grado di aiutarmi.

Stiamo creando una nuova applicazione Java Enterprise, in sostituzione di una soluzione JSP legacy. A causa di molti cambiamenti, l'interfaccia utente e parti della logica aziendale verranno completamente ripensate e reimplementate.

Il nostro primo pensiero è stato JSF, in quanto è lo standard in Java EE. All'inizio ho avuto una buona impressione. Ma ora sto cercando di implementare un prototipo funzionale e ho alcune preoccupazioni molto serie sull'uso.

Prima di tutto, crea il pseudo-HTML / CSS / JS invalido peggiore e ingombrante che abbia mai visto. Viola ogni singola regola che ho imparato nello sviluppo web. Inoltre mette insieme ciò che non dovrebbe mai essere così strettamente accoppiato: layout, progettazione, logica e comunicazione con il server. Non vedo come sarei in grado di estendere comodamente questo output, sia con lo stile con CSS, aggiungendo candy UI (come tasti di scelta rapida configurabili, widget drag-and-drop) o altro.

In secondo luogo, è troppo complicato. La sua complessità è eccezionale. Se me lo chiedi, è una cattiva astrazione delle tecnologie web di base, paralizzata e inutile alla fine. Quali vantaggi ho? Nessuno, se ci pensi. Centinaia di componenti? Vedo anche diecimila frammenti HTML / CSS, diecimila frammenti JavaScript e migliaia di plug-in jQuery. Risolve davvero molti problemi - non avremmo se non usassimo JSF. O lo schema del controller frontale.

E infine, penso che dovremo ricominciare da capo, diciamo 2 anni. Non vedo come posso implementare tutto il nostro primo mock-up della GUI (Inoltre, non abbiamo un esperto JSF nel nostro team). Forse potremmo hackerarlo insieme in qualche modo. E poi ce ne saranno altri. Sono sicuro che potremmo hackerare il nostro hack. Ma ad un certo punto, saremo bloccati. A causa di tutto quanto sopra il livello di servizio è in controllo di JSF. E dovremo ricominciare da capo.

Il mio suggerimento sarebbe quello di implementare un API REST, usando JAX-RS. Quindi creare un client HTML5 / Javascript con MVC lato client. (o qualche sapore di MVC ..) A proposito; avremo comunque bisogno dell'API REST, poiché stiamo sviluppando anche un front-end Android parziale.

Dubito che JSF sia la soluzione migliore al giorno d'oggi. Dato che Internet si sta evolvendo, non vedo davvero perché dovremmo usare questo "rake".

Ora, cosa sono i pro / contro? Come posso sottolineare il mio punto di non usare JSF? Quali sono i punti forti da usare JSF rispetto al mio suggerimento?

— Bruno Schäpper
fonte

24

Questa è una domanda ben scritta da parte di un nuovo utente. Valuta di lasciare un commento quando effettui il downvoting.

— ThiefMaster,

2

Dato che stai riscrivendo tutto, non solo prenderei in considerazione l'idea di non utilizzare JSF, ma di non utilizzare affatto Java. I moderni linguaggi di scripting (cioè non PHP o Perl) sono piuttosto belli e facili da sviluppare.

— ThiefMaster,

11

Non ho votato a fondo, ma questa non è una domanda, è un rant. Vain ha deciso di odiare JSF, ora chiede altri motivi per non usarlo?

— Michael Borgwardt,

4

Java è la scelta migliore se la tua applicazione sarà grande (complessa e / o scalabile) e / o distribuita, usando molti servizi; se la tua applicazione non rientra in questa categoria (non è così complessa e non deve essere scalabile), Python (Django) o Ruby (Rails) sarebbero le scelte migliori. La complessità di JSF, ha i vantaggi della potenza che ne deriva; in alternativa, dovresti dare un'occhiata ad altri Web Frameworks come Spring MVC o Struts 2 se Java è obbligatorio.

— m3th0dman

14

Questo è un rant in cerca di backup, non una domanda in quanto tale.

26

C'è almeno un ottimo motivo per considerare JSF.

È una parte standard dello stack Java EE e quindi sarà disponibile - e funzionante - in TUTTI i container Java EE per un tempo molto, molto lungo. E mantenuto anche, senza che tu debba farlo se hai aderito rigorosamente alla specifica Java EE.

Se questa è una preoccupazione per te, allora dovresti considerarla. La maggior parte dei software vive più a lungo di quanto credano i loro progettisti, specialmente se presi in considerazione durante la scrittura.

4

Non ne sono sicuro. Per J2EE, le parole "standard" e "working" non sono scritte in pietra, specialmente quando parliamo di un sistema che sarà / dovrebbe essere supportato per molti anni, comprese le modifiche alla versione di j2ee utilizzata.

— magallanes,

7

Nella mia (limitata) esperienza con JSF questo argomento in realtà non regge. Ho visto le applicazioni rimanere bloccate con una versione di JSF e nessun percorso di migrazione sensato verso una versione più recente. Sicuramente il server delle app lo ha ancora eseguito, ma si trattava di tutto il supporto che otterresti se non avessi grandi quantità di denaro da bruciare con contratti di supporto troppo costosi.

— Jens Schauder,

@JensSchauder la mia esperienza è solo che puoi scrivere applicazioni portatili, migrare e aggiornare la loro versione di jsf. Ciò implica conoscere le specifiche e codificarle, non alla sua implementazione. Funziona, come funziona la codifica per JPA invece di Hibernate. Lo faccio da anni.

— ymajoros,

14

Ora, cosa sono i pro / contro? Come posso sottolineare il mio punto di non usare JSF? Quali sono i punti forti da usare JSF rispetto al mio suggerimento?

Sembra che tu abbia già preso una decisione circa i contro, e devo accontentarmi di alcuni di essi (non separa abbastanza layout e logica e l'HTML risultante è spesso atroce), ma non sono d'accordo con altri (se usi Facelet, che consiglio vivamente, quindi l'output dovrebbe essere sicuramente valido).

Quindi, ecco alcuni pro:

Esistono librerie di componenti molto potenti come PrimceFaces o RichFaces che offrono molte funzionalità pronte all'uso. Questi possono farti risparmiare un sacco di lavoro se coprono i tuoi requisiti (non tanto se hai requisiti non negoziabili non coperti da loro).
I componenti compositi offrono un modo molto pulito di modularizzare le tue pagine
JSF si integra molto bene con il resto di Java EE
AJAX tramite il re-rendering dei componenti è davvero semplice e conveniente

Ma certamente nessuno di questi vantaggi è così grande che dovresti usare JSF su qualche altro framework con cui il tuo team ha già esperienza.

— Michael Borgwardt
fonte

1

Non sono gli ID, sono attributi non validi. Come "ruolo" e "aria-espanso" nella vista a schede. Sai come aggiustarlo?

— Bruno Schäpper,

1

@Vain: no, sembra essere un problema diverso, forse con un componente che non ho usato o che è nuovo. È possibile modificare l'output HTML dei componenti JSF specificando un renderer alternativo (che idealmente sovrascrive solo uno o due metodi del renderer predefinito), ma ovviamente questo non è qualcosa che dovresti fare solo per ottenere un markup valido.

— Michael Borgwardt,

1

L'HTML atroce è dovuto all'implementazione utilizzata. Comprendo che la modalità di debug dell'implementazione JSF di riferimento è particolarmente dannosa. Saresti a conoscenza di impostazioni migliori per produrre HTML migliore?

1

@ Thorbjørn Ravn Andersen Sì, il problema con HTML non valido è in realtà un problema di PrimeFaces. Lo usiamo perché è basato su jQuery-UI. Qual è il tuo consiglio; dovrei usare un'altra libreria? Mi piace molto l'HTML valido. Per me è semplicemente un must.

— Bruno Schäpper,

1

Rivisitando la mia prima domanda qui, vorrei condividere alcune esperienze sui tuoi professionisti: stiamo lavorando con JSF e con quell'esperienza non la sceglieremmo più. Quasi nulla funziona come previsto e pronto all'uso. Sì, ci sono potenti librerie. Ma abbiamo finito per fare da soli tutti i nostri componenti, perché non avrebbero funzionato esattamente come ne avevamo bisogno. È incredibile quanto velocemente abbiamo avuto la nostra 'DataTable' con caricamento lento durante lo scorrimento. I componenti compositi non hanno funzionato per noi, non posso dirti perché, sono difettosi immagino. Il re-rendering di AJAX è in realtà un problema per il lato client JS.

— Bruno Schäpper,

9

JSF è un framework web stateful adeguato per Java, che è uno standard che significa che è supportato e pronto all'uso da molti principali fornitori (inclusi quelli FOSS). Ha un forte supporto per le librerie di terze parti (PrimeFaces, IceFaces ecc.). Tuttavia, fondamentalmente "rompe il web" a causa della sua natura di stato (e un sacco di altre cose). Vedi il confronto tra Matt Raible dei framework Web basati su JVM , JSF di solito si avvicina all'ultimo.

Modifica - con JSF 2.2 - puoi iniziare a sostenere che non spezza il web come una volta. In realtà è l'integrazione HTML5 non è tutto terribile :-).

— Martijn Verburg
fonte

1

"Rompere il web", in effetti ... E grazie per il confronto di Matt Raible, non lo sapevo.

— Bruno Schäpper,

3

Si noti che JSF non è necessariamente con stato. Sono d'accordo che spesso lo è, ma esiste un supporto abbastanza buono per le richieste basate su GET senza stato e se non si utilizza un modulo, non esiste alcuno stato.

— Arjan Tijms,

Giusto punto Arjan, immagino di aver appena visto molti usi di stato.

— Martijn Verburg,

Link alla presentazione di Raible: slideshare.net/mraible/…

— zaidaus,

6

Avevamo un'applicazione JSP / Struts 1.0 legacy. Abbiamo saltato Struts 2, JSF e tutto ciò che è successo da Struts 1 e siamo passati alla Spring 3.0. Ha il supporto (e una comunità attiva) per la nostra lista dei desideri - Eclipse IDE, MVC e REST. Inoltre abbiamo abbandonato il nostro Javascript / ajax nostrano vintage per jquery.

YMMV ma la primavera è stata una migrazione regolare per noi.

— JQA
fonte