Alors, en tant qu'ancien contributeur de Mozilla, je vais répondre.
Au départ, Gecko avait une API pour pouvoir être embarqué. Bon, elle n'était pas terrible, mais elle faisait le job à l'époque. Cela a permis le développement de navigateurs comme Epiphany, ou encore Camino (sous Mac OS). Ces navigateurs utilisaient vraiment la version "embarquée" de Gecko : leur interface n'était pas en XUL/JS, mais en pur GTK pour l'un, et Cocoa pour l'autre.
Malheureusement, cette API Embedding n'a pas été maintenue comme elle aurait dû l'être.
En fait les développements de Gecko étaient plus orientés pour faire une plateforme, pour réaliser des applications SUR Gecko, grâce à la technologie XUL pour l'interface, la technologie XPCom pour embarquer des composants tiers en C++, JS, voir Python (ce dernier binding a été réalisé par ActiveState, l'auteur de l'IDE Komodo, qui est donc en XUL + Python).
En effet, Mozilla développait Firefox, Thunderbird, Composer. Il fallait donc une "plateforme".
Bref, Gecko était plus fait pour embarquer, qu'être embarqué. Le paroxysme a été atteint quand XulRunner est sorti, ce qui a permis le développement d'application diverses et variées par divers boites..
Mais du coup, les ressources chez Mozilla n'étant pas extensible, l'API Embedding a connu le succès inverse : de moins en moins maintenue, car pas le temps, et pas utilisée par Mozilla. Et malheureusement pas de contributeurs externes pour la maintenir (ou si peu).
Bref, c'est pour ça qu'Epiphany a fini par se tourner vers Webkit, et que Camino est... mort.
Je me souviens avoir participé à un workshop dédié à l'API embedding lors d'un Summit Mozilla, pour discuter de l'avenir de cette API : abandon ? ou pas ? faut-il la réécrire ? ce qu'il faudrait pour l'améliorer, etc... On était plusieurs à essayer de pousser à faire renaître cette API, parce que la concurrence commençait à se développer, grâce à la facilité d'embarquer WebKit.
Malheureusement, ça n'a pas vraiment eu de suite. Il y a bien eu des tentatives pour la remettre au goût du jour mais la mayonnaise n'a pas pris, vu le peu de contributions externes.
Et puis c'est un peu le cercle vicieux : moins une API est utilisée, moins cela encourage à la maintenir. Et moins elle est maintenue, plus elle a des problèmes, et donc moins elle est utilisée.
Maintenant, dire que "Mozilla a décidé de", est très fortement exagéré. Mozilla n'a rien décidé du tout. L'abandon de l'API Embedding s'est fait par la force des choses, tout simplement. Mozilla ne l'utilisait pas, n'avait pas forcément les moyens humains et financiers d'investir là dedans, et avait d'autres chats à fouetter.
À noter que :
Servo est conçu dés le départ pour être embarqué
la "plateforme XUL", est en train d'être abandonnée, et qu'un gros chantier est en cours pour la virer, en remplaçant les composants XUL/XBL par des Web Components (à terme, d'ici 2 ans je pense, toute l'interface sera probablement en HTML)
Gecko redevient peu à peu embarquable. C'est ainsi qu'il y a une GeckoView, qui sert pour leurs navigateurs et autres expériences sur Android (sur MacOS, ils n'ont pas le choix, Apple impose l'utilisation de WebKit). Pour le coté embarquable sur les autres plateformes, je n'ai pas trop suivi, donc je ne peux pas dire si les choses se sont améliorées.
[^] # Re: From the past
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Microsoft serait en train de développer un navigateur web basé sur Chromium. Évalué à 10.
Alors, en tant qu'ancien contributeur de Mozilla, je vais répondre.
Au départ, Gecko avait une API pour pouvoir être embarqué. Bon, elle n'était pas terrible, mais elle faisait le job à l'époque. Cela a permis le développement de navigateurs comme Epiphany, ou encore Camino (sous Mac OS). Ces navigateurs utilisaient vraiment la version "embarquée" de Gecko : leur interface n'était pas en XUL/JS, mais en pur GTK pour l'un, et Cocoa pour l'autre.
Malheureusement, cette API Embedding n'a pas été maintenue comme elle aurait dû l'être.
En fait les développements de Gecko étaient plus orientés pour faire une plateforme, pour réaliser des applications SUR Gecko, grâce à la technologie XUL pour l'interface, la technologie XPCom pour embarquer des composants tiers en C++, JS, voir Python (ce dernier binding a été réalisé par ActiveState, l'auteur de l'IDE Komodo, qui est donc en XUL + Python).
En effet, Mozilla développait Firefox, Thunderbird, Composer. Il fallait donc une "plateforme".
Bref, Gecko était plus fait pour embarquer, qu'être embarqué. Le paroxysme a été atteint quand XulRunner est sorti, ce qui a permis le développement d'application diverses et variées par divers boites..
Mais du coup, les ressources chez Mozilla n'étant pas extensible, l'API Embedding a connu le succès inverse : de moins en moins maintenue, car pas le temps, et pas utilisée par Mozilla. Et malheureusement pas de contributeurs externes pour la maintenir (ou si peu).
Bref, c'est pour ça qu'Epiphany a fini par se tourner vers Webkit, et que Camino est... mort.
Je me souviens avoir participé à un workshop dédié à l'API embedding lors d'un Summit Mozilla, pour discuter de l'avenir de cette API : abandon ? ou pas ? faut-il la réécrire ? ce qu'il faudrait pour l'améliorer, etc... On était plusieurs à essayer de pousser à faire renaître cette API, parce que la concurrence commençait à se développer, grâce à la facilité d'embarquer WebKit.
Malheureusement, ça n'a pas vraiment eu de suite. Il y a bien eu des tentatives pour la remettre au goût du jour mais la mayonnaise n'a pas pris, vu le peu de contributions externes.
Et puis c'est un peu le cercle vicieux : moins une API est utilisée, moins cela encourage à la maintenir. Et moins elle est maintenue, plus elle a des problèmes, et donc moins elle est utilisée.
Maintenant, dire que "Mozilla a décidé de", est très fortement exagéré. Mozilla n'a rien décidé du tout. L'abandon de l'API Embedding s'est fait par la force des choses, tout simplement. Mozilla ne l'utilisait pas, n'avait pas forcément les moyens humains et financiers d'investir là dedans, et avait d'autres chats à fouetter.
À noter que :