JSF with JSP

Pourquoi serait-ce le bon moment d’arrêter d’utiliser JSF avec JSP ?

/ 02.08.2022 Java

Lorsque quelque chose est censé être dépassé mais fonctionne toujours, on peut dire qu’il n’est pas dépassé après tout, n’est-ce pas ? C’est l’un de ces scénarios qui dit : « si ce n’est pas cassé, on ne le répare pas ». Et dans de nombreux cas, cette stratégie peut s’avérer payante. Mais dans le monde du développement logiciel, ce type d’approche comporte de nombreux risques. L’utilisation d’une technologie dépassée, telle que JSF (JavaServer Faces) avec JSP (JavaServer Pages), pose de plus en plus de problèmes chaque année, et peut finalement vous faire perdre de l’argent au lieu de l’économiser sur une mise à jour technologique. Parlons des risques liés à l’utilisation d’une technologie dépassée en prenant l’exemple de JSF et JSP. Il convient de noter que les deux solutions sont officiellement dépréciées.

Pourquoi les technologies JSF et JSP sont-elles dépassées ?

Avant de passer aux risques, expliquons pourquoi nous utilisons encore ces technologies, et ce qui pose problème. La raison la plus courante est que de nombreuses solutions construites à l’aide d’une ancienne pile technologique sont suffisantes, du moins pour le moment. Même si elles ne sont si faciles à modifier et à mettre à jour, les entreprises sont habituées aux anciennes méthodes qui leur ont permis de prospérer pendant de nombreuses années. D’autant plus que le passage à des technologies modernes, beaucoup plus populaires, comporte un coût très élevé. Nous parlons souvent de la reconstruction de systèmes massifs qui ont pris de nombreuses années à construire. Bien sûr, cela est parfaitement compréhensible si l’on ne tient pas compte des risques. Mais ne nous emballons pas. Il est juste de dire que les nombreux problèmes liés à JSP et JSF sont très caractéristiques de l’ensemble du problème des « technologies dépassées ». Tout commence par les questions techniques et le fait qu’au fil des ans, le monde des technologies évolue sensiblement alors que les solutions restent à la traîne. À bien des égards, rester attaché aux anciennes technologies, c’est comme refuser de changer sa vieille voiture de plus de 750 000 kilomètres même si elle nécessite une visite mensuelle chez le mécanicien et consomme trois fois plus de carburant que les nouvelles. Donc, pour résumer, parlons des principales lacunes de JavaServer Faces. 1. Un développement rapide est un développement bon marché, mais JSF complique les tâches simples. 2. Ce framework est relativement difficile à apprendre, et il est donc difficile d’élargir l’équipe si le besoin s’en fait sentir rapidement. 3. Il est incompatible avec un certain nombre de technologies Java standards 4. Il complique les tests par rapport à d’autres solutions plus modernes. 5. Le front-end et le back-end sont étroitement couplés, ce qui se traduit par un temps de développement plus long et plus coûteux et nécessite des développeurs de pile complète pour faire le travail. 6. Il s’agit d’une norme d’interface utilisateur désignée pour Java EE 8, dont la version finale a été publiée le 17 avril 2017. 7. Il est sujet à des problèmes de performance. 8. Côté serveur, les technologies JSP et JSF donnent des pages aux rendus lourds et inefficaces. 9. Et ce n’est pas tout. Parmi les conséquences de ces problèmes, il y a un temps de développement plus long et plus élevé sans oublier l’impossibilité de charger les sites en raison de la surcharge des serveurs. Ce qui est encore plus délicat, c’est que JSF ne fournit pas aux développeurs les outils nécessaires pour résoudre la plupart de ces problèmes.

Pourquoi est-il risqué de s’en tenir à une pile technologique dépassée ?

Les développeurs rencontrent de nombreux défis lorsqu’ils sont confrontés à une pile technologique dépassée, mais pour vraiment comprendre le problème, nous devons l’envisager d’un point de vue plus large. Examinons certains risques figurant parmi les plus importants en lien avec l’utilisation de technologies dépassées, et parfois même en voie de disparition.

Le coût croissant de la maintenance et du développement

