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.
# Passionnant
Posté par Jean Canazzi . En réponse au lien Firefox a du changer 2 fois de système d'extensions pour pouvoir évoluer (multi-thread, legacy code). É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.