Forums : Les possiblités de la plateforme Mozilla

C'est très difficle de te répondre sur le choix stratégique à adopter sur un projet à long terme. Ce que je peux te conseiller - mais je suis sur que tu l'as déjà fait ;) - est de (re)lire la page /entreprises/ du site...

C'est une vraie bonne question.

De mon expérience avec XUL qui date de 2ans et demis, voilà ce que je peux en retenir.

Coté XUL, les seules vraies évolutions viennent de l'ajout de balises (richbox), et du changement du fonctionnement des arbres (nsIColumn).

Coté XPCom, les IDLs n'ont pratiquement pas bougées.

Il y a pourtant eu une évolution violente, le passage de XPFE (la suite Mozilla) au toolkit (aviary), mais qui a eu lieu lors de la création de Firefox.

Coté XPCom, à chaque évolution de Gecko, il y a des modifications. Si tu travailles exclusivement avec l'API frozen, tu n'auras pas de grosses mauvaises surprises.

En ce qui conserne l'enregistrement d'un chrome, il y a eu entre Gecko 1.7 et 1.8 une réelle modification mais celle de Gecko 1.8 (le fichier manifest) sera certainement conservée un bout de temps.

Mon avis personnel est que dans 5 ans, on aura de nouvelles balises, un processus de compilation XPCom simplifié (XDK). On travaillera exclusivement sur XulRunner. Coté code C++ pour le XPCom, il est probable que les choses changent un peu. Si ton appli n'est que du XUL & JS, je reste persuadé qu'il n'y aura aucun boulversement, peut etre quelques modifications, mais rien de violent.

Honnetement, tu peux parier sur ces technologies. De plus, meme si il a un gros changement, les anciennes versions de gecko sont entretenues pendant un petit bout de temps. Donc à mon avis, vas y, fonce :)

Je m'intéresse aussi à cette techo. Mais au niveau pérénité je reste encore inquiet. Xul existe depuis 5 ans et pourtant aucune killer application n'existe, toujours pas d'ide pour construire des interfaces graphiques pour un néophyte en 10 mn. Bcp de langage a maitriser ( javascript ( version 1 puis bientot version 2 ) + css + html + c++ + ... )... et dernièrement limité au moteur Gecko/Firefox ( seulement 10 à 20% des utilisateurs )

Attention aussi au version de firefox <1.0, ==1.0, +1.5 ... , au api qui change, évolue, au difficulté de faire des choses simple sans tomber dans des tonnes de code (cf code pour gérer un arbre 'complexe' (tree)).

Ajax , lui promet de fonctionner sur IE/Firefox/Opera/Etc. Regarde backbase, Rialto, flex, openlaszlo ...

Sur 10 ans : actuellement je tablerais sur Java Web Start pour un projet professionnel.

Mon avis

Ami

Ami a écrit:

Xul existe depuis 5 ans et pourtant aucune killer application
n'existe

Heu, pourtant j'en connais quelques unes :)

* Firefox
* Thunderbird
* Le projet Calendar

Ne venant pas de la fonfation Mozilla:

* Nvu
* Songbird
* bientôt AllPeers

De plus, n'oublions pas que XUL existe en effet depuis assez longtemps mais n'est connu comme un langage à part entière que depuis une année environ. La techno est jeune mais robuste.

toujours pas d'ide pour construire des
interfaces graphiques pour un néophyte en 10 mn.

On a déjà souvent eu l'occasion d'en parler. Personne n'est vraiment d'accord sur la faisabilité et l'intéret d'un tel IDE. Pour moi, finallement, je n'en vois pas l'intéret, à part peut etre fournir un moyen de promouvoir XUL plus facillement. Mais jamais un tel outil ne pourra couvrir réellement le potentiel de Gecko (gérer les XBL/Overlays/scripts etc...), ou alors il faudra un sacré gros boulot.

