Pendant plus d'une décennie, les applications Web Java se sont appuyées sur un format assez commun :- un Front-End s'appuyant sur un framework Web Java (Struts, JSF, etc.) ;
- un Back-End en Java classique.
Cependant, cette tendance tend à évoluer depuis quelques années. De nombreuses raisons émergent poussant à l'abandon de l'utilisation des frameworks Web Java. Est-ce un effet de mode ou cela se base-t-il sur de réelles bonnes pratiques ? C'est ce que nous allons tenter de cerner à travers ce débat.
Logan de l'équipe Java nous donne son avis sur cette tendance. Il l'explique par plusieurs points majeurs :
Envoyé par Logan Mauzaize
1. Le tout Web
Tout est connecté à Internet et pas simplement des ordinateurs : téléphone, tablette, TV, appareil photo, montre, voiture, frigo, absolument tout ! Toutes ces vues possibles deviennent ainsi difficiles à gérer pour un serveur d'application.
La vue se décorrèle encore davantage de la logique métier et de l'organisation des données.
2. Nouveaux standards
La standardisation des HTML5, CSS3 et autre ECMAScript 2015 permettent aujourd'hui aux développeurs de réaliser des applications Web très riches plus sereinement. Ces standards ont certainement aidé les navigateurs à devenir plus performants. Il faut ajouter à cela que les machines deviennent toujours plus puissantes.
Ces éléments permettent ainsi aux applications Web de prendre en charge des calculs (et donc la gestion de la vue) qu'on limitait autrefois aux clients riches.
3. Scalabilité
Puisque tout est connecté, le nombre de requêtes tend à exploser. Les serveurs d'applications doivent donc se munir d'un maximum de puissance pour être en mesure de le gérer. Séparer du traitement des données et de la génération de la vue est alors un élément nécessaire.
À cela s'ajoute que les frameworks Web sont souvent gourmands en données de session, car orientés stateful.
4. Orientation service
L'interconnexion des systèmes est également une tendance. Les frameworks Web ne permettent alors pas toujours de gérer ce type d'interface. Il devient plus logique de structurer une organisation en service plutôt que de servir du contenu web.
5. Volatilité
L'utilisation des frameworks Web tend également à s'enfermer dans une technologie. En effet, difficile de changer de framework ou carrément de socle technologique. La séparation de la vue permet ainsi de faciliter la transition technologique aussi bien niveau vue que côté traitement des données. Une équipe peut ainsi bénéficier plus facilement d'une organisation Front-End/Back-End plutôt que des développeurs Full-Stack.
Ce n'est pas la fin pour autant
La gestion d'interface côté serveur a encore quelques beaux jours devant elle. Nombreuses sont les personnes formées à Java et ses différents modèles de développement Web, mais beaucoup moins pour gérer des services, du JavaScript, etc. Les éléments de sécurité également restent à la charge du serveur. Il est alors parfois plus simple de tout gérer côté serveur pour garder le contrôle des données diffusées.
À noter qu'Angular2 fournira également un service permettant d'effectuer du prérendu (et donc du calcul de vue) auprès du serveur.
Tout est connecté à Internet et pas simplement des ordinateurs : téléphone, tablette, TV, appareil photo, montre, voiture, frigo, absolument tout ! Toutes ces vues possibles deviennent ainsi difficiles à gérer pour un serveur d'application.
La vue se décorrèle encore davantage de la logique métier et de l'organisation des données.
2. Nouveaux standards
La standardisation des HTML5, CSS3 et autre ECMAScript 2015 permettent aujourd'hui aux développeurs de réaliser des applications Web très riches plus sereinement. Ces standards ont certainement aidé les navigateurs à devenir plus performants. Il faut ajouter à cela que les machines deviennent toujours plus puissantes.
Ces éléments permettent ainsi aux applications Web de prendre en charge des calculs (et donc la gestion de la vue) qu'on limitait autrefois aux clients riches.
3. Scalabilité
Puisque tout est connecté, le nombre de requêtes tend à exploser. Les serveurs d'applications doivent donc se munir d'un maximum de puissance pour être en mesure de le gérer. Séparer du traitement des données et de la génération de la vue est alors un élément nécessaire.
À cela s'ajoute que les frameworks Web sont souvent gourmands en données de session, car orientés stateful.
4. Orientation service
L'interconnexion des systèmes est également une tendance. Les frameworks Web ne permettent alors pas toujours de gérer ce type d'interface. Il devient plus logique de structurer une organisation en service plutôt que de servir du contenu web.
5. Volatilité
L'utilisation des frameworks Web tend également à s'enfermer dans une technologie. En effet, difficile de changer de framework ou carrément de socle technologique. La séparation de la vue permet ainsi de faciliter la transition technologique aussi bien niveau vue que côté traitement des données. Une équipe peut ainsi bénéficier plus facilement d'une organisation Front-End/Back-End plutôt que des développeurs Full-Stack.
Ce n'est pas la fin pour autant
La gestion d'interface côté serveur a encore quelques beaux jours devant elle. Nombreuses sont les personnes formées à Java et ses différents modèles de développement Web, mais beaucoup moins pour gérer des services, du JavaScript, etc. Les éléments de sécurité également restent à la charge du serveur. Il est alors parfois plus simple de tout gérer côté serveur pour garder le contrôle des données diffusées.
À noter qu'Angular2 fournira également un service permettant d'effectuer du prérendu (et donc du calcul de vue) auprès du serveur.
- l'émergence des microframeworks comme mentionné à travers ce sondage : Utilisez-vous les microframeworks Java en 2016 ? Si oui, lesquels ? ;
- la popularisation des modèles à base de JavaScript du côté Front-End (à la place d'un framework Web Java). L'on peut citer AngularJS ;
- le passage à des solutions n'étant plus orientées Java (comme celles à base de NodeJS).
Toutes ces tendances vont dans le même sens : une plus forte utilisation de frameworks Web basés sur d'autres langages (JavaScript en premier lieu) et des modèles ne se basant plus sur les frameworks Web Java éprouvés. À noter que tout ceci met en évidence une véritable problématique : la maintenabilité de l'existant (la reprise des applications Web développées entièrement en Java).
Votre opinion
Pensez-vous ainsi que tous ces constats sont avérés ? Et s'ils le sont, qu'ils mettent la perte de vitesse de Java dans le monde web, voire de la disparition à moyen terme des frameworks Web Java ? La maintenabilité des applications existantes en Java ou la migration vers ces nouveaux socles peut-elle être un frein à cette transition technologique ? Envisagez-vous une migration ?N'oubliez pas de justifier toute position au sein de vos commentaires.
Pour aller plus loin
Voici quelques liens pour approfondir le sujet :
- Quel framework Web Java utilisez-vous principalement en 2016 ?
- État de GWT en 2016
- Quel est votre retour d'expérience d'AngularJS sur la maintenabilité quand les applications grandissent ?
- Comment convaincre votre DSI d'adopter Node.js et AngularJS ?
Merci à tous pour votre participation.
du coup ?
, ce qui fout en l'air le flux de travail de l'utilisateur. Et enfin, comparez une belle page html avec du css3 bien propre et la même page générée par angularjs avec des template, la différence de consommation mémoire fait peur. J'ai des pages SPA qui occupent 200M dans le browser, ça fait peur.
