HTML5 et le Web ouvert, pour les aigris et les cyniques


L’actualité récente autour de HTML5 a fait réagir beaucoup de développeurs, ce qui à tout le moins permet d’avoir un instantané des opinions de la communauté Web. Elle vont de l’inutilité d‘avoir un logo aux affirmations du type “HTML5 ne me concerne pas car je supporte IE6”. Ceux qui participent au débat sont soit enthousiastes soit aigris par la réalité de leur travail. Ceux qu‘on ne voit pas parler sont les blasés. Ce post d‘opinion, plutôt inhabituel sur ce blog technique, s‘adresse à ces 2 dernières catégories : pourquoi soutenir ou même s‘intéresser à l‘extension des technologies du Web en général, et au mouvement HTML5 en particulier ?

Un peu de machiavélisme

Mettons de côté les principes philosophiques d’un web ouvert : soit vous y adhérez déjà par principe, soit ça vous en touche une sans faire bouger l’autre auquel cas il est bon de se rappeler ce que le Web ouvert peut vous apporter personnellement.

Ca n’appartient à personne

On peut remercier Apple pour nous avoir démontré avec Objective-C et les applications iOS tous les désavantages liés aux langages et processus de distributions fermés. C’est un succès commercial et les utilisateurs sont heureux, alors pourquoi est ce que les développeurs joueraient les rabats-joie ?

  • Outils et langage imposés, parfois payants
  • Une autorité arbitraire peut décider unilatéralement que votre application ne sera pas visible ou doit fermer
  • La même autorité peut décider que votre business model ne lui convient pas (voir le cas de la presse belge)
  • Si la communauté est petite, la formation sera chère. Les infos pour développer sur iOS sont monnaie courante, mais il est difficile de trouver des infos pour les autres plate-formes

Le multi-plateforme arrive

Ca m’ennuie de le reconnaître, mais le Web à partir du bureau devient l’exception plutôt que la règle, en particulier lorsque l’on regarde les statistiques mondiales. Depuis plusieurs années déjà il y a plus d’internautes sur mobile que sur bureau, et dans les pays en voie de développement c’est même l’unique usage du Web. Certes pour ces pays ça n’est pas du smartphone mais ça viendra. Dans l’occident, l’usage du Web depuis différents terminaux est maintenant courant et se fait selon la fonctionalité et les conditions pratiques : le mobile pendant les pauses, les éventuels trajets ou le soir au lit pour vérifier son facebook et ses mails, le PC au bureau et à la maison pour du e-commerce par exemple.

Hors dans l’ère pré-iPhone il fallait savoir coder en java ou pire dans des langages propriétaires pour faire des applications. Apple a imposé l’Objective-C, Android et d’autres sont restés sur java. Je n’ai rien contre java, mais pourquoi j’apprendrais un nouveau langage si j’ai la possibilité de capitaliser sur ce que je connais déjà ? Et quelles sociétés hormis les pages jaunes peuvent se payer de construire et maintenir la même applications sur une dizaine de plate-formes mobiles différentes ?

Il est déjà possible de construire des applications Web qui tournent très bien sur la majorité des webkits mobiles, et aujourd’hui ces sites-applications peuvent se passer d’une connexion au net (Offline, Web Storage), peuvent parfois avoir accès aux capacités matérielles du mobile (la géolocalisation) et peuvent être “installés”.

Le W3C est en train de spécifier de quoi accéder à beaucoup plus de matériel (SMS, contacts, caméra, fichiers locaux …), avec le concours de Nokia, Ericson ou Vodafone. Il y a donc un espoir pour qu’une application Web ait les mêmes possibilités qu’une application native. Pousser dans le sens des standards du Web, c’est donc aussi se donner la possibilité de pouvoir changer de branche ou d’utiliser la même équipe de développeurs pour faire du Web desktop, mobile et de l’applicatif mobile.

La concurrence, c’est bon, mangez en

Pourquoi les technos du Web devraient elles s‘attaquer au mobile voire au software ? Il existe déjà de très bons langages avec de très bons frameworks et de très bons développeurs dans ces domaines. Sauf que le manque de concurrence dans la technologie est très dangereuse, même si elle entraîne des difficultés pour les développeurs. Souvenez vous comme c‘était pratique pour les développeurs Web de voir IE6 gagner la première Browser War. En ces temps heureux pendant 1 ou 2 ans, beaucoup ont eu le sentiment qu’ils pouvaient ne tester qu’un seul navigateur et ignorer les autres (Safari Mac, Lynx …). Et puis Firefox est arrivé, a grandi et a forcé Microsoft à s’engager, négocier puis bientôt respecter les standards du Web. Le projet Webkit a survécu et a facilité l’arrivée de Chrome et des Webkits sur mobiles. Opéra a testé un business model et a fourni de bonnes idées à tout le monde.

