XulRunner : l'arme de XUL contre XAML
Par Laurentj le vendredi, août 26 2005, 16:54 - Technologies Web - Lien permanent
Un lecteur, Thomas, me fait trés justement remarquer que cela fait presque deux ans que j'ai écris ce billet, La nouvelle bataille du web s'annonce : XUL vs XAML, dans lequel j'émettais quelques souhaits à propos de XUL pendant ces deux dernières années, de façon à être prêt face à XAML qui devait voir le jour cette année avec Windows Vista.
Cette bataille annonçée se fera-t-elle comme prévue ?
Remarquons déjà que le début de la confrontation réèlle prend du retard, à cause de la sortie de Windows Vista sans cesse repoussée. Mais ce n'est finalement pas plus mal, parce que XUL n'est pas forcément prêt sur certains points, même si depuis 2 ans, cela a beaucoup avancé sur d'autres.
En effet :
- Face à XAML et au futur Visual Studio pour Windows Vista, il n'y a toujours pas aujourd'hui d'environnement de développement digne de ce nom, finalisé, pour XUL. Même si il y a eu beaucoup d'initiatives, beaucoup d'entre elles ont avortées.
- Malgré certaines rumeurs de l'époque qui annonçaient que cela pourrait se faire, le moteur gecko n'est toujours pas intégré dans les environnements libre comme GNOME, KDE. Dommage, cela aurait pu faciliter l'adoption des technologies XUL.
- Il est toujours aussi compliqué de faire une application XUL "standalone" car cela nécessite une recompilation de Mozilla, donc une certaine maîtrise de la plateforme.
Cependant, il ne faut pas perdre espoir. Des projets d'environnements de développement sont en plein développement et trés actifs, comme on peut le voir sur le wiki de mozilla. De plus, il s'en est passé des choses en deux ans.
Tout d'abord, le succés incontestable du navigateur Firefox. 83 millions de téléchargements depuis sa sortie il y a 10 mois, plus de 10%, 15%, voire 30% de parts de marché selon les pays. Ce qui veut dire plusieurs millions de plateforme XUL installées dans le monde, donc plusieurs millions d'ordinateurs capable d'éxécuter une appli XUL livrée sous forme d'extension. C'est donc déjà une trés belle avance par rapport à la future plateforme XAML, qui devra mettre un certain temps avant d'être à égalité (Tout dépendra si la sauce marketing preparée par Microsoft prendra ou pas, et si les entreprises auront suffisement de "cash" pour mettre à jour entiérement leur poste de travail).
Ensuite, le manque de ressources documentaires pour les développeurs XUL commence à disparaître. En effet, il y a eu depuis pour les francophones, la création du site xulfr.org, la traduction du tutoriel de xulplanet. La fondation Mozilla a lancé le wiki DevMo, un site de documentation technique sur Gecko, XUL &co, qui ne cesse d'être complété chaque jour, et dont la traduction en 7 langues est en cours.
La communauté d'utilisateurs et de développeurs n'a cesser de s'agrandir, grâce notament à la naissance d'organismes affiliés à la fondation comme Mozilla-Europe, qui fédèrent les projets de localisations des produits Mozilla, qui font de l'"évangélisme", voir même qui contribuent au développement de Gecko. Sans parler des sites comme geckozone qui eux aussi arrivent à rassembler des centaines d'utilisateurs.
Je finis par le plus croustillant, l'arme fatale de Mozilla selon moi : XulRunner. Certes, on n'en parle depuis longtemps dans le "milieu", ce n'est toujours pas sorti, mais quand Windows Vista/XAML sera disponible (courant 2006 ?), je pense qu'on disposera d'une version stable de XulRunner. On peut même déjà en télécharger des versions de tests.
Car XulRunner, c'est quoi ? c'est un "runtime" de Gecko, Firefox sans son interface utilisateur si vous preferez, qu'on installera comme on installe une machine virtuelle JAVA, ou un interpreteur python, ruby ou que sais-je encore. Bref, un "truc" qui sert à executer plusieurs applications et partagé par toutes ces applications. Grâce à XulRunner, on pourra faire des applications standalone (ne nécessitant donc pas Firefox qu'on n'a pas forcément besoin ou envie d'installer), trés légères (à télécharger), beaucoup moins gourmandes en ressources (que Firefox et Thunderbird réunis par exemple), simple à développer, qui peuvent se mettre à jour automatiquement, qui peuvent utiliser toutes les technologies rassemblées dans Gecko : XUL, SVG, MATHML, E4X, XForms, XTF et j'en passe etc. D'ailleurs, Firefox et Thunderbird deviendront des applications XulRunner. Ce qui veut dire, qu'un jour, en mettant à jour Firefox, vous installerez sans le savoir XulRunner. Et donc tout ce qu'il faut pour éxecuter pleins d'applications XUL indépendantes !
Et bien sûr, XulRunner sera multi-plateforme comme Firefox. Quand vous developperez une application basée sur XulRunner, elle sera executable sur windows, linux, MacOs etc.
En résumé :
- Xulrunner, Minimo (le futur "firefox" pour PDA), Firefox, Thunderbird..
- un support accru de technologies standards
- des millions d'utilisateurs
- des IDE prometteurs
- des technologies éprouvées depuis quelques années, open-sources, multiplateformes
- des innovations à venir, des ressources documentaires
Finalement, en deux ans, on a fait énormément de chemin, et il ne manque pas grand chose pour que XUL soit fin prêt à affronter son adversaire qui lui, aura tout à prouver et tout un marché à conquerir, chemin sur lequel XUL a déjà beaucoup d'avance.
Ainsi donc, pour répondre à Thomas : oui, je suis trés optimiste sur l'avenir de XUL et Gecko. Certes, il est illusoir de penser que XAML sera un flop. Des milliers de développeurs commençent d'hors et déjà à maitriser la plateforme XAML, via les SDK et les versions beta de Windows Vista fournit par Microsoft. Mais XUL aura (et commençe à avoir) toute sa place parmis cette future concurrence.
Commentaires
Me voilà un peu plus rassuré, surtout grâce aux promesses de XulRunner ;)
Note : l'hyperlien «il y a eu beaucoup d'initiatives» renvoie une erreur 404. (<note lj>corrigé</note>)
Pour avoir une vraie intégration de gecko dans Gnome, il faudrait commencer par avoir une libgecko, légère et rapide, indépendante de Firefox. Ceci dit on commence à avoir du mal à compter les applications qui utilisent le moteur gecko (même sans bibliothèque, directement à partir de firefox) sur ses petits doigts.
Pour KDE, c'est mort. Ils ont KHTML et je ne vois pas vraiment de raison pour eux de passer à Gecko, qui est plus lourd, plus lent et moins bien intégré.
Plus que XULRunner, je pense que j'attends avec plus d'impatience gecko1.9 avec cairo, et une bibliothèque libgecko indépendante de firefox.
SF : la "libgecko", elle existe depuis le debut de Mozilla, donc depuis trés longtemps http://www.mozilla.org/projects/embedding/
Comment crois tu qu'ils font pour epiphany et autres navigateurs utilisant Gecko (sans avoir XUL) ? ;-)
Sinon, pour un usage plus général, considère XulRunner comme une libgecko avec une API plus complete (comme on trouve dans Firefox).
Au fait, pour KDE, c'est pas tout à fait mort. Ils ont fait recement un Konqueror utilisant Gecko. Bon sinon, on pourra comparer la lourdeur, la lenteur de Gecko avec KHTML quand KHTML intégrera autant de technologie que Gecko ;-)
C'est donc peut etre une bonne raison d'utiliser Gecko à la place de KHTML : pouvoir utiliser les technologies que ne propose pas KHTML. (d'où cet essai concluant d'intégration de Gecko dans Konqueror :-p )
mm désolé, le "récement" n'est pas le bon terme. ça date déjà d'un an :-) http://dot.kde.org/1094924433/ Gecko utilisant QT, et embarqué dans un kpart. C'est pas mal déjà niveau intégration non ? ;-)
Je pense qu'il est dangereux de s'aventurer sur ce genre de comparaison. XUL et XAML diffèrent trop. On va avoir de mauvaises supprises si on laisse entendre que l'on va tuer XAML avec XUL, parce que quand quelqu'un va faire une démo d'une appli XAML qui va etre capable d'utiliser un élément <MSOfficeExcel/> permettant d'inclure un mini tableur à un application gérant une mini base de donnée de media qui peuvent être lus et controlés par un élément XAML <MediaPlayer/>.... bah là on aura l'air de rigolo avec notre XUL et nos jolis <button/> ou meme <browser/>.
Je ne dis pas que XPFE (XUL & co) c'est nul par rapport à XAML, mais différent.
Gecko est fortement lié au spécifications du W3C et est donc pour moi orienté Web et XAML vers le systeme d'exploitation Windows. XAML permettra de faire une application Windows "à la XUL". Ok, le media pouvant la diffuser/déployer passera certainement par internet. Mais Gecko lui est un outil permettant de rendre le web palpable, il offre des possibiliés de développer des applications rapidement, mais ça restera en général des applications webs poussées.
On pourra dire que Gecko sera un concurent à XAML le jour ou l'on pourra simplement intégrer des composants "office" (media, traitement de texte, etc...), mais ce la risque d'etre compliqué. Rappelons que Gecko est résolument multiplaterforme (une de ses forces), donc l'implémentation d'un composant "lecteur multimedia" devra être possible sous des ssyteme Unix (avec certainement Gnome) et sous Windows. Imaginez le boulot....
Sinon, Xulrunner en lui même est une révolution, mais il faut regarder surtout du coté de la libxul qu'il utilise qui est tout autant une performance.
Pour finir, le jour où l'on aura le choix entre Gecko VS XAML voilà les questions qu'il faudra se poser:
En ce moment la techno qui a le vent en poupe, c'est AJAX. Je me demande dans quelle mesure cette dernière : 1/ dédramatise le JavaScript pour les développeurs web 2/ prépare le terrain des XUL & Cie à venir...
Juste mes 2 centimes !
Ils compilent mozilla, et le lie dynamiquement. gtkmozembed nécessite de la même façon mozilla ou firefox. Pas une libgecko livrée à part, non, le gros browser. Je parle bien d'une libgecko livrée en tant que projet à part...
Paul, tu viens de mettre en lumière un aspect auquel je n'avais pas pensé, à propos de l'intégration des applis tiers en XAML...
Concernant l'intégration des applis tiers en XUL, il serait peut-être temps qu'un rapprochement se fasse avec les équipes d'OpenOffice. Curieusement d'ailleurs, la version 2.0 d'OpenOffice intègre un lecteur multumédia (je me demande ce que ça fait la dedans !) Il y a donc un espoir d'avoir un jour un équivalent à XAML multi-plateforme sur les points signalés par Paul.
L'espoir fait vivre ...
Pour le pb d'applications tiers, n'est ce pas le role d'un plugin ? Je ne sais pas.
Un exemple typique, c'est Foxytune. Une extension permettant de controler le lecteur Mp3 du systeme d'exploitation. Le codeur a du implémenter un composant XpCom pour WinAmp et pour xmms (entre autres). Mais là on ne fait que controler une appli extérieur.
La problématique de base serait par exemple d'intégrer un widget permettant d'intégrer un composant *office (openOffice ou microsoftOffice).
Faut il utiliser uniquement un élément OOo ou aussi MicrosoftOffice ?
Si on utilise uniquement OOo, c'est envisageable. On pourrait en effet envisager de lier Gecko à plusieurs applications présentes sur Windows et Linux (gstreamer, gaim, ...).
A quel point pourrait on envisager l'intégration de Gecko dans un OS ?
Personnellement, je ne crois pas qu'elle doive aller trop loin. C'est pour ça que je parlais de plugin.
Alors pouvons nous rivaliser avec XAML dans ce cas ? Non, je ne le crois pas. Il ne faut pas orienter Gecko dans ce sens là. Laissons à Gecko ses objectifs initiaux: un moteur permettant d'exploiter les standards du W3C !
Celà n'empechera pas l'implémentation de composants permettant de faire communiquer Gecko avec d'autres applis.
Mais je ne crois pas que les développeurs de Gecko se lancent dans ce genre de problématique. Ce serait un peu dénaturer les objectifs de Gecko, non ? Imaginons plutot un binding "très" générique Gecko <=> OS (disons plutot Desktop Manager).
KDE, Gnome et Windows ont leur propre système de composants (DCOP/Bonobo/XAML ?). Pourquoi ne pas envisager un binding pour chaque systeme ? Je ne sais pas dans quelles mesures ce genres de choses sont envisageables, mais ce serait l'idéal.
Après avoir manipé un peu avec XulRunner, voici mes impressions : - le toolkit mozilla est globalement très impressionnant (XUL, Gecko, Necko) - les templates RDF sont à la fois difficiles à utiliser et limités. Il faudrait revisiter le mécanisme de liaison entre une source de données et une IHM. C'est un sujet difficile, mais une techno comme XForms peut donner des idées. - Et gros point négatif, le support du seul et unique Javascript pour le dev hors XPCOM. JS n'est vraiment pas la panacée pour faire du code modulaire, maintenable. Une intégration de Pyton, Ruby, C, XQuery serait vraiment un progrès !
En tout cas ce n'est pas le mien. Javascript est largement suffisant pour son rôle de "glue" entre l'interface et les traitements métiers. Car il va de soit que dans une application codée correctement, on code les traitements métiers dans des XPCOM, qu'ils soient réalisés en C++, python, perl, ruby...(js en dernier recourt ou pour des trucs basiques).
Tu te doutes bien que si Javascript n'était pas adapté à l'utilisation qui en est fait dans les applis mozilla, aprés toutes ces années de bons et loyaux services, il y aurait longtemps qu'ils auraient changés ;-) Bon et puis, ils ne vont pas rajouter de la lourdeur en plus à gecko en ajoutant les moteurs python ou ruby (le moteur JS est trés léger et rapide).
À noter que Javascript 2.0 est en préparation, corrigeant les "quelques" lacunes de 1.5 ;-)
Mon point de vue sur JS n'est pas biaisé par le monde web. C'est une simple comparaison avec les autres langages (par exemple, on est obligé de gérer les dépendances d'include dans la fenêtre qui importe les JS et non dans les JS eux-mêmes)...
Et tu mets en lumière une faiblesse de la plateforme Mozilla : sa complexité : il faut maitriser trop de technologies pour être pleinement efficace. De ce côté, XAML va paraître immensément plus facile d'accès.
Je crois cependant que le potentiel de la pf moz est supérieur, et qu'on doit pouvoir améliorer tout ça !
Pas du tout :-) Tu peux faire des include en js dans mozilla (mais pas dans les pages web).
Pour le reste, d'autres langages sont plus puissant, certes, mais plus gourmand aussi. Sans compter que cela pose des problèmes.
Imaginons inclure python par exemple, pour remplacer javascript. Ok. Donc on embarque le moteur python dans la plateforme. Et que fais-t-on des bibliothèques du langage ? on les laisse ? ou on ne les inclus pas ?
dans le premier cas, ça va faciliter le developpeur python habituel, il va pouvoir utiliser ses libs/api habituelles. Mais d'un autre coté, ça va faire beaucoup de doublons avec l'API de la plateforme (api de manipulation de chaine, accés fichier etc..). Sans compter l'embonpoint que prend alors la plateforme. Dans le deuxième cas, on décide de n'intégrer que le moteur. Mais alors il ne reste que la structure du langage. Le développeur doit alors passer par l'API de mozilla (donc appeler les XPCOM). Le developpeur python risque donc d'être perdu, il n'a plus les objets "standards" de python. Est ce qu'alors ça reste interressant d'utiliser python ? je ne connais pas assez bien python pour répondre. Quant à n'inclure seulement certains libs, j'imagine qu'avec les dépendances qu'il y a entre toutes, ça risque d'être un casse-tête à ne vouloir que garder une partie. (peut etre je dis une bêtise...)
C'est valable pour les autres langages. Faire des bindings pour XPCOM, ça va (puisque ça existe, tu *peux* faire des XPCOM en python ) : il faut toutefois que python soit installé sur la machine cliente. Mais remplacer JS par python dans les scripts de l'interface utilisateur necessite d'embarquer python dans gecko, ce qui pose les problèmes que j'ai cité, en plus d'autres auxquels je n'ai pas pensé..
Pour le coté complexe de la plateforme: je suis d'accord avec toi. En même temps, la majorité sont des standards que connait ou doit connaître tout bon développeur web d'aujourd'hui : CSS, SVG, XFORMS, XHTML, RDF, XML, DOM, XSLT, SOAP, E4X, Ecmascript (JS)... C'est pas comme si tout ça était d'obscures langages proprios, utilisés par une seule plateforme de dev ;-). Ce sont des langages utilisés dans beaucoup d'autres logiciels. Les apprendre donc pour Mozilla n'est pas "perdu" si on veut passer à autre chose. c'est je dirais de la capitalisation de connaissances ;-) (c'est justement tout l'interet des standards !)
Il n'y a que XUL, XBL ou XPCOM qui restent spécifiques à Mozilla. Et encore pour qui a déjà développé avec du COM (MS) ou corba, n'aura aucun problème avec XPCOM. (si il a vraiment besoin de faire des xpcom)
Pour info le LoadSubScript est foireux en protocole asynchrone (en http par exemple) et ce jusqu'a la version courante de mozilla (cvs) car il plante si ton fichier js fait plus de 4096 caracteres (erreur à la code ds le code). En revanche en synchrone ca passe (file:// chrome://).
Ps : En http, on peut toujours utiliser xmlhttprequest et Eval pour faire l'equivalent d'un include
J'ai posté un bug la dessus ;-)
le bug : https://bugzilla.mozilla.org/show_bug.cgi?id=303376
Salut,
Juste pour dire que je me suis bien amusé à faire mesblogs.com en XUL et que j'avais trouvé ce site d'exemples bien pratique : http://www.hevanet.com/acorbin/xul/top.xul
Perso je ne pense pas que XAML soit une menace. Ce n'est pas la 1er technologie de pointe que nous sort Microsoft ! ça n'en reste pas moins du windows et que du windows donc pas standard donc pas multiplatforme donc pas interessant. Sauf .... si tout le monde se met à le dévelloper dans son coin ( ex : cloner Xaml pour linux ) et du coup bill se frotterait les mains. Il faut faire comme toutes les chose pas interessantes : l'ignorer !