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

Je viens d’un contexte de formulaires ASP.NET et j’ai trouvé le codage côté serveur très puissant par le passé. Plus récemment, toutefois, je souhaitais éliminer progressivement le code côté serveur du serveur frontal et le remplacer par du code HTML / JavaScript pur, qui permet d’accéder aux données via les services Web JSON. Je n'ai aucune expérience réelle dans ce domaine et j'aimerais donc savoir s'il s'agit d'un modèle éprouvé. Aussi, quels sont les pièges qui l’entourent?

Je trouve les contrôles utilisateur ASP.NET très utiles. Je souhaite donc garder la théorie derrière elle en stockant les modèles de balisage dans des fichiers HTML distincts sur le serveur. Ceux-ci seront récupérés et utilisés via jQuery AJAX et le plugin de modèles HTML jQuery, respectivement.

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

PS Désolé pour la question noob, mais est-ce que ce type d'architecture Web s'appelle web-2.0 ou est-ce que je suis complètement hors piste?

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

Le projet est plus petit avec juste moi et un concepteur Web, et nous pensons tous les deux que cette méthode nous a permis de travailler beaucoup plus rapidement et d’obtenir quelque chose sur le marché beaucoup plus tôt.

Avantage: travailler avec des concepteurs Web

L’avantage majeur de cette technique est que le concepteur Web, qui connaît PHP, mais ne se considère pas comme un programmeur, peut travailler sans encombrement dans les langages HTML et CSS sans avoir à parcourir d’innombrables lignes de fichiers JSP, balises taglib et autres éléments côté serveur. Le balisage dont on nous dit depuis des années est censé faciliter grandement la vie des développeurs front-end.

Sans tout le balisage côté serveur, nous avons été plus agiles. Le concepteur de site Web a échangé et révisé directement son dessin original 3 ou 4 fois, avec très peu de modifications de ma part.

Il m'a dit qu'il avait l'impression que le code HTML était vivant, qu'il pouvait le modifier et voir immédiatement les modifications sur sa machine avec des données dynamiques. Nous bénéficions tous les deux de ce fait en ce que l'intégration est généralement automatique.

Code côté serveur et transferts HTML / CSS

Dans des projets antérieurs, il devait transférer le code HTML et CSS aux développeurs Java, qui devaient ensuite reprendre ses codes HTML et CSS et le réécrire complètement à l'aide de la technologie JSP. Cela prendrait beaucoup de temps et entraînerait généralement des différences subtiles mais importantes dans le rendu réel des pages ainsi que dans la validation de celui-ci par le validateur W3C.

Globalement, nous sommes tous les deux très satisfaits de cette technique, et j’ai toujours zéro page JSP ou code côté serveur dans mes pages HTML.

Pièges de la technique REST / JSON

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

Un autre piège 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 contracté une légère dette technique en vue d'une libération rapide. Peut-être que choisir un meilleur cadre aurait permis d’alléger une grande partie du code. À mon avis, rien de tout cela n'a été un coup dur, et je suis encouragé à continuer à utiliser cette technique et à affiner mes compétences dans ce domaine.

Avantage: d'autres applications peuvent être construites sur la plate-forme

Enfin, je devrais mentionner un avantage caché. Comme il existe un bon degré de séparation entre mes services Web RESTful d’arrière-plan et mon interface, j’ai également créé une plate-forme que je peux facilement étendre.

Un de nos responsables des opérations a voulu essayer une preuve de concept dans une autre application et, grâce à mes services RESTful, nous avons pu créer une interface totalement différente de l'application afin de résoudre un problème complètement différent. La preuve de concept rapidement développée utilisait ses propres HTML, CSS et JavaScript, mais elle utilisait les services RESTful comme back-end et source de données.

En fin de compte, un autre chef de projet a constaté ce que j'avais fait et il est immédiatement devenu évident que la fonctionnalité devait être davantage qu'une simple démonstration de concept. Son équipe l'a donc mise en œuvre.

Je ne saurais trop insister sur le fait que cette architecture est réutilisable, tant au niveau de l'application que du niveau HTML / CSS / JavaScript, et je vous encourage vivement à l'essayer dans votre prochain projet.

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

Avantages :

• si cela est fait correctement, les applications développées de cette manière 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)
• plus facile à développer des interfaces graphiques de type bureau, puisque vous êtes moins dépendant du paradigme de demande / réponse

Inconvénients :

• vous devez écrire votre code client en Javascript, ou un langage capable de le compiler en Javascript, car c'est la seule chose disponible dans un navigateur
• l'utilisation des ressources sur le client peut être supérieure, de sorte que l'application risque de ne pas fonctionner correctement sur les périphériques de qualité inférieure (pensez aux navigateurs mobiles, etc.)
• cela ne fonctionnera pas du tout avec javascript désactivé; si vous avez un site Web destiné 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 utilisant beaucoup de 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 une fois encore sur le serveur (car vous ne pouvez jamais faire confiance au client)
• la simultanéité peut être un enfer, vous devez donc concevoir votre code côté client très soigneusement et vous préparer à toutes sortes de problèmes de simultanéité

C'est certainement possible et probablement encourageable comme meilleure pratique. Vous proposez de séparer l'interface utilisateur de la logique métier afin de séparer clairement les préoccupations. Ceci est vraiment bon.

Trop souvent, les frameworks que nous avons essayés de brouiller les pistes et vous vous retrouvez avec un logiciel monolithique dans lequel l'interface utilisateur, la logique métier et les données sont étroitement liés. Cela rend plus difficile à maintenir et à modifier.

Une fois que vous avez scindé l'application en deux parties, vous pouvez remplacer l'interface utilisateur entièrement par quelque chose d'autre: un programme de bureau ou une autre interface utilisateur pour mobile par rapport aux navigateurs de bureau.

La difficulté que vous découvrirez en procédant de la sorte est qu’un peu de code qui devrait théoriquement se trouver sur le serveur serait mieux placé sur le client - la validation par exemple, sa rapidité et sa réactivité pour que l’utilisateur mette du code de validation sur un serveur. forme sur le client que de frapper le serveur pour vérifier, par exemple, 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 aux couches métier. Il vous suffit de prendre des décisions éclairées et pratiques pour savoir quand violer la distinction entre les couches.

Un inconvénient est de dupliquer une partie de la logique en JavaScript et ASP.net. Cela peut ne pas être un gros problème pour vous en fonction de votre application. Il arrive souvent parce que vous ne voulez pas demander au serveur de tout vérifier ("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 étant le seul à effectuer la validation puisque l'utilisateur a le contrôle sur le client.

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

• Concevez votre application en gardant à l'esprit SOLID
• Désactiver ViewStatesur toutes les pages et les contrôles utilisateur

• Ne pas utiliser les contrôles côté serveur

  <%: VeiwModel.Title%> au lieu de <asp: Literal id = "Title" runat = "serveur">

• Dans le backend, écrasez la méthode OnInit et effectuez toute l'initialisation ici:

  protégé remplacer void OnInit (System.EventArgs e) {CreateViewModel (); base.OnInit (e); }

• Compressez tous les fichiers .css et .js en 1 en utilisant SquishIt

• Images paresseuses
• Mettre en cache des objets complexes

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