L'idée est donc que comme on reproche d'avoir une technologie lente et consommatrice de RAM, on la quitte pour encore plus lent et encore plus consommateur de RAM.
XUL, ce n'était qu'un format permettant de concevoir une interface graphique décrite en XML style HTML mais en utilisant des composants natifs du système (enfin, aussi natifs que possible), animée avec JavaScript, par Gecko, le même moteur que pour HTML/JS. Je doute que passer de XUL à HTML/JavaScript entraîne des ralentissement. On peut d'ailleurs imaginer que c'est plus rapide, parce que les moteurs JS ont eu le temps d'être optimisés à mort depuis l'abandon de XUL, et le rendu HTML est probablement plus travaillé / optimisé que le rendu XUL dans Gecko. L'idée derrière passer de XUL à HTML était de permettre le retrait du support de XUL, on peut supposer que cette simplification permet aussi des optimisations. Mais je ne sais pas si ça a eu lieu, j'ai l'impression que XUL, ça traine encore dans Gecko.
Après, je trouve ça dommage que XUL ait disparu et que des trucs comme Electron ont pris la place que XUL aurait pu prendre (c'était pratique XUL !), et que le passage à HTML dans Firefox/Thunderbird nécessite probablement la maintenance d'un toolkit graphique dédié (probablement moins prenante que la maintenance de XUL) mais ça c'est une autre histoire.
Tout cela étant dit, là on parle d'un passage de C vers JS, pas de XUL vers HTML/JS, espérons que ce passage de C à JS pour l'implémentation des protocoles mail dans Thunderbird ne sera pas source de ralentissements / consommation mémoire significative. L'informatique doit s'alléger maintenant, pas l'inverse. Si ce passage permet de libérer du temps pour optimiser d'autres trucs (plus) significatifs, ça peut être gagnant, indirectement. Je doute que ça soit ça qui se passe, mais pourquoi pas.
[^] # Re: Pour des raisons de sécurité
Posté par raphj (site web personnel) . En réponse à la dépêche Dernières avancées du côté de Thunderbird. Évalué à 3. Dernière modification le 25 octobre 2022 à 13:15.
XUL, ce n'était qu'un format permettant de concevoir une interface graphique décrite en XML style HTML mais en utilisant des composants natifs du système (enfin, aussi natifs que possible), animée avec JavaScript, par Gecko, le même moteur que pour HTML/JS. Je doute que passer de XUL à HTML/JavaScript entraîne des ralentissement. On peut d'ailleurs imaginer que c'est plus rapide, parce que les moteurs JS ont eu le temps d'être optimisés à mort depuis l'abandon de XUL, et le rendu HTML est probablement plus travaillé / optimisé que le rendu XUL dans Gecko. L'idée derrière passer de XUL à HTML était de permettre le retrait du support de XUL, on peut supposer que cette simplification permet aussi des optimisations. Mais je ne sais pas si ça a eu lieu, j'ai l'impression que XUL, ça traine encore dans Gecko.
Après, je trouve ça dommage que XUL ait disparu et que des trucs comme Electron ont pris la place que XUL aurait pu prendre (c'était pratique XUL !), et que le passage à HTML dans Firefox/Thunderbird nécessite probablement la maintenance d'un toolkit graphique dédié (probablement moins prenante que la maintenance de XUL) mais ça c'est une autre histoire.
Tout cela étant dit, là on parle d'un passage de C vers JS, pas de XUL vers HTML/JS, espérons que ce passage de C à JS pour l'implémentation des protocoles mail dans Thunderbird ne sera pas source de ralentissements / consommation mémoire significative. L'informatique doit s'alléger maintenant, pas l'inverse. Si ce passage permet de libérer du temps pour optimiser d'autres trucs (plus) significatifs, ça peut être gagnant, indirectement. Je doute que ça soit ça qui se passe, mais pourquoi pas.