Je parlais récemment avec un ami du développement de l’interface utilisateur. Il a également été programmeur depuis que la programmation était considérée comme un art arcanique (quand ceux d’entre nous qui l’ont fait étaient considérés comme Gandalf le Gris face au Balrog). Ou peut-être, on se voyait comme ça. Quoi qu’il en soit, nous avons tous les deux été programmeurs Java pendant une grande partie de cette période.
Nous avons tous deux déploré le fait qu’il s’agissait d’un changement de contexte pour passer du codage de la plupart de nos projets en Java, puis de passer à JavaScript pour le frontal.
Sur la base des conversations que j’ai vues en ligne, plusieurs lecteurs réchauffent leurs claviers pour me réprimander de me plaindre de devoir coder en JavaScript. Gardez vos clés au frais, nous et nos collègues sommes expérimentés et heureux d’écrire dans JavaScript et l’un de ses frameworks pour nos clients. Mais l’utilisation de JavaScript n’est pas toujours la meilleure approche.
Dans cet article, nous présentons deux frameworks qui vous permettent de coder votre interface utilisateur en Java : GWT et Vaadin.
Quand Utiliser Java Pour Votre Interface Utilisateur?
La conversation m’est revenue alors que je parlais avec un client — une petite boutique de seulement quelques programmeurs et un architecte logiciel qui a également programmé. Ils avaient décidé qu’ils ne voulaient pas maintenir leurs projets dans deux langues distinctes. Leur entreprise s’était normalisée sur Java, et ils voulaient utiliser les mêmes outils et le même état d’esprit pour créer des interfaces utilisateur puissantes et modernes pour leurs applications Web.
J’ai remarqué sur des équipes plus grandes que l’équipe semble se séparer, certaines préférant se concentrer sur le front-end, et d’autres travaillant principalement sur le back-end ou le code côté serveur. Lorsque le travail est approuvé pour le développement, je vois souvent les mêmes programmeurs prendre ou recevoir la majorité du travail frontal JavaScript, et d’autres prendre le back-end.
Je ne dis pas que c’est une mauvaise chose; en fait, cela semble être tout le contraire. Tout le monde semble être plus productif dans sa zone de confort, mais tout le monde est également conscient de ce que tout le monde fait et peut entrer dans cette zone si ou en cas de besoin. Pour les petits magasins, ce n’est pas une option. Souvent, le même programmeur écrira le code d’un projet entier de l’interface utilisateur au modèle.
Heureusement, il y a des choix si vous souhaitez garder votre interface utilisateur dans la même langue que votre back-end si cette langue est Java. Parlons de quelques-uns d’entre eux maintenant.
GWT
Google Web Toolkit, ou GWT, est une excellente option.
J’ai eu beaucoup de succès avec GWT sur un projet que j’ai commencé il y a environ 8 ans et que je maintiens toujours. GWT m’a permis de construire la logique de vue pour une application d’une seule Page entièrement en code Java standard. Il est livré avec un plugin Eclipse. Je ne l’ai pas utilisé car j’ai utilisé Netbeans pour mon environnement de développement, mais comme Eclipse est la norme pour la plupart des équipes, cela pourrait être très pratique.
J’ai pu décomposer la logique des widgets (comme une zone de texte personnalisée), en classes ou en méthodes d’assistance, tout comme je le ferais dans la logique métier sur un projet côté serveur. Grâce à l’héritage, j’ai pu créer facilement plusieurs widgets ayant des exigences similaires. Le seul vrai concept de changement auquel j’ai dû faire face était que l’interface utilisateur est beaucoup plus axée sur les événements que la plupart des services Web ou d’autres codes côté serveur.
Il y a deux inconvénients principaux que je vois à GWT. L’un est le temps de compilation. GWT ajoute une étape de compilation au processus qui prend un certain temps. Les classes GWT qui ont été construites en Java doivent être compilées dans des bibliothèques JavaScript. J’ai vu plusieurs plaintes concernant le temps que cela prend.
La seconde est que cela fait un bon moment que GWT n’a pas connu de mise à jour significative. Au moment d’écrire ces lignes, la version 2.8.2 a été publiée il y a plus d’un an en octobre 2017. Trois ans auparavant, la version 2.7.0 était sortie, soit quatre ans après la rédaction de cet article. Je vois des messages et des commentaires sur la version 3.0 sortir, y compris certains d’il y a deux ans demandant si l’affiche devrait attendre la sortie de la version 3.0 avant de mettre en œuvre un grand changement (j’espère que l’affiche n’attend toujours pas), mais je ne trouve aucun calendrier quant à la date de sortie de cette version.
Bien que je sois un grand fan du framework et que je le considère assez mature tel quel, je sais que ce flou dans la possibilité de futures versions rend certains chefs de projet plutôt nerveux. Personne ne veut être lié à un cadre qui les met dans l’impasse.
GWT est une bibliothèque que je continuerai à utiliser et suggérerai à d’autres équipes de l’utiliser si elle répond à leurs besoins.
Vaadin
Vaadin est une autre excellente option.
Je pensais à l’origine que le GWT était mon seul choix pour écrire des interfaces utilisateur en code Java standard. Mais quand j’ai parlé avec ce petit magasin que j’ai mentionné ci-dessus, ils m’ont dit qu’ils avaient décidé d’utiliser Vaadin pour leurs projets. Alors, bien sûr, je devais aller jeter un oeil. Et je suis impressionné.
Je vais être honnête, au moment d’écrire ces lignes, je n’ai pas encore utilisé Vaadin pour créer un projet. Mais j’intensifie quelques projets personnels pour lesquels j’ai besoin de front-ends et j’ai l’intention de l’utiliser. Si Vaadin tient ses promesses, ce sera un cadre parfait pour ces projets.
Vaadin promet de prendre en charge les langages qui s’exécutent dans la machine virtuelle java tels que Kotlin et Scala. J’espère que cela inclut Groovy. Si vous lisez beaucoup de mes articles précédents, vous saurez que je suis fan de cette langue car vous pouvez rapidement créer du code qui peut être facilement maintenu. Ce sont des exigences importantes pour moi, en particulier la maintenabilité. Rien ne détruit plus un projet sur la route que de ne pas pouvoir maintenir facilement le code déjà écrit.
Réflexions finales
Vous avez de nombreux choix lors de l’architecture de votre application Web en matière de technologie d’interface utilisateur. Que vous conceviez un projet ou un environnement de production, vous avez tellement d’exigences à garder à l’esprit.
Deux exigences que vous devez garder à l’esprit sont la facilité de développement et la maintenabilité.
- Un environnement de développement dans lequel il est difficile de travailler entraînera de nombreux dépassements de coûts et rendra très difficile l’arrivée de nouveaux programmeurs.
- Un projet difficile à maintenir provoquera des frustrations et gaspillera plus d’argent à l’avenir.
En fonction des besoins et des exigences de votre équipe, une solution Java complète, de l’interface utilisateur au modèle, est non seulement possible, mais également un excellent choix pour un développement rapide et une facilité de maintenance.
Croyez au bon code.