Article passionnant à lire, pour ce qui comme moi se demandent comment FireFox a réussi à se faire distancer par Chrome d'un point de vue technique. On apprend pas mal de choses sur les galères et désillusions qu'à traversé Mozilla ces dernières années :
* Parce que le fabuleux système de greffons de FireFox leur permettait de se greffer absolument n'importe où, il était extrêmement difficile de refactoriser le code. Les messages XPCOM, qui dans un autre projet auraient fait partie de l'architecture interne, étaient de-facto devenus des APIs publiques : impossible d'y toucher sans obliger les développeurs à mettre à jours leurs addons. De nombreux développeurs ont quitté le navire pour cette raison (car des fois il fallait quand même casser des choses).
* Les benchmarks étaient meilleurs que Chrome, mais ce dernier utilisait des artefacts d'UI pour paraître plus rapide au niveau de l'expérience utilisateur, notamment le multi-process qui le rendait plus réactif par rapport au design monothread de FireFox. L'équipe a mis du temps à réaliser qu'il fallait cesser de se conforter grâce aux benchmarks. C'est vrai qu'avant son passage à l'architecture Quantum (multiprocess/multithread), FireFox semblait vraiment ramer, et freezait même parfois à la manière d'un Netscape 4.
* Firefox OS était le grand chantier et la priorité de l'équipe à l'époque où ils développaient leur système multi-thread Electrolys. Ce dernier a donc pris un retard énorme en bonne partie parce qu'il fallait absolument qu'il tourne de manière optimale sous FireFox OS. On peut comprendre que ce dernier ait été abandonné assez brutalement.
Autrement, j'apprends que XULRunner a été lancé voilà 20 ans. Sacré coup de vieux, alors que je me rappelle l'avoir testé. C'était l'époque où IE6 retardait l'évolution du standard HTML.
Rust c'est leur seule solution. Ils ont essayé ce qu'ils ont trouvé pour gérer les threads en s'interfacant avec le reste de leur code et en ayant pas de race condition. Ils ont pas trouvé.
# Passionnant
Posté par Jean Canazzi . Évalué à 6.
Article passionnant à lire, pour ce qui comme moi se demandent comment FireFox a réussi à se faire distancer par Chrome d'un point de vue technique. On apprend pas mal de choses sur les galères et désillusions qu'à traversé Mozilla ces dernières années :
* Parce que le fabuleux système de greffons de FireFox leur permettait de se greffer absolument n'importe où, il était extrêmement difficile de refactoriser le code. Les messages XPCOM, qui dans un autre projet auraient fait partie de l'architecture interne, étaient de-facto devenus des APIs publiques : impossible d'y toucher sans obliger les développeurs à mettre à jours leurs addons. De nombreux développeurs ont quitté le navire pour cette raison (car des fois il fallait quand même casser des choses).
* Les benchmarks étaient meilleurs que Chrome, mais ce dernier utilisait des artefacts d'UI pour paraître plus rapide au niveau de l'expérience utilisateur, notamment le multi-process qui le rendait plus réactif par rapport au design monothread de FireFox. L'équipe a mis du temps à réaliser qu'il fallait cesser de se conforter grâce aux benchmarks. C'est vrai qu'avant son passage à l'architecture Quantum (multiprocess/multithread), FireFox semblait vraiment ramer, et freezait même parfois à la manière d'un Netscape 4.
* Firefox OS était le grand chantier et la priorité de l'équipe à l'époque où ils développaient leur système multi-thread Electrolys. Ce dernier a donc pris un retard énorme en bonne partie parce qu'il fallait absolument qu'il tourne de manière optimale sous FireFox OS. On peut comprendre que ce dernier ait été abandonné assez brutalement.
Autrement, j'apprends que XULRunner a été lancé voilà 20 ans. Sacré coup de vieux, alors que je me rappelle l'avoir testé. C'était l'époque où IE6 retardait l'évolution du standard HTML.
[^] # Re: Passionnant
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
C'est curieux qu'après ces échecs, ils misent encore sur une techno maison comme Rust.
Je leur souhaite de réussir, mais bon…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Passionnant
Posté par barmic 🦦 . Évalué à 2.
Rust c'est leur seule solution. Ils ont essayé ce qu'ils ont trouvé pour gérer les threads en s'interfacant avec le reste de leur code et en ayant pas de race condition. Ils ont pas trouvé.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.