WebKit : de la vibration et une nouvelle architecture JavaScript
WebKit évolue à toute vitesse ces temps-ci. Sur le blog Surfin' Safari, Peter Beverloo détaille les derniers changements apportés au moteur de rendu de Safari.
Parmi les récentes améliorations, une nouvelle API a récemment fait son apparition. Il s'agit de Vibration. Comme son nom peut le laisser entendre, elle permet de faire vibrer un terminal mobile. Voilà qui peut être intéressant dans certains cas.
D'autre part, JavaScriptCore utilise désormais une machine virtuelle à trois niveaux. Elle comporte un nouvel interpréteur bas niveau qui est 2 à 2,5 fois plus performants que le précédent. LLInt exécute le code dans un premier temps, et le transmet au compilateur Just In Time uniquement si cela est nécessaire.
Apple précise que les améliorations ne se voient pas avec des outils de benchs comme SunSpider, mais sont palpables lors d'une utilisation courante. Ceci s'explique par le fait qu'avec cette architecture, le compilateur JIT est moins sollicité.
Parmi les récentes améliorations, une nouvelle API a récemment fait son apparition. Il s'agit de Vibration. Comme son nom peut le laisser entendre, elle permet de faire vibrer un terminal mobile. Voilà qui peut être intéressant dans certains cas.
D'autre part, JavaScriptCore utilise désormais une machine virtuelle à trois niveaux. Elle comporte un nouvel interpréteur bas niveau qui est 2 à 2,5 fois plus performants que le précédent. LLInt exécute le code dans un premier temps, et le transmet au compilateur Just In Time uniquement si cela est nécessaire.
Apple précise que les améliorations ne se voient pas avec des outils de benchs comme SunSpider, mais sont palpables lors d'une utilisation courante. Ceci s'explique par le fait qu'avec cette architecture, le compilateur JIT est moins sollicité.
on dirait qu'on pourra bientôt pouvoir avoir toutes les possibilités d'une app native sur une webapp
Bah y a intérêt parceque sinon Mozilla et son B2G, ils vont être embêté...
Bon c'est pas le même moteur et doit y avoir l'équivalent chez gecko ...
Mozilla développe la Web API justement qui va permettre toutes les interactions avec le téléphone et vont le soumettre ensuite au W3C pour standardisation.
J'espère juste qu'on aura pas besoin à terme de faire une version pour gecko et une pour mozilla... ça tue un peu l'intérêt des web apps.
Pour les performances c'est une très bonne chose en revanche, ça va stimuler la concurrence entre les différents moteurs JS et au final on aura des applis web de plus en plus fluides.
Le travail sur le code natif des processeurs ne cesse pas non plus. Il y aura toujours un écart, par principe.
@oomu la compilation JIT génère du code natif, son gros défaut est que ça consomme beaucoup de RAM.
@iNabil :
si tu n'est pas déjà convaincu de ça, regardes un projet comme PhoneGap... Tu peux déjà accéder à toutes les subtilités et puces hardware d'un smartphone via du Javascript
Tant qu'on n'aura pas accès au systeme de fichiers, le reste n'est que détails.
@lmouillart :
la RAM est un problème de courte durée. Assez rapidement les terminaux mobile profiterons de "l'aisance" des postes fixes. Dans 2 ans, nous aurons certainement des mobiles avec 4Go de RAM.
Apple bride et bridera les possibilites des navigateurs sur iOS vu que si l'on peut faire une webapp aussi bonne qu'une native, l'appstore n'a plus aucun interet financier. Ces avancees sont minimes au final.
3 tiers ? En anglais tier signifie niveau, donc s'agit-il d'une architecture à 3 niveaux ? Parce sinon on peut dire que du client serveur c'est du 2 demis !!!
@dway :
sauf que l'intérêt d'Apple il est de vendre des téléphones, pas des applications qui ne sont qu'un moyen.
C'est très clair dans les résultats de la pomme.
@ esantirulo
j'ai trouvé l'expression dans un dico informatique. J'étais pas convaincu mais bon. Je me range derrière ta proposition