new Blog( perso );

Basé sur le moteur de rendu WebKit (utilisé également par Safari) il apporte :

d'une part un modèle multi-processus, basé sur le constat qu'on utilise aujourd'hui le navigateur pour exécuter des applications, et non plus pour visualiser des pages. Une application = un processus, c'est logique et cela stabilise le navigateur (étanchéité entre applications).

d'autre part un moteur d'exécution JavaScript basé sur une machine virtuelle crée par Google DK, "V8". Compilé plutôt qu'interprété, le code JS est nettement plus rapide, comme l'a déjà démontré le moteur SquirelFish (cf mon billet sur le sujet). V8 semble particulièrement efficace d'après les premiers benchs, et je confirme l'impression générale de rapidité.

Pour découvrir en image les idées derrière Chrome, consultez la BD éditée par Google : http://www.google.com/googlebooks/chrome/. L'accent porté sur les tests et l'intégration continue associée est intéressant.

Basé sur WebKit, il ne devrait pas y avoir de problème de compatibilité majeure. Peut-être aura t-on tout de même droit à une combinatoire dédiée dans la prochaine version du compilo GWT.

Quel intérêt ?

Pour Google, dans l'esprit "the browser is the platform", une application dans le navigateur doit être au moins aussi rapide, stable et démarrer aussi vite qu'une application installée. 

• Pour la rapidité, le passage par la compilation du JavaScript est la clé. 
  
• Pour la stabilité, le modèle 1 onglet = 1 processus est la solution poussée par Google. 
• Pour le temps de démarrage, il suffit d'utiliser le mode "raccourci sur le bureau" de chrome pour comprendre : on lance gMail en un temps record, avec un "navigateur" réduit à sa plus simple expression.
  

Résultat : gMail exécuté sous chrome en mode "application" écrase tous les clients de messagerie connus - ce n'est que mon point de vue ;-)

Il est juste domage que gMail n'exploite pas Gear (à moins que j'ai raté quelque chose?).