WebOS plombé par WebKit

J'ai du mal à comprendre cette information, Chrome et Safari sont, il me semble, des navigateurs particulièrement rapides et ce grâce à WebKit. De plus, la version iOS de Safari repose sur les mêmes bases.
L'utilisation de WebKit à l'air plutôt performante....à mon avis c'est une sorte d'alibi.

En fait WebOs s'appuie sur une ancienne version de webkit et faute d'ingénieurs de développement compétents dans le domaine, l'OS n'a jamais pu évoluer à temps en terme de rapidité. De plus, un OS conçu pour faire tourner en grande majorité des applis web sera toujours beaucoup moins réactif qu'un autre.
C'est pour ça.

Webkit est performant quant utilisé comme navigateur web.
Là, de ce que j'ai compris, il est question de l'utiliser pour toute l'interface de l'OS. Toutes les applications, au lieu d'être développées en langage machine (iOS) ou Java (Android) seraient en fait des "extensions" de webkit.

D'ailleurs la fondation Mozilla a rencontré le même problème pour Firefox : l'interface du navigateur, ainsi que ses extensions, sont dessinés par Gecko, son moteur de rendu.
Et sur les version mobiles ça pose des problèmes de performances, ce qui les oblige a ré-écrire les versions mobiles pour que l'interface soit dorénavant écrite en langage machine plutôt qu'en XUL (le langage de script Mozilla permettant de créer des interfaces)
http://www.pcinpact.com/news/66432 [...] -natif.htm

Donc, non, je ne pense pas que ce soit une sorte d'alibi...

Shoryu, ils ne parlent pas juste de navigateur, mais d'OS.

Ceci dit perso, utilisateur depuis 3 mois, je trouve webOS très performant, donc le New York Times son article sur quoi. Je suis d'ailleurs assez d'accord sur certaines réactions de lecteurs du NYT : webOS a encore de nombreux avantages sur iOS ou d'autres, et est bien plus stable et performant avec les dernières mises à jour. Je ne vais probablement pas le remplacer de suite et je l'utilise couramment (perso et pro d'ailleurs) avec satisfaction.

webOS a bien plus été plombé par un management incompétent (et toujours en place puisque c'est bien l'intégralité du Board of Directors, des gens grassement payés et souvent déjà pas très bons dans leurs autres ou anciennes activités, qu'il faudrait virer) que par son moteur ...

HP's Board of Directors is Pathetic (Forbes)

Si j'ai bien compris ils utilisent WebKit même pour tout ce qui se passe en dehors du navigateur également, comme le rendu de l'interface etc

La dernière phrase de l'article me parait assez explicite. Le tout web n'est pas encore à la hauteur. D'une part, il y a les problèmes de latence réseau, et d'autre part (et surtout), HTML+css+JAVASCRIPT ne permettent pas de construire des choses aussi fines qu'avec un cocoa ou un qt. D'autant que ce mix a tendance à virer à l'usine à gaz à vitesse grand V.

webOS en OpenSource c'est l'assurance qu'il va être forké est réécrit en langage haut niveau. Enfin ça dépend de l’intérêt que va susciter cet OS dans la communauté. Après le dual boot win/linux pourquoi pas un dual boot Android/webOS ou iOs/webOS?

iOS/webOS sur un futur iPad3 en Retina ce serait surement un beau projet

Tout à fait WebKit est utilisé sur les autres plateformes mobile.
Cependant, l'erreur de Palm a été d'en faire le coeur du système (contrairement à Android ou iOS où WebKit n'est que le moteur de rendu web utilisé par le Navigateur ou les applications).
Tout passe par WebKit sur WebOS et c'est bien le problème.

L'article du New York Times n'est pas très détaillé sur les sois disant gros problème d'optimisation des applis basé sur webkit.
Attention au raccourci trompeur web = interprété = lent; dans webos il s'agit de la stack graphique qui est basée sur une API web, ce qui est légèrement différent.

A mon avis, baser une appli sur webkit peut être intéressant au niveau performance : si l'implémentation de webkit repose sur un scene graph, comme c'est le cas pour la plus part des implémentations de webkit (core animation pour iOS, skia/chrome layer pour chrome, evas pour les efl, qt-scene-graph pour qt en cours d'élaboration pour qtwebkit ...) alors toutes les applis utiliserons un scene graph pour l'affichage.
Hors un scene-graph permet de ne mettre à jour que les parties utiles des éléments de l'écran et permet d'utiliser plus finement le GPU (j'ai pas trouvé mieux que les explications de Zack Rusin, ou voir aussi celle de evas : le scene-graph des efl section rendering and canvas).
C'est, de mon point de vu, un moyen facile et unifié (j'ai même envie de dire élégant) pour accélérer toute représentation 2D (avec l'avantage d'être transparent pour le développeur).
De plus cela permet de développer plus simplement des applis s'adaptant à différentes tailles d'écrans et de résolutions (surtout depuis le framework Enyo).

Alors évidement le couple html+javascript n'est pas des plus performant pour les calculs lourds, c'est pour ça que le pdk permet de faire du cpp et du c, de lier le code en plugin webkit et d'être appelé depuis de javascript.
C'est encore une fois, plutôt élégant, d'abord parce que c'est moins chiant d'écrire des interfaces en web qu'en natif ou en java, ensuite parce qu'on utilise ainsi un webkit qui permet d'accélérer les éléments html 2D et on garde la puissance du cpp/c pour les traitement lourds. Ca conviendra dans la majorite des cas.
Après pour faire des jeux, de la 3D et de la retouche d'image, visiblement le pdk permet d'utiliser la SDL et OpenGL, donc y a tout ce qu'il faut.

Le manque de détail technique de l'article me fait dire que le New York Times est passé à côté de qqch ou que les personnes interrogées n'étaient pas forcément si technique que ça. Ou bien que les phrases ont été sorties de leurs contextes, après tout ce sont des journalistes .
Il est possible que webos souffre de qlq lacunes de jeunesse (une version de webkit sans svg par ex), mais je pense que l'architecture globale est très intéressante, notamment par l'utilisation de webkit.
De plus j'utilise un Pre3 régulièrement et je ne constate aucun lag (contrairement aux appareils android que j'ai pu tester, apparemment je suis pas le seul), sous webos visiblement tout s'affiche à 60fps ce qui ne serait pas le cas si la stack graphique n'avait pas été prévue pour.


Pour ce qui est de la comparaison avec firefox mobile, je pense que le problème n'est pas le même :
Firefox n'utilise q'une instance de son moteur web Gecko (un seul processus de gecko pour tout traiter : interface + page web). C'est cette architecture mono-thread qui pose problème, car Gecko est nécessaire à l'interface en XUL, donc au lancement le temps que le moteur se charge, l'interface ne répond pas aux actions de l'utilisateur, de même lorsque Gecko doit effectuer des opérations lourde sur la page web.
Webkit dans webos n'a pas ce problème, j'imagine qu'il y a autant d'instances de rendu webkit que d'applis lancées.

@back6 : dans webos c'est l'API web et son implémentaion webkit qui est utilisée mais les applis sont bien en locale sur l'appareil : le réseau n'est pas utilisé pour, donc il n'y a pas de latences réseau (sauf si l'appli utilise le réseau évidement).