Bcp de langage a maitriser ( javascript ( version
1 puis bientot version 2 ) + css + html + c++ + ... )

Enfin bon, en général, pour un dev web, il suffit d'apprendre le XUL, un langage XML pas ci compliqué que ça. Le C++, ce n'est vraiment pas nécessaire. Sur tous le gens que je connais faisait du dev Mozilla, une toute petite minorité fait du dev XPCom, et encore moins du dev XPCom en C++.

Attention aussi au version de firefox <1.0, ==1.0,
+1.5 ... , au api qui change, évolue

l'API ne change pas autant (cf. mon dernier message).

au difficulté de faire des choses simple sans tomber
dans des tonnes de code (cf code pour gérer un
arbre 'complexe' (tree)).

Alors là non, je ne suis absolument pas d'accord. En général, cela vient souvent du manque de connaissance du développeur. C'est tout l'intéret de XUL, on peut construire des choses extrètement complexes en terme d'UI sans avoir à gérer une quantité incroyable de code. Regarde toolkit ainsi que le code de Thunderbird et de Firefox. En détail, peux tu expliquer ton problème avec les arbres complexes ?

Ajax , lui promet de fonctionner sur
IE/Firefox/Opera/Etc. Regarde backbase, Rialto,
flex, openlaszlo ...

Sur 10 ans : actuellement je tablerais sur Java
Web Start pour un projet professionnel.

Pour le coup, je reprends ce que tu dis au dessus:

... difficulté de faire des choses simple sans tomber
dans des tonnes de code (cf code pour gérer un
arbre 'complexe' (tree)).

Raconte moi comment tu peux gérer un arbre complexe avec ce genre de technologies sans tomber dans un code monstrueux ?

Ajax n'est pas une technologie concurrente à XUL.

Ajax == DOM + XMLHttpRequest.

XUL & Co == DOM + XMLHttpRequest + Overlay + XBL + XPCom + Soap + plein d'autres trucs.

Gecko/Firefox ( seulement 10 à 20% des
utilisateurs )

Là je suis d'accord.

Mais, est-ce impensable de demander l'utilisation de Firefox ? Crois tu que Firefox mourra d'ici les 5 ans qui arrivent ?

Non, vraiment, je crois que l'on peut croire en cette techno.

Je comprend parfaitement l'enthousiasme que suscite xul, la preuve je continue a m'y intéresser.

Dire que xul, c'est facile ... oui et non. L'exemple du tree n'est pas anodin : tout le monde cherche un exemple pour gerer des arbres complexes et il n'y a que très récemment que j'ai vu quelqu'un poster une solution complète : c'est du code pour HYPER expert !

Ide pourquoi faire ? Mais a gagner en productivité / simplicité ! Ton client appelle et demande ses boutons 'annuler','ok' en bas, puis un autre jour à droite, et tel truc en rouge ou en vert ... tu ne vas perdre du temps a rentrer dans le code xul/css/javascript. A quoi sert la 'souris' à ce jeux ...

Mais, est-ce impensable de demander l'utilisation de Firefox ?

C'est LA question importante à soulever avec le client. Si il te dit OUI pour tous les postes internes et externes ( commerciaux sur le terrain, fournisseurs, clients). Faire miroiter que xul c'est génial et que le principal client (du client de john) ne peut pas y accéder car il veut reste avec IE, john risque de perdre son client de 7 ans beaucoup plus vite qu'il ne le pense.

Crois tu que Firefox mourra d'ici les 5 ans qui arrivent ?

Non bien sur, mais Firefox sera reconnu pour sa stabilité, ses perfomances avec des applications Ajax. Cela ne remet pas en cause xul mais c'est Ajax pour IE/Firefox/Opera/Etc qui l'emportera, car les décideurs continueront en majorité a utiliser IE.

Il manque une killer application, genre Compiere/SugarCrm sous xul pour vraiement commencer à rassurer des décideurs. Il n'existe aucune application pro en xul convainquante à ce jour.

