it-swarm.it

Quando non utilizzare Google Web Toolkit?

Sto prendendo in considerazione l'uso di GWT su un importante progetto di sviluppo di app Web in-house, vale a dire il mio grande vantaggio è la compilazione incrociata su Javascript che (almeno teoricamente) aiuterebbe il mio team a ridurre le dimensioni dello stack tecnologico di uno .

Tuttavia, essendo stato bruciato in precedenza (come la maggior parte degli sviluppatori), mi piacerebbe sentire i programmatori che lo hanno effettivamente utilizzato su eventuali problemi con GWT che ostacolerebbero o limiterebbero l'uso all'interno di un determinato dominio problematico.

Quali sono gli argomenti contro l'utilizzo di GWT e perché?

55
Jas

Sono sia buono che cattivo a rispondere a questa domanda - buono, in quanto l'ho effettivamente usato prima, e cattivo, in quanto ero abbastanza esperto con HTML/CSS/JavaScript prima di lavorare con GWT. Questo mi ha lasciato impazzito usando GWT in un modo che altri Java che non conoscono davvero DHTML potrebbero non esserlo.

GWT fa quello che dice: estrae JavaScript e in una certa misura HTML in Java. Per molti sviluppatori, questo sembra brillante. Tuttavia, sappiamo, come afferma Jeff Atwood, tutte le astrazioni sono astrazioni fallite (vale la pena leggere se si considera GWT). Con GWT, ciò introduce specificamente i seguenti problemi:

L'uso di HTML in GWT fa schifo.

Come ho già detto, in una certa misura, elimina persino l'HTML. Sembra buono per un Java. Ma non lo è. HTML è un formato di markup del documento. Se volessi creare Java per definire un documento, non userebbe gli elementi di markup del documento. È esasperatamente prolisso. Inoltre non è abbastanza controllato. In HTML esiste essenzialmente un modo per scrivere <p>Hello how are <b>you</b>?</p>. In GWT, hai 3 nodi figlio (testo, B, testo) collegati a un nodo P. È possibile creare prima la P o creare prima i nodi figlio. Uno dei nodi figlio potrebbe essere il risultato di ritorno di una funzione. Dopo alcuni mesi di sviluppo con molti sviluppatori, provare a decifrare l'aspetto del tuo documento HTML tracciando il tuo codice GWT è un processo che induce mal di testa.

Alla fine, il team ha deciso che forse usare HTMLPanel per tutto l'HTML era la strada giusta da percorrere. Ora, hai perso molti dei vantaggi di GWT di avere elementi prontamente disponibili a Java per legare facilmente i dati.

L'uso dei CSS in GWT fa schifo.

Per allegato all'astrazione HTML, ciò significa che anche il modo in cui devi usare i CSS è diverso. Potrebbe essere migliorato dall'ultima volta che ho usato GWT (circa 9 mesi fa), ma al momento il supporto CSS era un disastro. A causa del modo in cui GWT ti fa creare HTML, spesso hai livelli di nodi che non sapevi fossero iniettati (qualsiasi sviluppatore CSS sa come questo può influenzare notevolmente il rendering). C'erano troppi modi per incorporare o collegare i CSS, risultando in un disordine confuso di spazi dei nomi. Inoltre, hai avuto il supporto Sprite, che suona di nuovo bene, ma in realtà ha mutato il tuo CSS e abbiamo avuto problemi con la scrittura di proprietà che poi abbiamo dovuto sovrascrivere esplicitamente in seguito, o in alcuni casi, abbiamo contrastato i nostri tentativi di abbinare la nostra mano- CSS codificato e doverlo semplicemente ridisegnare in modo che GWT non lo abbia rovinato.

Unione di problemi, intersezione di benefici

Qualsiasi lingua avrà il proprio insieme di problemi e benefici. Se lo usi è una formula ponderata basata su quelli. Quando hai un'astrazione, quello che ottieni è l'unione di tutti i problemi e un'intersezione dei benefici. JavaScript ha i suoi problemi ed è comunemente deriso dagli ingegneri lato server, ma ha anche alcune funzionalità utili per un rapido sviluppo web. Pensa alle chiusure, alla stenografia della sintassi, agli oggetti ad hoc, a tutto il materiale fatto da Jquery (come le query DOM tramite il selettore CSS). Ora dimentica di usarlo in GWT!

Separazione degli interessi

