Recentemente stavo parlando con un amico sullo sviluppo dell’interfaccia utente. È stato anche un programmatore da quando la programmazione era considerata un’arte arcana (quando quelli di noi che lo facevano erano considerati come Gandalf il Grigio di fronte al Balrog). O forse, ci siamo visti cosi’. Indipendentemente da ciò, entrambi siamo stati programmatori Java per una grande quantità di quel tempo.
Entrambi abbiamo lamentato il fatto che si trattava di un interruttore di contesto per passare dalla codifica della maggior parte dei nostri progetti in Java, quindi la necessità di passare a JavaScript per il front-end.
Sulla base delle conversazioni che ho visto online, diversi lettori stanno riscaldando le loro tastiere per rimproverarmi di lamentarsi di dover codificare in JavaScript. Mantieni le tue chiavi fresche, sia noi che i nostri colleghi abbiamo esperienza e sono felici di scrivere JavaScript e qualsiasi framework per i nostri clienti. Ma usare JavaScript non è sempre l’approccio migliore.
In questo post, introduciamo due framework che consentono di codificare l’interfaccia utente in Java: GWT e Vaadin.
Quando usare Java per la tua interfaccia utente?
La conversazione è tornata a me mentre stavo parlando con un cliente — un piccolo negozio di solo un paio di programmatori e un architetto software che ha anche programmato. Avevano deciso che non volevano mantenere i loro progetti in due lingue separate. La loro azienda aveva standardizzato su Java, e volevano utilizzare gli stessi strumenti e mentalità per creare interfacce utente potenti e moderne per le loro applicazioni web.
Ho notato nei team più grandi che il team sembra separarsi, alcuni preferiscono concentrarsi sul front-end e altri lavorano principalmente sul back-end o sul codice lato server. Quando il lavoro viene approvato per lo sviluppo, spesso vedo gli stessi programmatori che prendono o ricevono la maggior parte del lavoro front-end JavaScript e altri che assumono il back-end.
Non sto dicendo che questa sia una brutta cosa; in realtà, sembra essere esattamente l’opposto. Tutti sembrano essere più produttivi nella loro zona di comfort, ma tutti sono anche consapevoli di ciò che tutti gli altri stanno facendo e possono entrare in quella zona se o quando necessario. Per i negozi più piccoli, questa non è un’opzione. Spesso, lo stesso programmatore scriverà il codice di un intero progetto dall’interfaccia utente al modello.
Fortunatamente, ci sono scelte se si desidera mantenere l’interfaccia utente nella stessa lingua del back-end se quella lingua è Java. Parliamo di alcuni di loro ora.
GWT
Google Web Toolkit, o GWT, è un’opzione eccellente.
Ho avuto un sacco di successo con GWT su un progetto che ho iniziato circa 8 anni fa e ancora mantenere. GWT mi ha permesso di costruire la logica di visualizzazione per un’applicazione a pagina singola completamente in codice Java standard. Viene fornito con un plugin Eclipse. Non l’ho usato perché ho usato Netbeans per il mio ambiente di sviluppo, ma poiché Eclipse è lo standard per la maggior parte dei team, questo potrebbe essere molto utile.
Sono stato in grado di suddividere la logica per i widget (come una casella di testo personalizzata), in classi o metodi di supporto, proprio come farei con la logica di business su un progetto lato server. Attraverso l’ereditarietà, sono stato in grado di creare diversi widget che avevano requisiti simili facilmente. L’unico vero concetto di cambiamento che ho dovuto affrontare era che l’interfaccia utente è molto più basata sugli eventi rispetto alla maggior parte dei servizi Web o altro codice lato server.
Ci sono due aspetti negativi primari che vedo a GWT. Uno è il tempo di compilazione. GWT aggiunge una fase di compilazione al processo che richiede del tempo. Le classi GWT che sono state costruite in Java devono essere compilate in librerie JavaScript. Ho visto diverse lamentele sul tempo che questo richiede.
Il secondo è che è passato un bel po ‘ di tempo da quando GWT ha visto un aggiornamento significativo. Al momento della stesura di questo articolo, 2.8.2 è stato rilasciato più di un anno fa in ottobre 2017. Tre anni prima, 2.7.0 è stato rilasciato, il che rende quattro anni dal momento in cui scriviamo. Vedo post e commenti su 3.0 che escono, inclusi alcuni di due anni fa che chiedono se il poster dovrebbe aspettare che 3.0 esca prima di implementare un grande cambiamento (spero che il poster non sia ancora in attesa), ma non riesco a trovare scadenze su quando quella versione potrebbe essere fuori.
Anche se sono un grande fan del framework e lo considero abbastanza maturo così com’è, so che questa vaghezza nella possibilità di versioni future rende alcuni project manager piuttosto nervosi. Nessuno vuole essere legato a un quadro che vicoli ciechi su di loro.
GWT è una libreria che continuerò a utilizzare e suggerirò ad altri team di utilizzare se soddisfa le loro esigenze.
Vaadin
Vaadin è un’altra grande opzione.
Inizialmente pensavo che il GWT fosse la mia unica scelta per scrivere interfacce utente in codice Java standard. Ma quando ho parlato con quel piccolo negozio che ho menzionato sopra, mi hanno detto che avevano deciso di utilizzare Vaadin per i loro progetti. Quindi, ovviamente, sono dovuto andare a dare un’occhiata. E sono impressionato.
Sarò onesto, al momento della stesura di questo articolo, non ho ancora usato Vaadin per creare un progetto. Ma sto dilagando un paio di progetti personali per cui ho bisogno di front-end e intendo usarlo. Se Vaadin mantiene le sue promesse, sarà un quadro perfetto per questi progetti.
Vaadin promette di supportare le lingue che girano nella JVM come Kotlin e Scala. Spero che include Groovy. Se leggi molti dei miei post precedenti, saprai che sono un fan di quella lingua perché puoi creare rapidamente codice che può essere facilmente mantenuto. Questi sono requisiti importanti per me, in particolare la manutenibilità. Nulla distrugge un progetto lungo la strada più che non essere in grado di mantenere facilmente il codice che è già stato scritto.
Considerazioni finali
Hai molte scelte quando si progetta la tua applicazione Web quando si tratta di tecnologia di interfaccia utente. Che tu stia progettando un progetto o un ambiente di produzione, hai tanti requisiti da tenere a mente.
Due requisiti che devi tenere a mente sono la facilità di sviluppo e la manutenibilità.
- Un ambiente di sviluppo in cui è difficile lavorare si tradurrà in molti superamenti dei costi e renderà molto difficile portare nuovi programmatori.
- Un progetto che è difficile da mantenere causerà frustrazioni e sprecare più soldi in futuro.
In base alle esigenze e ai requisiti del tuo team, una soluzione Java completa, dall’interfaccia utente al modello, non è solo possibile, ma un’ottima scelta sia per lo sviluppo rapido che per la facilità di manutenzione.
Credi nel buon codice.