D'accord, appelez-moi simplement le gardien de la crypte pour tout ce que je fais, mais je n'ai jamais senti que la vraie valeur de cela avait été bien comprise. Historiquement, il a été affirmé que "JavaScript discret" ou, garder votre JS hors du HTML via des attributs de gestionnaire d'événements HTML en ligne et des balises de script qui ne se liaient pas autant que possible à un fichier est un énorme élément clé de:
- Problèmes d'accessibilité
- SEO
- Et une amélioration progressive
LIES! (eh bien, maintenant ils le seraient)
La vérité est que vous pouvez faire du JavaScript techniquement intrusif tout en retirant les trois éléments ci-dessus. À moins que vous ne construisiez du contenu HTML de manière dynamique, ce qui était un gros non-non SEO à l'époque.
Mais arrêtez-vous et pensez ... à VOUS!
Vraiment, le gros avantage, la victoire la plus importante et la moins vendue du maintien de la séparation a toujours été l'avantage direct que le développeur en tire. Vous pouvez avoir autant de gestionnaires d'événements que vous le souhaitez sur le même élément html pour le même événement que cela est pratique. Cela signifie que si une balise avec class="some_class"obtient toujours un certain comportement mais obtient également un comportement bonus lorsqu'elle est à l'intérieur d'une id="bonus_behavior"div, nous n'avons pas à commencer à jouer avec la logique à l'intérieur de notre gestionnaire d'événements à autorisation unique pour créer une branche pour cela. Nous pouvons simplement ajouter ou non des gestionnaires selon le contexte.
Facile à lire aussi
Un autre avantage est la lisibilité. C'était une préoccupation plus critique lorsque les outils de navigation consistaient en un message d'erreur exclusif d'IE vous disant qu'il y avait quelque chose de mal avec [object]mais IMO, c'est toujours un gros problème. CSS ici, JS là-bas et HTML est l'endroit où eux et le serveur se rencontrent. Avec toutes ces choses réunies en un seul endroit, il est logique de s'appuyer sur les crochets (les ID, les classes et la hiérarchie) pour créer une couche d'abstraction que tout utilise pour se connecter au HTML.
IMO, plus vous POUVEZ garder vos HTML, CSS et JS séparés, plus il est facile non seulement de lire, mais aussi de modifier et de comprendre ce qui se passe. Je vois un div vide avec "dynamic_combo_box" en tant que classe et j'ai une bonne idée que quelque chose fait une sélection de fantaisie qui charge les données dynamiquement. J'ai une piste sur la façon de trouver cela dans le JS et le CSS et si je rencontre la classe dans ces préoccupations, j'aurai une bonne idée de quoi il s'agit et comment le trouver dans le HTML.
Trop facile à rendre encore plus bâclé
Et bien sûr, la lisibilité a tendance à aller de pair avec la maintenabilité. Lorsque vous faites simplement les choses directement en vidant le tout dans des balises de script où se trouve le HTML pertinent, le plus souvent, il devient plus facile pour les gens de simplement couper et coller ce script dans le HTML d'une autre page sur laquelle ils travaillent lorsque ils veulent des fonctionnalités similaires, ce qui signifie que vous avez maintenant une chose qui deviendra probablement deux choses ennuyeusement similaires mais pas 100% similaires dont le comportement peut devenir problématique au fil du temps en défiant les attentes et nécessiter l'ajout de branchements plus inutiles pour gérer les exceptions dont vous avez besoin un autre ne l'a pas fait.
Ainsi, le comportement de rigging de ces crochets HTML encourage la réutilisation du code de manière intelligente. Si vous avez besoin de brancher le comportement pour une implémentation alternative, il vous suffit d'aller à la même fonction et de la gérer avec la hiérarchie HTML ou peut-être un data-att déclenchant un comportement alt. C'est un guichet unique pour quiconque veut comprendre comment les éléments d'interface utilisateur d'un certain type fonctionnent et ces types de copier-coller paresseusement paresseux feront la bonne chose / plus maintenable juste parce que c'est la chose la plus facile à faites maintenant et c'est la meilleure façon de rendre la maintenabilité possible. Faites-en la chose la plus simple à faire, même pour quelqu'un qui s'en fiche, que ce soit à cause de la panique ou de l'apathie.
Mais qu'en est-il de 2014?
Il peut être légitime de dire que dans les applications modernes d'une seule page, certaines de ces choses insignifiantes ne devraient peut-être pas être bloquées aussi dogmatiquement qu'elles l'ont été, mais croyez-moi quand je dis que je ne pense pas que je suis le seul à a été vendu dessus car cela rend finalement le travail plus facile. Je suis paresseux d'une manière (j'espère) plutôt bonne. J'aime quand je n'ai qu'à changer les choses en un seul endroit pour obtenir des changements partout dans une application, quand je n'ai qu'à regarder au même endroit pour comprendre ce qu'est le bogue, et quand j'ai du mal à comprendre ce qu'est le diable en cours et comment mieux réutiliser ce code pour faire quelque chose de très similaire.
C'est bien comme fractionner une base de données ou une couche de données, c'est bien. En fin de compte, c'est un gain de temps, pourquoi n'ai-je pas juste fait, comme prendre les cinq minutes pour faire la lessive la veille plutôt que de passer 10 minutes à fouetter vos boxers et à effectuer des contrôles d'odeur paranoïaque le lendemain matin.
Pour moi, ce sont ces motivations égoïstes qui ont toujours été le point principal de pourquoi je m'accroche non seulement à JS discret, mais à la séparation des préoccupations de style / comportement / contenu autant que possible, même si WHAT-freaking-WG fait de son mieux pour brouiller ces préoccupations de manière compréhensible et cool / pratique.
Maintenant que tout le monde fait des SPA et qu'il est presque stupide d'essayer de convaincre les entreprises que nous devons nous soucier des personnes qui fonctionnent sans JS (l'accessibilité peut maintenant être supposée être gérée avec du contenu généré par JS), il semble que la prochaine génération de développeurs JS se soucie moins à ce sujet mais IMO, il y a toujours une victoire là-bas et c'est principalement pour vous, le développeur qui écrit et maintient ce genre de choses. Et vraiment, cette victoire aurait toujours dû être le point le plus souligné, mais ne l'a jamais été pour une raison quelconque, car elle profite finalement à vous et également au produit par un heureux accident, car il est plus facile d'ajuster / modifier / déboguer.
Est-ce que ça va?
Eh bien oui, je suppose. Dans une application jetable jetable pour un concours ou quelque chose comme ça. Mais je le ferais quand même parce que j'en ai l'habitude et que ce n'est pas plus difficile à faire.