Oui, parceque la partie bytecode de asm.js quand elle est compilée avec les optimisation AOT fait référence à une autre VM (enfin un chemin tellement différent dans la VM que l'on pourrait séparer les deux - si d'ailleurs asm.js a du succès il est probable que c’est ce qui se passera)
Alors que asm.js est lui même 100% compatible javascript.
Et si on te propose les 2 : les perfs ET sans compilation ?
En fait les choix sont plutôt
coté asm.js les bons points : Mozilla + perf + comptabilité avec l'existant + nombreuses preuves de ce qui a été fait (je pense notamment à la démo banana bread optimisée et à la démo Epic citadel). Avec en défaut : langage pénible à écrire (même en passant par LLJS c'est pas top) chaine de compilation compliquée à mettre en place (ca devrait s'arranger très vite si le langage a du succès)
et coté dart les bons points : perf + langage relativement agréable à écrire + pas de chaine de compilation à mettre en place (donc test et debug grandement accéléré); et en mauvais mauvais points : double rupture avec l'existant (Non seulement il faut implémenter Dart dans les nouveaux navigateurs pour en tirer parti, mais en plus toutes les étapes de manipulation DOM et events sont à réapprendre), google (on sait ce qui se passe quand une techno google a le succès escompté, on sait aussi ce qui se passe quand elle ne l'a pas), pas d'exemple "real life" (les exemple donnés sont pour le moins simplistes, pas moyen de trouver de "gros" exemple sur le web).
Les deux ont des avantages et des défauts, masi j'aurais plus tendance à croire en asm.js qu'en dart.
[^] # Re: Petite digression sur asm.js
Posté par Kaane . En réponse au journal Normalisation du langage Dart de Google par l'Ecma. Évalué à 4. Dernière modification le 30 décembre 2013 à 10:23.
C'est l'emploi du mot "bytecode" qui te choque ?
Oui, parceque la partie bytecode de asm.js quand elle est compilée avec les optimisation AOT fait référence à une autre VM (enfin un chemin tellement différent dans la VM que l'on pourrait séparer les deux - si d'ailleurs asm.js a du succès il est probable que c’est ce qui se passera)
Alors que asm.js est lui même 100% compatible javascript.
Et si on te propose les 2 : les perfs ET sans compilation ?
En fait les choix sont plutôt
coté asm.js les bons points : Mozilla + perf + comptabilité avec l'existant + nombreuses preuves de ce qui a été fait (je pense notamment à la démo banana bread optimisée et à la démo Epic citadel). Avec en défaut : langage pénible à écrire (même en passant par LLJS c'est pas top) chaine de compilation compliquée à mettre en place (ca devrait s'arranger très vite si le langage a du succès)
et coté dart les bons points : perf + langage relativement agréable à écrire + pas de chaine de compilation à mettre en place (donc test et debug grandement accéléré); et en mauvais mauvais points : double rupture avec l'existant (Non seulement il faut implémenter Dart dans les nouveaux navigateurs pour en tirer parti, mais en plus toutes les étapes de manipulation DOM et events sont à réapprendre), google (on sait ce qui se passe quand une techno google a le succès escompté, on sait aussi ce qui se passe quand elle ne l'a pas), pas d'exemple "real life" (les exemple donnés sont pour le moins simplistes, pas moyen de trouver de "gros" exemple sur le web).
Les deux ont des avantages et des défauts, masi j'aurais plus tendance à croire en asm.js qu'en dart.