Quando non utilizzare Google Web Toolkit? [chiuso]

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é?

— Jas
fonte

Pensavo che GWT fosse morto.

— Aaron McIver,

@Aaron, davvero?

— Jas,

Non consiglio GWT personalmente. La mentalità che ti costringe a lavorare per le applicazioni desktop, ma ti darà problemi cercando di pensare in questo modo nelle funzioni HTML. Sono un fan di abbinare il paradigma della codifica al problema attuale e l'astrazione mi si presenta. Ecco perché ogni volta che ho iniziato a valutarlo, ho deciso di non usarlo.

— Berin Loritsch,

@Jas Experience è tornata un paio d'anni fa; nella sua infanzia e all'epoca sembrava molto crudo. È cambiato? Forse .... ma sto lentamente tentando di apprendere le basi dei framework invece di fare affidamento sui framework stessi. Alla fine della giornata è un tritacarne per sfornare JS; non che sia una brutta cosa, ma non da qualche parte voglio sforzarmi. Molti di questi framework sono stati scelti a causa della mancanza di conoscenza della tecnologia X o di qualcosa del genere ... ma alla fine dovrai diventare esperto nella tecnologia X ad un certo punto nel tempo .... potrebbe anche seguire prima quella strada.

— Aaron McIver,

Sono molto ben informato in JS, ho scritto alcune cose piuttosto serie lì, tuttavia ora sto conducendo un progetto molto critico in termini di tempo e non posso permettermi di far perdere tempo al personale junior a causa di errori indotti dal passaggio dal contesto Java a JS. Quindi, per favore, se hai qualche esempio del mondo reale del perché GWT non ha funzionato per te, allora descrivilo, altrimenti non perdiamo tempo a vicenda con discussioni ipotetiche e altamente soggettive.

— Jas,

Risposte:

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 sviluppatori 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, astrae persino l'HTML. Sembra buono per uno sviluppatore Java. Ma non lo è. HTML è un formato di markup del documento. Se si desidera creare oggetti Java per definire un documento, non utilizzare 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 Pnodo. È 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 documento HTML tracciando il 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 al codice Java per legare facilmente i dati.

L'uso dei CSS in GWT fa schifo.

In 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 al crescere 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 ho accennato in precedenza, le tecnologie basate su HTTP - HTML, CSS, persino caricamento delle risorse e memorizzazione nella cache (immagini, ecc.), Sono state sviluppate per quella piattaforma. B) Gli sviluppatori Java che hanno lavorato sul web non passano facilmente a questa mentalità dell'applicazione desktop. L'architettura in questo mondo è una disciplina completamente diversa. Gli sviluppatori Flex sarebbero probabilmente più adatti a GWT rispetto agli sviluppatori Web Java.

In conclusione...

GWT è in grado di produrre applicazioni AJAX veloci e sporche abbastanza facilmente usando solo Java. Se quick-and-dirty non suona come quello che vuoi, non usarlo. La società per la quale lavoravo era una società che teneva molto al 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 rendessero l'utilizzo di GWT come provare a suonare il pianoforte con i guantoni da boxe.

— Nicole
fonte

Ho riconosciuto alcuni dei motivi per cui abbiamo scelto Wicket rispetto a GWT, tanto per i cappelli alla presentazione.

— biziclop,

-1 per FUD, la mia esperienza con GWT utilizzata per applicazioni su piccola e grande scala è stata molto più positiva che negativa. E non ho riscontrato nessuno di questi "problemi", quindi il commento FUD. Abbiamo incorporato con successo widget generati da GWT in pagine HTML molto complesse con il minimo sforzo. Se sai cosa stai facendo è meraviglioso, se non vuoi considerare che potrebbe esserci un nuovo modo migliore di fare le cose, segui questa "risposta" e ignora questo commento.

@Jarrod Questi non sono "problemi" da affrontare, ma semplici descrizioni della natura di GWT. Ove pertinente, li ho ulteriormente qualificati come negativi specificamente nell'ambito degli obiettivi del nostro progetto. Se hai un'esperienza alternativa sentiti libero di scriverlo. Fino ad allora, l'unica informazione non dimostrata è la tua affermazione che GWT è "nuovo e migliore". A proposito, da quando ho scritto questa risposta, l'azienda (per cui non lavoro più) ha buttato giù un anno di lavoro di diversi ingegneri e ha riscritto il progetto senza GWT. In meno tempo.

— Nicole,

@JarrodRoberson Sono d'accordo con NickC, sarebbe bello leggere un articolo altrettanto dettagliato delle tue esperienze.

— funkybro,

@NickC "In meno tempo" per la riscrittura di un progetto non è considerato un duro colpo per GWT IMO; qualsiasi progetto in cui stai sostanzialmente ripetendo ciò che è stato fatto prima anche in un contesto o linguaggio diverso dovrebbe richiedere "meno tempo".

— funkybro,

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 di sviluppo Java 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 look 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 quando si tratta di 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 usa GWT su 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

— ChrLipp
fonte