Le più grandi insidie ​​di GWT? [chiuso]

Sono all'inizio / a metà di un progetto che abbiamo scelto di implementare usando GWT. Qualcuno ha riscontrato gravi insidie ​​nell'uso di GWT (e GWT-EXT) che non sono state superate? Che ne dici di una prospettiva di performance?

Un paio di cose che abbiamo visto / sentito già includono:

• Google non è in grado di indicizzare i contenuti
• CSS e lo stile in generale sembrano essere un po 'traballanti

Cerchi ulteriori feedback anche su questi articoli. Grazie!

Inizierò dicendo che sono un grande fan di GWT, ma sì, ci sono molte insidie, ma la maggior parte, se non tutte, siamo riusciti a superare:

Problema: i tempi di compilazione lunghi, man mano che il progetto cresce, aumenta anche il tempo necessario per la compilazione. Ho sentito parlare di compilazioni di 20 minuti, ma le mie sono in media circa 1 minuto.

Soluzione: dividere il codice in moduli separati e dire a ant di crearlo solo quando viene modificato. Inoltre, durante lo sviluppo, puoi velocizzare notevolmente i tempi di compilazione creando solo un browser. Puoi farlo inserendolo nel tuo file .gwt.xml:

<set-property name="user.agent" value="gecko1_8" />

Dove gecko1_8 è Firefox 2+, ie6 è IE, ecc.

Problema: modalità Hosted è molto lenta (almeno su OS X) e non si avvicina alla corrispondenza delle modifiche 'live' che si ottengono quando si modificano elementi come pagine JSP o Rails e si fa clic su Aggiorna nel browser.

Soluzione: puoi dare più memoria alla modalità host (generalmente ho 512M) ma è ancora lento, ho scoperto che una volta che sei abbastanza bravo con GWT smetti di usarlo. Apportate una grande quantità di modifiche, quindi compilate per un solo browser (in genere 20 anni di compilazione) e quindi premete semplicemente Aggiorna nel browser.

Aggiornamento: con GWT 2.0+ questo non è più un problema, perché usi la nuova "Modalità di sviluppo". Fondamentalmente significa che puoi eseguire il codice direttamente nel tuo browser preferito, quindi nessuna perdita di velocità, oltre a poter eseguire il firebug / ispezionarlo, ecc.

http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM

Problema: il codice GWT è java e ha una mentalità diversa da quella di creare una pagina HTML, il che rende più difficile prendere un progetto HTML e trasformarlo in GWT

Soluzione: ancora una volta ci si abitua a questo, ma purtroppo la conversione di un progetto HTML in un progetto GWT sarà sempre più lenta rispetto a fare qualcosa come convertire un progetto HTML in una pagina JSP.

Problema: GWT si prende un po 'la testa, e non è ancora mainstream. Ciò significa che la maggior parte degli sviluppatori che si uniscono al tuo team o mantengono il tuo codice dovranno impararlo da zero

Soluzione: resta da vedere se GWT decollerà, ma se sei un'azienda che controlla chi assumi, puoi sempre scegliere persone che conoscono GWT o vogliono impararlo.

Problema: GWT è una mazza rispetto a qualcosa come jquery o semplicemente javascript. Ci vuole molta più configurazione per farlo accadere che includere semplicemente un file JS.

Soluzione: utilizzare librerie come jquery per attività più piccole e semplici adatte a quelle. Usa GWT quando vuoi creare qualcosa di veramente complesso in AJAX, o dove devi passare i tuoi dati avanti e indietro tramite il meccanismo RPC.

Problema: a volte per popolare la pagina GWT, è necessario effettuare una chiamata al server al primo caricamento della pagina. Può essere fastidioso per l'utente sedere lì e guardare un simbolo di caricamento mentre recuperi i dati di cui hai bisogno.

