Quand JavaScript doit-il générer du HTML?


34

J'essaie de générer le moins possible de code HTML à partir de JavaScript. Au lieu de cela, je préfère manipuler le balisage existant chaque fois que je peux et ne générer du HTML que lorsque j'ai besoin d'insérer dynamiquement un élément qui n'est pas un bon candidat pour utiliser Ajax. Je pense que cela facilite beaucoup la maintenance du code et sa modification rapide car le balisage est plus facile à lire et à tracer. Ma règle empirique est la suivante: HTML pour la structure du document, CSS pour la présentation, JavaScript pour le comportement.

Cependant, j'ai vu beaucoup de code JS générer des tas de HTML, y compris des formulaires entiers et des boîtes de dialogue modales lourdes en contenu. En général, quelle méthode est considérée comme la meilleure pratique? Dans quelles circonstances faut-il utiliser JavaScript pour générer du HTML et quand ne devrait-il pas?


2
Pourquoi pensez-vous que le balisage est plus facile à lire et à suivre via Ajax?
psr

3
J'utilise habituellement Ajax de deux manières: en chargeant des extraits de code HTML préalablement rendus dans la page ou dans un tableau JSON que j'analyse, puis que j'insère les données dans des éléments existants. Très rarement, je générerai dynamiquement du HTML à partir de données Ajax et l'insérerai dans la page. Comme le contenu Ajax est généralement pré-rendu au format HTML, il est plus facile à lire que d'essayer de suivre la création d'éléments dynamiques en JavaScript. Je peux rapidement y jeter un coup d'œil et voir la structure et le contenu.
VirtuosiMedia

2
Question épineuse ...
Mark Canlas

2
@VirtuosiMedia - Mais les extraits de code HTML pré-rendus ne posent-ils pas les mêmes problèmes lorsqu'ils sont restitués côté serveur que lorsqu'ils sont restitués via javascript? Je n'essaie pas d'être contentieux, je ne comprends vraiment pas votre problème.
psr

1
@ psr En général, non. Lorsque vous utilisez un framework JS ou même simplement du JavaScript JavaScript, vous allez générer votre code HTML avec une série d'appels de méthodes et de fonctions. Si cela est fait avec un grand nombre d'éléments, il peut être très difficile de voir quelle est la structure réelle du document. En revanche, le côté serveur généré par HTML conservera généralement une structure propre et il suffira que le code serveur renvoie les données dans un modèle HTML plutôt que de générer les éléments eux-mêmes. Donc, si vous voulez modifier le comportement de JS, vous devez suivre les méthodes générant des éléments pour voir la hiérarchie.
VirtuosiMedia

Réponses:


19

Chaque fois que j'ai rencontré une génération HTML lourde en javascript, c'était presque uniquement dans un plugin d'interface utilisateur autonome. Cela a du sens, car cela permet d’encapsuler tout le plugin dans un seul fichier .js (+ un .css pour personnaliser les styles), le rendant ainsi facilement réutilisable, distribuable et indépendant du framework utilisé dans l’application.

Ainsi, si vous écrivez un plug-in JavaScript autonome ou un composant d'interface utilisateur générique que vous souhaitez utiliser dans différentes applications, une telle approche a ses avantages. Sinon, je pense que c'est à la fois plus propre, plus facile à écrire et plus facile à maintenir lorsque vous éloignez la génération html du javascript et du côté serveur.


29

Je pense que le problème est que vous comparez clairement les modèles côté serveur à la génération HTML mal écrite du côté client ad-hoc. Bien sûr, le code bien écrit est plus facile à lire, à maintenir et à tracer.

Vous appelez le code côté client "mounds of HTML", mais il s'agit bien entendu du même code HTML où qu'il soit généré. Le "monticule" est vraiment le gros morceau de code.

Il existe de nombreuses bibliothèques de modèles côté client. Ils fonctionnent de la même manière que ceux côté serveur. En ce qui concerne ce que vous devriez préférer, le compromis performance est compliqué, mais JSON est généralement plus compact que le HTML qu'il devient et le fait de disposer du modèle sur le client peut éliminer certains appels au serveur. D'autre part, le client peut avoir JS désactivé ou être trop lent pour être pratique, cela dépend donc également de votre public cible. Globalement, je pense que les approches sont assez comparables, le facteur le plus important étant les capacités du navigateur de votre public cible.

Mais cela dépend exactement de ce que vous faites, si vous préférez JS à votre environnement de serveur, quelle solution de gabarit vous préférez, etc.


15

Il existe une tendance à utiliser des modèles côté client. Dans les cas extrêmes, le serveur fournirait uniquement une API RESTful, par exemple au format JSON, tout en effectuant tout le rendu du côté client. L'avantage de cette approche est que le code et les modèles JS sont des ressources statiques pouvant être mises en cache, envoyées par proxy et distribuées via un CDN. Ce qui ne peut être fait si vous avez du code HTML dynamique généré par le serveur. De plus, si vous ne renvoyez que des données de l'API RESTful au format allégé, les ressources côté serveur sont considérablement réduites, ce qui accélère la réponse. En plus d'être plus léger, le transfert de réseau est réduit, ce qui le rend encore plus rapide. De cette façon, vous pouvez avoir une application très réactive à faible latence, même sur des connexions lentes telles que la 3G. Ainsi, cette approche est populaire pour les pages et les applications mobiles.

Il existe de nombreuses bibliothèques de mise en œuvre des modèles JS, l' un des plus populaires sont pures , Mustache et dust.js . Par la suite, LinkedIn a décrit les avantages de son article intitulé "Laisser les JSP dans la poussière: déplacer LinkedIn vers les modèles client de dust.js" .


