| |
 |
Christophe Porteneuve
Directeur de spécialisation
INSIA |
|
Christophe Porteneuve (INSIA)
"Le couple JavaScript/Ajax est une alternative souvent viable à ActionScript"
Auteur d'un livre sur le développement Web de qualité, l'enseignant a répondu pendant une heure aux questions de nos lecteurs sur le Web 2.0, la sémantique, Ruby on Rails et les frameworks de développement.
13/12/2006 |
| |
 |
 |
Mettre "Web 2.0" dans son titre, ce n'est pas un peu dangereux côté crédibilité ?
Christophe Porteneuve : Ah, le grand classique... Il est vrai qu'aujourd'hui, ce terme est repris à tout bout de champ, sans beaucoup de compréhension.
Le concept de "Web 2.0" est pourtant loin d'être creux, et il a été largement développé par Tim O'Reilly quand il a co-inventé l'expression... Il s'agit surtout d'un pivot, d'un tournant dans l'utilisation du net.
C'est un phénomène essentiellement social, et légèrement technique dans le sens où il s'agit d'une combinaison de technologies préexistantes qui n'avaient pas forcément percé jusque-là.
Avant tout, "Web 2.0", c'est l'occasion de faire ce qu'on devrait faire à chaque nouvelle version :
corriger les erreurs de l'ancienne.
Ici, ce sont la soupe de balises, le balisage 0% sémantique, les CSS mal foutues, le JavaScript utilisé n'importe comment, etc. C'est pourquoi le vrai mot-clé du titre, comme le dit Tristan Nitot dans la préface, c'est "Bien développer", pas Web 2.0.
L'avant-propos met bien les choses au clair là-dessus :)
On entend déjà parler de "Web 3.0", "Web 4.0", etc. Le phénomène ne devient-il pas "tendance" et purement commercial ?
Pour le Web 4.0, sûrement.
Des titres de conférence comme "Le Web 3" sont également éminemment racoleurs.
Je préfère la définition de Fred Cavazza, qui en parle déjà sur son blog, et montre clairement une évolution dans l'utilisation et la nature des services.
C'est là aussi du social, pas tellement de la technique.
On a simplement une convergence de plus en plus forte entre "applis desktop" et "applis Web". Le jour où la frontière n'existera vraiment plus, où les usages seront les mêmes, où le poste individuel ne sera finalement qu'un nœud d'un Web "peer to peer" (ou à peu près), on aura atteint un vrai nouveau stade par rapport au "Web 2.0" existant.
| |
|
|
|
|
 "Le concept de 'Web 2.0' est loin d'être creux." |
