Est-ce une bonne idée de faire l'interface utilisateur à 100% en Javascript et de fournir des données via une API?

Mon travail principal consiste à créer des applications HTML. Avec cela, je veux dire des applications de type CRUD utilisées en interne avec beaucoup de vues de grille, de zones de texte, de listes déroulantes modifiables, etc. devez sauter à travers des cerceaux pour obtenir ce dont vous avez besoin. Cerceaux suspendus au plafond et enflammés.

Je me demande donc si ce serait peut-être une bonne idée de déplacer toute l'interface utilisateur du côté JavaScript. Développez un ensemble solide de contrôles réutilisables qui sont adaptés spécifiquement à nos besoins et n'échangez des données qu'avec le serveur. Oui, j'aime le paradigme du "contrôle" (alias "widget"), son tout à fait bien adapté à de telles applications. Donc, côté serveur, nous aurions toujours une disposition de base similaire à notre balisage ASPX actuel, mais cela ne serait envoyé au client qu'une seule fois, et la partie Javascript prendrait en charge toutes les mises à jour ultérieures de l'interface utilisateur.

Le problème est que je n'ai jamais fait cela auparavant, et je n'ai jamais vu personne faire cela non plus, donc je ne sais pas quels seraient les problèmes. En particulier, je m'inquiète:

• Performance encore. L'analyse comparative montre qu'actuellement le retard principal est du côté client, lorsque le navigateur essaie de restituer la majeure partie de la page après une mise à jour AJAX. Le balisage généré par les formulaires Web ASP.NET donne une nouvelle signification au mot «web», et les riches contrôles Devexpress ajoutent leur propre couche de complexité Javascript en plus de cela. Mais serait-il plus rapide de recalculer toutes les modifications nécessaires côté Javascript et de mettre à jour uniquement ce qui doit être mis à jour? Notez que je parle de formulaires qui ont plusieurs vues de grille modifiables, beaucoup de zones de texte, de nombreuses listes déroulantes contenant chacune un demi-zillion d'éléments filtrables, etc.
• Facilité de développement . Il y aurait beaucoup plus de Javascript maintenant, et il se mélangerait probablement avec le balisage HTML de la page. Cela ou une sorte de nouveau moteur de visualisation devrait être produit. Intellisense pour Javascript est également bien pire que pour le code C #, et en raison de la nature dynamique de Javascript, on ne peut pas s'attendre à ce qu'il s'améliore beaucoup. Les pratiques de codage peuvent l'améliorer un peu, mais pas beaucoup. De plus, la plupart de nos développeurs sont principalement des développeurs C #, il y aura donc une courbe d'apprentissage et des erreurs initiales.
• La sécurité . De nombreux contrôles de sécurité devront être effectués deux fois (côté serveur et côté interface utilisateur), et le côté serveur informatique devra en inclure beaucoup plus. Actuellement, si vous définissez une zone de texte en lecture seule côté serveur, vous pouvez dépendre que sa valeur ne change pas lors de l'aller-retour client. Le framework a déjà suffisamment de code pour garantir cela (via le cryptage viewstate). Avec l'approche basée uniquement sur les données, cela devient plus difficile, car vous devez tout vérifier manuellement. D'un autre côté, les failles de sécurité seront peut-être plus faciles à repérer, car vous n'aurez que des données à vous soucier.

Dans l'ensemble, cela résoudra-t-il nos problèmes ou les aggravera-t-il? Quelqu'un a-t-il déjà tenté cela et quels ont été les résultats? Y a-t-il des cadres là-bas qui aident dans ce genre d'entreprise (jQuery et équivalents moraux mis à part)?

