L'équipe de WebKit présente son nouveau moteur JavaScript

Christophe Laporte |

La semaine dernière, nous évoquions le fait qu’Apple travaillait sur un nouveau moteur JavaScript. Jusqu’à présent, WebKit FTL JIT était présenté comme un projet expérimental permettant d’adresser les problématiques relatives au JavaScript d’une nouvelle manière. La grande nouveauté de ce moteur, c’est qu’il utilise LLVM comme compilateur Just In Time (JIT)

Hier, sur WebKit.org, WebKit FTL JIT a officiellement été présenté. Indiscutablement, le ton a changé concernant WebKit FTL JIT, qui est présenté comme le grand projet du moment. Filip Pizlo d’Apple indique que WebKit FTL JIT a été activé dans les nightly builds de Webkit pour iOS et OS X. Vu le timing, on ne serait guère étonné de voir ce moteur dans les prochaines versions de Safari pour OS X 10.10 et iOS 8.

Ce nouveau moteur dispose d’une nouvelle architecture : FTL pour Fourth Tier LLVM, possède une architecture à quatre niveaux contre trois pour la précédente. L’intérêt d’utiliser LLVM (Low Level Virtual Machine), c’est qu’il permettra de créer une machine virtuelle.

Cette partie du moteur de JavaScript ne sera appelée que dans certains cas. La compilation par LLVM nécessite du temps de calcul. Par conséquent, le moteur JavaScript l’appellera uniquement pour des tâches complexes où il sera beaucoup plus performant que les « autres moteurs ». Tout l’art d’un moteur JavaScript réside notamment dans le fait de recourir au bon élément pour exécuter du code.

Au final, l’idée est toujours la même : offrir des performances qui se rapprochent du code natif. Ce toujours plus de performances, Apple en a non seulement besoin pour que son navigateur web reste performant, mais aussi en tant qu’éditeur. La Pomme réalise sur le web des projets de plus en plus ambitieux. Le travail effectué par les développeurs d’Apple concernant iWork.com est assez impressionnant de ce point de vue.

avatar cecile_aelita | 

Le jour ou les script JavaScript seront aussi véloce que du code natif, on aura fait un bon de géant vers la problématique du portage inter-OS.
Plus besoin d avoir une version par système.

avatar hirtrey | 

@romainB84 :
Jamais

avatar thej8 | 

On y arrive presque, avec les initiatives comme node-webkit et son node.js.
Et personnellement, je pense que ce qui va nous sauver de tout cas ce sont les webapp et le cloud, on continuera surement à créer des clients par plateforme mais le gros du code sera du coté serveur comme c'est le cas de plus en plus.

avatar JLG47 | 

@romainB84

Justement avoir un langage compilable évite de devoir gérer un langage par système et version de système.
La compilation in fine permet de le faire en connaissance du système local.
Car il faudra toujours le compilateur ad-ok.
Et en contre partie, le programmeur n'a pas a s'inquiéter du système qui sera utilisé.
C'est la principale raison d'être de Java.

avatar PixelCat | 

Cet acronyme est aussi un joli clin d'œil pour les fans de SF : FTL veut aussi dire "Faster Than Light" (vitesse supraluminique)

avatar Corentin.R | 

@PixelCat :

Stop stargate ^^

avatar PixelCat | 

@Corentin.R :
Et bien d'autres encore ;)

avatar florian1003 (non vérifié) | 

C'est une révolution qui dort ...

avatar Ginger bread | 

Et les résolutions de bug et failles de securité ils sont dessus?

avatar sebMacNewGen | 

C'est bien d'avoir d'avantages de perfs mais je ne crois pas que l'on puisse atteindre un jour les perfs d'un code compilé.
D'autres part je ne crois pas non plus au remplacement généralisées des App natives par des webapp pour au moins 2 raisons. 1) la problématique des navigateurs qui ont tous des spécificités et donc un coût non négligeable lors du dev et 2) je pense que ce n'est pas dans l'intérêt d'Apple, Google, Microsoft... Car ils veulent garder leur magasins d'applications, aucun intérêt d'avoir des webapp cross plateforme et sur lesquelles ils ne feraient pas de profits et ou la distinction de plateforme n'aurait plus de sens.
C'est mon avis et il vaut ce qu'il vaut ;-)

avatar jackWhite92 | 

@sebMacNewGen :
Je suis d'accord, mais maintenir des apps sur des technologies hétérogènes coûte très cher. C'est risqué d'embaucher des spécialistes de chaque techno et la prestation coûte cher... Wait n See

avatar fornorst | 

Et surtout ça ne sera sûrement pas le choix de Google, Apple et Microsoft : les technos Web poussent très forts d'elles mêmes sans avoir besoin d'être soutenus par tel ou tel acteur. Il y a tellement d'enjeux et de projets Open Source autour de ces technos que le raz de marée qu'elles représentent n'en est qu'à ses prémices.

En terme de perfs, il fait rappeler qu'ASM.js, un subset de JavaScript pousse par Mozilla arrive à n'être que 2 fois plus lent que du code natif. Et c'était déjà il y a 6 mois ! Imaginez ce que LLVM pourrait faire dans quelques temps sur ce type de subset ! Vraiment, les perfs de JavaScript ne deviennent plus un problème pour les applications Web. Celles de CSS ne le sont plus depuis l'accélération matérielle. Il ne reste qu'à booster un peu le DOM et on va vraiment voir des choses énormes arriver !