Soluzione: nel caso di una pagina JSP, la tua pagina era già stata renderizzata dal server prima di diventare HTML, quindi puoi effettivamente effettuare tutte le tue chiamate GWT e precaricarle sulla pagina, per un caricamento immediato. Vedi qui per i dettagli:

Accelerare il caricamento della pagina pre-serializzando le chiamate GWT

Non ho mai avuto problemi nello stile dei miei widget CSS, pronti all'uso, personalizzati o meno, quindi non so cosa intendi per essere una trappola?

Per quanto riguarda le prestazioni, ho sempre scoperto che una volta compilato il codice GWT è veloce e le chiamate AJAX sono quasi sempre più piccole rispetto a un aggiornamento di un'intera pagina, ma non è univoco per GWT, anche se i pacchetti RPC nativi che ottieni se usi un back-end JAVA è piuttosto compatto.

Lavoriamo con gwt da quasi 2 anni. Abbiamo imparato molte lezioni. Ecco cosa pensiamo:

1. Non utilizzare librerie di widget di terze parti, in particolare gwt-ext. Ucciderà le prestazioni di debug, sviluppo e runtime. Se hai domande su come ciò avvenga, contattami direttamente.

2. Usa gwt per compilare solo le parti dinamiche delle tue app. Quindi se hai interazioni utente complesse con molti campi. Tuttavia, non utilizzare i pannelli forniti. Prendi le pagine fornite dallo stock designer esistente. Ritaglia le aree che conterranno i controlli per la tua app. Collega questi controlli alla pagina in onModuleLoad (). In questo modo puoi usare le pagine standard del tuo designer e anche fare tutto lo styling al di fuori del gwt.

3. Non creare l'intera app come un'unica pagina standard che quindi crea dinamicamente tutti i pezzi. Se fai ciò che suggerisco al punto 2, questo non accadrà comunque. Se costruisci tutto in modo dinamico, ucciderai le prestazioni e consumerai enormi quantità di memoria per app di medie e grandi dimensioni. Inoltre, se fai quello che sto suggerendo, il pulsante Indietro funzionerà alla grande, quindi indicizzazione dei motori di ricerca ecc.

Anche gli altri commentatori hanno avuto dei buoni suggerimenti. La regola empirica che uso è quella di creare pagine come se stessi facendo una pagina Web standard. Quindi ritaglia i pezzi che devono essere dinamici. Sostituiscili con elementi che hanno un ID e poi usano RootPanel.get( id ).add( widget )per riempire quelle aree.

Insidie ​​che abbiamo riscontrato:

• Sebbene sia possibile ottenere molto chilometraggio dall'uso di qualcosa come GWT EXT, ogni volta che si utilizza questo tipo di impiallacciatura sottile su una libreria JavaScript, si perde la possibilità di eseguire il debug. Più di una volta ho sbattuto la testa sulla scrivania perché non riesco a ispezionare (all'interno del mio debugger IntelliJ) cosa sta succedendo nella classe di tabella GWT EXT ... Tutto quello che puoi vedere è che è un oggetto JavaScript. Questo rende abbastanza difficile capire cosa è andato storto ...

• Non avere qualcuno nel tuo team che conosca i CSS. Dalla mia esperienza, non importava che la persona non fosse esperta ... è sufficiente che abbia delle buone conoscenze lavorative e che conosca i termini giusti per google quando necessario.

• Debug tra i browser. Tieni d'occhio la modalità Hosted Out of Process [ 1 ] [ 2 ] [ 3 ], speriamo che arrivi in ​​GWT 1.6 ... Per ora, devi solo fare le cose bene con la modalità hosted, quindi utilizzare il pulsante "Compila / Sfoglia" , dove puoi giocare con altri browser. Per me, lavorando su Windows, ciò significa che posso visualizzare il mio lavoro su FireFox e utilizzare FireBug per migliorare e migliorare le cose.

