Re: Pas convaincu

J'ai du mal à comprendre ce que tu cherches à critiquer ici

Le message auquel je reponds juste au dessus (dont l'auteur n'a pas du prendre le temps de lire l'intro de la spec), ainsi que la partie de ton journal qui dit "Le code asm.js utilise les mêmes APIs DOM que n'importe quel code JavaScript."

J'ai peut-etre compris la spec completement a l'envers, mais quand je lis les autres commentaires dans le journal j'ai l'impression que les gens mettent un peu tout et n'importe quoi dans l’appellation 'APIs DOM' (et melangent WebGL, JavaScript 'normal' et modules asm.js).

Qu'est ce que tu entends par "utilise les memes APIs"? Qu'un module asm.js peut utiliser une grande partie des APIs DOM (sans tourner en version interpretee)?

Non content d'introduire son propre langage intermédiaire, ce qui est inutile comme je viens de l'expliquer

Disons que pour faire quelque chose du niveau de asm.js, c'est en effet pas forcement interessant de specifier son propre format de bytecode. Cela-dit, Mozilla prevoit d'ecrire un parseur separe pour les modules asm.js, du coup on voit plus trop l'interet d'etre un sous-ensemble de javascript.

Finalement c'est plutot pour des raisons de strategie: etre pret rapidement en reutilisant l'infrastructure existante, communiquer sur le fait que ca marche partout en mode interprete (on rigole, parce que le moteur Unreal 3/4 qui tourne avec la version interpretee en haute resolution, j'attends quand meme de voir).

C'est tres probablement une strategie gagnante. Au niveau technique j'ai tendance a trouver ca un peu degeu, mais si ca permet une adoption par tous les navigateurs rapidement, ca se discute pas :)

Native Client introduit un langage intermédiaire séparé pour chaque architecture (le code machine)

C'est pour ca que Google bosse sur PNaCl depuis un moment (oui, c'est pas si facile que ca et c'est toujours pas pret - voir au dessus pour mon avis sur la meilleure strategie).

Native Client introduit aussi son propre ensemble d'APIs, Pepper, remplaçant les APIs DOM, ce qui sape l'influence des autres développeurs de navigateurs

Ce qui gene Mozilla c'est qu'ils n'ont aucun controle dessus, pas le fait que ca soit de nouvelles APIs. Si lorsque PNaCl est stabilise Google essaye de standardiser tout ca, Mozilla serait toujours aussi contre.

J'ajoute que cet article est vraiment mon opinion personnelle

Si j'ecris un journal pour parler des trucs biens que fait ma boite et critiquant la concurrence (developpement ferme, pas standard), ca sera peut-etre mon avis personnel mais ca fera la comm' de ma boite.

Ce que tu decris dans ton journal est tres interessant (j'ai pertinente), mais les parties non techniques s'averent etre exactement l'axe de comm' de Mozilla. Ca ne veut pas dire que tu repetes betement la comm' mais:

• quand tu bosses dans une boite, c'est normal de discuter ou de se renseigner sur ce que font les collegues et d'etre enthousiasme par les trucs innovants sur lesquels ils bossent. Les-dis collegues ne vont pas evidemment pas dire que ce qu'ils font c'est tout pourri et que la concurrence fait mieux.
• Mozilla et Eich critiquent tres fortement et depuis longtemps NaCl et sont categoriquement oppose au concept (surprise surprise).

Bref, ca a beau etre ton avis perso, c'est aussi dans la ligne de l'entreprise (et ne soyons pas naifs, en tant qu'employee de Mozilla si tu etais tres critique vis a vis de la strategie de ta boite, tu viendrais pas poster sur LinuxFR).

Desole si ca fait tres critique envers ta demarche, je pointe juste que certaines des critiques que tu fais n'ont rien d'objectif. J'ai d'ailleurs le meme avis sur les personnes qui par exemple sont toujours promptes a critique web/internet et deviennent mysterieusement silencieuses des que ca parle de sauvegarde de la vie privee et tracking des utilisateurs…

Donc continue a poster des journaux sur ce que fait Mozilla, je les lis avec plaisir :)