7
votes

Simple HTML vs JavaScript généré HTML?

Dans mon application Web, j'aimerais également éviter tout HTML et utiliser uniquement JavaScript pour créer l'arbre Dom de la page Web.

Qu'est-ce que le contenu Web d'écriture plus rapide de la manière traditionnelle dans HTML

du texte ou à l'aide de JavaScript DOM Render, comme ceci: div.AppendChild (document.createtextNode ("Quelque texte")); ?

3 commentaires

"Dans mon application Web, j'aimerais éviter complètement HTML et utiliser uniquement JavaScript afin de créer des pages Web." Je suis intrigué; Pourquoi voulez-vous le faire de cette façon?


L'approche JavaScript s'appuie également sur vos clients permettant à JavaScript. Ils existent, il y en a un assis à côté de moi pour le moment. En outre, il nécessite beaucoup d'action client qui est traditionnellement plus lente que le serveur. Coller avec le traditionnel.


@Ed Daniel: La raison est simple - j'écris mon application de serveur en combinaison C + JavaScript, alors je voulais rendre les choses uniformes et utiliser uniquement ces deux langues.


12 Réponses :


12
votes

Stick avec le HTML traditionnel. Ce n'est pas seulement plus rapide que de tout faire avec JavaScript, il est beaucoup plus maintenu.

sauf s'il y a une raison convaincante, sinon, collez-le avec le HTML droit et utilisez JavaScript pour les pièces les plus interactives de votre application.


3 commentaires

Voir aussi JavaScript discret


Ajout sur, le grand Almighty Google, "n'expose pas" une page générée JavaScript. Comme ses web-crawlers ignorent le code JavaScript! Donc, à moins que votre portail Web ne soit utilisé de manière privée / interne. Ne pas être sur Google s'apparente presque à ne pas être sur Internet. (Pour le cas du site Web étant 99% JS)


Vous devriez expliquer pourquoi HTML traditionnel est plus rapide que JavaScript.



1
votes

HTML est analysé et généré par le navigateur, puis entré dans le DOM. Utilisation de JavaScript pour manipuler la pièce Dom par pièce est plus aérienne.

Imaginez si vous deviez retaper un article d'un magazine. Maintenant, imaginez le faire si chaque phrase était sur une nouvelle page. Bien que le résultat final soit un article copié, vous deviez dépenser tout ce temps à retourner des pages.


0 commentaires

1
votes

De loin la manière traditionnelle est plus rapide, l'utilisateur télécharge le fichier, il est présent, analysé et fait.

Si vous faites la voie JS La page doit être construite au client, chaque fois qu'ils chargent la page.

C'est juste un moyen horrible de construire une page IMHO et un cauchemar pour gérer / mettre à jour / créer


2 commentaires

Bonjour, je suis de l'avenir. Nous avons des applications à une seule page


@Alejandrocavazos Yup, 8 ans plus tard et beaucoup de choses changent de technologie



3
votes

La vitesse est une préoccupation secondaire à l'exactitude - c'est-à-dire que cela servent d'abord les exigences fonctionnelles, puis le rendez-le si nécessaire (certains endroits, cela pourrait déjà être assez rapide).

Dans ce cas, la décision d'utiliser Static Markup Versus JavaScript est une question de qui consommer votre document - est-ce que seuls les utilisateurs avec JavaScript sont activés? Si oui, cela n'a pas beaucoup d'importance. Avez-vous besoin de prendre en compte les moteurs de recherche? Utilisateurs handicapés? Les clients minces qui n'ont pas de support complet JS, ou des utilisateurs paranoïdes atteints de JS handicapés? Dans tous ces derniers cas, avoir un balisage sémantique, non encombré d'éléments superflus, amélioré avec JavaScript, est le seul moyen de partir.


0 commentaires

1
votes

Si vous allez faire beaucoup de modifications à HTML via JavaScript, je vous recommande d'utiliser une bibliothèque de modèles comme trimpath .


0 commentaires

1
votes