• IE6. È incredibile come diversi IE 6 renderanno le cose. Ho adottato l'approccio di applicare uno stile al "viewport" più esterno in base al browser in modo da poter avere regole CSS come:

  .my-style { /* stuff that works most everywhere */ }
  
  .msie6 .my-style { /* "override" so that styles work on IE 6 */ }

Infine, assicurati di utilizzare un editor che ti aiuti. Uso IntelliJ: ha un sacco di intelligenza GWT. Ad esempio, se provo ad usare una classe che non è gestita dall'emulazione JRE, mi fa sapere; se specifico uno stile per un widget, e non ho ancora definito quello stile, il codice diventa leggermente rosso ... O, guardando il CSS, mi dirà quando ho specificato attributi contrastanti in un singola regola. (Non l'ho ancora provato, ma capisco che la versione 8 ha un supporto GWT ancora migliore, come mantenere sincronizzate le interfacce e le implementazioni RPC "locali" e "asincrone".)

GWT 2.0, che dovrebbe uscire nei prossimi mesi, risolve molti dei problemi discussi.

• Crea layout usando un html / xml come la sintassi
• Caricamento dinamico degli script: inizialmente verrà scaricato solo il JS essenziale. Il resto verrà scaricato secondo necessità
• Modalità ospitata nel browser: questo potrebbe occuparsi dei problemi di velocità della modalità ospitata discussi, tra gli altri vantaggi
• "Ottimizzazioni del compilatore" - Compilazione più veloce, si spera

Anteprima video GWT 2.0 su Google I / O

Non "incapace di essere superato", ma un po 'di dolore per qualcosa di essenziale.

Gestione della data:

GWT utilizza il deprecato java.util.Dateche può portare a comportamenti imprevisti quando si gestiscono le date sul lato client. java.util.Calendarnon è supportato da GWT. Maggiori informazioni qui .

Esempi di problemi correlati:

• GWT java.util.Date serialization bug
• Ottieni i dettagli della data (giorno, mese, anno) in GWT
• Supporto fuso orario lato client in GWT

Aggiungerò alcuni punti a quelli già menzionati:

• Databinding / validazione. GWT non ha un supporto di database / validazione pronto all'uso, anche se ci sono alcuni progetti in quest'area che stanno iniziando a emergere. Ti ritroverai a scrivere molto di questo:

TextField fname, faddress;
...
fname.setText (person.getName ());
faddress.setText (person.getAddress ());
...

• Caricamento lento. Poiché gwt è sul lato client, il caricamento lento non è in realtà un'opzione. Dovrai progettare con cura i tuoi RPC e Domain Objects per farlo
  • inviare tutti i dati oggetto necessari
  • evita di desiderare di recuperare tutti i tuoi dati
  • Dovrai anche assicurarti di non inviare proxy / oggetti non serializzabili. hibernate4gwt può aiutarti con questi punti.
• Progettazione dell'interfaccia utente. È più difficile visualizzare un'interfaccia utente in Java (pannelli, pulsanti, ecc.) Che in HTML.
• Supporto alla storia. GWT non viene fornito con un sottosistema Cronologia, né viene fornito con alcun sottosistema per URL utili o segnalibri con stato. Dovrai lanciare il tuo (anche se ha il supporto per i token Cronologia, che è un inizio). Questo succede con tutti i toolkit AJAX AFAIK.

IMHO, a GWT manca un framework che supporta immediatamente tutti i problemi citati in questo 'thread'.

Al momento sto lavorando a un progetto che utilizza EXT GWT (GXT) da non confondere con GWT EXT. C'è una differenza, EXT GWT è quello che viene effettivamente prodotto dalla società che ha scritto ExtJS nella libreria javascript. GWT EXT è un wrapper GWT attorno alla libreria ExtJS. GXT è GWT nativo.