Je suis en train de faire ma première webapp (comme on les appelle de nos jours, j'ai un background java / c ++). Et il me semble naturel de générer beaucoup de html avec JS lorsque l'utilisateur passe par un processus dans lequel il a besoin de plusieurs composants d'interface utilisateur différents, et je ne recharge jamais la page
Emile Vrijdags

2

L’avantage de générer du code HTML sur le client est que vous déchargez le travail de rendu sur chaque client, qui reste généralement inactif en attente de la réponse. Libérer davantage de ressources de serveur pour ne livrer que des données JSON et du contenu statique (HTML, JS et CSS).

Nous faisons une application Web qui génère exclusivement du HTML avec Javascript. Les données JSON représentent 87% des accès au serveur. Le contenu statique est généralement chargé une fois, puis à partir du cache du navigateur.

Mais vous ne pouvez pas l'utiliser - du moins pas facilement - si vous avez besoin de référencement. Ou si vous ciblez une population dont le Javascript est désactivé, mais je ne suis pas sûr que celui-ci soit toujours pertinent avec Youtube, Twitter, Facebook, Gmail, ... obligeant naturellement les gens à l'activer.


0

En ce qui concerne le chargement de page dynamique, il faut se rendre compte que derrière tous les "JQuery AJAX Cloud!" magie, il n’ya que deux choses possibles:

  1. Le code d'un élément est en train d'être injecté dans un div (mauvais), ou
  2. Le contenu est en cours de chargement dans un iframe (c'est mieux, mais ce n'est pas pareil ...)

En ce qui concerne la question initiale, je crée uniquement du contenu HTML via Javascript lorsque je crée une application Web permettant de lire des données XML ou JSON stockées sur le serveur, ce qui entraîne de nombreuses modifications.

Cela n'aurait pas de sens de charger du contenu statique sur une page avec Javascript, car il est toujours possible que le chargement ne soit pas correct ou que le client le désactive ("prenez ces annonces embêtantes!"). En outre, il est très difficile de modifier le contenu HTML lorsque celui-ci est inséré dans un laide document.write()ou dans une chaîne de document.createElement().

Alors tu as raison; soit taper le code HTML brut, ou si un contenu dynamique est nécessaire, utilisez un script côté serveur pour générer ce qui est nécessaire. Utilisez Javascript pour injecter du code HTML uniquement si le site est conçu pour fonctionner sans connexion Internet ou dans un cas similaire.

Une dernière remarque, si vous souhaitez implémenter xmlhttprequests, euh, AJAX, dans un site Web, le meilleur moyen / le plus sûr de le faire est de stocker les données dans un format de données (comme XML), de les charger et de les exporter en conséquence. sur le client. document.writeet element.innerHTMLce n’est vraiment pas la meilleure façon de manipuler le contenu, et est susceptible de causer des maux de tête potentiels à l’avenir (pourquoi ce script n’exécute-t-il pas? Ma <i>balise cassée met tout en italique! etc.).


1
Ce ne sont certainement pas les seules choses qui peuvent arriver. Javascript dispose d'un accès complet au DOM et vous pouvez manipuler l'arborescence DOM comme bon vous semble lors du traitement d'une réponse AJAX.
tdammers

Pourquoi l'injection de contenu dans un div bad?
Peter Taylor

@PeterTaylor injecter du contenu n'est pas mauvais, utiliser innerHTMLest.
Raynos

@PeterTaylor Si un élément ou deux est ajouté avec document.appendChildou quelque chose, il n'y aura probablement pas de problèmes. Le problème est avec un code qui ressemble à quelque chose comme ça div.innerHTML="<table cellpadding='0'><tr><td><label>Val:</label></td><td><input type='text' /></td></tr></table>- c'est un cauchemar à déboguer.
Jeffrey Sweeney

Mais qu'est-ce que cela a à voir avec '"JQuery AJAX Cloud!" la magie'? Votre exemple ici ressemble plus à son antithèse.
Peter Taylor

0

Ma devise est la suivante: quand c’est plus facile et que personne ne se soucie du balisage.

Vous pouvez également exploiter les deux et définir une limite où il est trop difficile de se soucier du balisage et où vous préférez vous concentrer sur l'arborescence DOM. Par exemple, un formulaire comportant des lignes dynamiques (par exemple, "ajouter une autre pièce jointe"), vous souhaiterez probablement le formulaire en HTML, le bouton "ajouter une ligne" et le bouton d'envoi ... vous ne souhaiterez probablement pas générer le HTML avec votre langue côté serveur ou quelque chose.

Une autre règle de base peut être la réutilisabilité. Si votre solution peut être appliquée à d'autres problèmes côté client, encapsulez-la dans js.


0

Nous construisons des applications d'une seule page (comme Google Mail) et il n'y a aucune génération de HTML côté serveur dans nos applications. Au lieu de cela, nous utilisons Backbone.js pour structurer notre côté client et des Handlebars pour rendre notre code JSON dans des modèles intégrés à la page. Cela fonctionne vraiment très bien et nous arrivons à la fin de notre première application qui l'utilise et nous aborderons un projet encore plus grand dans le futur.

Tout type de client lourd où le serveur est utilisé uniquement pour conserver les données et renvoyer les résultats de la requête est un poster posteriste pour une époque où vous souhaitez que JavaScript génère du HTML. Veillez simplement à utiliser un bon moteur de template pour le rendre propre et facile.


0

Je génère du code html dans jquery car j'utilise un portlet et, après l'exécution du code jsp, je dois créer une boucle avec du code html, car je ne parviens pas à obtenir une boucle java avec du code javascript. Je suis donc en train de rendre une liste Java dans un tableau javascript et d'utiliser les chaînes pour générer du HTML.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.