Avantages et inconvénients d'une application Web HTML / JavaScript uniquement

Question

Je viens d'un arrière-plan de formulaires ASP.NET et j'ai trouvé le codage côté serveur très puissant dans le passé. Plus récemment, cependant, je souhaitais supprimer progressivement le code côté serveur du frontal et le remplacer par du HTML/JavaScript pur, qui accède aux données via les services Web JSON. Je n'ai pas vraiment d'expérience dans ce domaine, et j'aimerais donc savoir s'il s'agit d'un modèle éprouvé. Quels sont également les pièges qui l'entourent?

Je trouve que les contrôles utilisateur ASP.Net sont très utiles, donc je voudrais garder la théorie derrière en stockant des modèles de balisage dans des fichiers HTML séparés sur le serveur. Ceux-ci seront récupérés et utilisés via jQuery AJAX et le plug-in de modèles HTML jQuery respectivement.

Toute contribution sera extrêmement appréciée.

P.S. Désolé pour la question noob, mais ce type d'architecture Web est-il appelé Web-2.0 ou suis-je complètement hors de piste?

jmort253 · Accepted Answer

J'ai utilisé cette technique exclusivement pour une application Web sur laquelle nous travaillons. Mon backend est hébergé sur Google App Engine en utilisant le Java SDK, et mon frontend utilise HTML, CSS et JavaScript (avec jQuery).

Le projet est plus petit avec juste moi-même et un concepteur Web, et nous pensons tous les deux que cette méthode nous a aidés à travailler beaucoup plus rapidement et à commercialiser quelque chose beaucoup plus tôt.

Avantage: travailler avec des concepteurs Web

Le principal avantage de cette technique est que le concepteur Web, qui connaît certains PHP mais ne se considère pas comme un programmeur, peut travailler sans encombre dans le HTML et CSS sans avoir à parcourir d'innombrables lignes de JSP , les balises taglib et les autres balises côté serveur dont on nous dit depuis des années est supposé pour faciliter la vie d'un développeur frontal.

Sans tout le balisage côté serveur, nous avons été plus agiles. Le web designer a troqué et révisé directement son design original 3 ou 4 fois, avec très peu de changements de ma part.

Il m'a dit qu'il avait l'impression que le HTML était vivant en ce qu'il pouvait le modifier et voir immédiatement les changements sur sa machine avec des données dynamiques. Nous en profitons tous les deux, car l'intégration est principalement automatique.

Code côté serveur et transferts HTML/CSS

Dans des projets antérieurs, il a dû transférer le HTML et le CSS à Java développeurs qui prendraient ensuite son HTML et CSS et le réécriraient complètement en utilisant la technologie JSP. Cela prendrait beaucoup de temps et entraîner des différences subtiles mais importantes dans le rendu réel des pages ainsi que sa validation dans le validateur W3C.

Dans l'ensemble, nous sommes tous les deux très satisfaits de cette technique, et je n'ai toujours aucune page JSP ou code côté serveur dans mes pages HTML.

Pièges de la technique REST/JSON

Les plus gros pièges sont peut-être ceux que nous n'avons pas encore rencontrés. Je m'attends pleinement à avoir des désaccords avec des développeurs Java Java plus expérimentés qui ont été soumis à un lavage de cerveau par ce que la fondation Apache et l'équipe Spring leur ont dit concernant la façon dont les bibliothèques de balises facilitent le travail des développeurs frontaux.) Je m'attends à ce qu'il y ait une courbe d'apprentissage à mesure que ce projet se développe et que nous embauchons plus de développeurs qui pourraient avoir à désapprendre ces techniques obsolètes qui, selon mon expérience, ont rendu le travail des concepteurs Web plus difficile .

Un autre écueil est que le code JavaScript est devenu très massif. C'est plus un problème peut-être parce que j'utilise cette technique pour la première fois, et parce que nous avons introduit une légère dette technique en vue d'une sortie rapide. Peut-être que choisir un meilleur cadre aurait aidé à alléger une grande partie du code. À mon avis, rien de tout cela n'a été un spectacle, et je suis encouragé à continuer à utiliser cette technique et à affiner mes compétences dans ce domaine.

Avantage: d'autres applications peuvent être créées sur la plate-forme

Enfin, je dois mentionner un avantage caché. Parce qu'il y a un bon degré de séparation entre mes services Web RESTful backend et mon frontend, j'ai également créé une plateforme que je peux facilement étendre.