Ad ogni modo, GXT è ancora un po 'immaturo e manca di una solida comunità che ritengo abbia GWT EXT. Tuttavia, il futuro è con GXT, poiché è nativo GWT e in realtà sviluppato dalla società che ha creato ExtJS. GWT EXT è in qualche modo paralizzato quando la licenza è cambiata nella libreria ExtJS, rallentando così lo sviluppo di GWT EXT.

Nel complesso, penso che GWT / GXT sia una buona soluzione per lo sviluppo di un'applicazione web. In realtà mi piace molto la modalità hosted per lo sviluppo, rende le cose facili e veloci. Avrai anche il vantaggio di essere in grado di eseguire il debug anche del tuo codice. Anche i test unitari con JUnit sono piuttosto solidi. Non ho ancora visto un ottimo framework di test di unità JavaScript che ritenevo abbastanza maturo per testare un'applicazione aziendale.

Per ulteriori informazioni su GWT EXT: http://gwt-ext.com/

Per ulteriori informazioni su EXT GWT (GXT): http://extjs.com/products/gxt/

Non ci sono state grosse insidie ​​che non sono stato in grado di superare facilmente. Usa la modalità host pesantemente. Dato che stai usando GWT-ext non avrai quasi mai bisogno di toccare CSS da solo, a meno che tu non voglia modificare l'aspetto originale.

La mia raccomandazione è di usare un widget "nativo" GWT su uno di una libreria in cui sono simili nelle funzionalità.

Per quanto riguarda l'indicizzazione dei motori di ricerca: sì, il sito non avrà normalmente gli URL navigabili (a meno che non si aggiungano solo widget agli elementi di un normale sito Web). Puoi fare la cronologia indietro / avanti funzionalità però.

Ho usato GWT e GWT-ext insieme su un progetto qualche tempo fa. L'esperienza dello sviluppo web è stata abbastanza fluida, ma il mio consiglio sarebbe questo:

Non mescolare i widget nativi GWT con i widget EXT. È confuso da morire, poiché di solito i nomi sono gli stessi (GWT.Button o GWText.Button?)

Una cosa che mi è successa e che ha reso il codice più complesso di quanto mi piacerebbe è che volevo un pannello che fosse a) aggiornabile dinamicamente b) collegabile a cascata

I pannelli nativi GWT sono dinamici, i pannelli Ext sono collegabili in cascata. Soluzione? Un GWT.VerticalPanel che avvolge un pannello GWTExt ... Caos. :)

Ma hey, funziona. ;)

Secondo il commento di Ykagano, il più grande svantaggio è perdere la V in MVC. Sebbene sia possibile separare la vera classe dell'interfaccia utente dal resto del codice lato client, non è possibile utilizzare facilmente una pagina HTML generata da un graphic / web designer. Ciò significa che hai bisogno di uno sviluppatore per tradurre HTML in java.

Ottieni un editor per l'interfaccia utente wysiwyg, ti farà risparmiare un sacco di tempo. Uso GWTDesigner.

Il più grande vantaggio di GWT è riuscire a dimenticare i problemi tra browser. Non è al 100%, ma toglie quasi tutto quel dolore. Combinato con il vantaggio del debug in modalità hosted (al contrario di Firebug che è eccellente ma non uguale a un debugger java) offre allo sviluppatore un enorme vantaggio nella generazione di app ajax complesse.

Oh, è veloce in fase di esecuzione, soprattutto se si utilizza un filtro gzip.

Leggermente fuori tema, ma il canale #gwt su irc è molto utile, nel caso tu abbia un problema persistente.

GWT è piuttosto semplice e intuitivo.

Soprattutto con il rilascio di UIBinder per consentire ai widget GWT di essere strutturati in XML e quindi codificati dietro in Java.

Quindi, se hai utilizzato altri strumenti di progettazione Ajax o Flash, o Silverlight, ecc., GWT è molto facile da imparare.

