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

19

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)?

Vilx-
la source
So on the server side we would still have a basic layout simliar to our current ASPX markup, but that then would get sent to the client only once, and the Javascript part would take care of all the subsequent UI updates.Vous décrivez exactement ce qu'est ASP.NET, ce qui me dit que vous ne l'utilisez probablement pas correctement. :) Dans vos applications ASP.NET si vous placez des composants dans des panneaux de mise à jour, la bibliothèque javascript ASP.NET effectuera des publications asynchrones côté serveur et ne restituera que les composants que vous spécifiez.
maple_shaft
@maple_shaft - Je sais, mais d'une manière ou d'une autre, cela fonctionne lentement comme l'enfer. De plus, les grilles effectuent déjà des rappels. Pour tout le reste, s'il y a une publication, dans la grande majorité des cas, vous devez de toute façon actualiser la plupart de la page, car les contrôles changent la visibilité / l'écriture / etc. Et c'est lent.
Vilx
3
Chaque fois que je vois une application ASP.NET où quelqu'un met tout sur la page dans un panneau de mise à jour, j'ai envie de jeter mon moniteur contre le mur>. <! Cela bat à peu près tout le but d'ASP.NET. Pour maintenir le cycle de vie côté serveur et les événements d'application, il est nécessaire qu'il communique d'avant en arrière avec le ViewState entier de la page. Si vous avez 200 contrôles et une grille de données, il ne faudrait pas à Joel Spolsky pour prévoir que vous aurez d'énormes problèmes de performances. Ed Woodcock et AmmoQ ont tout résumé parfaitement, je n'ai donc pas besoin de vous donner une réponse supplémentaire.
maple_shaft
1
@maple_shaft - Désolé, mais j'ai en fait profilé ce truc. Elle était / est lente également sur les ordinateurs des développeurs locaux, et Fiddler a clairement montré que la connexion HTTP était ouverte pendant moins d'une seconde, tandis que la page n'apparaissait que quelques secondes plus tard, et tout le temps que le navigateur utilisait autant de CPU que possible. obtenir et a été essentiellement gelé. Ce n'est pas Viewstate gonflé, c'est HTML / Javascript gonflé.
Vilx
1
@ Vilx - il n'y a rien de mal avec C # /. NET (à part Windows uniquement / coût). Il y a de gros problèmes avec le ballonnement que les frameworks Web ASP.NET mettent en plus. Comme mentionné, essayez Nancy si vous aimez .NET. Mais c'est complètement hors sujet, c'était juste un commentaire que vous vous en sortiriez mieux si vous cessiez d'utiliser des formulaires Web
Raynos

Réponses:

10

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!

