Après que WebKit ait emporté la première manche via le test Acid 3 [1], WebKit vient de marquer un nouveau point (de bien moindre importance, certes...). Les developpeurs du projet Epiphany, le navigateur web de GNOME, ont annoncé sur la mailing-list [2] qu'ils n'utiliseraient plus Gecko pour le rendu des pages web à partir de la prochaine version, numérotée 2.24, c'est à dire dans six mois.
Les raisons invoquées sont multiples :
- nouvelles versions de Gecko pas assez régulière
- API et fonctionnalités trop orientées vers Firefox, pas pensées pour les autres navigateurs
- API instable
- futur incertain de Gecko (version 2.0)
Mais la principale raison mentionnée dans l'annonce concerne le manque de temps. En effet, maintenir une couche de compatibilité avec plusieurs moteurs de rendu prend du temps et l'équipe d'Epiphany en manque. De plus, cette couche d'abstraction complexifie le code.
Le principal avantage apporté par WebKit est une meilleure intégration à GNOME : l'API est "GObject", le rendu des éléments graphiques et de la page est fait par GTK/Cairo et les éléments multimédia sont interprétés par Gstreamer. De plus, utiliser un seul moteur de rendu permettra d'avoir des extensions qui peuvent accéder directement à l'arbre DOM, ce qui permettra d'agir directement avec le contenu des pages.
Si les développeurs d'Epiphany font en sorte que WebKit devienne une dépendance de GNOME, alors d'autres projets GNOME devraient rapidement s'en servir. Par exemple Evolution qui pourrait l'utiliser comme moteur de rendu des emails HTML et comme éditeur pour la rédaction d'email en HTML. Yelp, qui est le système d'aide de GNOME, pourrait également s'en servir.
Les développeurs ont annoncé que s'ils n'arrivaient pas à terminer cette migration pour la sortie de GNOME 2.24, alors il n'y aurait pas de nouvelle version d'Epiphany dans GNOME 2.24 et qu'il faudrait alors patienter jusqu'à GNOME 2.26. Souhaitons leurs bon courage pour pouvoir rapidement profiter de Epiphany/WebKit !
[1] http://webkit.org/blog/173/webkit-achieves-acid3-100100-in-p(...)
[2] http://mail.gnome.org/archives/epiphany-list/2008-April/msg0(...)
Journal WebKit - Gecko : 2 - 0
2
avr.
2008
# Outch...
Posté par ondex2 . Évalué à 2.
[^] # Re: Outch...
Posté par BAud (site web personnel) . Évalué à 2.
[^] # Re: Outch...
Posté par cosmocat . Évalué à -1.
http://linuxfr.org/2008/04/02/23928.html
# mouaif
Posté par GPL . Évalué à 0.
gobject ne semble être là que pour jouer d'interface sur certains modules. Si j'en crois les rumeurs, gobject semble plus propre que le XPCOM de Mozilla. Donc sur ce point ça serait moins pire que Gecko.
Gecko semble (j'ai pas essayé) très difficile à extraire de l'usine à gaz de mozilla. Webkit est un module bien indépendant. Ça c'est moins pire que Gecko.
Bref... ce qu'il faut c'est un renderer web en C optimisé pour les achitectures modernes: optimisation sur les caches de nos machines multicœurs sans ignorer les capacité de nos GPUs modernes. Bon quand on doit mixer un rendu CSS avec du SVG... j'imagine ça ne doit pas être fun car sacrément barré.
YaKa? Dsl mais la première étape c'est le GPU... ensuite on verra pour le renderer web.
# erreur
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 8.
Mouai, ils se sont franchement pas casser le cul à se documenter sur le sujet.
Parce que si ils s'étaient renseigné un peu sur Mozilla 2, ils auraient su qu'un des objectifs majeurs de Mozilla 2, c'est de simplifier encore plus l'embarquement de gecko dans les applis tiers, avoir quelque chose de plus propre, plus léger, avec le support XPCOM supprimé en interne etc... Car il faut savoir qu'un autre objectif principal de Mozilla 2, c'est Mozilla Mobile, autrement dit l'utilisation de Gecko dans l'embarqué.
Bref, donc en gros, Mozilla 2 correspondra beaucoup plus à leurs exigences. C'est une très mauvaise raison qu'ils ont donné là.
[^] # Re: erreur
Posté par GPL . Évalué à 1.
C'est juste histoire de nous mâcher le travail...
[^] # Re: erreur
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
http://wiki.mozilla.org/Mobile
[^] # Bravo!
Posté par GPL . Évalué à 0.
Hum la belle m... qu'ils nous préparent pour le web!
Un des seuls trucs sur la bonne voie comme spidermonkey et bien paff! Ils dropent ce qui était bien dedans pour recoder en C++.
Quand on voit les participants, et bien je ne remercis pas adobe car manifestement ce sont eux qui ont réussis à faire un coup d'état sur la communauté de mozilla.
Il semblerait que toutes ces mauvaises idées soient essentiellement les leurs. Faut dire je n'attendais pas plus de la part des personnes qui ont fait flash.
Je comprend *beaucoup* mieux pourquoi epiphany fuit gecko maintenant, puisqu'il semble très très mal tourner... remarque tu vas me dire qu'avec mono, gnome ça ne sent pas plus la rose non plus.
[^] # Re: Bravo!
Posté par Gof (site web personnel) . Évalué à 6.
[^] # Non
Posté par GPL . Évalué à -1.
Écrit un compilateur C (pas d'optimisation non plus).
Et là... miracle! Tu réalises pourquoi!
[^] # Re: Non
Posté par Gof (site web personnel) . Évalué à 9.
Selon toi ça veux dire que tout le monde devrais coder en assembleur ou en brainfuck ?
C'est pas parce que le compilateur d'un language est plus simple à écrire que le language est plus adapté.
[^] # Re: Non
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
[^] # Re: Non
Posté par GPL . Évalué à -1.
Si tu te places dans le contexte qui consiste à considérer la complexité de l'ensemble de la pile logicielle dont dépend le programme en question, un langage délirant à mettre au point est évidement moins bon. Ça ne va pas chercher plus loin. C'est une priorité/une limite comme une autre.
Je suis un développeur soucieux de la simplicité de la totalité de la pile logicielle. Dans cette optique, il n'est pas possible de considérer le C++ et similaires car la complexité d'un compilateur C++ lambda est délirante donc explose les limites que je me suis imposées.
[^] # Re: Non
Posté par ragoutoutou . Évalué à 6.
c'est beau, ces considérations à l'emporte-pièce et ce "délirant" asséné avec autosuffisance pour essayer de jeter le C++ à la poubelle... mais bon, c'est fréquent de vouloir discréditer les outils qui nous dépassent.
Tu sembles être un champion des faux prétextes en tout cas, ça et le discours concernant l'utilisation de VM ...
[^] # Re: Non
Posté par GPL . Évalué à 1.
Comme j'ai le droit de ne pas être d'accord avec les tiennes et de le faire savoir.
[^] # Re: Non
Posté par Guillaume Denry (site web personnel) . Évalué à 5.
[^] # Re: Non
Posté par GPL . Évalué à 1.
Je vais faire sur le même niveau mais avec l'excès dans l'autre sens:
"Je ne supporte pas de manger mon haricot vert si celui-ci n'est pas déposé dans ma bouche par la fourchette Two thousand and eight!
La fourchette Two Thousand and Eight vient livrée avec sa centrale nucléaire et son datacenter. Bien entendu au cas où la centrale nucléaire tchernobylerait, la fouchette Two Thousant and Eight est livrée en standard avec un backup à l'énergie solaire avec son rayon solaire viendant de l'espace avec son satellite géostationnaire intégré!
La fouchette Two Thousant and Eight, simplifie ton quotidien pour manger ton haricot vert!"
[^] # Re: Non
Posté par ragoutoutou . Évalué à 1.
Et si pour toi le paradigme orienté objet est un élément délirant issu du marketting de 2008, ton problème ne relève pas de l'informatique.
A moins que tu ne fasse juste le troll au finish...
[^] # Re: Non
Posté par Moonz . Évalué à 3.
[^] # Re: Non
Posté par GPL . Évalué à 1.
[^] # Re: Non
Posté par ragoutoutou . Évalué à 3.
Tu confonds aussi complexité de la "pile logicielle" et complexité d'un de ses composants.
Je me demande vraiment ce que tu trouves "délirant" dans le C++ si ce n'est pas la partie objet en tout cas...
Fatigué tu es, et ça se voit...
[^] # Re: Non
Posté par GPL . Évalué à 3.
Tu confonds aussi complexité de la "pile logicielle" et complexité d'un de ses composants.
Peut-être que la complexité de la pile logicielle dépend de la complexité de ses composants? Là tu fais dans le lamentable. Dsl, j'ai pas fait polytechnique mais ça j'arrive à le comprendre.
D'un autre côté, tu confonds bien le fait de faire interpréter un langage script dans une VM et le fait de faire tourner du byte code directement dans une VM, d'où tes jérémiades concernant la "porte ouverte aux applis proprios"...
Relis mes commentaires:
Il ne faut pas que le web s'approche d'une VM à bytecode (le pire sont celles à registres). Car cela augmente énormémement le risque d'application proprio web. Ce n'est pas de savoir comment elle va être utililsée qui est important, mais juste le fait qu'elle soit là.
De plus la performance d'une interface web graphique n'a pas besoin de s'encombrer de la complexité d'une VM, un bête interpréteur doit suffire, au pire tu rajoutes des structures de données plus riches et tu as des méthodes pour bosser dessus cablées en C/ASM optimisées de la mort qui tue dans l'interpréteur.
Je me demande vraiment ce que tu trouves "délirant" dans le C++ si ce n'est pas la partie objet en tout cas...
Bon là tu ne me fatigues plus... tu m'as tué... ras le bol.
[^] # Re: Non
Posté par ragoutoutou . Évalué à 1.
Euh, et à part ça, une argumentation? En dehors de 'cépabien' ?
Non? Pas d'arguments? Faut juste avoir peur des VM et pas se poser de questions?
Tu te dis polytechnicien mais tu semble verser beaucoup dans la superstition.
Et en passant, ce n'est pas la peine de mettre en gras tes propres fautes d'orthographe comme ça :)
[^] # Re: Non
Posté par Moonz . Évalué à 1.
De la même manière qu'une chaine est au moins aussi faible que le plus faible de ses maillons, une pile logicielle est au moins aussi complexe que leplus complexe de ses éléments. C'est pas une analogie fumeuse, juste du bon sens.
> Je me demande vraiment ce que tu trouves "délirant" dans le C++ si ce n'est pas la partie objet en tout cas...
Toi par contre, tu confonds concept (le paradigme objet, que personne n'a critiqué ici) et implémentation.(le C++, qui a été effectivement critiqué pour sa complexité monstreuse)
[^] # Re: Non
Posté par Étienne . Évalué à 1.
Comparaison n'est pas raison.
[^] # Re: Non
Posté par Moonz . Évalué à 2.
[^] # Re: Non
Posté par GPL . Évalué à 2.
Ouf! Je suis pas tout seul. Mais fait gaffe à ne pas te faire prendre au piège par ces personnes: attention aux threads interminables...
[^] # Re: Non
Posté par Vador Dark (site web personnel) . Évalué à 2.
[^] # Re: Non
Posté par GPL . Évalué à 4.
[^] # Re: Bravo!
Posté par Psychofox (Mastodon) . Évalué à 6.
c'est fini les poissons, on est le 2 avril
[^] # Re: Bravo!
Posté par Larry Cow . Évalué à 3.
Adobe n'a fait "que" racheter Macromedia. Ils n'ont pas "fait" Flash.
[^] # Re: Bravo!
Posté par Thomas Douillard . Évalué à 4.
Je t'aime, dans le genre troll, avis à l'emporte pièce d'une pertinence douteuse, voire qui veulent rien dire, cf. http://linuxfr.org/comments/918824.html#918824 t'es très fort.
Autant dire que ton avis n'engage que toi, en fait.
Exemple con : adobe est bien connu pour flash, qui est d'après toi une merde niveau perfs ? Si effectivement ce sont eux qui sont à l'origine de ces idées, leur avis technique vaut pas tripette, selon toi ?
[^] # Re: Bravo!
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5.
La VM dans Gecko2 (Tamarin), est déstinée à exécuter le javascript des pages web. Faudra donc que tu expliques en quoi ça va apporter "son lot d'appli web riches proprio". Du javascript reste du javascript. Ça va pas se transformer en flash ou je ne sais quoi hein. Surtout que bon, pour que la VM puisse executer du flash, il faudrait l'API flash et sa lib derrière, hein, et ça c'est pas du tout au programme.
Et puis si ils ont choisi d'utiliser une VM, c'est bien parce que ça va apporter un plus par rapport à spidermonkey, en terme de perf &cie. Ils ont pas fait ces choix à l'aveuglette pour le bon plaisir d'adobe. D'autant plus que Tamarin a une certaine avancée dans l'implémentation de Javascript 2...
Bon et puis je vois pas ce que viens faire le troll C++ vs C la dedans... Webkit est fait en C++, idem pour Kjs (moteur JS de webkit), et pourtant tu n'en dis rien.
[^] # Re: Bravo!
Posté par GPL . Évalué à -2.
J'attend le moment où le W3C va normaliser une VM à byte code...
[^] # Re: Bravo!
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: Bravo!
Posté par GPL . Évalué à 0.
On verra quand le W3C normalisera une VM...
Et puis si ils ont choisi d'utiliser une VM, c'est bien parce que ça va apporter un plus par rapport à spidermonkey, en terme de perf &cie. Ils ont pas fait ces choix à l'aveuglette pour le bon plaisir d'adobe. D'autant plus que Tamarin a une certaine avancée dans l'implémentation de Javascript 2...
L'interpreteur (sans VM) est largement suffisant pour des interfaces graphiques. Et cela nous protège des applications riches web propriétaires bien mieux.
Bon et puis je vois pas ce que viens faire le troll C++ vs C la dedans... Webkit est fait en C++, idem pour Kjs (moteur JS de webkit), et pourtant tu n'en dis rien.
Relis moi: je préfère le spidermonkey de maintenant, pas celui qu'adobe nous prépare.
[^] # Re: Bravo!
Posté par Thomas Douillard . Évalué à 4.
The goal of the "Tamarin" project is to implement a high-performance, open source implementation of the ECMAScript 4th edition (ES4) language specification. The Tamarin virtual machine will be used by Mozilla within SpiderMonkey, the core JavaScript engine embedded in Firefox®, and other products based on Mozilla technology.
De ce que je vois du projet, la VM, c'est pour avoir une couche intermédiaire, genre :
code jvs <- compilateur de bytecode -> bytecode tamarin <- VM , éventuellement compilation jit -> code natif machine
et pas pour exécuter du bytecode directement.
Sinon pour le reste, je vois pas en quoi ça va faciliter l'arrivée d'appli proprio, qui est déja ultra triviale, genre un plugin flash et roulez jeunesse chez la plupart des gens, un bon vieux gmail ou ce genre d'appli web, une appli proprio de plus qui existe déjà. A toi de faire le tri j'imagine.
[^] # Re: Bravo!
Posté par jeffcom . Évalué à 2.
Adobe n'a pas fait Flash, Adobe a racheté la boîte qui l'a fait : Macromedia.
Quitte à cracher sur quelque chose, autant le faire bien...
[^] # Re: erreur
Posté par SF . Évalué à 3.
En attendant ils font quoi ? Rien comme depuis quelques années qu'ils attendent... (parce que bon le rendu html dans gnome et les applis gtk en général...)
Je crois que le fond du problème c'est qu'ils en ont marre d'attendre Gecko, les devs ont envie de s'amuser un peu.
Mais c'est vrai que c'est au moment où mozilla commence à s'en préoccuper que les rats quittent le navire. A moins que Mozilla commence à s'en préoccuper parce qu'ils sentent le vent tourner ?
Et puis si l'usage de gecko se simplifie, il sera sans doute facile d'y revenir.
# WebKit j'aimerais l'aimer...
Posté par MiniMoi . Évalué à 3.
C'est fort dommage, parce que les performances sont vraiment la, et en plus ce moteur est promi à un bel avenir dans l'informatique mobile, entre l'iPhone et Android...
[^] # Re: WebKit j'aimerais l'aimer...
Posté par Alex . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.