On entend chaque jour parler du HTML 5 comme de la nouvelle panacée, ce qui induit un certain nombre de distorsions dans la perception qu’ont les clients de ces technologies, tout comme celle des développeurs qui ont massivement commencé à l’utiliser.
Cet article a été publié à l’origine en anglais sur le site Gamasutra au mois de Septembre
Il y a plus de 2 ans, nous avons commencé à parler du HTML 5. Pour nous, certaines fonctionnalités du HTML 5 telles que canvas, audio et video étaient les aspects les plus attrayants de ses spécifications, car elles semblaient destinées à remplacer le Flash. Flash avait été notre outil de choix pendant plus de 10 ans car il marchait… la plupart du temps. Pour les entreprises de divertissement et de médias ainsi que les plate-formes de jeux, Flash était sans pareil. Bien sûr, il comportait des problèmes: failles de sécurité, API propriétaires, problèmes de performances, etc. mais c’était aussi une plate-forme simple à utiliser. Un processus simple pour une technologie puissante.
Tout allait pour le mieux dans le meilleur des mondes.
Jusqu’à novembre dernier, les développeurs Flash croyaient que les plate-formes mobiles allaient intégrer cette technologie. « Apple sera raisonnable », disaient-ils, « Flash marchera sur l’iPad 3 et l’iPhone 5 ». Pas parce que nous pensions que Flash était parfait, ou parce que nous n’aimions pas l’idée de l’HTML 5, mais parce que pendant plus de 10 ans nous avions goûté à ce qui se rapproche le plus d’un « standard ». On entend parler des « standards web » depuis des années, ce sont de magnifiques et poétiques concepts qui n’ont jamais vraiment éclos parce que les créateurs de navigateurs, de systèmes d’exploitation et de plate-formes avaient leur propre idée de ce qui était « standard » et de ce qui ne l’était pas. Pourtant, avec Flash, nous avions véritablement goûté à ce concept dont nous avions si longtemps entendu parler.
En octobre dernier, Adobe abandonna le web mobile et tout fût bouleversé.
Les chantres des standards web ont applaudi, et l’angoisse des développeurs Flash n’a fait que de s’accroître, depuis l’annonce d’Apple en 2010. Peu de temps après, il a semblé que tout le monde se ruait sur l’HTML5. Les développeurs Flash savaient qu’ils devaient évoluer, et les défenseurs des standards web avaient éliminé leur dernier obstacle. La renaissance HTML sans plugin avait commencé.
Mais alors quelque chose d’étrange arriva. Même si en disant « HTML 5 », nous parlions de canvas, video, audio, stockage local des données, géolocalisation et nouvelles balises, nous avons remarqué que les clients demandant du HTML 5 ne savaient pas du tout ce que cette technologie comportait. En parlant aux développeurs de jeux des spécifications HTML 5, certains n’avaient pas utilisé une seule de ses implémentations. Ils utilisaient des technologies traditionnelles comme l’HTML, le JavaScript, le DOM ou le CSS. En fait, dans de nombreux cas le seul élément HTML 5 qu’ils incorporaient étaient le tag audio, et la plupart du temps il se comportait de manière imprévisible. Alors que l’utilisation de spécifications HTML comme le Canvas ont augmenté sur les navigateurs mobiles devenus plus puissants, il était clair que le HTML signifiait beaucoup de choses pour de nombreux développeurs, et cela n’incluait que rarement les véritables nouveautés du HTML présentées par le W3C.
Alors, qu’est-ce que le HTML 5? La FAQ du W3C concernant le HTML dit ceci:
– Se référe à un ensemble de technologies qui forment l’Open Web Platform. Ces technologies incluent les spécifications HTML5 , CSS3, SVG, MathML, Geolocation, XmlHttpRequest, Context 2D, Web Fonts (WOFF) et d’autres. La délimitation de cette liste de technologies et informelle et change au cours du temps.
– Se réfère aux spécifications HTML5, ce qui, bien sûr, fait aussi partie de l’Open Web Platform.
Ce que nous avons appris suite à nos conversations et projets ces derniers mois, c’ est que pour celui qui ne suit pas cette technologie de près (ou plus précisément, le client qui a besoin de quelque chose tout de suite), « c’est tout du HTML 5″, et donc ils se réfèrent à l’Open Web Platform. Dans ce sens, HTML5 est autant une idée qu’une spécification précise, et cette idée de l' »Open Web Platform » s’est répandue comme une traînée de poudre, même si les limites qui la définissent n’ont jamais été plus obscures. Pourtant, ce qui est sûr, c’est que le lancement de cette tendance coïncide avec la critique d’Adobe Flash.
Qui a été invité à la fête de l' »Open Web Platform »? Bien sûr, HTML5, CSS et DOM ainsi que SVG, Web Workers, Web Storage, Geolocation et Web Sockets. Ensuite des technologies expérimentales comme la Web Audio API, Media Capture… et l’on ne fait qu’effleurer la surface au W3C. Nous devons également ajouter Javascript et WebGL, WebbKit, qui sont développés par d’autres organisations mais sont tout aussi importants.
Nous avons ensuite Modernizr, et la reine des API JavaScript, JQuery. JQuery est si populaire qu’il semble que de véritables religions se soient formées autour d’elle. JQuery comporte JQuery UI et JQuery Mobile. En fait, certains personnes nous ont dit que nous n’aurons jamais besoin de rien d’autre, si nous utilisons la suite JQuery. Vraiment? Cela laisserait de côté toutes ces technologies dont nous entendons parler, comme MooTools, ExtJS, Sencha Touch, Ripple, JQMobi, Jo, JoshFire, Inuit, LungoJS et Dojo toolkit. Celles-ci semblent vraiment bien et prétendent résoudre les mêmes problèmes de compatibilité HTML5. Mais finalement, c’est également la prétention d’outils et de templates DOM/CSS comme HTML5Boilerplate, Initializr, Bootstrap, Crafty.DOM, LESS, 960, Blueprint, 52 Framework, Gravity, Gridless, Skeleton, G5 et bien d’autres.
En même temps, si vous souhaitez créer des « jeux HTML5 », il faut également considérer de nombreuses autres technologies comme Construct 2, CreateJS, Game Maker, KineticJS, Processing.js, ImpactJS, LimeJS, Jaws, Box2SJS, CasualJS, Cocos2D, EntityJS, GameJS, GMP, Isogenic, PlayN, PropulsionJS, Mibbu, Sprite.js et d’autres librairies WebGL comme SpiderGL, GLGE, Copperlicht et SceneJS. Ensuite nous avons les libraires média JavaScript comme VideoJS, MediaElementJS, Kaltura HTML 5 Media Library, Jukebox, Buzz Audio Library et Popcorn.js. Plus d’autres outils comme RGraph pour les graphiques, Mashi pour l’animation de timeline, BakerFramework pour les ebooks ou encore Pixtastic pour les filtres d’image en temps réel. Et n’oublions pas les plate-formes d’hébergement et de développement HTML5 comme AppMobi, Spaceport.io, FunSockets, Turbulenz et Pixie Engine ou le fait que nous pouvons regrouper toutes ces technologies et les convertir en applications mobiles avec phoneGap, Appcelerator ou Apache Cordova. Et si vous souhaitez utiliser votre JavaScript côté serveur, alors node.js et Kinvey sont faitspour vous! Beaucoup de ces technologies prétendent être la « seule » solution, alors laquelle choisir?
Et nous devons aussi mentionner les plate-formes et applications. Jusqu’à il y a quelques années, nous écrivions des applications pour Firefox, IE et peut-être Safari, mais seulement si vous étiez prêt à souffrir. Maintenant il faut considérer de multiples versions d’Internet Explorer, Chrome, Safari, Mobile Safari, Firefox, Opera, Silk, les quelques 30 combinaisons de plate-formes iOS et systèmes d’exploitation, et des milliers de combinaisons Android/Système d’exploitation. Pour compliquer encore davantage la situation, le consensus, du monde du côté des consommateurs, c’est que les applications web créées avec l' »HTML5 Open Web Platform » doivent être lisibles parfaitement sur toutes ces plate-formes. Mais ce n’est pas le cas. En fait, certaines des fonctionnalités HTML5 les plus attrayantes telles que audio et video ne fonctionnent pas de manière consistante sur les navigateurs mobiles. C’est pourquoi de nombreux jeux HTML5 mobiles ont tout simplement abandonné le son.
Ces derniers mois, une atmosphère tendue s’est formée autour du concept de l’HTML5 Open Web Platform. C’est un sentiment de burn-out pour les développeurs, qui essaient de répondre aux demandes des consommateurs qui s’attendent à une solution unique pour tous leurs besoins en développement web et mobile.
Ce sentiment semble prendre de l’ampleur. L’une de mes parodies favorites publiées ces derniers mois s’appelle HTML9ResponsibeBoilerStrapJS. Elle résume bien l’esprit de burn-out technologique lié au HTML5: « H9RBS.js (v0.0001) is a flexible, dependency-free, lightweight, device-agnostic, modular, baked-in, component framework MVC library shoelacestrap to help you kickstart your responsive CSS-based app architecture backbone kitchensink tweetybirds. »
Pour nous, le jargon vole à gauche et à droite, et tout le monde semble vouloir régler les mêmes problèmes et créant un nombre impressionnant de technologies et d’outils différents. D’un côté, c’est une bonne chose. C’est une évolution et une révolution, et nous sommes heureux de faire partie de cette petite bulle technologique qui a rempli le vide laissé par Adobe quand ils ont abandonné le web mobile.
D’un autre côté, la grande quantité de « nouveautés » autour du HTML5, que ce soit de nouvelles façons de décrire le code, des templates, technologies et plate-formes est absolument démentiel. La situation est au mieux déroutante, au pire déconcertante. De plus, la plupart des « bulles technologiques » sont inévitablement suivies d’un tri qui laissera des dizaines de technologies sur le carreau (Vous souvenez-vous quand Flash a mis à la retraite le DHTML, Silverlight, les Applets, JavaFX, VRML, Realplayer et Shockwave?). Pour les développeurs, cela signifie qu’il faut être prudent lors du choix d’une technologie, en sélectionnant celle qui sera présente à moyen terme, ou nous courons le risque d’investir notre temps et nos ressources dans quelque chose qui ne sera plus jamais utilisé.
Tout ce qu’on sait en ce moment, c’est que lorsque les gens demandent du « HTML5 », ils n’ont pas de technologie spécifique à l’esprit et n’ont pas lu les spécifications du W3C à cet égard. Peut-être connaissent-ils l’un ou l’autre des objets HTML5 tels que CSS3, Webkit, Canvas ou video, mais ce n’est pas important. Ce qui compte est la traduction de cette question: quand ils demandent du HTML5, ils veulent probablement un site web ou une application qui tourne sur toutes les plate-formes, mobiles et autres, et que cela signifie « Pas du Flash ».
Pour les développeurs qui étaient autrefois à l’aise avec Flash comme plate-forme compatible, cela peut signifier naviguer à travers une multitude de spécifications, d’outils ou d’API faisant partie de l’Open Web Platform avant de trouver la bonne solution pour leur projet.
Donc lorsque vous nous appelez pour la création d’un jeu, d’un site ou d’une application en HTML5, et qu’une réponse ne vous est pas proposée immédiatement, ce n’est pas de l’ennui, du désintérêt ou de la distraction, mais parce qu’il faut considérer de nombreux points avant de formuler une réponse adéquate. Si vous nous laissez quelques minutes pour reprendre notre souffle, le résultat sera excellent, promis.
Nous vous remercions de votre patience.
— traduction d’un article publié le 26.09.2012 sur Gamasutra