Après la mort du moteur de rendu Presto d'Opera, beaucoup a été dit sur la "monoculture WebKit". C'était sans compter sur… Google, qui a officiellement forké WebKit hier en annonçant Blink.
Avec un nom aussi évocateur le lecteur aura tôt fait de vérifier la date, mais non, le 1er avril est bien révolu.
Au menu, du gros nettoyage dans le code et des changements côté architecture, et quelques choix intéressants : en particulier, les préfixes propriétaires disparaîtront. Les nouveautés ne seront disponibles qu'après activation d'une directive de configuration dédiée, et ne seront utilisables qu'une fois considérées comme suffisamment stables. Le site fait référence à diverses discussions sur ce sujet au W3C. On se remémorera également l'appel de Daniel Glazman (_co-chairman_ du groupe de travail CSS, mais publié en son nom propre).
Enfin, Opera utilisera lui aussi ce nouveau moteur de rendu.
# Emmerder Apple ?
Posté par Misc (site web personnel) . Évalué à 6.
Suis je le seul à voir dans ce mouvement un coup de Google pour faire chier Apple ( vu que Webkit sert aussi pour Safari et iOS ) ?
[^] # Re: Emmerder Apple ?
Posté par VinDuv . Évalué à 8.
C’est possible, mais d’un autre côté si j’ai bien compris WebKit a aussi du code spécifique pour gérer certains aspects de Chrome (notamment l’utilisation du moteur JavaScript V8 au lieu de JavaScriptCore), donc ça pourrait aussi simplifier le code de WebKit et donc le travail d‘Apple.
Aussi, en suivant la liste de diffusion concernant le développement de WebKit (webkit-dev), j’ai vu que les relations entre les développeurs Chromium et les autres n’était pas au beau fixe (par exemple leur propositions d’intégrer d’autres languages de script à WebKit ou d’ajouter des les bindings V8 à WebKit2 ont été rejetées plus ou moins unanimement), donc ce fork n’est pas vraiment une surprise à mon avis.
[^] # Emmerder KDE ?
Posté par ʭ ☯ . Évalué à 10.
Suis je le seul à voir dans le fork Webkit de KHTML un coup de Apple pour faire chier le libre( vu que KHTML sert aussi pour Konqueror ) ?
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Emmerder Apple ?
Posté par Jean B . Évalué à 3.
Si j'en croit cet échange[0] entre un dèv de chrome et un dèv d'apple, les deux partie se sentent rejetée par l'autre.
Webkit car Google n'a pas développé son model de multiprocess directement dans Webkit.
Et Google car plutôt qu'intégrer le multiprocess de Chromium dans Webkit ils ont implémentée une autre solution incompatible ce qui cause de la misère à Chrome pour intégrer Webkit.
[0][EN] https://news.ycombinator.com/item?id=5490242
[^] # Re: Emmerder Apple ?
Posté par Yukito (site web personnel) . Évalué à 8.
Dans ce cas précis, je ne crois pas que Google ait ce type d'arrière-pensées. C'est juste qu'il y a tellement d'acteurs regroupés autour de Webkit que c'était même surprenant qu'ils arrivent à s'entendre jusqu'ici.
Google était déjà le contributeur le plus actif de Webkit depuis quelques années mais sans être vraiment celui qui prend les décisions. C'est une situation typique qui mène à un fork, parce qu'il y a un moment où le contributeur principal veut pouvoir prendre les décisions importantes.
[^] # Re: Emmerder Apple ?
Posté par GeneralZod . Évalué à 2.
Euh, Google s'en branle des autres, suffit de voir le bordel que c'est Chromium, la plupart des libs sont forkés en interne, aucun effort n'est fait pour collaborer avec la communauté.
Apple c'était guère mieux, jusqu'à ce que les développeurs de KDE tapent une bonne gueulante.
Les chiffres ? Ils ont contribués quoi ? Le moteur javascript, le modèle multiprocessus, etc… tout ça a été développé dans un coin sans jamais en discuter avec la communauté WebKit, et aucune volonté de réintégrer ça.
De fait, la version de WebKit fourni par Google était un fork, un bon fork bien crade qui ne portait pas son nom.
[^] # Re: Emmerder Apple ?
Posté par ribwund . Évalué à 2.
http://blog.bitergia.com/2013/02/06/report-on-the-activity-of-companies-in-the-webkit-project/
[^] # Re: Emmerder Apple ?
Posté par GeneralZod . Évalué à 3.
Euh, je vois qu'Apple et Google contribuent à peu près autant l'un que l'autre (check les camemberts plus bas)
Par ailleurs, Google se plaint de ne pas pouvoir intégrer son modèle multiprocessus dans WK, mais à l'origine c'est eux qui ont fait le choix de le développer dans un coin, au point que WK2 a été développé pour offrir les mêmes fonctionnalités dans la branche principale (et ce en concertation avec tout les acteurs).
Non, la raison du fork n'est pas "Le gentil Google a été spolié par le méchant Apple qui veut partager le pouvoir", non, Google veut clairement faire chier Apple. On risque de retomber dans les pires travers de la guerre des navigateurs.
Qui va payer pour les conneries de Google ? les standards ouverts et l'intéropérabilité.
[^] # Re: Emmerder Apple ?
Posté par claudex . Évalué à 5.
Je ne vois pas pourquoi, ils n'auront pas plus de part de marché que n'a Webkit actuellement, les moteurs seront donc obligés de respecter les standard pour avoir un rendu correct des sites.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Emmerder Apple ?
Posté par ribwund . Évalué à 6.
Le camembert c'est depuis la création du projet. Si tu regardes les dernieres années (y'a les graphes ici: http://blog.bitergia.com/2013/03/01/reviewers-and-companies-in-webkit-project/ ), c'est quasi 50% des contributions qui viennent de google (et 25% apple).
[^] # Re: Emmerder Apple ?
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 4.
Non ;)
# Très bonne nouvelle
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 10.
Je suis extrêmement content de cette décision et des choix effectués !
La diversification dans les moteurs de rendu augmente après une baisse inquiétante. Il va moins y avoir de "faux" standards.
Le fait de cacher les nouveautés non stable est aussi une très bonne chose, et je pense la meilleure solution pour le développeur web : il ne sera pas tenté, comme c'est le cas actuellement, d'utiliser des trucs pas fini, pas standardisé, non dispo dans les autres navigateurs. Bref, il fera du code plus propre et meilleur pour ses utilisateurs.
# Quid de webkit-gtk, qtwebkit et consors ?
Posté par 태 (site web personnel) . Évalué à 4.
Qu'est-ce que ça signifie pour les "petits" navigateurs basés sur webkit et les bibliothèques qu'ils utilisent ? J'ai lu qu'epiphany passait à webkit2, vont-ils revoir leurs projets ? Est-ce que rekonq, midori, luakit, uzbl, jumanji, arora vont passer à webkit2 ? Ou vont-ils rester sur webkit1 ou passer à blink ? Va-t-on voir apparaître des bibliothèques blink-gtk et qtblink ? Va-t-on avoir des forks de tous les navigateurs entre la version à moteur webkit, la version à moteur blink et la version à moteur gecko (nan, je déconne, gecko ailleurs que chez mozilla, c'est fini) comme quand epiphany expérimentait le moteur webkit tout en continuant à proposer la version motorisée par gecko ?
Que de questions ! C'est une redistribution majeure dans le petit monde des navigateurs qui point !
[^] # Re: Quid de webkit-gtk, qtwebkit et consors ?
Posté par claudex . Évalué à 4.
Pour les réponses à ces questions, il faudra attendre un peu et voir si Blink s'oriente sur du facilement embarquable ou fait comme Gecko et reste très lié (je penche pour la première solution pour des questions de licence, mais on verra). Et s'il facilement embarquable, tous ces petits navigateurs pourront se poser la question de savoir vers où migrer.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Quid de webkit-gtk, qtwebkit et consors ?
Posté par oao . Évalué à 2.
Sans trop connaitre la question, mais sachant que Webkit est utilisé comme widget sous Android, je pense que Google préfèrera garder son moteur embarquable facilement, d'autant que l'effort pour le garder embarquable doit être inférieur à celui de Mozilla qui part d'une solution très lié à Firefox.
[^] # Re: Quid de webkit-gtk, qtwebkit et consors ?
Posté par Anonyme . Évalué à 2.
Pour information, juste au cas où et parce que ca me plait beaucoup, Gecko existe également en version découplée de l'interface XUL de firefox
https://wiki.mozilla.org/Embedding/IPCLiteAPI
[^] # Re: Quid de webkit-gtk, qtwebkit et consors ?
Posté par GeneralZod . Évalué à 3.
Au vu du passif de chromium, on s'oriente très probablement vers la solution 2.
# Servo
Posté par Strash . Évalué à 9.
Il y a également Servo (Mozilla + Samsung) qui semble également augmenter la diversité des moteurs.
https://blog.mozilla.org/blog/2013/04/03/mozilla-and-samsung-collaborate-on-next-generation-web-browser-engine/
[^] # Re: Servo
Posté par gasche . Évalué à 4.
Mais Servo est un projet de recherche sur le moyen-long terme, pas quelque chose prévu pour être en production. Je ne comprends pas la façon dont a été diffusée ce coup de pub de Mozilla, tout content que Samsung s'intéresse à leur projet, avec des conclusions assez fumeuses.
# Analyse plus apronfondie
Posté par Zenitram (site web personnel) . Évalué à 10.
PC inpact a mis une analyse plus approfondie, avec un graphique sur les commits qui aide à comprendre.
[^] # Re: Analyse plus apronfondie
Posté par Guillaume Denry (site web personnel) . Évalué à 4.
Wow en effet, voilà qui permet de réfuter assez rapidement l'hypothèse du premier commentaire de ce journal ; Google se sentait à l'étroit dans un projet dont ils n'avaient pas la gouvernance mais auquel ils contribuaient massivement.
# Condition d'utilisation
Posté par Anthony Jaguenaud . Évalué à 0.
Mauvais souvenir des conditions d'utilisations initiales de chrome…
--->[]
# Odd...
Posté par miun . Évalué à 1.
Bonjour,
Au delà de la technique, vous nous trouvez pas cela bizarre qu'Opéra réagisse aussi vite ? Il n'y aurait pas eu comme une discussion et en partenariat en amont entre les 2 (Google et la société gérant Opéra) ?
On sait très bien qu'une société ne peut réagir aussi vite sur un choix ayant tant de conséquences. Cela sent le rapprochement et voir plus :)
[^] # Re: Odd...
Posté par ribwund . Évalué à 5.
Je trouve pas ça bizarre, le choix qu'ils avaient annoncé c'était de se baser sur le code de chromium, pas webkit en particulier. C'est donc tout à fait logique qu'ils suivent chromium dans le fork.
[^] # Re: Odd...
Posté par Zenitram (site web personnel) . Évalué à 9.
http://www.brucelawson.co.uk/2013/hello-blink/
"It’s great to be able to talk publicly about Blink".
Clair, net et précis : il avait un NDA depuis un moment dessus.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.