Il principale ostacolo, se non una trappola, è GWT RPC. La vera ragione per cui desideri utilizzare GWT è a causa dell'RPC asincrono GWT. Altrimenti, perché non basarsi semplicemente sul CSS per formattare la tua pagina?

GWT RPC è quell'elemento che consente al server di aggiornare i dati sul server senza dover aggiornare la pagina. Questo è un requisito assoluto per pagine come il monitoraggio dell'andamento delle scorte (o l'attuale debito pubblico e nazionale degli Stati Uniti o il numero di bambini non ancora nati abortiti in tutto il mondo dal secondo).

GWT RPC richiede alcuni sforzi per capire, ma dopo alcune ore, dovrebbe essere tutto chiaro.

Inoltre, dopo esserti sforzato di imparare GWT RPC, scopri finalmente che non puoi usare JSP come componente del servizio per RPC, a meno che ... non abbia una serie di 8 parti (penso) sul mio blog su come usare JSP come servicer RPC GWT. Tuttavia, dal momento che non hai chiesto risposte ma solo problemi, desisterò dalla pubblicità del mio blog.

Così. Sono fermamente convinto che i peggiori ostacoli / insidie ​​nell'uso di GWT siano scoprire come distribuire correttamente RPC asincrono GWT e come abilitarlo a utilizzare i server JSP.

Abbiamo avuto difficoltà a sposare la nostra base di codice GWT con modelli Web HTML che abbiamo ottenuto da un web designer (pagine HTML statiche con ID div specifici che volevamo che GWT gestisse). Almeno quando l'abbiamo usato, non siamo riusciti a far integrare GWT con parti del nostro sito Web che non erano codificate in GWT. Alla fine l'abbiamo fatto funzionare, ma è stato un grande trucco.

• L'interfaccia Async che devi scrivere per ogni interfaccia di servizio sembra qualcosa che potrebbe essere stata generata automaticamente dal compilatore GWT.
• I tempi di compilazione diventano lunghi per progetti di grandi dimensioni

Ma per un grande progetto Javascript è la scelta migliore

GWT 2.4 ha risolto molti dei problemi di cui sopra e una grande libreria di widget è appena uscita da Beta (Ext GWT 3.0.4 aka GXT), che è scritta completamente in GWT, non un wrapper di una libreria JS.

Dolore residuo:

• Mancanza del supporto del selettore CSS3, è possibile utilizzare "letterale ()" in alcuni casi per aggirare il problema.
• Mancanza di supporto per CSS3 e moderni eventi del browser come transizioneEnd .
• Mancanza di supporto per la classe del calendario Java (molti anni dopo).
• Mancanza di supporto per JUnit4 (5 anni e oltre).
• Mancanza di una road map chiara e di un programma di rilascio da parte del team di Google GWT.

Per quanto riguarda GWT 2.4, usa Firefox quando esegui il debug di GWT, è molto più veloce rispetto a Chrome. E se utilizzerai solo Firefox, considera di inserire questa riga nel tuo file project.gwt.xml

<set-property name="user.agent" value="gecko1_8" />

Inoltre, se si utilizza eclipse, aggiungere quanto segue in argomenti -> Argomenti VM:

-Xmx512m -XX: MaxPermSize = 1024m -XX: PermSize = 1024m

È possibile dividere il server e il client e utilizzare i seguenti argomenti -> Argomenti del programma: -codeServerPort 9997 -startupUrl http: // yourserver / project -noserver

Inoltre, per impedire l'aggiornamento del server su ogni modifica, utilizzare JRebel http://zeroturnaround.com/blog/how-to-rock-out-with-jrebel-and-google-web-toolkit-gwt/ Ed ecco una demo live http://www.youtube.com/watch?feature=player_embedded&v=4JGGFCzspaY

Una delle principali insidie ​​è che a volte è necessario assegnare esplicitamente un ID a quello che alla fine diventa un elemento HTML per poter utilizzare determinati stili CSS. Ad esempio: un TabPanel GWT farà: passa il mouse sopra tabBarItems quando alla tabBar del tabPanel è stato assegnato un ID e si specifica un: hover su quell'elementoId.

Ho scritto di altri svantaggi di GWT altrove, ma sono già coperti dalla risposta di rustyshelfs :).