Sappiamo tutti che con l'aumentare delle dimensioni di un progetto, è fondamentale avere una buona separazione delle preoccupazioni. Uno dei più importanti è la separazione tra visualizzazione ed elaborazione. GWT lo ha reso davvero difficile. Probabilmente non impossibile, ma la squadra in cui ero in squadra non ha mai trovato una buona soluzione, e anche quando pensavamo di avere, ne abbiamo sempre avuto uno che si perdeva nell'altro.

Desktop! = Web

Come @Berin Loritsch ha postato nei commenti, il modello o la mentalità per cui GWT è costruito sono applicazioni viventi, in cui un programma ha un display vivente strettamente accoppiato a un motore di elaborazione. Questo suona bene perché è quello che molti pensano che manchi al web. Ma ci sono due problemi: A) Il web è basato su HTTP e questo è intrinsecamente diverso. Come accennato in precedenza, le tecnologie basate su HTTP - HTML, CSS, persino caricamento delle risorse e memorizzazione nella cache (immagini, ecc.), Sono state costruite per quella piattaforma. B) Java che hanno lavorato sul web non passano facilmente a questa mentalità dell'applicazione desktop. in questo mondo è una disciplina completamente diversa. Gli sviluppatori Flex sarebbero probabilmente più adatti a GWT di Java di Java.

In conclusione...

GWT è in grado di produrre quick-and-dirty AJAX abbastanza facilmente usando solo Java. Se quick-and-dirty non sembra quello che vuoi, non usarlo. La società Per cui lavoravo era un'azienda che si preoccupava molto del prodotto finale, ed è un senso di lucidità, sia visiva che interattiva, per l'utente. Per noi sviluppatori front-end, questo significava che dovevamo controllare HTML, CSS e JavaScript in modi che hanno reso l'uso di GWT come provare a suonare il pianoforte con i guantoni da boxe.

84
Nicole

Usiamo GWT per una grande applicazione web di eGovernment (SOA nel backend) che ha un uso intenso. La vecchia interfaccia utente era in DHTML ma avevamo problemi con la compatibilità del browser, l'ottimizzazione delle prestazioni e il processo di sviluppo, quindi abbiamo cercato alternative.

I nostri requisiti sono stati:

  • livello dell'interfaccia utente lato client per ridurre al minimo il carico del server
  • compatibilità del browser
  • rIA basata sul web
  • Ottimizzazioni delle prestazioni facili
  • Nessuna installazione di plugin client necessaria, dovrebbe funzionare con una semplice installazione di Windows

Abbiamo scelto GWT e non me ne pento mai. Il nuovo team non ha avuto o meno esperienza DHMTL e quindi il processo Java dev di GWT è stato molto utile. Quello che ottieni dalla scatola è:

  • compatibilità del browser
  • Processo di sviluppo basato su Java e riutilizzo del codice
  • facile minimizzazione delle richieste (pacchetto di immagini, ...)
  • facile memorizzazione nella cache aggressiva (le nuove app sono completamente memorizzate nella cache sul lato client)
  • facile compressione di tutte le risorse (anche con js su vecchi IE con errori)
  • e molto altro, molto da menzionare qui

La nostra applicazione invia una sola richiesta al server all'avvio. Il lato negativo è che GWT (e anche Android) hanno un design scadente fuori dalla scatola, ma comunque se applichi il tuo aspetto e senti che devi adattare il CSS. In alternativa è possibile utilizzare varie librerie di componenti per GWT che semplificano l'applicazione di stili e temi adeguati.

Per me non ha senso che forse il DOM HTML non è buono come fatto a mano, questo non è mai stato un problema. Quando sviluppo in C++, non guardo il codice assembler generato. Quando sviluppo in GWT non ho mai avuto motivo di guardare il codice JS e solo una volta un motivo per guardare il DOM e fare qualche refactoring.

Per me GWT è l'unica scelta per quanto riguarda lo sviluppo della RIA e spero che GWT abbia un futuro brillante. Vedi la dichiarazione di missione su:

[1] http://code.google.com/intl/de-DE/webtoolkit/makinggwtbetter.html#introduction

Ma non si deve menzionare che Google non utilizza GWT in molti dei suoi progetti interni e che al momento ci sono alcune voci sul futuro di GWT, vedi

[2] http://googlewebtoolkit.blogspot.com/2011/11/gwt-and-Dart.html
[3] https://plus.google.com/105933370793992913359/posts/bLfSagtziBC

24
ChrLipp