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.
Tijuan faut dire que maintenant que le billet a été expurgé des paragraphes qui posaient à juste titre problème la « polémique » n’a plus vraiment lieu d’être.
C’est dommage de ne pas indiquer que le billet a été « retouché », dans des cas comme celui-ci le plus propre est de simplement barré le texte que l’on renie, car maintenant si le billet est plus équilibré les commentaires ne sont plus trop raccord :D
Fred, merci pour ton analyse de NaCl.
Je comprends ton agacement face au ton de certains commentaires. Qu’oxomoxo t’attaque sur ton manque de maîtrise technique dénote un manque total de tolérance ! J’ai personnellement un profil technique et ce qui me plaît dans tes analyses c’est que tu abordes les choses d’une façon différente.
Sur le fond je ne suis pas toujours d’accord mais l’effort que tu fais pour formaliser et partager ta pensée est très intéressant, que ceux qui considèrent que tu écris des choses fausses ou qui ne partagent pas ta vision prennent le temps de formaliser la leur, ça nous permettra de disposer de plusieurs points de vue sur un sujet ce qui ne peut être qu’un avantage.
Ceci étant dit j’espère qu’une discussion sur le fond (NaCl) est possible (cf mon commentaire suivant)
@Oxomoxo : Côté performances, tu semble convaincu que NaCl est la panacée ? Peut-être mais pour quels types d’applications ?
Des jeux, de la 3D ? Mais apparemment NaCl étant basée sur une analyse statique, il impose des contraintes assez fortes sur les applis, par exemple impossible de faire de l’OpenGL ! (cf http://groups.google.com/group/native-client-discuss/browse_thread/thread/4f45298cb6f0639a#)
Donc pour faire une démo avec Quake 1 pas de pb (avec Quake 3 ça ne serait pas possible). A priori ce n’est pas demain qu’on prendra n’importe qu’elle appli en C/C++ pour la compiler en x86 fonctionnement directement sur NaCl.
Autre problème de NaCl: je n’ai pas vu mention de fonctionnalités liées au téléchargement des applications (comment reproduire la notion de librairie partagée ?). Ce qui signifie que les applications x86 exécutées par NaCl doivent être téléchargées d’un bloc ? Sachant que la cible de NaCl serait des applications complexes ça me semble un gros pb (combien de Mo pour un jeux 3D).
Je crois aux besoins d’applications ultra-performantes et optimisées pour certains besoins et donc à l’intérêt de C et C++, mais je ne vois pas l’intérêt de vouloir les exécuter dans un navigateur.
Pour terminer après relecture de l’analyse de Fred je la trouve très pertinente (il faut juste remettre dans leur contexte les quelques affirmations sur C/C++ et prendre en compte le ‘background’ de Fred).
Bravo a Fred pour avoir mis le doigt sur un point particulièrement sensible de la création multimédia actuelle, provoquant ainsi pléthore de réactions parfois agressives et ce n’est pas étonnant. Durant mon parcours professionnel, j’ai plusieurs fois assisté a des discutions assez vives dont la teneur était sensiblement identique a ce que je vois ci-dessus, tant dans le billet que les réactions d’ailleurs. Je pense qu’il reste en effet un abime culturel entre les tenants du développement informatique pur et dur d’une part et ceux du multimédia d’autre part. Nous sommes bien la face a deux systèmes de valeurs, des compétences et des méthodologies professionnelles différentes.
Un concept comme Native Client pourrait-il les réconcilier ? J’aimerais bien ! Le Web aurait beaucoup à y gagner. Mais ce n’est sans doute pas tant une question de technologie que la capacité de professionnels d’horizons différents à communiquer et a s’entendre sur un but commun.
Merci Fred pour ce billet et Joyeuses fêtes a tous !
Certains développeurs font preuve d’une telle fermeture d’esprit quand il s’agit de leur domaine de compétence, et d’un tel élitisme qu’il ne faut pas s’étonner à ce qu’aucun programmeur ne parvienne à créer de la valeur s’il n’est accompagné d’une personne commerciale ou marketing. En bref, il faut se rendre compte qu’à un moment, savoir comment fonctionnent les choses n’est pas suffisant à les faire avancer, et que la connaissance de la machine ne vaut pas encore la connaissance humaine, qui conduirait pourtant à vite comprendre que l’auteur n’est pas un programmeur mais un vulgarisateur qui saisit les contours et n’a pas besoin d’en savoir plus, car lu par 99% de gens qui conduisent leur voiture sans vouloir comprendre le fonctionnement de leur carburateur. Et au final, on se demande qui facture ses heures de consulting le plus cher…
Pour rester dans le sujet, Native Client c’est les prémisses de l’OS Google, une nouvelle brique open source qui va permettre à la communauté de faire encore les 3/4 du boulot (vous allez voir dans les prochains mois un pseudo concours google code.. qui a parlé de pigeonnerie?), et de faire mûrir le systeme jusqu’a ce qu’il soit bulletproof. Si Google maitrise un art, c’est bien celui d’exploiter la psychologie du nerd, et en lui lachant des bribes de validation il fait avancer et développer ses produits à moindre cout… ils font meme des conférences (google talks) pour expliquer en substance que les nerds s’emmerdent et manquent de confiance en eux, et que pour eux, passer leur journée à travailler bénévolement pour une cause qui comble ces déficits est interprétée comme un engagement légitime… Mais ca, le programmeur pur et dur ne voudra pas l’entendre.
Bon… j’ai comme l’impression que nous perdons le contrôle de la situation ! Si la discussion dérape plus encore je serais obligé de fermer les commentaires et de faire le ménage.
Merci pour les auteurs des derniers commentaires qui font l’effort de comprendre le fond du billet et d’y apporter leur point de vue.
/Fred
J’ai lu avec attention ce billet dès sa parution et j’étais certain qu’il allait engendrer un déluge de commentaires plus creux les uns que les autres et n’ayant pratiquement aucun rapport avec NaCl.
Comme le dit FC lui-même, ce n’est pas une bible de l’informatique. Il faut le lire avec du recul et en tenant compte du contexte : FC est un consultant web, il y a tout à parier qu’il n’a aucune vision sur ce qui se pratique en industrie. En tant que consultant web, les technos phares sont java, php, flash/silverlight, GWT, etc. On peut même supposer qu’il n’a pas de connaissances techniques pointues sur ces technos. A ses yeux, les ressources C/C++ « doivent » être rares.
Comparées aux ressources PHP disponibles je comprends également qu’elles peuvent le paraître (J’ai été moi-même développeur C/C++), le PHP étant une techno tellement facile à s’approprier rapidement.
C’est en ce sens que ce billet est intéressant : Comment perçoit un consultant Web cette nouvelle techno alors que Google l’a encore très peu commenté ?
Bonne résolution pour l’année prochaine : Arrêter de blogguer ou ne plus s’attaquer à des débats qui peuvent déchaîner les foules ;-)
—
Billet de l’ami sami extrêmement intéressant :
http://www.dng-consulting.com/blogs/index.php/2008/12/10/avec-native-client-google-invente-l-os-d?blog=1
D’aucuns pourraient penser que ces commentaires sont drôles, à défaut d’être percutants.
Je suis tout à fait en phase avec le raisonnement de Fred. Je tiens à le soutenir, car je ne comprends pas la virulence de certains commentaires.
Il faut distinguer les usages des langages.
Je précise ma pensée : les langages de scripts : AS, JS, Php, sont utilisés par les agences Web missionnées par leurs clients pour développer des interfaces évoluées en un minimum de temps en se basant sur des logiciels écrits par des éditeurs (comme adobe ou microsoft) en langages de « bas niveau », en général du C ou C++ qui eux doivent être optimisés et performants.
Ces deux catégories de langages sont fait pour des publics differents.
Je fait l’hypothèse que l’avenir de NaCl, est donc, peut-être, de faire tourner plus rapidement les animations flash ou Silverlight, qui ne seraient plus exécutés au sein d’un plug-ins, mais dans NaCl directement.
Adobe nous reserve une version du plug-ins flash pour NaCl ? Il est vrai qu’une animation Flash, a toujours du mal à bien tourner quand il y a bcp d’objets, des transitions, des transparences, … Votre avis m’interesse.
@Max : Tout ceci n’a rien n’a voir, d’où le tollé technique. Les transparences par exemple sont des ‘effets’ programmés en … C (ou C++). Ils tournent nativement, on aura beaucoup de mal a faire plus rapide (ils utilisent maintenant pour les version recentes de Flash la carte graphique, mais ce n’a pas toujours été le cas).
Que l’ont soit d’accord sur une chose : Native Client ne peut *pas* être plus rapide qu’un plugin à-la Flash. Par contre, la programmation DANS Flash utilise une virtual machine Javascript. En clair : Flash est écrit en C, C++, peut être meme assembleur, et ne peut, a algorithme equivalent, être plus lent que Native Client. La programmation de Flash par contre, se fait en javascript, la est toute la difference.
Tout ça pour dire que cet article est ecrit par quelqu’un qui ne connait pas le sujet, tout le monde sera d’accord, mais qui pourrait poser des questions importantes. Malheureusement, ce n’est pas le cas. Mais regardez … plus on raconte de conneries, plus on a de visites !
@J : puisque tu adoptes un ton méprisant évites de dire n’importe quoi genre ‘la programmation dans Flash utilise une virtual machine Javascript’ et ‘la programmation de Flash, se fait en javascript’. Renseigne toi et soit plus tolérant c’est utile dans la vie pour apprendre des autres.
Tiens, a part des problemes semantiques, je ne vois pas « n’importe quoi ».
Javascript == Ecmascript == ActionScript, au niveau du language. Precise donc ta pensée, cela serait peut etre utile aussi.
Javascript == ActionScript si tu veux mais dans ce cas n’accuse pas Fred de manque de rigueur.
A moins que le typage statique (optionel certes) ou le support des mots clès de visibilité ou encore les nombreux débats autour de feu ECMAScript 4 ne relèvent que de « problèmes sémantiques ».
Qui a la plus grosse?
Il y a différentes « écoles » les gars qui ont commencés avec C/C++ et qui jurent que par ça d’autres gars qui sont sur Java et ne jurent que par ça et encore d’autres gars qui sont sur flash et aussi ne jurent que par ça. Et en fait, c’est un peu pareil pour tous les langages, leurs « écoles », leurs « mondes », etc. et tres peu jouent bien avec les autres.
Mais ca va un peu plus loin que le classique flame « mon langage est meilleur et plus utilisé que le tien »,
là, on est plus au niveau de la plateforme :
– coder du C qui vise x86 (en general) c’est une plateforme
– viser la VM Java c’est une plateforme
– viser la VM .NET (CLR et DLR) c’est aussi une plateforme
– et flash, ca aussi, c’est une platforme
Je fais du flash depuis environ 8ans, mais ca m’empeche pas de coder aussi en C/C++, ce qui me gene dans l’article c’est de lire que C c’est une vieille techno dépassée, sans C et tous les outils codés en C je serais plutot malheureux. Ce qui me gene aussi c’est le manque d’infos concernant flash : Adobe au dernier MAX 2008 a sorti un petit projet appelé Alchemy qui permet de prendre du code source C/C++ et de le cross-compiler vers du bytecode qui tourne en natif dans la VM du flash player 10. Et récemment un gars a porté Lua avec ça ce qui permet donc d’executer/interpreter des scripts Lua dans Flash, oui comme le font bcp de jeux videos ecris en C/C++.
Le probleme avec un truc comme NaCI c’est que meme si c’est une bonne techno et que ca donne pas mal de potentiel, peu de gens pourront vraiment l’exploiter. Le gros avantage de Flash, c’est qu’avec un langage comme ActionScript basé sur ECMAScript, énormément de gens peuvent l’utiliser (meme si ils ne savent pas ce qu’ils font et meme si ils savent a peine programmer).
Je vais prendre un exemple sur le desktop avec le runtime AIR (meme VM que le plugin Flash et meme langage de prog), combien de gens peuvent vraiment programmer des applis cross-platform basé sur QT et le faire bien ? Je pense que le réponse est « peu », voir « tres peu ».
Prenez un plutot débutant en programmation, donnez lui un Flash CS3 et/ou Flex Builder + AIR et qlqs mois, et il arrivera a faire une petite appli cross-platform
maintenant prenez un dev C/C++ moyen, si a partir du moment où il arrive a arreter de dire que « flash c’est de la merde » il se met un peu a apprendre le langage AS3 et la platforme « flash », il pourra faire énormément de choses. Idem pour le dev AS3 qui est expérimenté mais connait surtout flash et rien d’autre, si il se met a apprendre C/C++ juste un tout petit peu, il pourra reutiliser tout un tas de bon code C, le cross-compiler avec Alchemy et le reutiliser dans Flash.
une technologie / un langage / une platforme n’est pas forcément antinomique d’une autre, un bon developpeur c’est surtout un developpeur qui peut programmer dans n’importe quel langage.
Bref, en mettant les petites gueguerre d’écoles de coté on peut jouer un peu avec tout le monde.
Personne ne voit ou ne veut parler des applications qui vont pulluller sur ce genre de techno ?
Je vois bien tout les boites de jeux vidéos coréennes incapable de publier un jeux au delà de l’alpha mais avec des bizness plan parfaitement adapté au causual gaming.
L’idée de fond est louable en soit, cela fait bien partie des technologie microsoft sortie 10 ans trop tôt (passport, xmlHttpRequest, …), l’idée d’une sand box pour du code en C, à l’instar des sandbox d’adobe AIR par exemple, pourrait potentiellement solutionner les problèmes des activX.
Malgré son concept et sa cible, il se peut tout de même que NaCl fasse le bonheur de très grande entreprise en lieu et place des technos de RIA que l’on connait bien. Traité plusieurs Go de donnéedans une interface flex n’est pas une bonne idée, malgré toutes les qualités de cette solution.
H
Tout à fait d’accord avec Zwetan.
Quand je suis passée du C++ à l’AS1, j’ai rien compris à l’AS1. Mais quand j’ai découvert l’AS2, j’étais aux anges et qu’est-ce que j’ai put rêver de l’AS3 quand on en parlait avant sa sortie !
C’est pourquoi, je crois sincèrement que NaCl a toutes ses chances. Ce n’est peut-être qu’un petit pas mais il se peu que ce soit le premier d’une grande course.
+1 pour Zwetan.
Alchemy permet déjà de porter un jeu comme Quake dans le runtime flash.Bon c’est qu’un début pas encore au point mais quand on pense à l’abondance des bibli C , on peut imaginer un énorme potentiel avec Alchemy.
Le C n’est pas mort (allons Fred ….), et une bonne techno est une techno adaptée au projet. :)
Et quand on vrai programmeur fait du Flash on oublie rapidement ce que des simples graphistes ont fait avec du Flash.
Merci pour la mention de Cmune :-) La vision du « Web OS » est en marche et au dela des jeux et des applications entreprise, c’est aussi la possibilite de faire tomber des barrieres – le meme contenu en ligne ou dans un widget, ou sur iPhone ! Si on regarde le track record de Google dans les environnements 3D (Lively), et le developpement poussif de Adobe / Flash et Microsoft / Silverlight, Unity3D semble idealement positionne pour le « Web 3.0 » – cross-platform, 3D et connecte.