Un nouveau moteur JavaScript pour Safari dans les tuyaux ?
Les prochaines versions de Safari pour iOS et OS X pourraient être l’occasion d’un grand toilettage. Outre des changements dans le moteur de rendu qui pourrait devenir plus compact suite à la scission avec Google Chrome (lire : WebKit : que le grand ménage commence), Safari pourrait embarquer un tout nouveau moteur JavaScript.

FTLJIT, c’est son petit nom, est en cours de développement. La grande nouveauté, c’est qu’il utilise LLVM comme compilateur Just In Time (JIT). Les travaux ont débuté il y a plusieurs mois et FTL peut être testé à titre expérimental dans Webkit en suivant les instructions données sur cette page.
Un moteur JavaScript est en quelque sorte une fusée à plusieurs étages. Pour résumer grossièrement les choses, le compilateur JIT est appelé pour les tâches les plus lourdes. Utiliser un compilateur LLVM (le même qu’Apple utilise avec Xcode) devrait permettre d’améliorer significativement les performances. Ce qui est intéressant dans l’approche d’Apple, c’est que ce gain de performances n’est pas limité à asm.js, le fameux sous-ensemble JavaScript développé par la fondation Mozilla qui permet de maximiser les performances. L’idée est toujours la même : offrir des performances qui se rapprochent du code natif.
Les premiers tests sont prometteurs. Webkit équipé de FTLJIT, fait mieux que Chrome, mais est derrière Firefox quand celui-ci peut tirer parti d’asm.js. Il est de toute façon beaucoup trop tôt pour tirer quelques conclusions que ce soit.
Apple n’est pas la seule à expérimenter cette voie, Google étudierait également la possibilité de passer par LLVM. Pour comprendre tout le potentiel de LLVM dans cette affaire, nous vous recommandons la lecture de cet article : Emscripten : du C++ vers JavaScript via LLVM.
On ignore si Apple ira au bout de sa démarche et quand le cas échéant FTLJIT se trouvera au coeur d’une version finalisée de Safari. Enfin, on ignore tout de l’avancée de ce projet sur iOS.
Java être mieux optimisé ?
@patrick86 :
Javascript n'a absolument aucun rapport avec Java
@Pato49
Ni avec les LGBT ^^
@Pato49 :
Je sais. J'ai pas dit le contraire.
http://www.nanarland.com/ilsontdit/eauxsauvages/eauxsauvages.mp3
Qu'est-ce que cela changerait concrètement ?
Aujourd'hui, la plupart des plateformes essayent de converger leurs systèmes. Microsoft veut un code commun entre Windows et Windows Phone.
Ubuntu converge avec Ubuntu Desktop et Ubuntu Touch.
Donc si on code une application pour l'ordinateur, logiquement, elle fonctionnera sur le mobile sans changer quoi que ce soit.
Au niveau du site web, vu que l'article parle de ça, je ne comprend pas du tout. Un site web, qu'il soit visualisé sur PC ou mobile, ne change pas de code et ne l'a jamais fait...
javascript est un langage interprété.
Je dirais que javascript est compilé dynamiquement. Ca fait longtemps que ce n'est plus interprété!
@nono68200 :
Beaucoup de sites s'adaptent au mobile en changeant du code JS.
@jackWhite92
C'est plutôt grâce au media queries du CSS3 que les sites s'adaptent.
@nono68200
Quel rapport avec l'article?
Il est question ici d'améliorer la rapidité d'exécution de JavaScript, pas de compatibilité entre navigateurs ou autres...
Autant pour moi, j'ai lu l'article qui était en lien sur cet article, et cela m'a embrouillé.
Donc le but de ce changement serait tout simplement d'avoir du javascript plus rapide, c'est ça ?
C'est cool d'autant que safari a déjà amélioré sa vitesse
Safari est plus rapide
FTLJIT = Faster Than Light Just In Time ?