Mon avis

Alban

Ami a écrit:

Dire que xul, c'est facile ... oui et non.
L'exemple du tree n'est pas anodin : tout le monde
cherche un exemple pour gerer des arbres complexes
et il n'y a que très récemment que j'ai vu
quelqu'un poster une solution complète : c'est du
code pour HYPER expert !

Je n'ai pourtant pas l'impression, mais je dois admettre que vu le nombre de personnes qui butent là dessus... ce doit etre en effet assez complexe. Mais ça ne demande pas de gérer plus de code que AJAX, mais clairement moins. Donc c'est peut etre un peu plus complexe, mais bien plus efficace.

Ide pourquoi faire ? Mais a gagner en
productivité / simplicité ! Ton client appelle et
demande ses boutons 'annuler','ok' en bas, puis un
autre jour à droite, et tel truc en rouge ou en
vert ... tu ne vas perdre du temps a rentrer dans
le code xul/css/javascript. A quoi sert la
'souris' à ce jeux ...

Oui, mais dans ce cas, il va en falloire du boulot pour fournir un IDE potable, mais je suis persuadé qu'au final, un bon développeur se sentira plus à l'aise sans ce genre d'IDE.

Donc pour conclure sur ces 2 derniers points, je pense que le vrai problème comme Laurent et moi l'avons souvent soulever, c'est la courbe d'apprentissage qui est vraiment importante. Pour quelqu'un qui baigne dans ces technologies, c'est vraiment l'idéal, par contre, l'apprentissage n'est pas évident, et c'est dans ce cas où un IDE pourrait etre intéressant ainsi qu'un framework simplifiant le développement. Pour le framework, il y a déjà la JSLib qui permet de simplifier l'accès aux XPCom courants (nsIFile & co). Pour manipuler un arbre, un IDE ne changera rien du tout. L'IDE ne pourra intervenir que pour des taches triviales, mais évidement, ce sera d'une grande aide pour les débutants et les designers.

>Mais, est-ce impensable de demander l'utilisation
de Firefox ?
C'est LA question importante à soulever avec le
client. Si il te dit OUI pour tous les postes
internes et externes ( commerciaux sur le terrain,
fournisseurs, clients). Faire miroiter que xul
c'est génial et que le principal client (du client
de john) ne peut pas y accéder car il veut reste
avec IE, john risque de perdre son client de 7 ans
beaucoup plus vite qu'il ne le pense.

Bien sur, c'est la condition sinequanone.

>Crois tu que Firefox mourra d'ici les 5 ans qui
arrivent ?
Non bien sur, mais Firefox sera reconnu pour sa
stabilité, ses perfomances avec des applications
Ajax. Cela ne remet pas en cause xul mais c'est
Ajax pour IE/Firefox/Opera/Etc qui l'emportera,
car les décideurs continueront en majorité a
utiliser IE.

Le client aura le choix entre une application de qualité qui ne tourne que sur Firefox ou alors une application de moins bonne qualité qui tourne partout.

On ne le nira jamais, le gros défaut de ces technologies, c'est qu'elles ne fonctionnent que sous Firefox. Après, ça dépend énormément du contexte. Il faut voir pour le client si les avantages des technos XUL & co contrebalancent le fait de ne travailler qu'avec un seul navigateur. Et on a la chance que ce navigateur fasse parti des meilleurs sur le marché, donc ce n'est pas non plus si lourd pour lui. Va lui montrer Mab en lui expliquant qu'il n'a rien eu à installer sur sa machine, que cela revient à une appi web classique, en général, ça fait réfléchir le client ;)

Il manque une killer application, genre
Compiere/SugarCrm sous xul pour vraiement
commencer à rassurer des décideurs. Il n'existe
aucune application pro en xul convainquante à ce
jour.

Et bien regarde cette page:

http://xulfr.org/wiki/RessourcesLogiciel(..)