Ed James
la source
Non, comme j'ai déjà commenté la réponse de Darknights, il s'agit d'une application interne, sans (bien, peu) partie accessible au public, donc la dépendance JavaScript est OK. Et j'ai fait du profilage. Le côté serveur est bon. C'est le côté client qui s'embourbe sous le HTML généré (comme je l'ai dit, le balisage généré par ASP.NET est lamentable) et le Javascript Devexpress.
Vilx
1
Les sites Web @EdWoodcock ASP.NET sont, de par leur nature, pilotés par Javascript. C'est ainsi qu'il gère la communication asynchrone de ViewState et le rendu des éléments de page.
maple_shaft
@ Vilx- Cela peut être un choc, mais les contrôles comme les grilles de données sont extrêmement complexes. Peut-être avez-vous simplement trop d'éléments sur une seule page?
maple_shaft
@ Vilx - Peut-être qu'il est temps de regarder votre utilisation des contrôles, s'ils génèrent un balisage fou (les contrôles asp.net par défaut ne le font pas dans la plupart des cas si vous utilisez des choses comme des répéteurs au lieu de DataGrids, etc.), alors peut-être vous devez rouler vos propres contrôles (ou passer au HTML manuscrit dans UserControls à la place).
Ed James
1
@maple_shaft - Ou, plus précisément Flex, qui (si je comprends bien) est construit au-dessus de Flash pour exactement de telles fins. C'est une autre idée avec laquelle je joue depuis un certain temps. Mais ... autant que j'ai essayé de le mentionner aux autres, je n'ai reçu qu'une réponse négative, donc je ne peux pas imaginer tirer cela à travers. Il nous faudrait également tous apprendre quelque chose de complètement nouveau.
Vilx
8

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.

user281377
la source
1
Je suis très à l'aise avec Javascript. Je sais que d'autres personnes ne le sont pas.
Vilx
2
Je l'ai fait pendant plusieurs années lors d'un précédent emploi. ExtJS est très agréable et vous pouvez en faire énormément.
Zachary K
@ZacharyK - Comment fonctionne-t-il sur des formulaires vraiment complexes? Ceux comme je l'ai écrit là-bas, avec plusieurs grilles, onglets, etc.?
Vilx
2
Plutôt bien. vous devez bien sûr penser à vos modèles de données. Pour être honnête, j'essaie d'éviter les formes énormes et de composer plusieurs éléments plus petits. Mais cela a moins à voir avec les limites d'ExtJS qu'avec un bon design, etc.
Zachary K
@ZacharyK - Trop paresseux pour me répéter. Lisez mon commentaire sur la réponse d'Ed Woodcock. Je ne peux pas faire plus simple. :(
Vilx-
8

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.

Joeri Sebrechts
la source
J'aimerais pouvoir faire plus que +1 en raison de votre expérience réelle!
Vilx
4

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.

tdammers
la source
1

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".

Nuit noire
la source
Les applications sont déjà lourdes en javascript et ne fonctionnent pas sans. Nos clients sont d'accord avec cela et ne se sont jamais plaints. Et, pour être honnête, je n'ai pas encore trouvé un utilisateur qui a désactivé Javascript aujourd'hui. Notez également que ces applications ne nécessitent aucun type de référencement (ce serait un désastre si un moteur de recherche pouvait accéder à toutes ces informations sensibles), et ne sont PAS destinées à être utilisées à partir d'appareils mobiles. Nous pensons également à créer quelque chose de similaire pour les appareils mobiles, mais ce n'est qu'à l'étape du concept pour l'instant, et nous ne savons même pas s'il y aurait une demande.
Vilx
2
"Et, pour être honnête, je n'ai pas encore trouvé d'utilisateur qui a désactivé Javascript de nos jours." Alors bonjour. J'ai installé noscript, la valeur par défaut pour moi est de désactiver Javascript lors de l'atterrissage sur un nouveau site Web. Et si rien ne fonctionne, je ferme généralement l'onglet du site Web.
Arkh
3
@Arkh vous pensez comme un programmeur pas un utilisateur, nous représentons une petite minorité dans le grand schéma des choses. Ne permet pas de transformer cela en "à js ou pas à js?" parce que ça a été fait à mort autour de ces parties :)
Darknight
1
Les personnes qui désactivent JS savent généralement que ce faisant, elles peuvent rencontrer des sites qui en dépendent et ne fonctionneront donc pas. Qu'ils souhaitent l'activer pour un site particulier est leur choix, mais s'ils désactivent délibérément une technologie standard, cela ne me dérange pas s'ils ne sont pas en mesure de parcourir un site. D'un autre côté, je ne connais pas le support JS pour les lecteurs d'écran. C'est peut-être un problème plus important. Et bien sûr, il y a le problème de l'indexation. Mais quand on veut créer une application qui n'a pas besoin d'indexation et qui ne sera de toute façon pas utilisable par des personnes aveugles, il est logique de s'appuyer sur JS.
Andrea
1
maple_shaft Je vous aime bien, donc je vais le dire gentiment, ne descendons pas sur ce chemin :) merci!
Darknight
1

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.

implorer
la source