Bref la concurrence entre navigateurs a fait que l’expérience utilisateur en général s’est améliorée. La situation pour les développeurs Web s‘est compliquée d‘une certaine manière, puisqu‘il y a une bonne dizaine de navigateurs à tester. Cette complexité est compensée par la maturité grandissante des développeurs et des librairies. Que se serait il passé si Microsoft était resté à 90% de part de marché ces 10 dernières années ? L‘accès aux technos du Web serait sans doute plus complexe (essayez de lire la MSDN), voire payante comme l‘est le développement iOS.

Même en regardant le processus d‘écriture des specs, le fait d‘avoir 2 organisations a déjà eu des effets positifs, et on espère que l’émulation va continuer. Après le schisme de 2004, le WHATWG (originellement Apple, Mozilla et Opéra) avait travaillé sur ces spécifications :

  • WebForms 2, qui améliore l’interface des formulaires natifs
  • Web Storage, pensé comme un super cookie
  • Web Socket et Server Sent Event qui permettent une communication plus efficace entre le client et le serveur

En résumé : ils se sont concentrés sur ce qui pouvait être utile aux développeurs d’application Web dans l’immédiat et se sont lancés dans le même temps dans l’implémentation dans les navigateurs. On n’est peut être pas dans la révolution technologique (les formulaires sont émulables en Javascript, le reste avec Flash), mais cette marche forcée du HTML vers les “applications Web” est très positive, car elle nous donne plus de pouvoir, et certaine API comme “Web Workers” sont très innovantes.

Un peu de pragmatisme

En attendant le mobile, voyons déjà ce qu’on peut faire des nouveautés sur navigateur desktop, avec notamment les apports de HTML5. Ce qui compte pour un développeur au moment de faire ses choix techniques, c‘est l‘état d‘implémentation de chaque API JavaScript par les navigateurs ou, pour la partie sémantique, de savoir quels sont les user-agent qui savent exploiter le nouveau balisage.

Sémantique

Côté sémantique, la politique des lecteurs d‘écran est probablement la même que celle du moteur Google : s‘adapter à ce que font la majorité des sites (source : un community manager de Google). Si les webmasters se mettent à utiliser nav ou article, ils suivront. Les navigateurs seront sans doute un peu plus pro-actifs pour proposer des fonctionalités tirant parti de l‘analyse des balises (un lecteur d‘article comme Safari par exemple). Dans les 2 cas, suivre les balises standards (et éviter d‘en inventer) c‘est se donner une longueur d‘avance sur les concurrents pour un coût de développement négligeable.

les APIs

Côté APIs (Web apps selon le WHATWG) il ne faut pas prendre HTML5 comme un bloc mais partir de la fonctionnalité souhaitée et regarder quelles sont les APIs qui peuvent vous être utiles. La plupart du temps, la fonctionnalité est simulable en JavaScript ou en Flash, et un certain nombre de petites librairies (ou polyfills, si l‘usage du terme prend) permettent d‘y accéder sans trop de problèmes. L‘intérêt fonctionnel est de proposer une meilleure expérience à la moitié de vos utilisateurs qui ont des navigateurs au niveau, et une fonctionnalité qui marche pour les autres.
Au niveau du code, les spécifications n‘étant pas réservées aux implémentation navigateur, l‘API est généralement également suivie par ces polyfills. Lors d‘un changement de projet, de librairie, ou lorsque vous passerez à l‘utilisation exclusive de la fonctionnalité en natif, vous retrouverez les mêmes signature de fonction et la même structure de code.

J‘ai fait une conférence entière à Paris Web 2010 sur ce sujet, je vous invite à regarder les slides pour vous forger une opinion sur le déploiement possible en production.

Mais que faire John ?

Au niveau individuel, pour aider à tout cela, c‘est autant une affaire d‘expertise technique que de savoir vendre en interne ces technologies. Formez vous, faîtes votre veille techno, participez aux réunions produit ou faîtes des démos en interne utilisant vos nouvelles connaissances : ça égaie le travail et vous donnera l‘impression salutaire d‘être un peu plus qu‘un cracheur de code.
Un engagement un peu plus fort pourrait aussi consister à signaler des bugs aux navigateurs, à ceux qui font des librairies open-source ou des outils vous permettant de transposer vos compétences Web sur mobile ou desktop.
Enfin vous pouvez également contribuer au code open source ou participer aux discussions W3C ou WHATWG, ils sont réellement dans l‘attente des avis des développeurs Web pour progresser!