et tout particulièrement celle là:

http://demo.webdevelopers.cz/

John Hohn :

Cependant, je m'adresse à vous pour savoir si en Juin 2006 cela vaut vraiment la peine d'attaquer un projet d'envergure avec une technologie comme XUL ?

Pourquoi pas ?

Cette technologie a-t-elle réellement un avenir ?

Bien sûr que cela a de l'avenir : le W3C envisage même de le standardiser. Et franchement, on est beaucoup plus productif avec du xul qu'avec un framework 100% ajax.

Le langage n'est-il pas encore un peu trop jeune pour attaquer de gros projets ?

XUL existe depuis plusieurs années déjà... Et il a fait ses preuves depuis longtemps dans les applis Mozilla...

Ce langage dépendra-t-il également de l'avancement de Firefox ?

Jusqu'à maintenant oui. Ce sera moins le cas quand XulRunner sera sortie en version stable.

Si Firefox, un jour, s'arrête, que se passe-t-il ?

Franchement, crois tu qu'un tel projet comme Firefox/Mozilla cessera dans un avenir proche ? Alors qu'il a des millions d'utilisateurs ? que des societés comme Novell, Ibm etc investissent dedans ? Et puis il y a trop de développeurs trés attachés à ce projet pour qu'il puisse mourrir un jour. Un exemple : AOL qui a liquidé Netscape en 2003 (société à l'origine de Mozilla). Le projet ne s'est pourtant pas arreté. Les développeurs l'ont repris en main, une fondation a été crée etc.. bref, pour son avenir, aucun souci.

L'interaction avec les bases Mysql, sqlite et la langage PHP est-il toujorus d'actualité dans l'avenir?

Mysql : oui, il y a une extension qui existe donc.. Sqllite : il est utilisé en natif dans Firefox 2,(MozStorage), donc... Interaction avec le langage PHP : je ne vois pas de ce que tu veux parler.. Il n'a jamais été question d'avoir du PHP avec XUL.. Ou alors tu confond avec les services web ou les applis web, mais rien à voir non plus car tu peux générer du XUL avec n'importe quel langage coté serveur.

XulRunner a-t-il lui aussi de l'avenir ?

Bien evidement, vu le nombre de projet qui fleurisse, alors même qu'il n'est pas encore en version finale.

La communauté Xulesque voit les choses comment ? Selon vous, quel est le point le plus inquiétant au sein de XUL et de sa philosophie ?

Aucun. C'est une technologie trés en avance sur son temps (ça date de 1999 hein ;-). Qui permet de faire des merveilles.

Même si cela ne semble pas en prendre le chemin, je suis comme tout le monde, je ne peux pas me permettre de refaire la roue tous les 2 ans parce que le langage n'est plus suivi et/ou devenu obsolète, ou je ne sais quoi d'autres...

Obsolète... il est plutôt en avance sur beaucoup de chose. C'est ce coté high tech qui fait un peu peur. Mais bon, si tout le monde hésite à se lancer, c'est clair que ça va pas faire avançer le shmilblik.

Je travaille dans une petite boîte, spécialisé dans les technos XUL. Et nous croulons sous le boulot. Bref : tout le monde veut faire du XUL, tu peux donc être rassuré ;-)

Ami :

Mais au niveau pérénité je reste encore inquiet. Xul existe depuis 5 ans et pourtant aucune killer application n'existe,

aheum... Paul a repondu à ce sujet...

toujours pas d'ide pour construire des interfaces graphiques pour un néophyte en 10 mn.

Bcp de langage a maitriser ( javascript ( version 1 puis bientot version 2 ) + css + html + c++ + ... )...

Et quand tu fais du dev web traditionnel, il faut que tu apprennes quoi ? HTML, Javascript, CSS, + langage coté serveur (java, php ou autre). Bref, au final, si tu fais le compte, tu n'a pas vraiment plus à apprendre en faisant du XUL...