Ho lavorato molto su GWT di recente, e questo è ciò che devo dire:

1. Lo stile CSS è difficile solo a volte, usa lo strumento di sviluppo IE in IE e il firebug in Firefox per capire cosa sta succedendo esattamente e avrai un'idea chiara di ciò che i CSS devono essere cambiati
2. Puoi usare i trucchi per far sì che Google lo indicizzi. Un sito molto famoso è http://examples.roughian.com/ controlla le sue valutazioni su google. Un sito molto meno famoso è www.salvin.in (non ho potuto resistere a dirlo), l'ho ottimizzato in parole: salvin home page (cerca su google queste tre parole)

Non so molto su GWT-EXT, ma anch'io sono convinto che non sia necessario includere librerie di terze parti.

Buona fortuna per la tua decisione :)

GWT esegue Browser Sniffing invece di Feature Detection e l'applicazione non funzionerà su alcuni browser (specialmente quelli nuovi)

Ecco alcuni riferimenti al problema:

• google-web-toolkit Numero 2938: RFE: migliorare il provider di proprietà user.agent per far fronte alla stringa "mascheramento" userAgent
• Iceweasel non è più supportato? - Guida di Google Documenti
• Implementazioni GWT per ogni browser

Ecco alcuni riferimenti al rilevamento delle caratteristiche:

• Browser Detecting (e cosa fare invece)
• Rilevamento delle funzionalità: script browser all'avanguardia
• Rilevamento delle funzionalità del browser

Estratto dal confronto dei framework JavaScript - Wikipedia

Il team di GWT ha apportato molti importanti miglioramenti allo scorso anno rilasciando GWT 2.7. Uno dei principali punti deboli di GWT è che la compilazione richiede molto tempo in GWT 2.6 e versioni successive. Ora questo è andato GWT non ha compilazione incrementale che è super veloce e compila solo le modifiche.

GWT 2.7 ora ha ( Fonte ):

• Build incrementali ora solo pochi secondi
• SourceMaps più compatte, più accurate
• Supporto GSS
• JSInterop
• Ottime prestazioni JavaScript
• Dimensione del codice più piccola

Il modo migliore per ottenere fatti affidabili è dal Ricorda che puoi usare js in GWT in qualsiasi momento, quindi se stai lottando con GWT considera di usare js. Alla fine della giornata GWT è js, quindi puoi fare qualsiasi cosa in GWT che puoi in js. In effetti, la maggior parte dei progetti GWT usa js. Il problema è che GWT è drasticamente più complicato. Tuttavia, a volte vale la complessità extra. sondaggio gwt. . Uno dei maggiori problemi con GWT è sempre stato un lungo tempo di compilazione. Fortunatamente, sta migliorando molto rapidamente, quindi non sarà un problema significativo nel prossimo futuro. Un altro inconveniente è che GWT è drammaticamente più complicato perché Java è un linguaggio più complicato che resiste ai programmatori errati in ogni fase del processo. Inoltre, la compilazione aggiunge un livello. Ad esempio, js interop richiede una piccola piastra di cottura. Il problema fondamentale è che GWT non è stato progettato per essere semplice. È stato progettato da zero per app Web estremamente complicate e l'intera comunità dà priorità in modo coerente, prestazioni, qualità del codice, architettura eccetera rispetto alla semplice codifica.

Vale la pena notare che GWT 3.0 porterà enormi miglioramenti.

Riutilizzo degli oggetti del servizio RPC.
Causa condizioni di gara con sintomi che sembrano app appesi.

