Malheureusement, certaines fonctionnalités importantes, très faciles à
implémenter en Ajax, s’avèrent un vrai calvaire à intégrer sans JS.
Il s’agit là d’un aspect très mal géré par Ruby on Rails : Il est
effectivement très simple d’ajouter du comportement Ajax dans un site
web. Mais qu’en est-t-il de l’accessibilité ? Alors que du coté
serveur, RoR encourage une séparation nette entre les modèles, la
présentation et le contrôle. Il n’existe rien en standard coté client.
Pire, les helpers par défaut vont généré du code mélangeant
allègrement le contenu (html), la présentation (css) et le
comportement (javascript). Ce qui a mon sens va à l’encontre des
bonnes pratiques du web!
Comme le souligne Philippe, il faudrait effectivement développer un
site en se concentrant sur son contenu. La présentation et Ajax sont
bien sur des “plus” certes importants mais qui ne doivent pas être des
facteurs de limitation. Il ne faut pas oublier que faire un site
accessible, c’est faire un site qui sera visible et utilisable par
tous les utilisateurs : Les être humains avec ou sans handicap mais
également les agents logiciels tel que les moteurs de recherche…
Pour palier à ce comportement il existe des plugins pour sortir le
Javascript des pages HTML.
Ou tout a fait. Je pense en particulier à ‘LowPro’
Je n’est pas dit qu’il n’existait rien, mais que Rails par défaut ne
force pas une séparation coté client tel qu’il le fait coté serveur.
Pour palier à ce comportement il existe des plugins pour sortir le
Javascript des pages HTML.
Ou tout a fait. Je pense en particulier à ‘LowPro’
Je n’est pas dit qu’il n’existait rien, mais que Rails par défaut ne
force pas une séparation coté client tel qu’il le fait coté serveur.
Pour faire du JS proprement, il me semble élémentaire de l’écrire de
manière totalement non intrusive.
Et on a pas besoin de LowPro pour cela, juste d’une bonne connaissance
de Prototype (ça fait 2 ans que j’ai plus écrit une ligne de
javascript dans des templates HTML et je n’ai pas encore utilisé
LowPro, beaucoup moins nécessaire depuis prototype 1.6 et son DOM
Builder) ou de Mootools ou jQuery.
Venant du monde PHP (CodeIgnitor, un framework MVC léger), je trouve
l’approche de Rails à ce sujet particulièrement mal adaptée, surtout
avec le .rjs : générer du javascript en ruby, diable pourquoi faire ?
Pour ne pas utiliser les caches des browsers et ralentir l’affichage
des pages ? Pour ne pas avoir à apprendre le Javascript alors que vous
vous êtes déjà tapé tout RoR ?
Une bonne pratique est donc, comme cela a déjà été suggéré plus haut,
d’écrire une application RoR classique et fonctionnelle en HTML, puis
de créer un fichier .js par écran/view et ajouter les actions
correspondantes aux requêtes AJAX dans les controlleurs (avec
rendering en json ou en partial view HTML, selon que vous “buildiez”
votre DOM vous même ou que vous injectiez plutôt du HTML “prégénéré”.)
Le taux de support JS sur les appareils mobiles ne fera qu’augmenter,
c’est un faux problème. Par contre surveillons les performances.
Les utilisateurs de noscript whitelistent les sites intéressants qui
utilisent les JS (ils savent le faire, puisqu’ils utilisent FF avec
des plug-ins).
Ils cherchent surtout à se prémunirent des pop-ups, d’une façon un peu
rétrograde et assez inutile depuis les navigateurs à onglets. Chrome
est encore une avancée sur ce point, il résiste même bien à des sites
genre “rickrolled . fr” (à tester avec Chrome…)
Il reste aussi à savoir si les gens sans JS forment une cible
commerciale intéressante.
En définitive, ce débat me semble daté, Gmail&co ont mis un coup de
pied dans la fourmilière. Il n’est pas écrit dans le marbre que le web
doit se limiter à envoyer du contenu dans la fenêtre de l’utilisateur,
même si ce fut un temps une règle d’or suite aux excès des années
‘pops’
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
