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)?
Par «APIs DOM» je veux dire les APIs exposées à JavaScript par les navigateurs. Du coup bien entendu que WebGL en fait partie, et comme asm.js est un sous-ensemble de JavaScript, cela ne fait aucune différence: le code asm.js a accès exactement aux mêmes APIs que n'importe quel code JavaScript.
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.
C'est déjà fait dans Nightly et c'est un compilateur ou plutôt une nouvelle passe de compilation ajoutée à IonMonkey (initialement appelée OdinMonkey). L'intérêt d'être un sous-ensemble de JavaScript reste que le code asm.js tourne sans condition sur tous les navigateurs.
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).
Je ne sais pas ce que tu veux dire par «en mode interprété». De plus en plus, dans la plupart des navigateurs, tout le code JavaScript est compilé, asm.js ou pas. D'ailleurs depuis hier il n'y a même plus d'interpréteur JS dans Gecko.
Comme je l'ai expliqué dans mon journal, même dans un navigateur dépourvu d'optimisations spécifiques asm.js, le code asm.js tend à tourner un peu plus vite que du JS normal, grâce à son typage implicite que la plupart des moteurs JS sont capables de reconnaître partiellement. Les optimisations asm.js ajoutées à Gecko ne font que formaliser ça pour le rendre systématique.
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).
«Pas si facile que ça» est un euphémisme. PNaCl essaye d'utiliser le langage intermédiaire de LLVM sur le Web, or les devs de LLVM ont clairement indiqué que c'était une mauvaise idée.
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.
Admettons un instant que PNaCl sorte en vrai. Le problème de portabilité de NaCl serait alors résolu, mais il resterait le problème que ça requiert le support des APIs Pepper, qui, comme je l'ai expliqué, est inacceptable pour tout autre développeur de navigateurs que Google, puisque ces APIs sont contrôlées par Google seul. Donc oui, Mozilla rejetterait ça même si asm.js n'existait pas, et oui ça serait parce que Mozilla n'aurait pas le contrôle nécessaire sur ces APIs, mais soyons clair, tu ne peux pas blâmer Mozilla pour ça: il est sain pour un développeur de navigateurs de rejetter une technologie qui implique de brader son influence au profit d'un concurrent, car il est sain que les APIs du Web soient contrôlées par tous les développeurs de navigateurs et non par un seul. Dans le monde réel maintenant, comme asm.js existe, Mozilla n'aurait même pas à invoquer ces raisons, puisqu'il suffirait de dire que comme PNaCl n'apporte rien qui ne puisse être fait avec asm.js et requiert bien plus de travail dédié, c'est simplement une mauvaise idée.
[^] # Re: Pas convaincu
Posté par Benoit Jacob . En réponse au journal La stratégie de Mozilla pour les jeux vidéo sur le Web ouvert. Évalué à 5. Dernière modification le 04 avril 2013 à 15:29.
Par «APIs DOM» je veux dire les APIs exposées à JavaScript par les navigateurs. Du coup bien entendu que WebGL en fait partie, et comme asm.js est un sous-ensemble de JavaScript, cela ne fait aucune différence: le code asm.js a accès exactement aux mêmes APIs que n'importe quel code JavaScript.
C'est déjà fait dans Nightly et c'est un compilateur ou plutôt une nouvelle passe de compilation ajoutée à IonMonkey (initialement appelée OdinMonkey). L'intérêt d'être un sous-ensemble de JavaScript reste que le code asm.js tourne sans condition sur tous les navigateurs.
Je ne sais pas ce que tu veux dire par «en mode interprété». De plus en plus, dans la plupart des navigateurs, tout le code JavaScript est compilé, asm.js ou pas. D'ailleurs depuis hier il n'y a même plus d'interpréteur JS dans Gecko.
Comme je l'ai expliqué dans mon journal, même dans un navigateur dépourvu d'optimisations spécifiques asm.js, le code asm.js tend à tourner un peu plus vite que du JS normal, grâce à son typage implicite que la plupart des moteurs JS sont capables de reconnaître partiellement. Les optimisations asm.js ajoutées à Gecko ne font que formaliser ça pour le rendre systématique.
«Pas si facile que ça» est un euphémisme. PNaCl essaye d'utiliser le langage intermédiaire de LLVM sur le Web, or les devs de LLVM ont clairement indiqué que c'était une mauvaise idée.
Admettons un instant que PNaCl sorte en vrai. Le problème de portabilité de NaCl serait alors résolu, mais il resterait le problème que ça requiert le support des APIs Pepper, qui, comme je l'ai expliqué, est inacceptable pour tout autre développeur de navigateurs que Google, puisque ces APIs sont contrôlées par Google seul. Donc oui, Mozilla rejetterait ça même si asm.js n'existait pas, et oui ça serait parce que Mozilla n'aurait pas le contrôle nécessaire sur ces APIs, mais soyons clair, tu ne peux pas blâmer Mozilla pour ça: il est sain pour un développeur de navigateurs de rejetter une technologie qui implique de brader son influence au profit d'un concurrent, car il est sain que les APIs du Web soient contrôlées par tous les développeurs de navigateurs et non par un seul. Dans le monde réel maintenant, comme asm.js existe, Mozilla n'aurait même pas à invoquer ces raisons, puisqu'il suffirait de dire que comme PNaCl n'apporte rien qui ne puisse être fait avec asm.js et requiert bien plus de travail dédié, c'est simplement une mauvaise idée.