Choisir entre Thymeleaf et Angular pour un nouveau projet Spring MVC
Je commence une nouvelle application Web Spring Boot et je dois faire un choix quant à la mise en œuvre de l'interface frontale.
Je suis vraiment à l'aise avec Thymeleaf que j'ai utilisé dans plusieurs projets, mais j'évalue Angular (v2) comme alternative possible.
Je suis assez nouveau dans les frameworks [~ # ~] mvc [~ # ~] du côté client et j'aimerais savoir s'il existe des directives pour choisir l'option qui convient le mieux. un projet web.
J'ai lu beaucoup de posts et de tutoriels à ce sujet, mais ils semblent tous décrire des opinions personnelles ou être juste des expériences de codage ...
Existe-t-il des exigences applicatives qui objectivement suggèrent d'utiliser une approche côté client au lieu d'une implémentation côté serveur?
Est-il possible et efficace d’utiliser les deux technologies ensemble?
Thymeleaf et AngularJS ne s’excluent pas mutuellement. Vous pouvez certainement les utiliser ensemble, en fonction de ce que vous essayez d'accomplir. Si vous avez l'habitude d'écrire une application Web dynamique d'une seule page, Thymeleaf est probablement inutile.
Pour répondre à votre question sur les frameworks côté client et ceux côté serveur, je suis un ingénieur en logiciel d’entreprise. Je ne crée donc pas de logiciel commercial et ma priorité est moins de sa beauté (un peu Bootstrap y parvient) et davantage sur la stabilité, la compatibilité des navigateurs (même avec les anciens navigateurs) et la facilité de maintenance. À mon avis, une grande base de code Javascript peut être un ours. Construire mes pages principalement côté serveur me fournit de meilleures capacités de débogage (Java va vous donner beaucoup d'aide à la compilation que vous n'obtenez pas avec Javascript J'utilise javascript (principalement jquery) côté client, mais mes applications Web sont généralement conçues pour se dégrader gracieusement si l'utilisateur a javascript désactivé. Ce sont à nouveau des applications internes, utilitaires, destinées à soutenir l'entreprise. . Je ne avoir le temps de rédiger toute une thèse sur le sujet et il y a beaucoup de nuances que je ne couvre pas, mais j'espère que cela sera utile.
Si vous souhaitez que votre application Web se comporte davantage comme une application mobile ou de bureau, une application Web dynamique d'une seule page utilisant un cadre tel qu'AngularJS est une solution.
Le choix ne consiste pas à utiliser une seule bibliothèque JavaScript ou Thymeleaf, ce serait une contrainte artificielle que vous avez créée. Ce sont deux animaux différents. Thymeleaf est destiné aux modèles, JQuery est une bibliothèque côté client permettant de créer des pages dynamiques. Il serait plus logique de choisir entre des bibliothèques basées sur des modèles ou entre des bibliothèques JavaScript, mais les deux peuvent aller bien ensemble.
En général, vos modèles ne devraient pas affecter votre code JavaScript, certaines personnes modélisent leur code Javascript, mais à mon humble avis, c'est une idée terrible. Utilisez plutôt Templating pour remplacer les attributs de balises en HTML et Javascript pour rendre votre site Web dynamique avec la bibliothèque de votre choix.
Je ne suis pas sûr de ce que vous entendez par
approche côté client au lieu d'une implémentation côté serveur
Mais ce que je vois aujourd’hui, ce sont deux approches différentes, créant l’application Web Microservies VS Monolith. Si vous développez entièrement votre site Web dans Thymeleaf, vous ne le rendrez pas très réutilisable. Netflix, Amazon, Uber, etc. créent tous des services (parfois appelés micro-services) qui sont réutilisés dans toute l’organisation via une API REST.
Si vous avez uniquement un site Web implémenté dans Thymeleaf, il ne sera pas possible pour une autre application (think mobile) d’accéder aux services créés par votre application. Par contre, si vous créez une API REST pour votre application), vous pouvez continuer à réutiliser votre serveur dorsal lorsque vous devez créer une application mobile ou une autre application Web présentant des exigences similaires.
Bien sûr, si vos services ne vont pas être réutilisés, cela ne vous importera peut-être pas et vous pourrez très bien faire les choses d'une certaine manière, même si vous n'êtes pas le plus réutilisable, bien sûr, nous ne créons pas toujours le prochain Amazon. Mais je crois toujours que c’est une bonne idée de suivre les meilleures pratiques, même si c’est juste pour améliorer les choses d’une certaine manière.