Discussion :

[Stéphane le calme]

Chrome : un développeur de Mozilla estime qu'une nouveauté du navigateur viole l'ouverture du Web
que Google affirme défendre

Il y a quelque temps Google a présenté au public Blink, son fork du moteur de rendu WebKit.

Google a introduit en mars sa technologie PNaCI (Portable Native Client), le successeur de Native Client, pour accélérer la vitesse d'exécution des applications Web. Désormais, leur vitesse devrait presque égaler celle des applications natives s'exécutant sur un système d'exploitation grâce aux API Pepper.

La technologie serait alors idéale pour les développeurs désireux d'apporter des logiciels codés en C/C++, comme des moteurs de jeux vidéo ou même des logiciels de décompression audio, aux applications web.

Le 15 mai dernier, l'entreprise a annoncé que Chrome 29 embarquerait PNaCl, mais qu'il serait désactivé par défaut. Les utilisateurs seraient alors en mesure d'exécuter des modules PNaCl sur n'importe quelle page web, c'est-à-dire que les applications n'auront plus besoin d'être déployées par Chrome Web Store avant l'exécution de ces modules, explique Google dans son communiqué.

Robert O'Callahan, un hacker pour le compte de Mozilla, estime alors que les admirables principes de normes web, vantés par l'équipe de développeurs derrière Blink, seront relégués au second plan face aux priorités générales de Google sur Chrome.

Parmi ces principes bafoués on trouve par exemple « en pratique, nous nous efforcerons de faire en sorte que les éléments par défaut soient des standards ouverts ». Pourtant PNaCl et Pepper ne sont pas standard.

Pour lui, PNaCl et Pepper ne répondent à aucun des critères décrits par Blink comme diminuant le risque d'incompatibilité. Les sites pourraient donc ne pas fonctionner sur tous les navigateurs et, quand une technologie aura un problème de compatibilité, Google pourrait proposer un projet de norme de la technologie.

« Malheureusement, il semblerait que les principes de Blink ne s'appliquent qu'à Blink, pas à Chrome en général » dit-il, ajoutant par la suite « je suis triste parce que cela porte gravement atteinte à la valeur des bonnes intentions de l'équipe de Blink, une équipe de Google qui ne veut pas être un bon citoyen du web devra probablement trouver le moyen (…) de piétiner le bon travail de l'équipe Blink ».

Sources : billet de blog O'Callahan, annonce PNaCI, Blink

Et vous ?

Que pensez-vous de PNaCl ? Partagez-vous l'avis de O'Callahan ?

[Uther]

C'est malheureusement aussi mon avis, le fait que Google soit le seul maitre a bord ne permet pas d'en faire une technologie standard viable.

C'est d'autant plus dommage que le LLVM-IR, bien qu'il ne soit pas parfait non plus, me parait sensiblement plus adapté que le javascript(via asm.js), ou même Java pour servir de bytecode à la fois efficace, multi-langage et muti-plateforme.

[ferber]

Personnellement je trouve ça bien que google aille de l'avant et cherche a créer de nouvelle solutions qui plus est très efficace et bluffante pour native client. Et sympas comme Dart.
Après ces solutions finirons peut être a la poubelle dans 5 ans.
Après si on garde à l'esprit que certaines technologies de google ne tournerons jamais sur les autres navigateurs et si on informe bien ces utilisateurs qu'il faut utiliser chrome pour ces composants : tout vas bien.
Mais il ne faut surtout pas investir trop sur ces technologies, elle sont vouées a la mort si les principaux détracteur de flash les classes dans la catégories " Oeuvre du démons "...
A moins que google arrête de financer Firefox et qu'opera ferme boutique, la ça changerais peut être les carte du jeu.

[Paul TOTH]

C'est malheureusement aussi mon avis, le fait que Google soit le seul maitre a bord ne permet pas d'en faire une technologie standard viable.

C'est d'autant plus dommage que le LLVM-IR, bien qu'il ne soit pas parfait non plus, me parait sensiblement plus adapté que le javascript(via asm.js), ou même Java pour servir de bytecode à la fois efficace, multi-langage et muti-plateforme.

euh...d'après le lien donné pour PNaCl

PNaCl development uses an LLVM compiler infrastructure with a "compile → link → translate" workflow.

[Uther]

euh...d'après le lien donné pour PNaCl

PNaCl development uses an LLVM compiler infrastructure with a "compile → link → translate" workflow.

Je vois pas en quoi c'est contradictoire avec ce que j'ai dit.

[pcdwarf]

"compile → link → translate" ? dans du web ???

Rien que l'idée aurait fait frémir tout les experts en sécurité il y a 5 ans.
Aujourd'hui cette monstruosité (qui n'en est pas moins un tour de force technique) est accueillie avec enthousiasme...