Microsoft a annoncé hier soir son intention d’intégrer le support du moteur JavaScript asm.js au sein de son propre moteur Chakra. Un important mouvement qui pave la voie non seulement à une coopération plus étroite avec Mozilla, mais également à une interopérabilité renforcée sur la toile. Explications.
Jamais Microsoft ne s’est autant investi dans les consensus. Les prémices de ces changements ont plusieurs années, mais au bout d’un an de Satya Nadella à la tête de l’entreprise, la nouvelle philosophie est manifeste : il faut être partout et prendre en charge tout ce qui est ou peut être intéressant ou très utilisé. Dans le cas présent, il s’agit d’asm.js, un sous-ensemble de JavaScript qui se présente sous la forme d’un langage intermédiaire.
Des applications web presque aussi rapides que du code natif
Quel est l’intérêt de ce projet développé chez Mozilla ? Augmenter tout simplement les performances des applications web afin qu’elles se rapprochent autant que possible de ce que l’on aurait nativement dans un logiciel équivalent. Pour cela, asm.js propose aux développeurs d’utiliser des langages à typage statique et à gestion manuelle de la mémoire, puis de les transcrire directement en JavaScript. Avec un langage tel que le C, le gain de performances est notable et provient en bonne partie de l’inutilité de recourir au ramasse-miettes, et pour le moteur d’effectuer les traditionnelles opérations sur les types dynamiques. Par ailleurs, tout langage compilable par LLVM peut être utilisé.
Et Microsoft s’enthousiasme. D’une part, parce qu’asm.js apporte justement un gain de performances manifeste et que sa prise en charge pourrait permettre de l’utiliser dans un plus grand nombre de scénarios. D’autre part, parce que le projet est vraiment un sous-ensemble du JavaScript et que son interopérabilité est, de ce fait, garantie entre toutes les plateformes et tous les navigateurs qui l’utiliseront. « Ce qui signifie que les moteurs qui supportent asm.js activeront les nouvelles fonctionnalités, tandis que ceux qui ne le font pas pourront fonctionner avec des performances moindres » indique ainsi l’éditeur.
Microsoft et Mozilla main dans la main
La firme indique que le support d’asm.js était le résultat d’une requête figurant dans le Top 10 de l’IE Suggestion Box. Conséquence, Microsoft travaille déjà depuis des mois avec l’équipe de Firefox afin de l'inclure dans Internet Explorer. Le statut de la fonctionnalité est d’ailleurs passé à « In Development » hier, mais la société ne donne aucune indication sur la disponibilité réelle. Il y a cependant de fortes chances qu’asm.js apparaisse avec une nouvelle préversion de Windows 10 dans Internet Explorer et Spartan.
Les réactions à l’annonce de Microsoft sont particulièrement positives, y compris du côté de chez Mozilla. La fondation se dit très enthousiaste, elle aussi, de ce partenariat rapproché, et ce, pour deux raisons : premièrement, il s’agit d’un vrai travail conjoint qui va mener à des optimisations sur asm.js, qui produira donc à terme de meilleures performances. Deuxièmement, et il s’agit d’un argument tout aussi important, l’adoption d’asm.js par Redmond va nettement augmenter la visibilité de la technologie, ce qui devrait accélérer son adoption.
Commentaires (81)
#1
Allez, je vois d’ici les rageux qui vont dire “MS récupère une idée du libre pour le mettre dans son IE pourri” …
" />
Jamais contents
#2
Une très bonne nouvelle qui permettra une adoption à un très large publique de ce moteur flambant neuf. J’ai vraiment hâte de voir le WEB évoluer ces prochaines années, ça promet (dans le bon comme dans le mauvais mais bon, c’est une autre histoire).
#3
Tu serais pas entrain de nous faire le coup de l’épouvantaillequand même 
" />
#4
A force de flirter en s’envoyant des gâteaux, je ne suis même pas étonné de voir l’union consommée. :)
#5
Encore une fois mozilla permet l’amélioration du net, et après on dira que firefox ne sert a rien et est mort, j’ai hate de voir le prochain project de mozilla aboutir (shumway)
#6
Mince, mon smiley n’était donc pas suffisant :)
En fait, certains souhaitent que MS abandonne son moteur pour prendre un truc libre.
Là, MS va récupérer une idée, et la mettre dans son moteur, ce qui risque de faire rager, alors qu’en fait MS progresse dans le bon sens.
D’où le “jamais contents”
#7
Attend de voir des gens pas content avec de dire “jamais content” 
" />
#8
Si j’ai bien compris, asm.js est un nouveau moteur JS qui compile le code JS des pages en langage natif ?
Une sorte d’AOT finalement ? Le JS actuel étant compilé à la volée (JIT) ? Ou simplement interprété ?
#9
M&M$… ça donne faim! :p
#10
Et tout le monde est content pour une fois
Je l’avais deja dit dans une precedente news, mais asm.js c’est un truc bancal qui va servir juste à ralentir l’arriver de quelque chose de concret pour executer du code natif sur le web…
Donc y’a aucune alternative parfaite existante, mais tout de meme: c’est de la merde…
Du coup je suis à moitié content… voila.
#11
Bonne nouvelle, j’attends surtout ça coté mobile, dès qu’une appli devient un peu lourde en javascript elles deviennent poussive en web mobile (surtout lorsque l’on cumule les librairies..)
#12
Je ne peux rien garantir, mais je comprends que asm.js compile du code qui est soit natif si le navigateur le supporte, soit en js le cas échéant.
Donc si par exemple tu as le code C++ de Doom, dans IE il sera compilé en binaire et exécuté depuis le navigateur, alors que dans Midori, navigateur au support js limité, le code C++ sera compilé en JS avant d’être exécuté. Autrement dit, d’un point de vue utilisateur dans les deux cas ça fonctionne, c’est juste la vitesse d’exécution qui change.
#13
Très bon ça. Au lieu de travailler à développer une solution concurrente, travaillez plutôt ensemble à des solutions ouvertes et pérennes. Les utilisateurs vous en remercient
" />
#14
Si seulement le moteur graphique de IE n’était pas si mauvais (hors tablette)… même si ça fait bizarre, ça fait presque peur de lancer IE quand on est un vieux de la vieille 
" />
#15
Sophisme de l’épouvantaille: représenter la position de ton interlocuteur de façon fausse, et s’en servir pour montrer que sa position n’est pas logique
Ce que je te dis c’est que les gens ne reprochent pas au moteur de IE de piquer les bonnes idées : ce qu’on leurs reproche c’est de pas suivre les standards
Quand ils suivent les bonnes initiatives, je ne pense pas que tu trouveras des gens qui se plaindront…
#16
#17
asm.js servira également à améliorer les performances des applications WinJS et donc du runtime WinRT pour ces applications là.
#18
#19
#20
asm.js est un sous-ensemble de JS, donc toujours un langage.
Avec LLVM (C/C++/autres -> bytecode) et emscripten (bytecode -> asm.js) tu peux transcompiler du natif vers asm.js, et donc JS.
#21
Même pas 
" />
#22
C’est sandboxé hein, tu passe par le contexte du navigateur pour avoir accès aux ressources, c’est pas parce que le traitement est fait de maniere native que tu peux tout te permettre…
Par exemple si tu fais un fopen() dans firefox, dans le meilleur des cas il va te crée un systeme de fichier en memoire…
#23
Comparer (les perfs de) JS et le C en résumant ça à une histoire de ramasse miettes et de typage ‘dynamique’, c’est quand même sacrément réducteur
" />
#24
Dire que la demande asm.js est dans le top 10, quand on voit que “Use blink” arrive en 3è position… J’espère bien que JAMAIS MS n’utilisera blink comme moteur… Qui consomme beaucoup trop.
Sinon intégrer des compatibilités supplémentaires, ça ne va que dans le bon sens, surtout s’ils contribuent à l’améliorer :)
#25
#26
M’en parle pas, je m’étonne moi-même : j’ai abandonné Apple, j’ai construit ma machine moi-même comme il y a 15 ans, je fais tourner Windows 8.1 et j’utilise la suite Office. Même un oracle n’aurait pas pu prédire ça lol.
Sérieux chez Crosoft, ils font de vrais efforts en ce moment, on peut les détester mais on ne peut nier cela.
#27
Ah, c’est pas le retour du texte clignotant qui est demandé ?
" />
#28
désolé, j’ai le chef qui rodait j’ai tapé le texte rapidement 
" />
#29
#30
#31
Des applications web presque aussi rapides que du code natif
D’après ce que j’avais lu, ça serait quand même entre 2 et 6 fois plus lent.
#32
Contre combien aujourd’hui?
#33
Je lis ici pas mal de choses differentes sur ASM.JS. Je vais essayer de reexpliquer l’idée:
asm.js c’est du javascript, que tu peux executer dans n’importe quel navigateur gérant javascript. Toutefois, asm.js se limite à seulement une partie du javascript suffisante pour faire des applis, mais à laquelle manque beaucoup de fonctionnalités bien pratiques pour le développeur (globalement des trucs qui simplifient la vie)
Toutefois un compilateur C++ peut facilement générer de l’asm.js, de même qu’un compilateur java ou C#.
Quand le navigateur rencontre de l’asm.js, il sait qu’il n’a affaire qu’à une partie du langage js qui peut facilement être compilée en natif, sans avoir besoin de binding dynamique. Donc il se sert à ce moment là de ce savoir pour optimiser un max. Il considère asm.js comme un langage intérmediaire (comme le bytecode java ou l’IL .NET) et compile à la volée une version native de l’application.
En théorie, il peut alors générer une application ayant des performances sensiblement équivalentes à une application native. En pratique on n’en est pas encore là, mais je crois personnellement beaucoup en cette techno, qui correspond à quelque chose dont je rêvais personnellement depuis des années _
#34
#35
Je considère .NET comme du natif.
#36
Très bonne nouvelle 
" />
#37
c’est complémentaire ou concurrent à typescript ?
#38
Plus serieusement oui c’est sandboxé, oui il y a du bound checking. Toutefois, je me permettrais de signaler que le natif peut parfaitement être sandboxé, et que je considère personnellement l’absence de bound checking (que ce soit dans le runtime ou dans le code lui même) comme un risque de sécurité.
#39
Ils ont pas du tout le meme objectifs, et les deux peuvent interagir ensemble sans aucun probleme (en passant par du js).
#40
Complémentaire
Typescript te permet d’ajouter une couche typée à javascript, et génère du javascript “lisible” et trés proche du typescript initial.
Asm.js est une sorte d’assembleur javascript pas trés lisible généré à partir de langages autres, qui ne supporte pas certaines fonctionnalités js comme le typage dynamique (mais je ne suis pas absolument sûre du dernier point)
#41
ok. Je m’auto réponds. Typescript, c’est server side. asm.js est client side
Donc, ça peut être complémentaire
#42
on est d’accord, mais t’es plus rapide
#43
Heu non non… Les deux peuvent etre utilisé coté serveur et coté client…
#44
Effectivement, il vaut lieu faire comme google. Créer ses propres standards quand on a le vent en poupe. Schinter le w3C, parce qu’ils sont chiant à mettre du temps à créer des standards. Et finir en disant que Microsoft ne respecte pas les standards, parce que le site full standard Google est pas compatible mozilla et ie.
L’avantage c’est qu’avec la réputation issue de IE6 que MS se coltine, au lieu de dire : Google impose des choses qui ne sont pas standards. Les gens disent : Microsoft ne respecte pas les standards.
Moi je comprend que Microsoft et mozilla ne respecte pas pleinement les standards de Google, ça me rassure.
#45
#46
C’est une bonne nouvelle, merci Satya
" />
#47
En attendant, le moteur de Firefox est une tortue comparé à V8…
#48
Ben désolé, mais je fais du dev js dans une grande part de mon travail sur des applications complexes d’entreprise, ce n’est pas ce que je constate.
dans l’ensemble ce que je peux voir est que chaque moteur optimise certains traitements. Dans l’ensemble Firefox se débrouille mieux au niveau de la mémoire, pour ce qui est des perfs js à proprement parler on sent bien que chaque moteur a optimisé (ou pas) certaines choses. par exemple certains traitement js sont particulièrement rapides sur FF et bizarrement lent sur V8, ou l’inverse (par exemple dans la manière dont ils optimisent les boucles sur l’interprétation des variables du for ou l’inclusion de fonctions appelées dans la boucle).
pour moi, à part parfois chakra qui à pourtant pris du grade ces dernières années, les principaux problèmes de perfs que je vois sont plus lié au programmeur qu’au moteur js.
chose intéressante dans le billet msdn, le fait d’avoir 2 moteurs, dont un qui prends le relais si le traitement est amené à être répété. C’est basique comme approche, mais particulièrement pragmatique en termes de résultats.
#49
#50
Pareil je fais du dév et franchement, ça dépends ce que l’on fait. Pas contre sur le rendu HTML, Chrome à clairement de l’avance, c’est ce qui donne parfois l’impression que Firefox se traîne… On peut le constater sur un test comme ça :http://sinz.org/Maze/table.html (Enfin, sous Linux Firefox et 2 à 10× plus lent sur le rendu du DOM suivant les cas… et j’aimerais bien que ça bouge de ce côté)
#51
en effet, mais chacun a son implémentation, et lorsque l’on profile les application on sent grandement la différence. après faut être pragmatique aussi, et sorti du mobile ou chaque 10ème de seconde compte, n’importe qui n’est pas facebook…
#52
ok mais demander de la même manière à M$ de prendre Blink comme moteur graphique est désastreux… le problème avec Google est qu’ils semblent avoir la main sur ce que l’on doit considérer le web comme étant conforme. et pour ma part cela me semble beaucoup trop orienté comme démarche.
Ils proposent de nombreuses “google experiments” dont ils pourraient y avoir un équivalent sur les autres moteurs de rendu, et ce n’est pas leur but… cela me dérange au plus haut point.
#53
#54
Comme dit plus haut dans les commentaires, ca me parait être un un truc bancale en attendant qu’un vrai langage de type “bytecode” soit géré par les browser web.
Cette idée que javascript est la solution a tout (dhtml, appli web coté client, appli coté serveur, bytecode), ca me fait penser à Maslow: “Quand le seul outil que vous avez est un marteau, tous les problèmes ressemblent à un clou”.
#55
quand je vois que certains pensent qu’on “tout” ce qu’on reprochait à IE6 c’est “d’imposer sa vision au marché”, je me dis que certain ont la mémoire courte 
" />
" />
" /> et les features innovantes des navigateurs concurrents restaient PLOMBES par la NÉCESSITE de maintenir le dinosaure 
" />
" />
Ce que tout le monde a reproché à IE6 c’est que la version “visionnaire” de IE6 sortie en 2001 n’a pas eut de mise à jour avant 2006 .
donc les “petits bugs” de 2001, sont devenu le “standard de FAIT” de 2006
Si IE 6 n’avait été “qu’une version”, et si fort de sa position dominante Ms n’avait pas considéré que le web “n’évoluait plus” pendant 5 ANS !!!! IE n’aurait pas la réputation qu’il a aujourd’hui …
Le vrai souci de Internet explorer ce n’est pas “son moteur” … c’est IE6 … et le temps qu’il a fallu pour arriver à “remonter au niveau des concurrents”
#56
#57
Ok, merci pour ces informations
" />
#58
Peut-on, une fois, breveter un script ? Ce n’est pas une idée, mais du concret
" />
#59
#60
#61
#62
Je ne dis pas le contraire, je trouve le rendu Blink affreux.
#63
Tu as des exemples ?
#64
#65
#66
#67
#68
#69
#70
( au passage, vu l’incapacité de CrowTown à s’exprimer sans traiter les autres de con, dans l’hypothése où le blocage sur une news fonctionne à nouveau, il a encore perdu le droit de commenter sur cette news)
#71
Honnêtement, les benchmarks je m’en fiche totalement. Quand il s’agit par exemple de faire des animations, et donc une tâche critique, le moteur JS de Firefox est infiniement plus lent que V8, benchmarks ou pas.