Au niveau de la communauté, je pense qu‘une initiative du W3 comme ce logo reste positive, tant que la discussion avec la communauté est ouverte (le logo ne sera officiel que début 2011) et que le message n‘est pas brouillé (une phrase heureusement retirée incluait CSS3, WOFF et SVG dans HTML5). Beaucoup de développeurs seront heureux d‘avoir une bannière à laquelle se rallier et tant pis pour ceux qui accusent le W3C de vouloir faire du marketing. Demandez à la fondation Mozilla si le marketing sert ou dessert la cause du libre.
A propos de brouiller le message, je ne pense pas que la décision du WHATWG d‘abandonner HTML5 et de parler de “living standard“ et de “web application” soit la bonne. Concernant le terme HTML5, on pourra se limiter à la spec du W3C, préciser quelles APIs on y inclue ou bien en parler à tort et à travers : comme “AJAX”, tout est fonction de votre interlocuteur.

Conclusion

Pourquoi pousser dans le sens du Web ouvert notamment avec HTML5 et les APIs associées ?

  • pour jouer le jeu de la concurrence et placer le tryptique Javascript/HTML/CSS  au backend, dans des applications de bureau ou sur mobile
  • pour les sociétés du Web, la possibilité de ré-utiliser les compétences et les outils en interne pour attaquer d’autres domaines
  • pour les développeurs, plus de possibilités de carrière, plus de nouveautés, bref que du bonheur
  • l‘accès à de nouvelles fonctionnalité est plus facile, ce qui permet d‘avoir une longueur d‘avance sur les concurrents
  • les standards même en construction facilitent la réutilisabilité et la maintenance du code