Un de nos opérateurs voulait essayer une preuve de concept dans une autre application, et grâce à mes services RESTful, nous avons pu créer une interface entièrement différente de l'application pour résoudre un problème complètement différent. La preuve de concept développée rapidement utilisait ses propres HTML, CSS et JavaScript, mais elle utilisait les services RESTful comme backend et source de données.

En fin de compte, un autre chef de projet a vu ce que j'avais fait et il est devenu immédiatement clair que la fonctionnalité devait être plus qu'une simple preuve de concept, alors son équipe l'a mise en œuvre.

Je ne saurais trop insister sur la réutilisabilité de cette architecture, tant au niveau de l'application qu'au niveau HTML/CSS/JavaScript, et je vous encouragerais certainement à l'essayer dans votre prochain projet.

tdammers · Answer

C'est certainement une stratégie viable, mais ce n'est pas une solution miracle.

Avantages:

si c'est fait correctement, les applications développées de cette façon sont très réactives
vous avez une séparation claire de la logique (sur le serveur) et de la présentation (sur le client); le serveur n'a pas du tout à se préoccuper des aspects de présentation de l'application
utilisation potentiellement plus efficace de la bande passante du réseau (vous n'envoyez que des données brutes, pas de passe-partout de présentation)
plus facile à développer des GUI de type bureau, car vous êtes moins dépendant du paradigme de demande/réponse

Contre:

vous devez écrire votre code client en Javascript, ou un langage qui peut être compilé en Javascript, car c'est la seule chose disponible dans un navigateur
l'utilisation des ressources sur le client peut être plus élevée, de sorte que l'application peut ne pas fonctionner correctement sur les appareils de qualité inférieure (pensez aux navigateurs mobiles, etc.)
cela ne fonctionnera pas du tout avec javascript désactivé; s'il s'agit d'un site Web accessible au public, vous devez réfléchir sérieusement si vous êtes prêt à prendre ce risque (surtout si vous considérez le référencement et l'accessibilité - une approche lourde en javascript est généralement dévastatrice sur ces deux fronts)
beaucoup de logique doit être écrite deux fois: une fois sur le client, et encore une fois sur le serveur (car vous ne pouvez jamais faire confiance au client)
la concurrence peut être un enfer, vous devez donc concevoir votre code côté client très soigneusement et être prêt à toutes sortes de problèmes de concurrence

Ken Fehling · Answer

Un inconvénient a besoin de dupliquer une partie de la logique dans JavaScript et ASP.net. Cela peut ne pas être un gros problème pour vous en fonction de votre application. Cela revient souvent parce que vous ne voulez pas avoir à demander au serveur de vérifier chaque petite chose ("L'utilisateur est-il autorisé à appuyer sur ce bouton ou à sélectionner cette option dans cette situation?"), Mais vous ne voulez pas non plus dépendre sur le client comme le seul à faire la validation puisque l'utilisateur a le contrôle sur le client.

gbjbaanb · Answer

C'est certainement possible, et probablement encourageable en tant que meilleure pratique. Ce que vous proposez est de séparer l'interface utilisateur de la logique métier afin qu'il y ait une séparation nette des préoccupations. Ceci est vraiment bon.

Trop souvent, les cadres que nous avons essayent de mélanger les choses et vous vous retrouvez avec un logiciel monolithique où l'interface utilisateur, la logique métier et les données sont toutes entrelacées. Cela rend plus difficile à maintenir et à modifier.

Une fois que vous avez divisé l'application en 2 parties, vous pouvez remplacer complètement l'interface utilisateur par quelque chose d'autre - un programme de bureau ou une autre interface utilisateur pour mobile par rapport aux navigateurs de bureau.

Les bits délicats que vous trouverez en faisant cela est qu'un peu de code qui devrait théoriquement être dans le serveur serait mieux placé sur le client - la validation par exemple, c'est plus rapide et plus réactif pour l'utilisateur de mettre du code de validation sur un formulaire sur le client que de frapper le serveur pour vérifier, disons, un champ de texte ne contient que des caractères alphanumériques. La même chose s'applique souvent aux couches de données et d'entreprise. Il vous suffit de prendre des décisions informées et pratiques sur le moment de violer la distinction entre les couches.

šljaker · Answer

Si vous utilisez toujours ASP.NET WebForms et souhaitez accélérer vos applications, voici ce que vous devez faire:

Enfin, consultez www.porsche.se. N'est-ce pas un site sacrément rapide?