Le JavaScript intrusif est-il toujours correct?

Je pensais que si tous les utilisateurs d'un site Web devaient activer JavaScript, est-il acceptable d'utiliser un code JavaScript intrusif?

Je suis tout à fait favorable à l'amélioration progressive, mais à quoi sert une application Web avancée qui fait rebondir les utilisateurs à la porte s'ils ont un ancien navigateur ou JavaScript désactivé?

Nous avons un public cible très mince, et nous pouvons dire à notre public cible quel navigateur et plugins / fonctionnalités ils doivent avoir. Donc ma question est, est-ce que le mélange de JS et de HTML va bien dans ce cas? Comme utiliser les attributs onclick.

Il s'agit d'une décision commerciale plutôt que d'une décision de conception.

Il y a un coût à fournir une version du site Web qui fonctionne sans JavaScript (ou Flash ou Silverlight). L' entreprise doit décider si la perte de revenus / visiteurs en vaut la peine ou non.

Donc, si cela coûte 10 000 $ pour écrire cette version (le nombre peut être important, mais il n'est là que pour cet exemple), l'entreprise récupérera-t-elle ces dépenses pendant la durée de vie du site? Sinon, ne fournissez pas cette version.

Cependant, s'il ne coûte que 100 $ pour écrire cette version, il serait logique de fournir la dégradation gracieuse.

Après avoir pris la décision commerciale de ne cibler que les navigateurs compatibles JavaScript et de vous attendre à ce que vos utilisateurs activent JavaScript, il est parfaitement logique que votre application tire parti des fonctionnalités dont vous disposez maintenant. La seule chose que vous devrez faire est (comme le fait Stack Overflow lui-même) un avertissement indiquant que le site ne fonctionnera pas correctement si l'utilisateur ne l'a pas activé.

Quelque chose que personne d'autre n'a encore évoqué…

99% des sites Web accueillent un visiteur particulier, un avec peu ou pas de JavaScript. Ce visiteur a un nom: Googlebot .

_{Une grande raison pour laquelle tout le monde devrait aussi se soucier des visiteurs aveugles}

Si vous êtes l'un des rares qui ne se soucie pas du tout du trafic des moteurs de recherche, eh bien, c'est votre prérogative, mais cela ne fait certainement pas une règle générale.

Les gens qui écrivent des choses pour des environnements internes spécifiques sont une grande raison pour laquelle IE6 est toujours là.

Pensez-y

Si vous faites un site JS uniquement (peut-être que «application» dans ce cas est un meilleur mot), la soi-disant «discrétion» de JS n'a pas autant d'importance que dans le cas où vous devez vous dégrader gracieusement en non Version JS.

Cependant: JavaScript écrit de manière discrète est en général plus facile à écrire (et du moins je le trouve de cette façon) et à maintenir. Il est plus facile d'introduire des modifications dans la mise en page HTML qui ne cassent pas JS et des modifications dans JS sans se soucier de casser HTML.

Si vous créez un site Web, je garderais JavaScript discret. Cependant, si vous construisez une forme d'application (comme Google Docs), JavaScript sera assez intrusif.

JavaScript et HTML5 sont parfaits pour créer des applications si tel est votre besoin, mais c'est vraiment un choix commercial.

La majorité des utilisateurs (mes utilisateurs, je ne connais pas vos utilisateurs) ont JavaScript disponible et activé. Donnons à ces utilisateurs une expérience utilisateur exceptionnelle. Cependant, vous devez toujours fournir une version de votre site qui fonctionne sans Javascript. Je sais que c'est compliqué de construire 2 versions, mais c'est comme ça que ça se passe dans le développement web. (En réalité, vous devrez peut-être créer plusieurs versions, une troisième pourrait être une version mobile de votre site).

Ce que vous ne voulez pas faire, c'est concevoir le plus petit dénominateur commun: "Eh bien, certains utilisateurs ont désactivé Javascript, nous allons donc concevoir notre site pour qu'il fonctionne bien pour eux - pas de Javascript, cliquez sur le serveur pour tout . " Cela pénalise juste la majorité de vos utilisateurs qui ont Javascript.

Vous avez mentionné l'utilisation d'attributs onlick. Envisagez-vous d'utiliser un gestionnaire d'événements JavaScript pour la navigation dans les pages?

Je le déconseille pour une seule raison: il casse le clic du milieu .

Pour un clic régulier sur un lien, en supposant que JavaScript est activé, ceux-ci seront fonctionnellement équivalents:

<a href="#" onclick="window.location = 'myPage.htm';">Click here</a>
<a href="myPage.htm">Click here</a>

Si vous essayez de cliquer avec le bouton du milieu sur le premier exemple, vous obtiendrez une page vierge plutôt que maPage.htm.

En dehors de cet exemple, je pense qu'il est correct d'utiliser du JavaScript intrusif si cela est logique pour vous. Il faut moins de temps pour écrire (mais pas nécessairement maintenir) JavaScript en ligne, et la perte de l'amélioration progressive peut ne pas être importante dans votre situation.

JavaScript intrusif était correct il y a 10 ans. C'est aussi bien si vous êtes un amateur, ou si vous construisez un prototype jetable, ou s'il y a des circonstances qui le nécessitent, comme une dépendance au code hérité ou au code piloté par les données et cela coûterait tout simplement trop pour réparer al

Si vous construisez quelque chose à partir de zéro, suivez les normes, écrivez un code correct, propre et maintenable. Écrivez quelque chose dont vous serez fier et qui ne vous rendra pas malade dans un an quand un pauvre schmuck vous demandera de l'aide parce qu'il ne comprend pas un hackjob que vous avez fait. Écrivez quelque chose qui garantit que vos concepteurs Web peuvent facilement échanger des CSS sans avoir à creuser leur chemin à travers HTML et JavaScript désordonnés.

Générez l'application de manière à ce qu'elle ait de la place pour se développer, afin que tout développeur puisse intervenir et la maintenir. Le temps investi maintenant vous fera gagner du temps à l'avenir, sinon votre temps, celui de quelqu'un d'autre.

Assurez-vous que le JavaScript peut être réutilisé dans un autre contexte. Assurez-vous qu'une refonte complète du site Web peut être juste cela, une refonte et non pas une reconstruction complète de quelque chose qui existe déjà mais qui n'a pas été construit dur.

Imaginez à quel point il serait embarrassant de devoir consacrer autant de temps à une refonte qu'à sa construction d'origine.

Faites-moi confiance par expérience, JavaScript discret vous empêchera de faire des erreurs coûteuses.

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.

Si vous connaissez votre environnement d'exploitation cible, Javascript et les frameworks comme jQuery peuvent être une véritable aubaine. Par exemple, dans un environnement d'entreprise où le SOE a Javascript et IE8 plus que son plus sûr pour écrire des applications de navigateur côté client intensives.

Faciliter la dégradation gracieuse n'est qu'un des nombreux facteurs qui font du JavaScript discret un choix attrayant, et à mon avis, ce n'est pas le plus important.

D'après mon expérience personnelle, je dirais que si vous parlez d'un projet plus important, qui évoluera probablement beaucoup au fil du temps, l'utilisation d'un style discret rendra l'application beaucoup plus facile à maintenir, à déboguer et à refactoriser. C'est la principale raison pour laquelle nous utilisons toujours un style discret, même sur les sites qui exigent que JavaScript soit activé pour tous les visiteurs.

En général, si vous développez un "site Web" traditionnel qui est disponible de manière anonyme, indexé par les moteurs de recherche et où les revenus sont générés par les annonces, alors vous devez fournir une dégradation gracieuse. L'idée étant que ce type de site vit et meurt par accessibilité, donc limiter l'accessibilité signifie perdre une tonne de pages vues et donc des revenus publicitaires.

Un accès restreint, généralement non indexable et non basé sur les revenus publicitaires (application Web) peut être beaucoup plus flexible. Cela revient à une décision entre l'étendue du support, la profondeur des fonctionnalités et le coût de développement. Pensez-y comme développer une application traditionnelle: quelle plateforme supportez-vous et quelles sont les spécifications minimales? Si vous ciblez une seule plate-forme et des spécifications limitées, vous pouvez vous concentrer sur la fourniture d'un produit supérieur avec moins de coûts de développement et de support, au prix d'une perte de part de marché potentielle.

Exemple: la recherche Google est un site Web. Google Docs est une application Web. Google Search n'est pas superflu et peut fonctionner à l'identique sans JavaScript, CSS et / ou images, etc ... - il fonctionne aussi bien dans les navigateurs en mode texte que dans les derniers navigateurs GUI. Google Docs ne fonctionne tout simplement pas avec JavaScript désactivé et ne se dégrade même pas gracieusement - pas même un avertissement pour activer JavaScript.

Je préfère que la plupart de la mise en page et de la navigation soient gérées en CSS. Oui, Lynx peut ne pas le prendre en charge, mais tous les navigateurs complets que je connais ne peuvent pas le désactiver. Ensuite, JavaScript peut être utilisé pour des choses plus flashy mais pas obligatoires. J'aime aussi Ruby on Rails à cet effet. Il peut faire beaucoup de ce que JavaScript serait requis pour faire côté serveur tant que vous n'avez pas besoin de mises à jour dynamiques de page.

Plus ciblé sur la réponse à la question: je N'AIME PAS le JavaScript requis, mais il y a une analyse de rentabilisation où il est requis comme l'a noté ChrisF.

Javascript est la norme par défaut en ce qui concerne tout type de contenu dynamique fourni par le client, s'ils n'ont pas JS, ils n'auront probablement pas Silverlight.

Ensuite, vous devez penser à votre marché / public. Êtes-vous programmers.stackexchcange ou bbc.co.uk/news? publics très différents.

Puisque vous pouvez regarder autour du Web et voir "Javascript intrusif" sur de nombreux sites, votre question de base est répondue, oui, elle est correcte, et de nombreux sites populaires le font, même Google.

Le plus important, cependant, est la dégradation gracieuse des fonctionnalités, même si vous insistez pour que vos utilisateurs aient activé Javascript, vous devez fournir un niveau d'expérience décent aux utilisateurs non-js, sinon ils ne reviendront jamais volontiers.