J'ai toujours dit c'est une bonne pratique (ala 'javascript discret') JavaScript distinct de balisage HTML. Cependant, j'ai été voir la tendance inverse avec un certain nombre de nouvelles infrastructures populaires tels que Bootstrap, Angular.js et Ember.js. Quelqu'un peut-il me dire pourquoi ce n'est pas considéré comme une mauvaise pratique?
Réponses
Trop de publicités?
Javascript discret est une bonne pratique pour de nombreux endroits sur le web. Les cadres que vous avez mentionnés sont souvent utilisés pour la création complète des applications Javascript. Dans nombre de ces applications, l'expérience sans Javascript est souvent une page vierge. Dans cet environnement, la valeur de la séparation de balisage à partir de Javascript est relativement faible.
edzhelyov
Points
309
Je me suis posé la même question que moi-même et en sont venus à la conclusion suivante:
Le HTML est le langage de balisage pour la présentation de documents. La sémantique que tout le monde est en se référant tout autour de est en fait liée à la représentation des documents riches. Cela inclut des images et des liens qui permettent aux plus riches de l'expérience. Les mêmes principes peuvent être appliqués à des documents Word, où, au lieu de marquer un texte spécifique en rouge, vous pouvez le marquer comme accent et puis le style de l'accent que le rouge, qui sera sémantiquement correcte manière d'exprimer l'intention.
Le problème se pose parce que le HTML ne comprend en fait des éléments qui permettent l'interaction de l'utilisateur - formes . La conception initiale était de permettre à des non professionnels pour créer interactive simple de l'Isu. Lorsque j'ai vérifié les différents bureau GUI cadres il n'y a pas une telle chose comme la séparation entre la vue et la logique de vue, parce que quand vous construisez GUI, vous n'avez pas besoin de cette séparation.
Pour moi l'importance est de savoir combien de ce que vous avez écrit est basée sur le contenu ou graphique. Parce que le HTML sert à deux fins, il est difficile de savoir à quoi servent partir du serveur. Essentiellement des sites comme Wikipédia, et même Stackoverflow sont contenu orienté. Cela signifie que si ils veulent être accessible à un plus large éventail de clients, comme les robots et les navigateurs plus anciens, ils devraient être en mesure de diffuser du pur html. Je pense à deux stratégies possibles lorsque vous souhaitez fournir un contenu et une INTERFACE utilisateur plus riche de l'expérience, comme le textare où j'écris ce commentaire. L'un est d'serveur html et ensuite initialiser l'interface graphique. Ce qui est aussi désigné comme javascript discret et semantical HTML. C'est ce que la plupart des contenus de sites axés faire. C'est surtout à être en mesure de bénéficier de navigateurs et les bots qui permettront à leur contenu afin d'être plus accessibles. L'autre stratégie consistera à identifier le type de client et de servir un contenu différent, qui ne peut être atteint de manière fiable que du côté client, parce que dans les deux cas, html sera servi. C'est toujours à proximité de la première stratégie, en raison de la façon dont le langage HTML est utilisé/abus à la fois comme contenu et de l'interface graphique de la représentation.
Si vous écrivez une application qui ne contiennent pas de contenu, mais de réels services et de processus, puis l'architecture comme AngularJS et similaires convient mieux.
Dans mon expérience, la plupart des entreprises doivent fournir à la fois. Disons que vous avez une application qui utilise le HTML/Javascript pour permettre aux utilisateurs de créer des dessins. Cette application n'a pas besoin de suivre toute discrète lignes directrices, mais il ne sera pas en mesure d'exécuter sur les vieux navigateurs aussi. Mais si vous fournissez un partage social des dessins entre les utilisateurs, permettant aux commentaires et autres contenus, alors il est préférable d'écrire cette partie du site, de manière que les robots et les autres clients peuvent accéder au contenu facilement.