et dernièrement limité au moteur Gecko/Firefox ( seulement 10 à 20% des utilisateurs )

et ?

Attention aussi au version de firefox <1.0, ==1.0, +1.5 ... , au api qui change, évolue, au difficulté de faire des choses simple sans tomber dans des tonnes de code (cf code pour gérer un arbre 'complexe' (tree)).

C'est vrai, il n'y a pas toujours de compatibilité descendante. Mais bon, d'un autre coté, bien souvent, dans les technos qui évoluent et reste compatibles avec l'existant, elles deviennent vite lourdes, elles se traînent des boulets, ça devient usine à gaz etc..

Ajax , lui promet de fonctionner sur IE/Firefox/Opera/Etc. Regarde backbase, Rialto, flex, openlaszlo ...

hum ! et tu te plains du nombre de techno à apprendre en XUL ? Et les heures d'apprentissages des API de ces frameworks Ajax, tu en fais quoi ? ;-)

Sur 10 ans : actuellement je tablerais sur Java Web Start pour un projet professionnel.

pas vraiment de ton avis vois tu ;-)

Cela ne remet pas en cause xul mais c'est Ajax pour IE/Firefox/Opera/Etc qui l'emportera, car les décideurs continueront en majorité a utiliser IE.

Alors là pas du tout. Ajax, c'est du trop bas niveau. de la techno de bricoleur. D'ailleurs la preuve, pour éviter de trop bricoler, il y a plein de framework qui sortent à droite et à gauche. Dans 10 ans, ajax, ça n'existera plus, ou alors sera reservé à quelques trucs spécifiques.

L'avenir est aux langages déclaratifs : XUL, XForms etc : On déclare, on ne programme pas (d'ailleurs Backbase s'appuie sur ce principe). Et ça change tout : c'est beaucoup plus simple, ce sont des technos beaucoup plus accessible à tout le monde.

Et comme je disais : le W3C est en train de travailler sur la standardisation d'un XUL-like, ce n'est pas pour rien.

Il manque une killer application, genre Compiere/SugarCrm sous xul pour vraiement commencer à rassurer des décideurs. Il n'existe aucune application pro en xul convainquante à ce jour.

Parce que cela n'interresse pas les entreprises de montrer toutes les applis XUL qu'ils font. Va voir la rubrique entreprise pour te donner une idée. Si des sociétés high tech comme Renault F1, si une grosse administration dont je ne citerai pas le nom car ce n'est pas encore officiel, passe ses applis à XUL, sur des milliers de postes, ce n'est vraiment pas pour rien. Euh ils ont tout de suite compris le potentiel de la techno. Pas besoin d'une *killer app*. Ou plutôt, la killer app, ils l'ont tout de suite vue : c'est Firefox.

Pour ton histoire d'IDE : il y en a, (exlipse XUL etc..). Pour des éditeurs d'interface graphique "à la souris" : c'est trop compliqué à faire, à cause de XBL notament.. Mais franchement, passer le cap du newbie, ce genre d'éditeur sera vite mis de coté car forcément trop limité. Pas grand interet. Beaucoup dont moi et Paul avons étudié la chose, et le jeu n'en vaut pas vraiment la chandelle. Croire le contraire, à mon sens, c'est ne pas comprendre XBL (qui est en train d'être normalisé aussi d'ailleurs...)

Pour faire court : perenité, stabilité. Il ne faut vraiment pas s'inquieter.

XBL (et probablement XUL) va être normalisé. On peut parier une implémentation de XBL dans d'autres navigateurs, car il permet d'ajouter la prise en charge de nouveaux dialectes XML, sans attendre que l'éditeur de tel ou tel navigateur veuille bien implémenter ces nouveaux dialectes. Et sachant que 80% des balises XUL sont des XBL, je vous laisse tirer les conclusions ;-)

XBL c'est LA pierre angulaire des technos Mozilla.