La sortie de Native Client, une technologie encore expérimentale du Google Labs, est passée complètement inaperçue à quelques rares billets près. Le problème n’est pas que les blogueurs soient peu inspirés par cette nouvelle, mais plutôt que ce produit a tellement été mal présenté au public que personne ne sait trop à quoi ça va servir. Pour information il m’a fallu près de deux semaines de cogitation avant d’attaquer la rédaction de ce billet.
Pas réellement un concurrent de Flash ou de AIR
Force est de constater que ce nouveau produit est plutôt obscur, que les explications sont rares et que même les équipes à l’origine de ce projet sont incapables de fournir une explication claire (cf. Native Client: An OS in Your Browser). Pour faire simple, Native Client est une extension que vous installez sur votre ordinateur pour pouvoir exécuter au travers de votre navigateur des applications en ligne écrites en code natif (C ou C++). Si vous avez le courage vous pouvez toujours lire l’annonce officielle mais vous n’y apprendrez pas grand chose de plus : Native Client, A Technology for Running Native Code on the Web.
Ne vous y trompez pas, même s’il est beaucoup question de RIA, NaCl n’est ni un plugin à la Flash ou Silverlight, ni un runtime à la AIR. Ce n’est pas non plus une technologie qui exploite une machine virtuelle à la JavaFX et pour finir c’est encore moins un mini-système d’exploitation. En fait c’est un peu tout ça à la fois (bien que pas tout à fait). Lire à ce sujet : Why Google Native Client is not a Flash competitor.
En tout cas le moins que l’on puisse dire c’est que Native Client laisse un certain nombre d’observateurs avertis très sceptiques : Google Native Client: A Game Changer or an Also-Ran? et Google Native Client: web deluxe, or ActiveX redux?.
Avec Native Client ne gaspillez plus la ressource de votre processeur
Pour bien comprendre tout l’intérêt de Native Client (NaCl pour les intimes), il faut se pencher sur l’architecture des ordinateurs et surtout sur le fonctionnement des plug-in. Pour faire simple un ordinateur est composé de couches matérielles (la carte mère, le processeur, la carte graphique…) et de couches logiciels (le système d’exploitation, les applications…). Quand vous consultez une interface riche en Flash, celle-ci repose sur du code qui est interprété par le plug-in, par le navigateur, par le système d’exploitation et finalement par le processeur. Ce dernier traite l’instruction et remonte un résultat dans l’autre sens. Toutes ces couches sont autant d’intermédiaires qui traduisent, interprêtent et ne font que vous gaspiller de la ressource (mémoire et puissance de calcul). Voilà pourquoi les animations 3D exécutées dans Flash vous paraissent minables comparé à ce que votre carte graphique est capable de faire.
Avec Native Client, la promesse est de ne plus gaspiller cette ressource en évitant les intermédiaires (les différentes couches logicielles) et de faire en sorte que les applications en ligne exécutées dans votre navigateur ne soient que 1% moins lentes que celles qui sont installées sur le système d’exploitation. Lire à ce sujet l’excellent mais très technique article de Samy : Avec Native Client, Google invente l’OS dans le navigateur.
Si la promesse est belle (des performances sans commune mesure) et l’exploit technologie réel, il y a une contre-partie : les applications en ligne doivent être développées en C ou C++. Et c’est là où ça coince : le C et le C++ sont des langages de programmation contraignants qui ne sont pas réellement adaptés aux interfaces riches. Il existe maintenant de nouveaux langages beaucoup plus sophistiqués qui se sont imposés sur ce créneau avec des environnement de développement dédiés beaucoup plus productifs (à l’image d’Eclipse ou de Flex Builder). Donc concrètement pour bénéficier des performances de NaCl il faut revenir 20 ans en arrière et se réapproprier des langages qui font dramatiquement chuter la productivité. En clair il va vous falloir beaucoup plus de temps pour développer la même application. Tout ça pour quoi ? Pour de meilleures performances, mais est-ce que la performance est réellement un problème ?
PS : Ceci est une tentative naïve de l’auteur d’expliquer de façon simple le fonctionnement des ordinateurs pour pouvoir mieux comprendre la prise de position sur NaCl. Les premières versions de cette explication étaient approximatives et ont engendrés des commentaires très aggréssifs qui ont polués la discussion avec un débat de forme (« le C n’est pas mort et il est plus performant que Java ») au détriment d’une discussion de fond (NaCl est une belle avancée technologique mais qui ne trouvera pas forcément son public dans la mesure où les usages de l’outil informatique sont amenés à beaucoup changés dans les prochaine années, notamment avec les approches centrées sur la collaboration de l’Entreprise 2.0).
Le faux débat de la performance
Oui, la performance est importante, car il en faut pour faire tourner dans votre navigateur des applications équivalentes à ce que vous avez sur votre disque dur. Mais d’un autre côté est-ce que c’est un but légitime ? Traduction : Quel est l’intérêt de faire tourner Word 2007 dans votre navigateur quand un wiki peut vous apporter un bien meilleur service ? Quel est l’intérêt de faire tourner un mastodonte comme Photoshop dans votre navigateur alors que dans 90% des cas vous pouvez vous suffir de Photoshop Express ou de Picnick ?
Nous entrons ici dans la partie délicate de la discussion autour de NaCl, la partie où l’on va se rendre compte que cette technologie est surtout révolutionnaire pour les éditeurs de logiciels, pas pour les concepteurs d’interfaces riches. L’industrie du logiciel est en effet en train de se scinder en deux clans : d’un côté les applications lourdes (Photoshop, 3DSMax…) qui sont avant tout destinées à un petit nombre de professionnels spécialisés dans un domaine et nécessitant beaucoup de ressources (mémoire, puissance de calcul, capacité de stockage…), de l’autre des applications plus légères (SalesForce, Basecamp…) qui sont avant tout orientées collaboration et qui consomment très peu de ressources. Le modèle SaaS est donc parfaitement adapté à la seconde catégorie avec des technologies parfaitement maîtrisées (HTML + Javascript, Flash…) qui ne posent pas de problème de performance.
Vous pourriez me dire que le débat sur la performance est revenu sur le devant de la scène avec la mode des ordinateurs low cost (les EeePC et autres netbooks) qui ne disposent pas du tout de la même puissance de calcul. Pour ce segment bien particulier il serait intéressant de voir s’il est rentable d’adapter des applications desktop existantes pour les reformater aux contraintes de ces ordinateurs (petit écran…). Mais encore une fois la solution se trouve plutôt dans une nouvelle approche de l’outil informatique (avec les intranets wikifiés et les mashups d’entreprise) plutôt que dans l’exploit technique de faire tourner Office 2007 et Vista sur un EeePC.
Ceci est d’autant plus vrai que les dernières versions de navigateurs comme Firefox, Opera ou Chrome ont fait un bond spectaculaire et ont réussi à décupler les performances d’exécution de code Javascript. Et comme une bonne nouvelle ne vient jamais seule, les plug-in progressent aussi à pas de géant puisque Flash 11 et Silverlight 3 devront également marquer une nette rupture de performance avec une prise en charge beaucoup plus poussée de l’accélération matériel, donc un recours plus intensif aux composants hardware (notamment la carte graphique) et moins de gaspillage de mémoire. Ca ne vous rappelle rien ? Bref, toutes ces améliorations à venir nous font relativiser le gain de performance annoncé par NaCl. Mais bon… l’idée n’est pas neuve car Microsoft avait tenté d’introduire une technologie équivalente avec les fameux ActvieX (cf. Google Native Client : Un ActiveX-Like ?) et n’oublions pas non plus que le javascript a ses limites (cf. L’invasion des machines virtuelles).
Donc au final NaCl doit être avant tout considéré comme un environnement d’exécution et de déploiement révolutionnaire car il permet aux éditeurs de ne développer qu’une seule version de leurs applications et de les distribuer via le web (en évitant les circuits de distribution classique avec boîtes et DVD). Vous noterez au passage que cette solution n’a été rendu viable que depuis l’adoption d’une architecture commune (x86) par les constructeurs et éditeurs de système d’exploitation (Microsoft / Windows, Apple / Mac OSX, Linux). Pour en savoir plus sur le potentiel de NaCl dans ce domaine je vous recommande cet article de Louis Naugès : Web 2.0, Lla marginalisation, définitive, de Windows sur les PC.
C’est quoi déjà une interface riche ?
Mais revenons à nos moutons : les interfaces riches. Dans la vision de Google, les interfaces riches sont avant tout destinées à être exploitées dans le cadre d’applications en ligne. Mais cette vision est très réductrice car que fait-on des innombrables interfaces riches qui reposent sur de la vidéo, des animations, du son, des transitions et autres effets spéciaux ?
Même si Native Client intègre un moteur de rendu vectoriel, Flash (et dans une certaine mesure Silverlight) reste la technologie la plus appropriée et de très loin pour faire ce type d’interface. Est-ce que vous vous imaginez faire un carrousel, un configurateur ou un assistant au choix en C ou C++ ? Non bien évidement car ce n’est pas pour cela que ces langages ont été conçus. L’avantage de Flash est d’autant plus net qu’il est couplé avec un environnement de production parfaitement adapté à ce type d’interface ainsi qu’une infinité de bibliothèques prêtes à l’emploi pour gagner du temps. Vous noterez que l’approche de Google centrée sur les applications en ligne se vérifie également avec d’autres produits comme GWT, un framework Ajax qui est exclusivement tourné vers une logique applicative.
Bref, ce n’est pas demain que nous allons voir des studios de production comme 2advanced, Blitz, Megalos ou Soleil Noir abandonner Flash pour faire du C. Ces studios sont capables de faire des prouesses que le C n’autorise pas.
Conclusion
Si nous résumons :
- NaCl n’est pas un plug-in, c’est un projet encore expérimental qui n’est même pas en phase alpha ;
- NaCl n’est pas un mini-système d’exploitation, c’est un complément qui permet de court-circuiter des intermédiaires pour profiter des pleines performances du matériel ;
- NaCl n’est pas concurrent de Flash ou Silverlight qui sont bien plus performants pour faire de belles interfaces riches ;
- NaCl dépend de langages de programmation (C et C++) qui sont plus plus performant mais plus contraignant ;
- NaCl propose une approche tout à fait intéressante de la distribution de logiciels, mais les gros éditeurs disposent de leviers très puissants (accords cadres, partenariats, lobbying…) pour défendre leur modèle de distribution (et je ne parle pas que de Microsoft).
Voilà pourquoi NaCl va très certainement chambouler la longue traîne de l’industrie logiciel bien que cette technologie ne soit en l’état pas viable pour survivre sur le marché des RIA. Marché déjà bien encombré avec Flash, Silverlight, JavaFX ou des acteurs de niche comme Curl ou Unity3D (respectivement pour des applications en ligne d’entreprise et pour des jeux en 3D comme Cmune).
Reste donc deux possibilités : Soit Google fait fortement évoluer son produit pour le rendre réellement attractif (en expliquant clairement ce à quoi il sert et ce qu’il n’est pas), soit NaCl restera une expérimentation intéressante mais qui sera confinée à un usage interne chez Google.
Très bon billet comme d’habitude.
Merci.
Merci Fred pour cette excellent billet et de nous partager tes trouvailles. En tous cas ce break t’as fait le plus grand bien ^^
La question que je me pose à la lecture de cet article est : Google ne nous présente-t-il pas en béta le moteur de sa future offre de cloudcomputing?
…
Sinon Noyeux Joel à tous ;)
Hmm, un peu dur de lire tous ces commentaires, beaucoup n’apportant rien.
Au passage, je tiens à souligner un truc que (je pense) personne n’a fait remarquer: NaCl fait tourner du code compilé dans un environnement sécurisé. C’est pas parce que la version actuelle de NaCl n’accepte que du C++ en entrée que ça ne changera jamais. Adobe fournira peut etre un jour une version du compilateur en ActionScript. Complètement l’opposé de ce que suggère Max :p:
[quote= »max »]Adobe nous reserve une version du plug-ins flash pour NaCl ?[/quote]
Au vu du dynamisme d’Adobe en ce moment vis-à-vis de Flex/Flash et notamment du format AMF (pour dialoguer avec un serveur distant), et même du partenariat pour le Flash Player spécial pour Google, ça ne m’étonnerait pas du tout qu’on voie fleurir un environnement NaCl programmable en ActionScript.
… et du coup, tout le monde sera content et arrêtera de déverser son fiel :p
Merci pour ce billet sur un sujet visiblement très chaud. Cela m’a motivé d’aller y jeter un coup d’oeil.
Pour ce qui est d’apporter mon grain de sel, je pense qu’une techno qui améliore le rendement des performances par rapport à l’énergie consommée a un bon potentiel pour l’avenir compte tenu de la forte demande pour les applications mobiles et l’augmentation du cout de l’énergie.
Pour les langages, le choix d’utiliser le C et C++ est effectivement surprenant car bien qu’ils soient encore beaucoup utilisés, il leur manque pas mal de fonctionnalités qu’on trouve dans les langages plus modernes. Ne fut-ce qu’un ramasse miette par exemple ou le contrôle de dépassement d’espace mémoire.
Je suppose que le choix de google se justifie par la sélection d’une solution la plus simple, la plus portable et la plus légère qui soit. Mais c’est un mauvais choix du point de vue de la productivité des développeurs. On ne va pas gagner en fiabilité et sécurité des programmes.
La solution .NET reste la meilleure. Son seul défaut est d’être propriétaire.
M. Cavazza, vous vous etes un peu fait avoir comme un bleu en lançant un sujet de Troll ;)
Je me permets de mettre aussi mon grain de NaCl en ajoutant deux petites choses:
– aujourd’hui, le développeur qui se restreint à un seul langage aura bien du mal. Et en tout cas, il ne maitrisera pas les bons outils à sa disposition. En particulier dans le monde du Web.
– tous les langages à mon sens se valent à peu de choses près. Seul compte le contexte dans lequel il peut s’utiliser (PHP sans ses librairies ne vaudrait pas un clou).
A mon humble avis, suivant le sujet depuis presque 2 ans, les RIA s’observent et sont observées par les développeurs. Tout le monde attend de voir qui « va gagner ». Je ne suis pas convaincu par Adobe Air, encore moins par Silverlight. Et je réserve mon jugement pour NaCl. Tout est encore possible, et celui qui gagnera (quelque soit le langage) sera celui qui fournira le meilleur environnement, et la meilleure API (et documentation). C’est elle qui garantit la productivité pour l’essentiel. Si Google fournit une API d’enfer, ce sera tout simplement eux qui pourront « gagner », et alors le système sera adopté, langage C++ ou pas.
Il y a un aspect que vous oubliez de préciser Fred, en comparant l’intérêt d’une interface en C-C++ plutôt qu’en flash. Nous sommes d’accord, Flash est cent fois plus productif et pratique pour développer une interface.
Seulement l’interface n’est que la couche supérieure d’une application. Sur les couches inférieurs ( accès aux données et traitements de celles-ci par exemple ), la puissance du C n’est plus à démontrer.
Je vais prendre un exemple tout simple, un antivirus en ligne permettant un scan complet du système de l’utilisateur. Rien n’empêche la présentation d’une interface en flash à l’utilisateur couplée à une application utilisant NaCl qui elle sera chargée de réaliser le scan.
Qu’es ce qu’on y gagne ? De meilleurs performances, et c’est loin d’être un faux problème. Les ressources nécessaires aux envies et besoins des utilisateurs grimpent plus vite que les performances d’un matériel bon marché.
Après m’être amusé à la lecture de tous ces commentaires, je suis frappé par le fait que peu portent sur le fond: NaCl est-il le début d’une nouvelle architecture ? Le post de Louis Nauges apporte une première réponse, et elle mérite d’être citée ici:
http://nauges.typepad.com/my_weblog/2008/12/web-20-la-marginalisation-définitive-de-windows-sur-les-pc-.html
Je ne vais pas répéter mon commentaire: il s’agit bien d’une nouvelle architecture (cloud + edge) et cela permet de faire des choses intéressantes (en effet, le problème des ressources n’est pas résolu, il y a encore trop de choses qu’on ne peut pas faire parce qu’elles sont trop « computationally intensive » (pour utilise mon jargon de vieux chercheur)- à titre d’exemple: http://organisationarchitecture.blogspot.com/2008/03/challenges-scientifiques-pour-la.html
Ceci étant dit, merci à Frédéric d’avoir posé la question et suscité le débat :)
Bonjour à tous !
Pour finir sur une conclusion positive pour FRED,
Fidèle lecteur de son blog, je me permets de vous faire part de la publication de plusieurs articles sur NITROBLOG depuis ce mois ci concernant justement les langages RIA en vectoriels.
Vous trouverez un support didacticiel avec des vidéos pour les passionnés d’interfaces vectoriels en VML et HTML+TIME sous IE8 de MS.
Voici le lien pour les courageux : http://nitroblog.mediasites.fr
Très cordialement,
Patrick GUINBERTEAU
J’aimerai dire un truc tout bête. Langages haut niveau VS bas niveau ?
Où est le choix ?
Le choix c’est: Qui paie ?!
Les bas niveaux coûtent plus cher aux entreprises, les haut niveaux coutent plus cher aux utilisateurs !
Et quand je vois que firefox utilise 100 mo de RAM pour tourner, je me dis, mais quake 3, il en utilise combien ? Et bah la différence n’est pas énorme car je le faisais tourner sur un vieux PC avec 64 MO ou 128 (je ne suis plus sûr).
Alors pour afficher du texte et des images: 100 MO, pour de la 3D: autant ?
Sérieusement, oui, c’est bien les langages haut niveau, pour les utilisateurs qui sont riches, et peuvent s’acheter des PC avec plusieurs gigas de ram.
N’empêche que ça fait plaisir quand on lance une application écrite en C qui tourne vite, alors que l’on voit tout de suite la différence quand elle est écrite en VB, windev, java, flash etc…
Enfin je voudrais faire un point sur le fameux web 2.0, un véritable tuyaux crevé, qui nous fait faire tout et surtout n’importe quoi sur un navigateur avec de l’ajax.
Quand il faut 3 heures pour charger une page web, et lire un mail, alors qu’avant c’était beaucoup plus rapide, et cela pour faire des gadgets en plus, et bah c’est navrant. Les sites en flash sont tout ce qu’il y a d’énervant car on perd nos repères, ils sont lent, laguent.
Tout ça pour dire, oui au C sur internet, ptète qu’on pourra enfin bloquer flash qui ne sert qu’aux pubs, et même bloquer javascript qui était bien lorsqu’il était utilisé avec parcimonie (son but premier), et qui nous sors aujourd’hui des sites imbuvables (refaire un tableur en javascript, on se demande ce que les gens ont dans la tête). Et ptète que le web 2.0 aura vraiment une raison d’exister avec des plug in en C /c++!
Points noirs, google, encore et toujours, et question sécurité, ça va être dur à gérer (si c’est compilé, même si ya des restrictions les pirates vont s’amuser).
au fait on va me dire que firefox est codé en C. A vrai dire c’est possible, mais il n’y a pas que le langage qui joue, ya la manière dont on code. A mon avis, pour qu’il prenne 100MO, juste pour interpréter du HTML et du javascript, c’est qu’il y a un problème.
Juste pour dire que chaque langage a son intérêt. Le php, c’est la facilité et la sécurité, mais pour l’utiliser ne serait ce que pour lister un répertoire, il faudrait mieux utiliser le C…
De même le javascript pour faire un menu déroulant, oui, pour faire un tableur non.
Le flash pour faire une animation oui, pour faire un tchat non.
Le java pour faire du portatif pour téléphones oui, pour faire une application windows ou linux, non…
Il faut savoir utiliser le véritable intérêt de chaque langage. Seul exception, visual basic et windev, qui ne servent vraiment à rien. A part pour les gens qui ne connaissent pas la programmation et qui veulent faire une petite application.
Désolé pour le hors sujet, mais ça m’ennerve de plus en plus de voir des applications toute simples qui demandent beaucoup de ressources. Au final, on augmente la puissance des ordinateurs et on peut même pas faire tourner plus de chose, et demander plus de rapidité des programmes. C’est hallucinant.
Désolé de prendre la discussion en retard.
Je suis d’accord que pour developper un client riche, le C ou C++ peux etre démodé. mais je pense que Silverlight ou Flash doivent etre certainement dévéloppé en C ou C++.
Donc, qu’est qui empeche de developper le plugin (seulement le plugin) en Native Client ?
Ceci aurait 2 avantages:
1) Le plugin n’aurait aucun intermédiaires.
2) Laisserait toujours la liberté à l’utilisateur de developper en C#(silverlight) ou AS3 (flash) tout en exploitant le maximun des ressources systeme.
bonjour, tout d’abord merci pour ce billet et cette synthèse comme toujours très instructifs
par contre vous avez bien un point de vu de developpeur « graphiste » ^^
non, les RIA (flash) ne sont pas la fin des languages de developpement traditionnel (java et C#), non ils ne sont pas plus « productifs » (!) mais adaptés à une niche précise, le developpement d’interface web, point.
et je suis désolé de le rappeler mais l’interface web n’est que la partie immergée d’une application, et si elle est importante (ancien dev Java je suis devenu fan de Flex) elle n’est pas forcément la plus importante (juste une couche du système, avec en dessous la logique « métier » et données (modèle classique MVC)
contrairement à ce que pourrait laisser croire la mode des gadgets et miniapplis facebook, une grosse appli web repose avant tout sur une grosse programmation serveur (que ce soit le système de réservation de la SNCF, un réseau social ou le site de votre compte en banque)
Flex est maintenant super pour enfin développer de vraies interfaces intégrées aux applis (et non plus juste du graphisme flash) au lieu de bidouille javascript (qui malgré la mode Ajax n’est pas concu pour des interfaces évoluées), PHP pour développer vite (et bien) un site (surtout avec les frameworks maintenant matures), Java pour créer un intranet ou extranet d’entreprise solide…
aucun n’est plus à la mode que l’autre, ils s’intégrent à des couches différentes de l’architecture.
si Native repose sur du C/C++ il sera surement possible ensuite de faire dessus du Java/C#, et cela pourrait devenir très puissant pour concevoir de véritables logiciels en ligne (et si on effacait la frontière entre applications d’entreprise et univers immersifs, pour un espace collaboratif global ?).
peut etre une nouvelle révolution à venir du développement ?
donc à suivre attentivement ! :)
mais s’il vous plait ne pas confondre les languages RIA avec ceux serveurs ou d’applications, cela n’a rien à voir avec etre démodé mais répondre à de nouveaux types de besoin et s’y interfacer (ex pour une architecture pro et propre : classes PHP ou Java intégrées dans un framework MVC avec au bout une interface flex au lieu du html classique)
PS : perso je pense que Java puis le C# ont remplacé le C il y a longtemps, ne serait ce que dans la manière de programmer… mais celui ci reste peut etre plus rapide pour des applis 3D
par contre on est aussi productif en Java qu’en flash, voir meme plus (véritable language objet, très structuré, avec outils très puissants…) ! mais pas pour faire les memes choses ^^
Le dernier mot est pour The Register : « C overwhelmingly proved to be the most popular programming language for thousands of new open-source projects in 2008 ».
http://www.theregister.co.uk/2009/01/21/open_source_projects_08/
@ Daniel > Donc c’est ça ton mot de la fin ? Même pas une petite explication sur ce qu’est Native client et en quoi cela va bouleverser la paysage des RIAs ?
Quelle déception pour moi de voir que le débat a complétement dérapé et que je suis passé à côté d’une argumentation qui me tenait à coeur (bien loin de ces gueguerres entre développeurs old scholl et new school)…
/Fred