|
On associe souvent Web 2.0 et Ajax. N'est-ce pas réducteur et/ou dangereux ?
Disons qu'il n'y avait pratiquement pas d'Ajax dans le "Web 1.0", celui des applications Web "à l'ancienne", et surtout dans lequel l'internaute n'était pas réellement participatif.
Inversement, une application Web moderne qui n'a aucun besoin d'AJAX est assez rare (mais pas du tout inconcevable).
Je pense que les deux concepts sont étroitement liés, mais pas identiques.
"Bien développer", ça veut dire qu'avant on développait mal ?
Absolument !
Et oui, c'est une opinion très forte, très en phase d'ailleurs avec certains univers de développement, genre Ruby On Rails.
Tous les phénomènes universellement décriés que j'ai indiqués tout à l'heure (soupe de balise, mise en page par tableaux, CSS mal fichues, JS propriétaire, DOM mal employé, document.write, etc.) sont mal. A tous points de vue...
Le Web 2.0, c'est aussi faire les choses bien, quand on sait enfin quelles sont les bonnes approches.
Si vous faites déjà un site statique en XHTML 1 Strict, sémantique, avec des feuilles de style alternatives en CSS 2.1, des méta-données DCMI, etc., vous êtes très "Web 2.0" à mon sens :)
Se reposer sur un framework, est-ce vraiment bien développer ?
Tout dépend du framework :)
Si le framework, ou la bibliothèque, est vraiment axé(e) sur de bonnes pratiques, on va dans le bon sens. Plus le framework est contraignant, d'ailleurs, et moins on a le choix : il faudra obéir aux règles qu'il impose, donc si celles-ci vont dans le bon sens, on a moins tendance à être "sale".
Ruby On Rails, par exemple, adopte une approche détaillée, cohérente, et qui suit rigoureusement des principes comme DRY (Don't Repeat Yourself), MVC (Modèle-Vue-Contrôleur), etc. Y faire autre chose devient compliqué, tandis que suivre ces préceptes est trivial : on a tendance à les suivre, et c'est tant mieux, je trouve.
Travailler sans framework, ou sur un framework qui est fondé sur des idées clairement "sales" ou "dangereuses", au vu des métriques de qualité établies, ce n'est pas faire un travail de qualité.
Et bien sûr, pour des micro-besoins, travailler sans framework n'empêche pas de travailler bien :)
| |
|
|
|
|
"Le Web 2.0, c'est aussi faire les choses bien, quand on sait enfin quelles sont les bonnes approches." |
|
Le Web 2.0 permet-il de faire des sites accessibles ?
Pas plus qu'avant. Presque au contraire, même.
On associe Web 2.0 à des pages hautement dynamiques, avec du JavaScript, de l'AJAX, etc.
Ces technologies posent de nouveaux challenges d'accessibilité.
Par exemple, quid d'un utilisateur dont le navigateur n'a pas JavaScript, ou ne l'a que partiellement ?
Quid s'il a l'habitude d'utiliser les boutons Précédent/Suivant ? S'il veut bookmarker une page qui n'est en fait qu'un état transient d'un processus plus global ?
On a déjà toutes les problématiques d'accessibilité connues avec XHTML, CSS et JS, qui sont souvent mal gérées. Mais en plus, celles d'AJAX.
Ceci n'est pas un gouffre : il existe des solutions, de bonnes pratiques, pour tous ces problèmes.
Mais il est clair qu'obtenir un niveau WAI-AAA, par exemple, pour un site hautement "AJAXifié", n'est pas une mince affaire.
En revanche, les avantages sont énormes.
Le secret, c'est d'adopter une approche "progressive enhancement" [ndlr amélioration progressive], comme l'appelle Jeremy Keith, en gros, du bottom-up [ndlr de bas en haut] :
on commence par une page XHTML Strict sémantique sans aucun style, histoire d'assurer un bon contenu et une bonne accessibilité sans CSS, ou avec des lecteurs d'écran, etc.
On ajoute les styles correctement.
On gère toute l'interaction client/serveur sans aucun AJAX.
On ajoute le JS en "unobstrusive" [ndlr non obstrusif]...
Et enfin, on redirige les envois GET/POST usuels vers de l'AJAX quand c'est pertinent, toujours en "unobstrusive".
Mon bouquin parle longuement de toutes ces pratiques, dans les chapitres idoines (2 pour JS, 3 pour les événements et le DOM, 6/7 pour AJAX, les effets visuels, le glisser/déplacer, l'ergonomie, etc).
Quels sont donc les "bons frameworks" ?
Moi je suis absolument accroc de Ruby On Rails, évidemment.
Après tout, j'étais conférencier à Paris On Rails, et je suis contributeur à RoR, Prototype et script.aculo.us... ça se voit donc un peu :)
D'une manière générale, un bon framework pour des applis Web va tenter de mettre en avant un maximum de bonnes pratiques établies, par exemple le MVC, l'unobstrusive JS, le balisage sémantique, la factorisation de code (principe DRY), etc.
On trouve aujourd'hui des frameworks pour de nombreux langages qui cherchent à émuler ce qu'ils ont trouvé bien dans RoR, donc on n'est pas 100% obligé de faire du Ruby pour avoir un bon framework.
Par exemple, on a TurboGears avec Python, ou Symfony sur PHP.
Notez aussi au passage que Prototype et script.aculo.us n'exigent pas d'avoir Rails côté serveur.
Bref, prenez le temps de vous documenter sur les choix d'architecture et de conception d'un framework.
| |
|
|
|
|
"Les bonnes pratiques que promeut le Web 2.0 vont toutes dans le sens d'une efficacité accrue" |
|
Ne pensez-vous pas que le Web 2.0 est trop consommateur de ressources ?
C'est plutôt l'inverse.
Avec AJAX par exemple, on peut ne plus réaliser que des micro-échanges avec le serveur, une fois la page principale obtenue.
Par ailleurs, un site Web 2.0, comme je l'ai dit, est un site qui obéit aussi à un balisage XHTML Strict, sémantique, et bien stylé.
Or on sait pertinemment, via de nombreuses études de cas très concrètes, que cela réduit énormément la consommation de bande passante, par rapport à un site codé "à l'ancienne".
Même côté ressources humaines, cela veut dire un seul contenu à maintenir, pour une grande variété de débouchés (navigateur sur PC, téléphone mobile, PDA, SMS, etc.)
Les bonnes pratiques que promeut le Web 2.0 vont toutes dans le sens d'une efficacité accrue, et d'une baisse de la duplication d'effort, donc aussi de ressources, à tout point de vue.
En revanche, ça consomme peut-être trop de forêt amazonienne, vu la quantité de bouquins, parfois creux, sur le sujet :) Mais le Web 2.0, c'est aussi l'avènement de l'e-publishing :)
Y'a-t-il d'autres usages à Ajax que celui de "charger les données sans recharger la page" ?
Eh bien, l'usage que vous donnez est en fait un concept technique. Mais il donne de nombreuses utilisations métier, très variées.
Par exemple, il permet aussi, simplement, de sauver automatiquement vos saisies à la volée (agencement des briques dans un portail personnalisable, réponses à un QCM présentant toutes ses questions d'un coup -- donc tolérance à la panne), etc.
Il permet aussi l'auto-complétion, par exemple,
façon Google Suggest, ou la recherche de station sur le site de la RATP.
Il permet également une sorte de push (ou de pull, suivant l'optique :) ), avec des contenus qui apparaissent "spontanément" (là, c'est consommateur de ressources, en revanche).
Comme toujours, on a une techno, et de nombreux usages innovants.
Après tout, XMLHttpRequest, le coeur technique d'AJAX, existe depuis 1999 ! Et on commence à peine à imaginer l'horizon de ses emplois !
| |
|
|
|
|
"Le marché de l'emploi Rails est très, très vif outre-Atlantique, et émergent en France." |
|
Rails a l'air sympa, mais comparé à Java c'est plutôt un gadget, non ? On peut faire de GROS sites avec ?
Oui !
D'ailleurs, il y en a : chez Amazon, chez NouvelObs, chez le Figaro, chez 43things/people/places...
Rails monte en charge pour de vrai, on a des études de cas détaillées là-dessus. On commence aussi à avoir l'expertise...
En revanche, par rapport à l'univers J2EE (que je connais très bien), on est plus dans la même cour en termes de facilité de développement.
Qu'un framework soit facile ne veut pas dire qu'il est gadget (sinon, on retournerait tous faire de l'assembleur, pour se sentir "un vrai développeur") ;
Cela veut dire qu'on peut passer du temps sur les fonctionnalités, au lieu de nourrir le framework à coup de cuillères Bledina saveur XML pour qu'il accepte de dire "Bonjour, monde".
Aujourd'hui, regardez un peu le temps de test d'un ajout d'une ligne de code dans un contrôleur Struts, ou même dans du Spring ! Il faut une machine avec 2Go de RAM, et attendre, dans le meilleur des cas, 30" le temps que XDoclet nous remette tout à jour, recharge le conteneur, etc.
C'est ahurissant.
Rails a encore des points faibles, c'est certain (on pense notamment à l'internationalisation/localisation/globalisation), mais il progresse à pas de géants, et la quantité des plugins disponibles est impressionnante.
Ruby on Rails est-il facile à apprendre ? Y'a-t-il un marché de l'emploi pour ce framework ?
Rails est extrêmement simple à apprendre, mais il faut arriver à laisser de côté ses habitudes externes (venant de Java, J2EE, PHP, etc).
En Ruby plus que partout ailleurs, il faut apprendre à écrire du code idiomatique, qui respecte les idiomes du langage, et du framework. Il existe heureusement de nombreuses ressources en ligne axées là-dessus (The Ruby Way, The Rails Way, etc.)
Quant au marché de l'emploi, il est très, très vif outre-Atlantique, assez vif en Europe, et émergent en France. Mais à titre de comparaison :
il y a un an, nous ne voyions qu'une offre d'emploi tous les 6-8 semaines sur RailsFrance.org.
Aujourd'hui, c'est plutôt 2-3 par mois.
On approche du coude de la courbe exponentielle ; 2007 sera, je pense, l'année du décollage français de Rails.
| |
|
|
|
|
"Ruby On Rails adopte une approche détaillée, cohérente, et qui suit rigoureusement des principes comme DRY, MVC, etc.
" |
|
Mais lorsque l'on doit plutôt s'inquiéter de ce que verra l'utilisateur final, vue l'étendue des navigateurs et de leurs approximations d'interprétation, n'est-ce pas un peu élitiste ou illusoire de développer ainsi ?
Il faut surtout que le client comprenne que l'ère du pixel-perfect est révolue. De très grandes agences comme Cosmic ont bien intégré ça.
L'internaute peut bidouiller la page comme il le souhaite aujourd'hui. Armé d'un navigateur moderne (Opera, Safari, Konqueror, Firefox...) voire d'extensions comme Greasemonkey et Platypus, il pourra jouer comme il veut !
Il y a une raison pour laquelle la spécification CSS mentionne explicitement la notion de "feuille de style utilisateur" partout.
C'est évidemment difficile à vendre aux rébarbatifs.
Je vais passer pour un doux illuminé, mais : si vos clients sont incapables de suivre le mouvement, n'en faites pas vos clients. Vous entrez dans une grosse galère.
Trouvez-en d'autres : le marché est très, très vaste. Et les plus juteux ne sont pas forcément les plus obtus, loin de là.
Et puis, maintenant qu'IE a corrigé les incontournables en CSS, on va un peu mieux... Il ne lui reste plus qu'à corriger les incontournables JS et DOM, d'ici 2040 sans doute.
Oui, mais comme qui dirait, "le client est roi", l'ère du pixel perfect est toujours d'actualité, et a encore beaucoup de temps devant elle.
J'en doute un peu.
Le pixel-perfect n'est tout simplement plus faisable.
Techniquement, je veux dire.
Le Web 2.0, c'est justement "internet aux mains des internautes". Vouloir contrôler au pixel près ne laisse que 2 possibilités :
- Flash
- Le retour aux publications papier.
D'autre part, le pixel-perfect va explicitement à l'encontre de l'accessibilité, puisqu'il exigera des tailles de police en unités non relatives (ex. px), qui d'ailleurs ne garantissent pas un rendu fixe (certains navigateurs accepteront quand même de "zoomer"). Or, la conformité aux référentiels d'accessibilité de type WAI est aujourd'hui obligatoire pour pratiquement tout site de service public, institutionnel ou gouvernemental en Europe, et dans une portion sans cesse croissante du secteur privé (notamment pour tout sous-traitant dans le cadre d'un contrat gouvernemental, etc.). Ça ne cesse de gagner du terrain, et ce sont les contrats les plus juteux, souvent ! Exiger du pixel-perfect aujourd'hui, c'est être descendu du train web en marche il y a plusieurs années déjà, et se fossiliser doucement, tout en marginalisant une partie énorme des utilisateurs.
Ajax et le référencement, est-ce vraiment incompatible ?
AJAX n'enlève strictement rien au potentiel de référencement d'un site.
Ce qui fait la force d'une page côté référencement, c'est la qualité de son balisage.
Tous les experts SEO (Search Engine Optimization) qui savent vraiment de quoi ils parlent vous le diront.
| |
|
|
|
|
"XMLHttpRequest, le coeur technique d'AJAX, existe depuis 1999.
" |
|
Le Web 2.0 implique de manipuler le DOM. Mais de gros problèmes de compatibilité subsistent selon le navigateur utilisé. Existe-t-il des librairies "cross-browser" complètes pour pallier à ces problèmes ?
Oui : Prototype.
Et bien d'autres, j'imagine, mais je suis moins au fait techniquement de Dojo, Mochikit, OpenRico et les autres.
Dojo est trop épais pour moi, c'est un "JsDK", comme je l'appelle. C'est trop lourd, tout simplement.
(j'oubliais de mentionner YUI, de Yahoo!, et GWT, de Google).
OpenRico a visiblement quelques soucis de compatibilité, pour le moment...
Prototype a totalement lissé, pour moi, très concrètement, les problématiques cross-browser en CSS, DOM et gestion événementielle.
Vu son poids (< 70Ko avant zipping/jsmin/etc.), je suis ravi.
Mon bouquin illustre tout ça très concrètement, aux chapitres 3 et 4.
Qu'en est-il de l'utilisateur? Il entend parler de Web2.0 partout, et ne voit rien, les nouveautés sont essentiellement internes, pourquoi un tel "tapage" ?
Internes ? Non, je ne dirais pas ça du tout.
C'est un changement dans les usages, justement. Pour l'interne, on parle de "respect des standards", un phénomène qui a donné au Web 2.0 son point d'essor.
Mais le glisser-déplacer, l'auto-save, la complétion automatique, les effets visuels cross-browser, la modification in-situ, etc. font le Web 2.0.
Regardez simplement l'utilisation de Google Agenda : c'est un showcase Web 2.0, on y trouve tout cela, utilisé de manière très intelligente, très pertinente.
Une telle application, tout comme Google Spreadsheet, Netvibes et d'autres, est tout simplement inconcevable du temps du Web 1.0.
Maintenant, il reste évidemment beaucoup de bruit, de tapage marketing plutôt creux, comme chaque fois qu'on sort quelque chose.
Un peu comme aujourd'hui autour de SOA (Service-Oriented Architecture) et des ESB (Enterprise Service Bus), mais je vais éviter d'entrer en croisade sur ce sujet dans ce chat :)
| |
|
|
|
|
"AJAX n'enlève strictement rien au potentiel de référencement d'un site.
" |
|
Les applications JavaScript peuvent-elles tenir une charge équivalente à des applications métier ?
Bien sûr.
D'ailleurs, une application "métier" ne sous-entend aucune techno précise.
Tout dépend de la connectique et de la pertinence de l'architecture des échanges client/serveur.
Côté client, la richesse de l'interface utilisateur est aujourd'hui équivalente, qu'on utilise YUI, GWT, qooxdoo, XUL...
La prochaine version de Firefox, due au premier semestre 2007, intégrera les avancées de la machine virtuelle JavaScript venue d'Adobe, qui va encore booster très sensiblement les performances de JavaScript.
Ensuite, si la connectique suit, tout va bien. De ce point de vue, réaliser des échanges AJAX sur des formats légers (donc pas XML...) comme JSON, permet justement d'économiser la bande passante...
Le dernier site Gucci est fait en ajax / library javascript. Le Web2.0, c'est la revanche du javascript sur l'actionscript ?
Oui, il est d'ailleurs réalisé par Wollzelle, et notamment par Thomas Fuchs, le papa de script.aculo.us :)
Je pense que c'est en effet une alternative souvent viable à ActionScript, au sens où elle permet de se reposer sur des technologies beaucoup plus accessibles - notons cependant que Flash fait de plus en plus d'efforts pour l'accessibilité, mais le temps que les logiciels clients, comme les lecteurs d'écran, suivent...
J'appelle cette évolution de mes vœux, car je suis personnellement plutôt en mauvais termes avec Flash :) Mais c'est strictement une question d'esthétique de code personnelle :)
Le Web 2.0, n'est-ce pas prendre le Web et son protocole HTTP pour ce qu'il n'est pas ? N'arrive-t-on pas à une utilisation abusive du protocole HTTP ?
Au contraire, on a jusqu'ici sous-utilisé HTTP. On n'a utilisé que deux méthodes (GET et POST) sur 6.
L'émergence très forte des APIs REST, qui visent justement à utiliser pleinement HTTP, est un signe très fort de ce virage.
Il suffit de voir comme de nombreux très gros acteurs, comme Flickr ou Amazon, mettent en avant la version REST de leur API par rapport à la version WS-* / XML-RPC.
Notez aussi l'émergence forte des microformats, qui utilisent souvent HTTP de façon riche (ex. AHAH).
| |
|
|
|
|
"Le secret d'un site Ajax accessible, c'est d'adopter une approche progressive enhancement." |
|
Suffit-il de mettre de l'Ajax sur son site pour être Web 2.0 ?
Absolument pas.
Ici comme partout, il faut se garder de coller une techno juste pour l'ajouter sur la pub du produit. Il faut utiliser la techno de façon pertinente.
Le Web 2.0 se soucie avant tout de bonnes pratiques et d'usages plus riches, pour un auditoire aussi large que possible. Cela passe par exemple par une meilleure accessibilité.
Et puis les stigmates traditionnels du Web 2.0, visuellement (coins ronds, réflexions, gradients, onglets bichromatiques, etc.) n'ont rien à voir avec AJAX :)
Est-ce possible de développer un jeu PHP / Ajax qui n'est pas trop gourmant en ressources ? Faut-il utiliser un framework ?
C'est bien entendu possible.
Tout dépend de l'intensité du gameplay.
Si c'est un morpion, un jeu de bataille navale, un démineur, un jeu tour par tour, etc. aucun problème.
Mais n'envisagez pas de faire World Of Warcraft ou Dark Ages of Camelot... On n'a pas la couche graphique portable nécessaire côté client.
Quant aux échanges, ça reste du réseau, et la montée en charge est soumise à la même règle fondamentale : la qualité de conception des échanges dans le protocole.
Côté framework, tout dépend de l'utilisation. Si c'est un projet vaste, un bon framework aidera clairement en vous évitant d'avoir à réinventer la roue à chaque coin de rue.
Votre livre sur le Web 2.0 s'adresse plus aux initiés ou aux amateurs ?
Quiconque a des connaissances de base en HTML (et idéalement en CSS) en tirera pleinement profit. Même pour les vrais débutants, s'ils sont malins, les annexes A et B suffiront amplement.
Avoir fait un poil de JS avant aide aussi, car je ne reprends pas toutes les bases. Mais un autre langage (même le C ou le Java) suffira aussi.
Il n'y a absolument pas besoin d'être déjà un cador :)
Ça rapporte, d'écrire un livre technique ?
En France ? En Français ? Non.
Pas financièrement en tout cas.
Ou si peu... Lorsque le livre devient un best-seller, une référence (on pense au PHP5 Avancé de Daspet et al., ou au CSS 2 de Raphaël Goetter), oui, ça rapporte un peu. L'équivalent, sur l'année, de +20/30% de salaire. Pas de quoi devenir millionnaire :)
En revanche, je voulais faire bénéficier le plus grand nombre d'un ouvrage clair, mettant en avant exclusivement de bonnes pratiques, un ouvrage pour bien développer. Le plus grand nombre en France, car on a déjà beaucoup de choses en anglais, mais les informaticiens français souffrent trop souvent d'anglophobie...
D'où ce livre.
Ceci dit, le prochain comble un manque global, il devrait donc être en anglais...
Christophe Porteneuve :
Merci à tous d'être venus et d'avoir participé à ce chat. J'espère que ceux qui utiliseront le livre y trouveront énormément de bonnes choses. |
| |
Propos recueillis par Xavier Borderie, JDN Développeurs |
|
|
PARCOURS
|
|
 |
| |
Christophe Porteneuve, 29 ans, est directeur de spécialisation à l'INSIA
2002 Directeur de spécialisation à l'INSIA
1998 Directeur R&D chez Posse42
1999 Architecte Portail chez Freesbee
1998 Ingénieur PSO chez Borland
Et aussi membre actif des communautés Open Source Mozilla, Prototype, script.aculo.us et Ruby on Rails.
|
|
|
|
Dossier 
