Peut-être qu'en démarrant aujourd'hui ils auraient choisi un toolkit existant multi-plateforme, Qt5 par exemple, au lieu de développer une solution interne.
Je pense que c'est difficile de remettre en cause le fait de développer des solutions maisons quand l'existant ne nous convient pas. À la limite, pourquoi pas. Après, je trouve ça un peu douteux, dans le cadre d'un logiciel comme un navigateur, de ne pas trouver son compte dans les tookits graphiques existants, mais bon, je méconnais peut-être les spécificités des navigateurs ou les problèmes de performances liés à l'utilisation de moteurs de rendus très complexes.
Le problème, c'est de ne pas développer ce toolkit graphique comme un toolkit graphique, justement. Le réflexe de tout programmeur, et surtout de tout libriste convaincu, c'est de réfléchir sur la portée et la généralité du code. Si pour des raisons qui t'appartiennent tu développes un jeu vidéo, et que pour résoudre certains problèmes tu as besoin de coder des routines optimisées pour inverser des matrices ou résoudre des équations différentielles, tu vas forcément te dire "ouhlala, ce code là n'a rien à faire dans un jeu vidéo", et tu vas dissocier les projets. J'imagine que quand on code un navigateur et qu'on en est à recoder un compositeur de fenêtre portable, on finit par se demander si ce qu'on fait ne mérite pas d'être dissocié du navigateur, et d'avoir sa propre vie.
C'est d'ailleurs ce qui s'est passé pour Rust, et c'est très bien. On peut utiliser Rust pour des projets qui n'ont rien à voir avec un navigateur, c'est devenu un outil mis à disposition de la communauté. Et inversement, je vois mal une fonctionnalité dans Firefox devoir attendre que Rust passe à la version supérieure.
[^] # Re: Wayland impacte les applis ?
Posté par arnaudus . En réponse au lien Firefox Nightly prend maintenant en charge (expérimentalement) Wayland. Évalué à 2.
Je pense que c'est difficile de remettre en cause le fait de développer des solutions maisons quand l'existant ne nous convient pas. À la limite, pourquoi pas. Après, je trouve ça un peu douteux, dans le cadre d'un logiciel comme un navigateur, de ne pas trouver son compte dans les tookits graphiques existants, mais bon, je méconnais peut-être les spécificités des navigateurs ou les problèmes de performances liés à l'utilisation de moteurs de rendus très complexes.
Le problème, c'est de ne pas développer ce toolkit graphique comme un toolkit graphique, justement. Le réflexe de tout programmeur, et surtout de tout libriste convaincu, c'est de réfléchir sur la portée et la généralité du code. Si pour des raisons qui t'appartiennent tu développes un jeu vidéo, et que pour résoudre certains problèmes tu as besoin de coder des routines optimisées pour inverser des matrices ou résoudre des équations différentielles, tu vas forcément te dire "ouhlala, ce code là n'a rien à faire dans un jeu vidéo", et tu vas dissocier les projets. J'imagine que quand on code un navigateur et qu'on en est à recoder un compositeur de fenêtre portable, on finit par se demander si ce qu'on fait ne mérite pas d'être dissocié du navigateur, et d'avoir sa propre vie.
C'est d'ailleurs ce qui s'est passé pour Rust, et c'est très bien. On peut utiliser Rust pour des projets qui n'ont rien à voir avec un navigateur, c'est devenu un outil mis à disposition de la communauté. Et inversement, je vois mal une fonctionnalité dans Firefox devoir attendre que Rust passe à la version supérieure.