COBOL est un langage de programmation qui a été conçu pour la première fois en 1959. Au fil des ans, ses nombreuses versions ont été largement utilisées par les établissements financiers, les gouvernements et les entreprises. Aujourd’hui, il n’y a absolument aucune chance que vous en entendiez parler dans une conversation sérieuse sur les logiciels modernes. Mais même s’il s’agit d’une technologie dépassée, elle est encore très présente dans de nombreuses entreprises bien établies, notamment dans le secteur bancaire. Alors, où est le problème ? Eh bien, il revient incroyablement cher. De nos jours, les jeunes développeurs n’apprennent pas ce langage, et les développeurs expérimentés sont souvent plus proches de la retraite que de la recherche d’un nouvel emploi. Il est donc très difficile de trouver des personnes pour assurer la maintenance des systèmes basés sur COBOL. Et s’ils sont disponibles, ils s’attendent à des salaires beaucoup plus élevés que la moyenne du marché. Nous avons déjà remarqué qu’un processus très similaire se produisait avec JSF et JSP, mettant les entreprises dans une position difficile.

Les lacunes des systèmes obsolètes et les attentes des utilisateurs (et des développeurs) modernes

L’un des défis les plus importants pour les entreprises de cette nouvelle ère est de créer des logiciels à l’épreuve du temps. Des logiciels qui soient facilement accessibles à tout type d’utilisateur, quel que soit l’appareil, ce qui inclut, bien sûr, les consoles de jeu portables, les réfrigérateurs et les aspirateurs robots. Les utilisateurs s’attendent à une accessibilité universelle tandis que les plateformes basées sur JSF ne peuvent même pas être des API RESTful. Bien sûr, c’est un exemple extrême. La plupart des applications construites en JSF ne nécessiteront pas de telles fonctionnalités, mais ce n’est qu’un exemple des nombreuses restrictions qui caractérisent le développement à partir de technologies dépassées. De plus, elles sont tout simplement peu attractives pour les développeurs qui recherchent des défis et veulent créer des logiciels novateurs. Ils ne les perçoivent pas non plus comme un parcours de carrière raisonnable parce qu’elles ne sont pas la voie de l’avenir. Le monde des technologies évoluera, et leurs compétences ne seront plus recherchées.

Quelle est l’alternative ?

Le risque croissant et les problèmes de développement qui accompagnent l’utilisation de JSP se retrouvent parfaitement dans les statistiques de popularité des technologies. À l’ère actuelle du développement logiciel, il n’y a aucune raison de choisir JSF si l’on construit quelque chose à partir de zéro. Dans le même temps, de plus en plus d’entreprises prennent la décision difficile de mettre à jour leur pile pour répondre aux exigences des utilisateurs et des appareils modernes. Selon une récente enquête sur JVM, 58 % des applications exécutées dans JVM utilisent Spring Boot, tandis que seulement 8 % utilisent JSF, et l’écart augmente chaque année. Qu’il s’agisse de Spring Boot ou de Spring MVC, les frameworks modernes traitent une grande majorité des problèmes liés au vieillissement de JSF. Dans le même ordre d’idées, des frameworks comme Angular et Vue.js parviennent à remplacer JSP. Bien sûr, ils ne se contentent pas de résoudre ces problèmes techniques. Il y a beaucoup plus de développeurs disponibles sur le marché, ce qui permet un lancement beaucoup plus rapide des projets et une extension plus facile des équipes. Cela signifie également que nous avons des communautés super actives qui se soutiennent mutuellement et partagent des solutions et des extensions prêtes à l’emploi. Par conséquent, le développement devient moins cher et plus rapide, et nous obtenons dans le même temps de bien meilleurs logiciels.

Est-il difficile de passer à des technologies plus modernes ?

C’est une question piège car, dans la plupart des cas, il ne s’agit pas de la difficulté ou même du coût, mais de la nécessité. De plus en plus souvent, la décision d’abandonner des technologies dépassées est une question de survie. Bien sûr, la décision n’est jamais facile à prendre. C’est toujours une tâche difficile qui nécessite une analyse, un engagement, du temps et un budget. Mais les risques que nous avons mentionnés ne sont pas près de s’estomper. Au contraire, chaque année, des technologies comme JSF se rapprochent de l’histoire du développement logiciel plutôt que de l’ingénierie logicielle moderne. Bien entendu, chaque logiciel nécessite une analyse appropriée. La décision radicale de changer complètement de technologie n’est pas toujours la bonne, mais le fait de l’envisager est un bon début. Et si vous avez l’impression que dire adieu à la pile technologique installée de longue date pourrait être un bon tournant pour votre entreprise, faites-le nous savoir, et nous vous aiderons à faire le bon choix pour votre entreprise. Łukasz Caputa Sales Engineer
Catégorie: Java


Conception, développement, DevOps ou Cloud - de quelle équipe avez-vous besoin pour accélérer le travail sur vos projets ?

Discutez avec vos partenaires de consultation pour voir si nous sommes compatibles.

Jakub Orczyk

Membre du Conseil d’administration/Directeur des ventes VM.PL

Réservez une consultation gratuite
kuba (2)