avatar Jean-Jacques Cortes | 

L'intérêt de cette solution à base de JavaScript, est qu'elle affranchira les développeurs d'avoir à apprendre x langages de programmation et les x outils de développement spécifiques à chaque machine.
Avouez que JavaScript est quand même plus simple à apprendre qu'Objective C.

avatar BeePotato | 

@ Jean-Jacques Cortes : « L'intérêt de cette solution à base de JavaScript, est qu'elle affranchira les développeurs d'avoir à apprendre x langages de programmation et les x outils de développement spécifiques à chaque machine.
Avouez que JavaScript est quand même plus simple à apprendre qu'Objective C. »

Boarf… Non, JavaScript n'est pas tellement plus simple à apprendre qu'Objective C, qui n'est vraiment pas un langage difficile à maîtriser. Le gros de l'apprentissage pour les développeurs concerne plutôt les frameworks qu'ils utilisent et leurs API.

Notons que même si le monde passait vraiment à du tout « webapp », les développeurs cherchant du boulot se devraient tout de même d'apprendre plusieurs frameworks JavaScript parmi tous ceux disponibles.

Mais j'espère vraiment que ça n'arrivera pas, car ce serait une perte pour l'utilisateur (perte de diversité, de choix — mais surtout d'ergonomie).

avatar iRobot 5S | 

"L’intérêt d’utiliser LLVM (Low Level Virtual Machine), c’est qu’il permettra de créer une machine virtuelle."

Eh bien ! Ça pourrais permettre de lancer un système d'exploitation entier depuis le web à terme !

avatar Romain-Geissler | 

Oui j'avoue que j'ai aussi du mal à comprendre cette phrase de l'article. Il n'est clairement pas question de machine virtuelle au sens virtualisation d'OS, et je ne vois pas quel est l'intérêt si évident d'utiliser une machine virtuelle (dans le sens d'un CPU fictif avec un jeu d'instruction identique sur toutes les plateforme, exemple la Java Virtual Machine), si évident que l'auteur ne l'explique même pas...

avatar jackhal | 

Résultat sous le bench V8 : Webkit nightly est 28% plus rapide que Safari 7.0.3 sous OS X 10.9.3

Bon, c'est qu'un bench et V8 montre spécialement les progrès des moteurs Javascript (et encore qu'une partie).
La réalité et les benchs...

avatar Tatie_Danielle | 

Mieux que safari. Mais très en deçà de chrome sur tous les benchs que j'ai testé.

avatar Boumy | 

Il faudrait aussi qu'Apple décide de de ce qu'elle fait des roll over en Safari iOS. Non? Et de la gestion des uploads de photos par exemple, Un site comme Facebook est révélateur des lacunes de Safari iOS dans ces deux fonctions.

avatar 6ix | 

Le Web qui prend le dessus sur les apps natives, on l'entend depuis plusieurs années, et force est de constater qu'aujourd'hui les apps natives prennent largement le dessus.

Ça évoluera certainement, mais le Web qui remplace le natif, ce sera pas pour tout de suite malgré tout ce que l'on entend.

L'amélioration des performances est une chose. Mais le natif est également toujours plus performant, et surtout, on en demande toujours plus. Les apps ne se contentent plus d'afficher une liste en couleur, il y a des animations, des rendus floutés, l'accès à toutes sortes de capteurs matériels, etc.

L'autre point essentiel est l'intégration. Quand on a un iPhone, on veut une app intégrée au look iOS. Tout comme les apps Java ont l'air d'horreurs sur OS X, une app multi-plateforme n'aura jamais un design adapté à chaque plate-forme. Et cela par définition.

Donc même si cela coûte cher de développer pour iOS, Android, etc., ce n'est au final pas forcément plus complexe que d'avoir une app Web qui doit tout supporter. Ça demande des compétences différentes, mais ça permet d'avoir une vraie expérience utilisateur. Là où le Web pourra gagner du terrain est sur les apps relativement simples.

Ou alors en restant sous la forme de sites Web. Mais un site Web rajoute un intermédiaire: le navigateur.

avatar MacOSXI | 

Je viens de l'installer et bizarre, il est presque 20% plus lent que Safari 7.0.4 selon SunSpider : 250 ms vs 300 ms (il faut dire cependant que Safari 7.0.4 sous OS X 10.9.3b est plus rapide que Safari 7.0.3 la version publique sous OS X 10.9.2, et qu'il met plus de 50 ms à Firefox 30b qui devance déjà largement Chrome ! ).

Sous V8 Bench on a cette fois un léger avantage de 5% pour le nouveau moteur javascript de Webkit mais rien de significatif...

Bref, toujours en développement, comme indiqué !

avatar marc_os | 

@fornorst :
'Il ne reste qu'à booster un peu le DOM'

Qu'est-ce qu'il ne faut pas lire !
Pour Info, DOM ça veut dire Document Object Model.
En pratique c'est l'ensemble des objets chargés en mémoire par le navigateur pour représenter un document HTML. On a par exemple un objet par balise HTML et ils sont organisés de manière hiérarchique.
Non, on ne « booste » pas « un peu » un modèle !

CONNEXION UTILISATEUR