J'ai du mal à comprendre ce que tu cherches à critiquer ici. On n'a jamais dit que le JS à la asm.js était «différent» d'un bytecode: la question n'a pas de sens, comme je vais essayer de l'expliquer maintenant. On n'a jamais non plus critiqué l'idée en soi d'utiliser un «bytecode» dans la mesure où ce «bytecode» serait vraiment utile et n'aurait pas d'inconvénient rédhibitoire. L'idée poursuivie par Mozilla ici est que tout langage peut être compilé vers tout langage, et donc en particulier que tout langage peut servir de «bytecode». À partir de là, on ne voit pas à quoi bon introduire un nouveau «bytecode» ou, pour utiliser un terme plus approprié, un nouveau «langage intermédiaire», puisque JS peut très bien remplir ce rôle. Tout langage peut être utilisé comme «bytecode», il suffit de savoir décompiler du code compilé vers ce langage. C'est clair?
Parlons maintenant de Native Client. Non content d'introduire son propre langage intermédiaire, ce qui est inutile comme je viens de l'expliquer, Native Client introduit un langage intermédiaire séparé pour chaque architecture (le code machine) ce qui casse la portabilité du Web, et 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. Voilà les raisons pour lesquelles Mozilla est résolument décidé à contrer Native Client. Tu peux en penser ce que tu veux, mais c'est cohérent avec les buts que Mozilla s'est fixés. J'ajoute que cet article est vraiment mon opinion personnelle: je n'en ai parlé à aucun collègue et la «comm» n'est pas mon métier.
[^] # 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é à 9. Dernière modification le 04 avril 2013 à 03:34.
J'ai du mal à comprendre ce que tu cherches à critiquer ici. On n'a jamais dit que le JS à la asm.js était «différent» d'un bytecode: la question n'a pas de sens, comme je vais essayer de l'expliquer maintenant. On n'a jamais non plus critiqué l'idée en soi d'utiliser un «bytecode» dans la mesure où ce «bytecode» serait vraiment utile et n'aurait pas d'inconvénient rédhibitoire. L'idée poursuivie par Mozilla ici est que tout langage peut être compilé vers tout langage, et donc en particulier que tout langage peut servir de «bytecode». À partir de là, on ne voit pas à quoi bon introduire un nouveau «bytecode» ou, pour utiliser un terme plus approprié, un nouveau «langage intermédiaire», puisque JS peut très bien remplir ce rôle. Tout langage peut être utilisé comme «bytecode», il suffit de savoir décompiler du code compilé vers ce langage. C'est clair?
Parlons maintenant de Native Client. Non content d'introduire son propre langage intermédiaire, ce qui est inutile comme je viens de l'expliquer, Native Client introduit un langage intermédiaire séparé pour chaque architecture (le code machine) ce qui casse la portabilité du Web, et 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. Voilà les raisons pour lesquelles Mozilla est résolument décidé à contrer Native Client. Tu peux en penser ce que tu veux, mais c'est cohérent avec les buts que Mozilla s'est fixés. J'ajoute que cet article est vraiment mon opinion personnelle: je n'en ai parlé à aucun collègue et la «comm» n'est pas mon métier.