Linkedin le fait pour son site mobile (voir http://engineering.linkedin.com/nodejs/blazing-fast-nodejs-10-performance-tips-linkedin-mobile partie 4), et cela a apparemment été très bénéfique pour eux d'un point de vue performance.

Cependant, je vous suggère d'éviter de faire de même, pour diverses raisons.

Le premier est la maintenabilité: C # / ASP.net est, car il s'agit d'un framework côté serveur, indépendant du client, alors que Javascript ne l'est pas (même avec un framework comme jQuery, vous n'obtiendrez pas une compatibilité multi-navigateurs à 100% , pas à l'épreuve du temps). Je dirais qu'il est également plus facile de vérifier la fonctionnalité d'une application de type statique qu'une application dynamique, ce que vous devez absolument considérer si vous créez des sites à grande échelle.

La seconde est que vous aurez du mal à trouver d'autres personnes capables (et désireuses) de créer une application purement javascript du type de complexité nécessaire pour exécuter l'ensemble de votre site Web (par rapport à la facilité relative de recherche. Programmeurs NET). Cela ne vous concerne peut-être pas directement, mais c'est certainement quelque chose à penser dans une perspective à long terme.

Le troisième problème est la compatibilité client; si vous créez des sites Web destinés au public, n'oubliez pas qu'une partie raisonnable du réseau n'a toujours pas activé JS (pour diverses raisons), vous devrez donc être absolument sûr que vous n'allez pas exclure une grande partie de votre base d'utilisateurs en passant à un site Web piloté par JS.

Quant à vos préoccupations à puces:

• Je ne m'inquiéterais pas trop de l'aspect sécurité, il n'y a aucune raison pour que vous ne puissiez pas mélanger les paradigmes et effectuer un traitement côté serveur lorsque vous avez besoin de sécurité (vous allez avoir un code de rendu d'affichage quelque part qui renvoie HTML , il n'y a aucune raison pour que vous ne puissiez pas simplement déclencher un appel AJAX à la place, si nécessaire).

• La facilité de développement n'est pas vraiment une préoccupation aussi, à mon avis, il existe de très bons outils disponibles pour le développement JS, ne vous contentez pas de vous connecter à VisualStudio parce que vous y êtes habitué! (essayez JetBrains WebStorm, par exemple).

• Les performances des moteurs de vue JS sont tout à fait correctes dans la plupart des cas (encore une fois, d'après mon expérience), je les utilise beaucoup au quotidien. Ce que je suggérerais, c'est d'éviter les cadres plus lourds comme knockout.js etc., et préférez plutôt quelque chose comme le moteur de micro-gabarits de Jon Resig. De cette façon, vous pouvez brancher le code de support de manière sûre et rapide.

Ce que je ferais, si j'étais vous, c'est vraiment d'examiner les raisons de ce changement; Il se pourrait bien que vous n'exploitiez pas efficacement .NET et que vous ayez besoin de mettre votre jeu à niveau, WebForms n'est pas un framework particulièrement lent, donc peut-être certaines des bibliothèques tierces que vous utilisez ralentissent votre rendu.

Essayez de faire un profil de performances de l'application à l'aide d'un outil de test de charge et de profilage, et voyez où se trouvent vos goulots d'étranglement avant de consacrer beaucoup de temps et d'efforts à une solution plus radicale, vous serez probablement surpris de ce que vous trouverez comme coupable de votre lenteur!

Utilisez ExtJS si vous voulez aller dans ce sens, ne réinventez pas la roue. Mais soyez prêt, cela signifie un changement complet de paradigme. Vos compétences HTML sont presque obsolètes. AJAX partout, le serveur fournit principalement une API AJAX. Vous écrirez beaucoup plus de javascript que jamais, alors assurez-vous que vous êtes vraiment en forme avec javascript.

L'équipe dans laquelle je suis a décidé de migrer vers ExtJS fin 2008. Nous avions alors une application PHP de 200 000 lignes qui souffrait de problèmes frontaux. Notre situation était bien pire que la vôtre, car nous avions un cadre de contrôle de formulaire à la main qui était vraiment mauvais, et nous avions beaucoup recours aux iframes pour charger des sections de la page (l'architecture visuelle remontait à 2005, et l'équipe n'était pas au courant d'ajax dès le début). Nous avons quand même dû refactoriser le code, ce qui a facilité la décision de fortement réorganiser la base de code pour qu'elle soit principalement côté client.

Aujourd'hui, l'application compte 300 000 lignes, dont 60 000 lignes sont en code extjs, et environ les 3/4 des fonctionnalités ont été migrées vers ExtJS. Le code extjs est une application d'une seule page, mais il intègre toujours certains formulaires hérités à l'intérieur des iframes. Nous avons d'abord porté sur le conteneur de navigation, puis migré les différentes zones de fonctionnalités au coup par coup. Avec cette approche, nous avons réussi à intégrer la migration extjs dans le processus normal de développement des fonctionnalités, sans trop nous ralentir.

• Performance

  Le code ExtJS s'est avéré beaucoup plus rapide que le code hérité. L'ancien code était bien sûr très mauvais en termes de performances, mais nous sommes néanmoins satisfaits des résultats. Le code de l'interface utilisateur est entièrement en javascript statique, donc il se cache très bien (nous sommes en train de planifier de le lancer sur un CDN). Le serveur n'est pas impliqué dans le rendu frontal, ce qui réduit la charge de travail. Cela permet également à ExtJS de fournir beaucoup de contrôle sur le cycle de vie de l'interface utilisateur (rendu paresseux, déchargement facile des éléments d'interface utilisateur invisibles). Généralement, une fois le code démarré (architecture de chargement à la demande), la plupart du temps de chargement d'un écran est consacré à l'appel de service Web pour récupérer les données. La grille ExtJS est très rapide, en particulier lors de l'utilisation de vues tamponnées pour le rendu des lignes visibles en défilement.

• Facilité de développement

  Pour être honnête, celui-ci est un sac mixte. ExtJS est un DSL, ce n'est pas vraiment du développement web au sens traditionnel. Il a fallu beaucoup de temps à nos développeurs pour vraiment apprendre l'API du framework, et je ne pense pas que cette courbe soit moins abrupte sur d'autres frameworks côté client. Tout le monde dans l'équipe doit être un développeur javascript "senior" (en règle générale, le livre de crockford ne devrait pas avoir de secret). Nous souffrons de problèmes d'amorçage avec les nouveaux développeurs, car l'expertise côté client n'est pas aussi répandue que vous le pensez, et l'expertise extjs est presque nulle (en Belgique, où nous sommes situés).

  D'un autre côté, une fois que vous êtes à jour, l'expérience de développement est très agréable. ExtJS est très puissant, donc si vous êtes dans le groove, vous pouvez créer des écrans incroyables très rapidement. En ce qui concerne l'IDE, nous utilisons PHPStorm, que j'ai trouvé assez compétent avec le code ExtJS.

• Sécurité

  La sécurité est l'une des principales raisons de faire une interface utilisateur côté client. La raison est simple: réduire la surface d'attaque. Les API de service Web utilisées par notre code ExtJS sont une surface d'attaque beaucoup plus petite qu'une couche d'interface utilisateur côté serveur. L'ASVS d'OWASP spécifie que vous devez valider l'exactitude de toutes les entrées sur le serveur avant de les utiliser. Dans une architecture de services Web, il est évident et facile de savoir quand et comment effectuer la validation des entrées. Je trouve également plus facile de raisonner sur la sécurité dans une architecture d'interface utilisateur côté client. Nous avons toujours des problèmes avec les problèmes XSS, car vous n'êtes pas absous du codage en HTML, mais dans l'ensemble, nous sommes bien meilleurs en matière de sécurité que nous ne l'étions sur l'ancienne base de code. ExtJS facilite la validation côté serveur des champs de formulaire, donc nous ne souffrons pas beaucoup d'avoir à écrire du code deux fois.

Si vous pouvez vous permettre de ne pas prendre en charge les utilisateurs sans script et que les moteurs de recherche ne vous concernent pas, alors oui, c'est une approche parfaitement viable. Voici un bref aperçu des avantages et des inconvénients:

Avantages:

• tout en un seul endroit (javascript)
• vous pouvez charger des données à partir du serveur, pas de balisage, ce qui peut économiser beaucoup de bande passante si c'est fait correctement
• plus facile d'obtenir une application réactive (la latence du réseau est toujours là, mais la réponse initiale à l'entrée d'un utilisateur est plus rapide)
• le serveur Web n'a pas besoin de restituer de code HTML ou de développer des modèles (c'est-à-dire que l'effort de traitement est déplacé du serveur vers le client)

Les inconvénients:

• tout doit être en javascript (peut ou peut ne pas être un problème)
• la logique critique doit être dupliquée sur le serveur
• l'état doit être maintenu sur le client et le serveur, et synchronisé entre les deux
• la sécurité peut être plus difficile à obtenir correctement (compte tenu de la façon dont tout élément du code côté client peut être manipulé par des utilisateurs malveillants)
• vous exposez une grande partie de votre base de code (le code qui s'exécute sur le serveur ne peut pas être vu de l'extérieur)

Personnellement, je pense que si vous suivez cette voie, les panneaux de mise à jour ASP.NET ne sont pas la bonne façon. Ils sont parfaits pour ajuster partiellement les applications Web existantes, mais ils envoient toujours du HTML sur AJAX, et la gestion de l'état de cette façon peut être assez velue. Vous feriez mieux d'aller jusqu'au bout, en ne servant qu'un document HTML statique, puis en utilisant une bibliothèque de modèles javascript pour effectuer le rendu HTML; le serveur ne sert pas du tout de code HTML dynamique, mais le client effectue des appels de niveau logique métier sur le serveur et reçoit des données brutes.

Oui tu peux mais ..

Vous devez vous assurer d'avoir une "dégradation" gracieuse afin que les parties critiques de votre application fonctionnent toujours sans Javascript.

C'est ainsi que je construis la plupart des applications de style "HIJAX".

Mon site est encore à ses balbutiements mais 100% js ui a été bien pour moi jusqu'à présent. La seule logique de serveur qui existe sur le frontal est les mappages de modèles et les URL ajax. Le serveur n'a aucune connaissance de l'interface utilisateur, ce qui est très facile à entretenir pour moi. Si vous êtes intéressé, vous pouvez consulter mon site qui est écrit en ExtJS http://coffeedig.com/coffee/ . Mon site n'a pas vraiment de problème de sécurité mais le client aide l'utilisateur normal par simple validation. Je sais qu'un utilisateur malveillant pourrait vraiment envoyer n'importe quel ajax au serveur, donc toute la logique de "sécurité" se fait sur le serveur.

Je pense que le plus gros problème pour vous est que vous allez faire un renversement complet de ce à quoi votre équipe est habituée, il y aura une courbe d'apprentissage abrupte. Je pense que la meilleure approche serait d'expérimenter avec certains frameworks js et d'essayer de les ressentir en écrivant quelques écrans simples.