Je trouve qu'il est intéressant d'envisager de créer un document purement via JavaScript. En fait, il est plus rapide de créer des éléments à l'aide du document DOM et DOCUMENT.CREATEELEELEMENT que .INNERHTML propriété. Cette méthode crée directement les objets de document directement, alors que l'utilisation de innerhtml nécessite l'analyseur à itération sur le HTML et créer les éléments.

D'autre part, en utilisant JavaScript au lieu d'écrire directement que le HTML nécessiterait que le JavaScript soit analysé et exécuté, créant ainsi des frais généraux supplémentaires sur l'analyseur HTML.


2 commentaires

Je pense que vous oublierez peut-être que l'analyseur HTML est indigène et assez rapide. Toutes les études que j'ai vues ont jusqu'à présent montrer à InnerHTML pour être la plus rapide ( andrew.hedges.name/experiments/ innerhtml ), bien que les moteurs JavaScript deviennent plus rapides tout le temps. J'ai compris que cette question est indifférente avec InnerHTML et préoccupé par la vitesse de développement, non pas de vitesse d'exécution. Peut être pas.


@Lee Kowalkowski: En effet, donc le dernier paragraphe de ma réponse. J'ai peut-être confondu innerhtml avec ce qui est écrit ici , bien que la première ligne indique que cela s'applique à toutes les méthodes basées sur la chaîne HTML. Je suppose que innerhtml serait plus rapide pour les très grandes tâches de manipulation DOM.



1
votes

HTML (modèles) est généralement considéré comme une approche plus intuitive, modulaire et maintenable pour la manipulation DOM.

Quelques endroits pour vous aider à démarrer:

Moteurs de modèles JQuery: Moteurs de modèles JQuery

Modèles de fermeture Google http://code.google.com/clost/templates/


0 commentaires

1
votes

J'ai déjà essayé dans le passé faisant un composant construit à 100% JavaScript pour une discussion Ajax. Il s'est avéré que, il était moins maintenu, a pris plus de temps pour le code et l'avantage là où il était probablement un projet susceptible de bénéficier beaucoup de cette approche JavaScript DOM.

Même si vous pensez qu'il pourrait y avoir un avantage, il n'y a pas. Coller à Pure HTML.


0 commentaires

2
votes

L'approche traditionnelle va être plus rapide car le navigateur doit uniquement télécharger, interpréter et afficher. L'approche que vous suggérez causerait que le navigateur doive télécharger, interpréter, changer * n fois puis afficher.

C'est en ce qui concerne le rendu.

En ce qui concerne la maintenabilité, vous créez un cauchemar. C'est la clé du développement. Le nombre de cauchemars dans la maintenabilité est proportionnel à la "qualité" du code, IMHO. La performance et l'optimisation devraient venir une seconde à la maintenabilité. (Il y a des exceptions, bien sûr. Rien n'est noir et blanc).

HTML a été créé pour être un langage expressif. JavaScript n'était pas. Fin de l'histoire, à mon avis.


0 commentaires

0
votes

IMHO, je pense que compiler JavaScript est une bonne solution pour créer des applications rapides à Web.


0 commentaires

1
votes

2019

(probablement la bonne réponse est correcte pour 2010). Voici une réponse pour 2019 avec référence. P>

Table génératrice avec Div code> Div code>, total de 500 lignes, des cellules de table 250K, 10 divs imbriqués par cellule de table. P>

                         | Download Size | Time 'til browser stops loading
--------------------------------------------------------------------------
HTML generated by server | 680,000 bytes | 00:01:48 
HTML generated by JS     |     570 bytes | 00:00:28 


0 commentaires

0
votes

Comme vous, je me demandais la même chose et faisait un test similaire comme @Evilreiko:

Afin de rendre une page contenant une table avec 1000000000 d'enregistrements, j'ai trouvé les résultats suivants:

  • Fichier HTML statique: Taille de fichier 32 Mo, page de chargement de la page 2.8 min
  • statique Fichier HTML avec contenu minifié: Taille du fichier 12 Mo, Temps de chargement de la page 1,3 min
  • Fichier HTML dynamique généré par JS: Taille du fichier 612 octets (+ 713 octets de JS), Temps de chargement de la page 10.09 secondes ...

0 commentaires