11 commentaires vers "HTML5 et le Web ouvert, pour les aigris et les cyniques"

  1. 01/29/2011 - 23:46 | Lien permanent

    Bonjour,

    Je suis passé, il y a à peu près 1 an, de “HTML5 ne me concerne pas car je supporte IE6” à “HTML5 me concerne car je ne supporte pas IE6”. (à près au moment où Google via youtube a décidé d’arrêter le support d’IE6, argument d’autorité !)

    +1 pour ça : « Formez vous, faîtes votre veille techno, participez aux réunions produit ou faîtes des démos en interne utilisant vos nouvelles connaissances : ça égaie le travail et vous donnera l‘impression salutaire d‘être un peu plus qu‘un cracheur de code. »

    Enfin une minute de silence pour les WebSocket… espèrons qu’une technologie « mode connecté » sorte dans pas trop longtemps.

  2. 01/30/2011 - 19:24 | Lien permanent

    Sans être ni aigri ni cynique, il faut avouer que le rapport signal/bruit sur le sujet n’est pas encourageant. Le récent embrasement autour d’un simple logo est symptomatique.
    Par ailleurs, de nombreux blogs|sites se sont montés pour surfer sur la vague, en se focalisant sur l’aspect cosmétique et en occultant totalement les fonctionnalités majeures (selon moi).
    Concernant l’ouverture et les standards, amen.

  3. 01/31/2011 - 09:14 | Lien permanent

    Comme toute nouvelle technologie, il y a deux vitesses :

    - le côté privé où l’on peut s’amuser à temps perdu (je me suis amusé sur mon site personnel à utiliser la balise vidéo, les nouvelles balises, etc.)

    - et le côté pro où l’adoption des nouveautés se fait petit à petit. Néanmoins, les cas d’utilisation concrète de HTML5 commencent à faire leur arrivée au travail : la balise vidéo entre autres (carte de voeux, présentation/teaser d’un site, etc.). Le discours est passé de « On utilise Flash, on se fera moins ch… pour la vidéo » à « ok, on utilisera Flash uniquement pour IE, les autres navigateurs afficheront la balise vidéo. ». Le markup va entrer plus lentement, notamment à cause d’IE 6/7/8 : je me vois pas encore dire aux clients : si vous avez IE sans JS, point de salut. Mais de petites expérimentations sont tentées en interne, on s’amuse et c’est intéressant.

    Ceci dit, c’est vrai qu’il y a un gros buzz autour de HTML5, et il y a beaucoup de bruit… ceci dit, c’est le propre du web : personnellement, je m’en amuse et j’ignore tout ce bruit, et après le buzz, nous verrons bien ce qu’il restera.

  4. 02/04/2011 - 10:34 | Lien permanent

    @ jpvincent : c’est plus une question d’éthique, je ne me vois pas imposer ça justement pour nourrir un buzz… sous prétexte que c’est hype.

    Je trouve ça malhonnête intellectuellement : sous prétexte que c’est IE et qu’on aime pas, on va dire « ok on peut ignorer cette case ‘IE sans Javascript’ », et quand ce sont les autres navigateurs, on va dire « mon dieu, on ne peut pas les ignorer »… y a un léger fond de mauvaise foi… même et surtout si c’est pour la bonne cause.

    Qui plus est, quand c’est un client qui a un parc dépassé d’IE6 avec du Norton tout pourri qui bloque le Javascript (y en a !).

    Mais par contre, je préfère donner envie en montrant les possibilités petit à petit et laisser doucement les clients venir (notamment grâce aux vidéos lisibles sur iPhone et consorts sans flash, c’est une excellente porte d’entrée que j’ai utilisée avec succès à plusieurs reprises). Si le client réclame ou évoque ce genre de possibilité, on peut s’engouffrer dans la brèche.

    En effet, le jour où le bénéfice SEO sera évident (car l’accessibilité, le client s’en fout en général), on risque d’avoir une vague de demande de migrations. ^^

  5. 02/08/2011 - 11:33 | Lien permanent

    Après qu’on s’entende bien : ça ne tiendrait qu’à moi, je dirais à mes clients de rapidement se débarrasser d’Internet Explorer (je le fais régulièrement d’ailleurs dès qu’ils ont un problème avec, j’ai pas compté, mais Firefox a gagné des utilisateurs comme ça), et le problème serait vite expédié, ça serait HTML5 et navigateurs modernes pour tout le monde dans un monde idéal. :)

    Néanmoins si on veut passer à HTML5, autant le faire complètement : je me vois pas dire : « ok, on switche à HTML5… mais on refuse d’utiliser la balise nav pour que ça soit acceptable sous IE sans JS ». Je trouve que c’est un peu idiot.

    Pour mon site personnel par exemple, si on a un IE sans JS… patatrac, la navigation est totalement buguée. Après, j’assume totalement ce genre de problème sur mon site personnel qui me sert de labo-test (et j’imagine que le combo IE sans JS doit être plutôt rare dans mes visites), mais je ne peux pas faire comme si de rien n’était si un client me signalait ça pour une réalisation pro. ^^

    Style le garagiste : « écoutez, votre voiture est tombée en miette car vous avez acheté votre essence chez BP, et il faut que vous la preniez partout ailleurs ! ». Cela ne ferait pas très sérieux !

    Après, j’ai ouï dire qu’on pouvait faire du HTML5 sans JS qui marche sous IE, ça serait à étudier sérieusement : http://www.debeterevormgever.nl/html5-ie-without-javascript/

  6. 02/18/2011 - 12:44 | Lien permanent

    Tiens, si ça t’intéresse, j’ai testé la méthode ci-dessus avec succès, le compte-rendu est ici : http://www.nicolas-hoffmann.net/source/1360-HTML5-sans-Javascript-pour-Internet-Explorer-c-est-possible.html

    (je ne sais pas si je vais garder le code en l’état ou revenir au bon vieux Javascript pour HTML5)

  7. Spider9166's Gravatar Spider9166
    08/01/2011 - 18:26 | Lien permanent

    Un commentaire sur l’assimilation d’Apple à une « autorité »: Apple est une société commerciale, et dispose des mêmes droits qu’un simple épicier pour juger des produits qu’il expose dans sa boutique, et à quelles conditions il les expose.
    Rien à voir avec une autorité.

    HTML5 est (sera ?) une avancée, mais cela reste dédié au web, et pas comparable à des langages de programmation multi-usages.

  8. 08/01/2011 - 22:30 | Lien permanent

    Il ne me semble pas avoir dit qu’Apple était une autorité au sens où elle fabrique ou fait respecter des lois, par contre pour reprendre l’image de l’épicier, ils sont dans une position où ils sont pratiquement seuls dans le village, et tout monopole est dangereux.

    La partie HTML5 d’aujourd’hui, celle qui est en cours d’implémentation dans les navigateurs est certes dédiée au Web et cherche à rattraper les fonctionnalités qui existaient déjà avec des plugins. Mais très clairement la volonté affichée du consortium W3 est d’utiliser HTML/JS/CSS sur toutes les plateformes et pour tous les usages, surtout en dehors d’un navigateur de bureau. On peut faire tourner JS sur un serveur, développer des applications pour mobile et TV, utiliser chromeless pour déployer une vraie appli de bureau sur tous les OS ou il n’y a qu’à voir le battage que fait Microsoft autour du HTML5 qui sera utilisable pour faire des applications Windows 8.
    Il y a donc collision directe entre HTML5 au sens large et les langages déjà multi-usages. Et à vue de nez, HTML5 pourrait avoir autant de succès que Java ou C++

Laisser un commentaire

1 Trackback vers "HTML5 et le Web ouvert, pour les aigris et les cyniques"

  1. sur 01/30/2011 at 20:03