Transcript de ma keynote de l'évènement WebGL Paris 2014, le 13 octobre 2014
Je ne vais pas vous parler de communauté. Mais je vais le faire quand même pour respecter un tant soit peu le programme. Je m'appelle Khalid Jebbari, j'organise (pas tout seul) le meetup mensuel Paris.js, qui est fier d'être sponsor de WebGL Paris. Qu'est-ce que Paris.js ? Une association de fait autour de Javascript. Autrement dit, c'est une communauté de développeurs qui propose, vote et présente des sujets, sur le principe du volontariat et de l'anarchie, un peu comme l'open-source. On se réunit tous les mois dans une entreprise différente, qui nous prête ses locaux et offrent le buffet et on y parle de tout ce qui a un rapport avec Javascript, dont WebGL. Par exemple, il y a un près d'un an, Microsoft ici présent nous a accueilli pour un meetup consacré à WebGL : Xavier organisateur de WebGL Paris nous a parlé de WebGL Academy, David Rousset de Microsoft nous a présenté Babylon.js, et Aerys nous a présenté son produit pour créer des applis WebGL/Javascript en C++.
Que dire de plus ? Rien. On verra ce que l'avenir et la communauté Javascript nous réserve. Si vous voulez nous accueillir un de ces quatre, faites-moi signe !
Sans transition, aujourd'hui je suis venu vous parler d'histoire.
Comme dans beaucoup de domaines, l'histoire de la technologie fait émerger des vainqueurs, mais pas toujours ceux que l'on voudrait. L'histoire a ses raisons que la raison ignore parfois.
L'histoire de WebGL, c'est celle de Javascript, de la 3d et du Web.
Pour certains le monde serait meilleur si Xerox et SmallTalk avaient gagné. Au lieu de ça on a C++, Java et C#. Pour d'autres on ne devrait coder qu'en Lisp. Au lieu de ça, on a Perl, Ruby et Javascript. D'ailleurs Brendan Eich s'est excusé lors de la JSConf 2013 pour ce qu'est Javascript. Javascript est un langage qui divise. Au sein de la communauté JS, entre les partisans des Good Parts et les autres (Douglas Crockford a fait un talk cette année que je vous invite à voir : The Better Parts). Au sein de la communauté des développeurs, certains trouvent Javascript génial, d'autres horrible, à tel point qu'ils préfèrent utiliser des langages qui compilent en Javascript et il y a le choix : Java avec GWT, C/C++ avec Emscriptem/Duetto/Mandreel, Dart, CoffeeScript, TypeScript, ClojureScript, OCaml avec Ocsigen, Haskell avec Fay/Haste/PureScript/ELM...
Pour certains le monde serait meilleur si on avait une seule façon de coder en 3D (Fahrenheit quelqu'un ?). Au lieu de ça, on a GL, OpenGL, Direct3D et Angle entre les deux.
Pour certains le monde serait meilleur si le navigateur était une vraie plateforme de développement d'applications. Certes, le Web est devenue la plateforme de diffusion de contenu universelle et est une révolution dans l'histoire de l'humanité. Rappel : aucune installation nécessaire, il suffit de taper une URL dans son navigateur. Mais rendez-vous compte : il est presque aussi compliqué de développer des sites et des applications "vraiment" cross-browser que d'écrire des programmes C++ cross-platform. Au lieu de ça, on commençait à peine à voir la lumière avec une vraie standardisation du comportement des navigateurs, quand sont apparus les navigateurs mobiles, sur télé, consoles, box et autres, avec des supports variés et disparates des versions de Javascript et des fonctionnalités offertes par CSS.
Pour certains, le monde serait meilleur s'il suffisait de se fier à la loi de Moore et de considérer la puissance de calcul et la mémoire disponible illimitée et en constante augmentation. Au lieu de ça, elle commence à s'essoufler et la seule manière de la vérifier aujourd'hui est de répartir son travail sur plusieurs cores. Problème : nos langages et outils de développement ne sont pas outillés pour réaliser simplement cette répartition, on partage encore des états mutables entre les threads et manipulons des locks, et les navigateurs, mono-thread, commencent seulement à entrevoir le multi-thread avec les Web Workers. De plus, si nos ordinateurs et smartphones sont aujourd'hui des millions de fois plus puissants que ceux d'il y a 2 ou 3 décennies, pour effectuer les mêmes tâches ils ne sont pas des millions de fois plus rapides.
Mais d'autres pages de l'histoire ont été écrites.
L'hégémonie d'Intel sur le marché des processeurs, que l'on croyait indétronable, commence à être remise en question sérieusement par ARM. ARM propose en effet une approche orientée vers de multiples petits cores, moins puissants mais moins gourmands en ressources, et le marché des smartphones a suivi. L'arrivée prochaine très probable d'ARM sur les machines de bureaux, serveurs et workstation promet d'être intéressante.
Puisque je parle de hardware, je reviens sur la loi de Moore. Une façon plausible et envisageable de répartir ses calculs est de se servir du GPU pour les calculs parallèles, indépendants et intenses sur des grands sets de données. Cette technique est appelée GPGPU (General Purpose GPU), et plusieurs technologies telles que OpenCL et DirectX 11.1 avec DirectCompute permettent de le faire dès aujourd'hui. J'ai vu des exemples d'utilisation du GPU pour soulager le CPU des calculs liés aux requêtes sur une base de données relationnelle. Les fabriquants de GPU l'ont compris, les machines d'aujourd'hui ont besoin de GPU quelque soit leur positionnement. Intel, par exemple, a commencé à se positionner sur l'entrée de gamme avec les chipsets intégrés HD Graphics, dont la dernière itération Iris permet de se passer de carte dédiée pour des usages communs. NVidia se positionne également sur la marché des smartphones, avec des processeurs dans les smartphones tels que le Tegra, ou sa console Shield basée sur Android. L'avènement du "GPU everywhere" augure de bonnes choses pour la communauté WebGL, qui pourra compter sur sa présence et sa puissance pour proposer des expériences 3D sur toutes les plateformes.
Malgré la jeunesse du Web en tant que plateforme de développement d'applications, on commence à voir émerger des solutions qui mettent à profit l'expérience acquise dans le développement d'applications et d'imagerie 3D durant les précédentes décennies. D'ailleurs, WebGL étant un subset strict de OpenGL ES, les connaissances en OpenGL ES sont réutilisables telles quelles. En ce qui concerne les applications, de plus en plus de frameworks et d'outils orientés UI, jeux et imageries 3D existent pour scaler le développement. Et les API disponibles dans les navigateurs, qui s'enrichissent d'année en année, telles que Ajax, WebAudio, WebRTC, la File API, la Gamepad API, Canvas, getUserMedia, permettent d'envisager des expériences riches dans les navigateurs aujourd'hui et dans les années à venir.
Les évolutions récentes du marché du jeux vidéo offrent des opportunités intéressantes. Le retour en force du PC en tant que plateforme de gaming, la montée de Linux et Mac OSX et l'omniprésence des smartphones font que la puissance de calcul et d'affichage est de plus en plus présente sur les machines grand public.
Aujourd'hui, la convergence de la puissance et de la variété du matériel et de la maturation des outils logiciels permettent de réessayer des expériences tentées ou rêvées par le passé et d'ouvrir la porte à de nouveaux usages. Je ne peux pas ne pas citer l'Occulus Rift, qui ouvre la réalité virtuelle au grand public de manière concrète. Pour rappel, Nintendo avait dans les années 90 lancer un produit similaire orienté jeux vidéo, le Virtual Boy, qui fut un échec complet. Les outils de saisie novateurs tels que le Leap Motion permettent d'envisager des interfaces utilisateurs détachés du clavier et la souris. Le Kinect, avec un projet comme Sarah, et l'apparition des objects connectés et des imprimantes 3D présagent d'une nouvelle révolution tridimensionnelle dans les années à venir.
Cette révolution, c'est à nous de l'écrire.
Merci.