Native Client, la technologie RIA de Google qui risque de faire long feu

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 FlashSilverlightJavaFX 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.

89 commentaires sur “Native Client, la technologie RIA de Google qui risque de faire long feu

  1. Dans le doute (et par conscience professionnelle) je reformule mes propos :
    – NaCl n’est pas un plug-in ou une offre de RIA « traditionnelle » comme il en existe déjà sur le marché ;
    – C’est une technologie avec un très gros potentiel mais qui va surtout intéresser les petits et moyens éditeurs de logiciels (les gros ayant d’autres batailles à livrer) ;
    – NaCl enfonce Flash en terme de performances d’exécution mais Flash écrase NaCl en terme de productivité quand il s’agit de développer une interface riche qui n’est pas un logiciel en ligne ;
    – NaCl ne parviendra pas à percer si Google ne se décide pas très vite à marketer convenablement ce produit en expliquant très clairement ce que c’est et surtout ce que ce n’est pas.

    /Fred

  2. @Fred Cavazza : Le commentaire de Xavier par exemple est on ne peut plus censé (bien plus que le billet en tout cas mais c’est pas ultra dur) et il n’est pas anonyme du tout.
    De même que celui de Kell qui même s’il utilise un pseudo à une photo donc une vrai adresse email qui lui correspond : pas anonyme et plein de bon sens.

    Ce que tu dis dans le billet est simplement faux, on NE PEUT PAS se passer de vrai langage comme le C et le C++, qui survivront très certainement à Java, C# et autre Pythonerie comme ils ont déjà survécuent à de nombreux langages, tout simplement parce qu’ils sont puissant et vraiment bien.

    Mais personne t’en veux non plus, justement tu as écris ton post sur ton blog et les commentaires sont ouvert ce qui permet le débats et entre autre les corrections du billets, personne n’est censé être omniscient (sauf JFM, private joke (JFM est un prof un peu trop prétencieux, il nous a même sorti qu’il a inventé QuickSort des trucs comme ça ^^)).

  3. le problème de ton article c’est ton postulat que le c/c++ est dépassé que PERSONNE ne l’utilise plus alors que c’est une contre vérité ENORME, flash est écrit en quoi ? je doute qu’il soit écrit en flash ;)

  4. « Avec Native Client faite une croix sur 20 ans d’évolution des langages de programmation »

    « De plus, il y a bien longtemps que la filière informatique ne forme plus les étudiants au C de façon intensive, c’est un langage qui est étudié dans les premières années mais les formations se concentrent sur des langages qui offrent un maximum de débouchés aux jeunes diplômés »

    Je suis désolée car je n’ai pas tout lu dans le détail (aussi bien l’article que les commentaires) mais quand je lis cette réflexion ou certains passages dans l’article, je ne peux que sentir tous mes poils se hérisser (si si je vous assure).

    Je suis jeune diplômée.

    Et la première chose que j’ai apprise en math info (à la fac donc… Pas en école ou autre truc spécialisé), c’est réaliser un algo et programmer en C++. Et j’en ai mangé du C++ !
    Alors à moins qu’en 5 ans l’enseignement est à ce point changé ses programmes, on ne peut vraiment pas dire que cette affirmation soit fondée.
    Quand on sait programmer en C/C++, on sait programmer quasiment dans tous les autres langages (avec un temps d’adaptation, je vous l’accorde mais c’est comme changer de voiture).

    Mais quoi qu’on en dise, NaCl est un un excellent produit et il a toutes ses chances sur le marché. Et le fait qu’il soit en C/C++ ne sera en rien un frein… Peut-être même que ce sera l’inverse. Qui sait ?

  5. Très intéressant tout cela. Merci pour cet article FC, même si vous avez eu quelques commentaires un peu « rugueux », je trouve que cela est assez constructif quand même. Étant (ou ayant été) un développeur C en entreprise, je peux certifier que c’est un langage très utilisé, très structurant mentalement parlant, et je pense qu’il est impératif qu’il soit toujours enseigné.
    Sinon concernant NaCL, je trouve quand même que c’est un tendance de fond des acteurs de pouvoir optimiser et exploiter au mieux les ressources de la machine cible.
    On va peut-être avoir des interfaces riches ++. Tiens, je vais me remettre au C…

  6. Fred, ce n’est ni des insultes, ni un redressement de torts (et encore moins anonyme).
    Je veux juste dire par là que non, C/C++ ne sont pas des langages obsolètes.

    1) Le marché des développeurs C++ (et C dans une très moindre mesure) est loin d’être un désert, consulte les job boards.

    2) TOUTES les écoles dignes de ce nom enseignent encore le C/C++ de manière plus ou moins intensive. Et je dirais même que le seule moyen d’être un bon développeur est de maîtriser cette brique de base.

    3) C/C++ restent quand même la référence en matière de code portable (je parle d’architecture), ce qui reste un must quand on parle de développement.

    4) Le C est derrière (directement ou non) 90% de ce qui se fait dans le merveilleux monde du Web, de la couche applicative en passant par la couche réseau, j’en passe et des meilleures.

    Je doute, à la lecture de ces lignes, que tu sois très calé dans ce qui touche au développement. Il est dommage que tu t’aventure sur ce terrain avec des avis aussi tranchés (surtout quand tu as tord).

  7. Fred, désolé mais ils ont raison. Entièrement. Et ton article et tes réponses aux commentaires ci-dessus sont, désolé de de voir le dire, franchement à côté de la réalité du marché. Tous les cursus informatiques, j’insiste TOUS, enseignent encore C et C++. Comme lex et yacc. Les développeurs c/c++ sont présent fortement sur le marché. Environ 80% des logiciels que nous utilisons tous au quotidien sont en c, c++, objective c ou c#. Et on ne fait pas une industrie du logiciel de haut niveau sur JS ou ROR.

  8. C’est pas le PC qui travaille ? Native Client récupère les données (compilées ou pas, je ne me souviens plus) et les exécute sur l’ordinateur.

    C’est certainement pas un concurrent de Flash (car il faut programmer en Flash). Avec Native Client on code en ce qu’on veut … C++ compris.
    Le port de Quake est d’ailleur parlant à ce niveau.

    Pour moi c’est de l’ActiveX 2.0 : on exécute un programme dans le navigateur (qui accède au système faut-il le rappeler) et y’a plus qu’croiser des doigts pour que ça dérape pas … or c’est principalement pour ça qu’ActiveX a été trainé dans la boue.

    C’est beau sur le papier, on va tout faire dans le browser mais … je ne le sens pas.

  9. Intéressant article et commentaires d’autant plus. Je crois que Fred n’a pas le profil technique et il a probablement une vision plus globale de l’évolution informatique. Les commentaires proviennent, je pense, pour une grande partie de développeurs purs CAD apprentissage C/C++ > Java > PHP/Asp (voir autoformation).
    J’ai aussi suivi ce parcours dans mes études et je ne suis pas vieux mais je pense aussi que certaine formation (universitaire / école) rattrapent le retard sur la demande PHP/asp du marché et propose ce type de matière donc forcement au détriment d’autres (probablement le CC++). Fred n’a fait que le décryptage peut-être un peu caricatural de la réalité du marché et a tenté d’expliquer une technologie pas forcément très claire.
    Même si des éléments de l’article m’ont surpris, je constate aussi que certaines dev réagissent comme des «maçons», susceptibles et agressifs lorsqu’on égratigne leur domaine, dommage.

  10. @ Julien > La question n’est pas d’avoir tord (ou raison) mais d’exprimer un avis. Puis-je te rappeler que tu es sur un blog tenu par un être humain, pas sur une bible de l’informatique.

    J’ai modifié mon article pour que la lecture en soit plus simple et pour qu’il n’y ai pas d’ambiguïté sur mon point de vue : je n’ai jamais dit que C et C++ étaient obsolètes mais qu’ils n’étaient pas du tout adaptés à la réalisation d’une interface riche (du moins beaucoup moins que des environnements dédiés comme Flash Pro).

    Cette discussion me gonfle car on est en train d’y faire le procès de Java et de C# alors que le coeur du débat porte plus sur les usages et sur une approche plus subtile de l’outil informatique en entreprise (grosses applications bureautiques vs. wikis ou espaces de travail collaboratifs) ou dans un contexte de divertissement (jeux ultra-gourmants en ressources à la Far Cry 2 vs. Casual games ou MMO dans le browser).

    /Fred

  11. Je partage tout à fait certains points de ton analyse, et je pense que beaucoup ici aussi.

    La réaction portait sur un avis trempé comme “Le problème c’est que
    nous sommes maintenant en 2009, que la ressource n’est plus un problème et que plus personne ne programme en C.” qui était une phrase non seulement fausse (deux hérésies en une phrase), mais aussi insultante pour certains. Je ne suis personnellement pas touché, je ne fais plus de C/C++ depuis presque une décade.

    Ce n’est pas le procès de JAVA, qui n’est plus à faire, mais la défense de C/C++ en tant qu’acteur proéminent mais souvent dénigré.

    Au dela, oui ce blog est édité par un être humain, il est de qualité, et si tu t’es senti offensé ou énervé par mes commentaires, désolé, ce n’était pas le but.

    Bonnes fêtes tout de même !

  12. Merci Julien pour ce dernier message.

    Difficile de défendre C/C++ dans un contexte RIA, surtout face à des acteurs historiques comme Macromedia / Adobe. C’est en résumé la teneur de mon billet et j’espère que la ré-écriture de certains paragraphes profiterons à la discussion car le sujet n’est pas simple et les enjeux vont bien au-delà de « simples » considérations sur la performance ou sur la qualité d’un langage vis à vis d’un autre.

    Sur-ce bonnes fêtes également, je m’auto-déclare en vacances.

    /Fred

  13. Vous m’avez l’air très peremptoire, pour quelqu’un qui dit autant de contre-vérités.
    Sans etre exhaustif, le C/C++ sont *loin* d’etre morts comme indiqués plus haut (on peut parier que 90% des applications qui tournent actuellement sont ecrites en C/C++, y compris les … interpreteurs JS, votre client flash, etc), que vous parler de « contourner le systeme d’exploitation », ce qui est non seulement impossible, mais tout simplement idiot (sans OS, vous n’affichez rien a l’ecran, vous ne faites pas de multitache, j’en passe et des meilleures), un processeur ne comprend absolument pas l’assembleur (d’ou le mot assembleur, qui permet … d’assembler un language a peu pres lisible en suite justement de 0 et de 1 que le processeur comprend) etc etc etc.

    Ne venez pas me dire que vous simplifiez, car vous dites clairement des choses fausses. Vous induisez vos lecteurs en erreur a chaque phrase, un peu plus de rigueur (et de connaissance du sujet) serait peut-etre utile.

    Et Joyeux Noël.

  14. On ne juge pas ici des qualités comparées de tel ou tel language mais de la capacité de FC à écrire des phrases lapidaires sans aucun fondement.

    Le moteur 3D qui tourne derrière la demo quake c’est pas celui d’NaCl, c’est réellement celui de quake, en fait cette démo c’est le code source de Quake compilé pour NaCl, par l’extention du compilateur gcc d’NaCl qui est du reste la clé de voute de la techno à l’heure actuelle.

    Comme le dit l’intitulé du document de recherche « Native Client: A Sandbox for Portable, Untrusted x86 Native Code » il s’agit bien de code portable et d’environnement securisé pour l’execution de code tiers …

    La seule chose à dire à propos d’NaCl dans le contexte RIA c’est qu’NaCl n’a rien d’une Interface Utilisateur et qu’a fortiori elle n’est pas riche …

    Si en revanche je peut me permettre une hypothèse à propos d’RIA c’est qu’à l’instar de la demo Quake les nombreux codeurs de moteurs 3d et autres demomakers ont là une fantastique ocasion de porter leur code sous NaCl affin qu’un public plus large ait accès à leurs travaux. Peut être en émergeront de nouveaux outils qui vont pourraient finalement faire sortir Flash de sa zone de confort …. Cette video qui est une capture de code executé en temps réel met en oeuvre un moteur vectoriel qui n’a rien à envier à flash selon moi…. Time will tell.

    Bonnes vacances.

    A++

  15. Je coinche sur la polémique du C

    Par contre je remarque que la premiere phrase de cette note s’applique quand même a beaucoup de technologies de Google

    Google moon aussi j’ai beaucoup de mal à voir à quoi ça va servir…

  16. je suis atterré de voir comment on peut prendre une si infime remarque dans billet aussi exhaustif en explications pour lancer des commentaires pareils… J’ai du mal à passer le pas pour ouvrir mon blog… je crois que çà sera pas pour 2009.

    Sur ce, Bonnes fêtes, merci pour ce Billet Riche en NaCl qui montre à tout le monde que …. t’es incapable de faire un vrai break ;)

Laisser un commentaire