Insidie ​​che ho riscontrato 1. Comportamento diverso in modalità superdev. Ad esempio Someclass.class.getName () funziona perfettamente in modalità Superdev e restituisce il nome completo della classe. In modalità produttiva questo non funziona.

2. addWidget (widget) chiamerà removefromparent () del widget

GWT è un capolavoro di tecnologia. Unisce la programmazione client e server rendendola un'applicazione coerente: il modo in cui il software è stato scritto prima del "layering" e il modo in cui dovrebbe essere scritto. Elimina diversi set di competenze, errori di comunicazione tra i membri del team e in generale l'intera fase del Web Design: sia artistica che di programmazione. Ed è il più vicino che potresti ottenere sul cellulare, ad esempio lo sviluppo Android. In effetti GWT è stato progettato per generare diverse interfacce utente native, non solo HTML. Anche se richiede un'enorme disciplina per garantire tale disaccoppiamento - per mantenere agnostici i tuoi strati interni.

Il primo errore che dovresti evitare, che mi ci sono voluti quattro anni per realizzarlo, è usare estensioni di terze parti come EXT-GWT aka GXT e SmartGWT. È molto allettante iniziare a utilizzare i loro graziosi widget desktop anziché investire nel proprio stile, ma non posso dire quanti problemi ho avuto con SmartGWT fino a quando non mi sono finalmente stufato. In breve, congela il set di funzionalità GWT di base al livello certo (piuttosto obsoleto) e poi si basa su di esso. Ricorda anche che l'aspetto e la sensazione del desktop cesellato sembrano sciocchi al giorno d'oggi, per non parlare delle prestazioni lente, tonnellate di bug e funzionalità di compatibilità, specialmente sui dispositivi mobili. Vuoi rimanere il più vicino possibile ai controlli del browser nativo, ad esempio i menu a discesa resi come elementi <select> nativi, non alcuni controlli personalizzati.

Grazie alle tendenze mobili, l'intera UX sta diventando più semplice e piatta, quindi non è necessario fare molto per progettare un'applicazione dall'aspetto nitido. Anche se vuoi un aspetto "3D", ci sono anche gradienti. CSS3 ha reso tutto semplice e GWT lo avvolge in un modo elegante orientato agli oggetti a differenza del CSS non elaborato. Quindi non scoraggiarti guardando i controlli piuttosto brutti di barebone nella GWT Showcase. Il team GWT non ha intenzionalmente offerto uno stile, perché è il lavoro dello sviluppatore.

Il resto è praticamente una programmazione browser convenzionale in Java fortemente tipizzato con belle API concise. Ma ovviamente non dimenticando mai che il codice viene eseguito all'interno del browser, quindi tutte le chiamate sono asincrone, ad esempio non è possibile chiamare i metodi GWT-RPC in un ciclo (per popolare un elenco), ma è necessario ricorrere in modo ricorsivo se si arriva a questo situazione.

Esistono alcuni "anti-schemi" autoproclamati come non usare GWT-RPC. Finora è stato buono con me: per 10 anni. La semplicità è la chiave. Non ci penserei nemmeno un secondo a sacrificare alcune prestazioni marginali per l'eleganza e la manutenibilità del codice. inoltre questo non è dove sarebbero i colli di bottiglia - nel database. Ovviamente ricorda quanti dati stai inviando al client.

E se non riesci a trovare o personalizzare il gadget esistente: leggi un ricco set di elementi HTML5, puoi sempre includerne uno di terze parti. L'ho fatto con un popolare FullQualendar jQuery. Niente scienza missilistica. Tutto il resto come Google Maps e Google Charts ha involucri GWT semi-ufficiali.

GWT è perfetto. L'unico motivo per cui non ottiene abbastanza amore è perché i primi utenti di Internet che influenzano ancora l'industria non sono venuti da Informatica e linguaggi orientati agli oggetti per apprezzarli. Hanno uno sfondo artistico (Photoshop / WordPress) o di rete (Perl / Python).