News Xulfr

Plus de XUL pour les applis web

vendredi 26 février 2010 à 12:07

Mozilla a décidé de supprimer le support de XUL dans les pages web. Cela signifie que l'on ne pourra plus utiliser des éléments XUL dans application "distantes", hors chrome.

Cette décision a été prise à cause des trop nombreux problèmes de sécurités que XUL offre sur le web. Les développeurs de Mozilla veulent s'enlever une charge de travail et voudraient profiter de ce temps pour travailler plus sur HTML5 et XBL2. On ne sait pas encore si cette suppression interviendra dans la prochaine version de Firefox ou d'autres version futures. Vous pouvez suivre l'évolution via le bug 546857.

Bien entendu, cette suppression n'intervient que pour les pages web. Il n'est absolument pas question de supprimer XUL pour les extensions ou les applications XULRunner.

Cela va tout de même poser des problèmes pour tout ce qui est démonstration en ligne de XUL (en particulier celles qui sont hébergées sur xulfr.org). Et puis bien sûr, ceux qui auraient développé des applications web en XUL, celles-ci ne fonctionneront plus. Il y a toutefois des alternatives.

  1. Il est tout à fait possible de réaliser une extension, comportant le minimum de fichiers, et ouvrant des pages XUL délivrées par un serveur web profitant des privilèges chrome. Par exemple, le nouveau CMS RBSChange utilise une telle technique. Certes, il faut installer une extension, mais l'essentiel de l'application se trouvant sur un serveur web, il n'y a pas besoin de mettre à jour l'extension à chaque évolution.
  2. Vous pouvez continuer à profiter du modèle de boîte flexible de XUL, utiliser les propriétés -moz-box-* sur des éléments HTML (ainsi que display:-moz-box;). Ces propriétés CSS sont d'ailleurs spécifiés dans un brouillon du W3C, donc amenées dans le futur à devenir un standard, tout comme -moz-appearance. À noter que Webkit (donc Safari et Chrome) a une implémentation similaire de ces propriétés.

D'ailleurs, les éléments XUL seront conservés dans le DOM par Firefox lors du chargement du document. Rien ne vous empêche de vous faire donc une feuille de style xul.css pour rétablir les propriétés CSS pour XUL. Vous perdrez cependant les comportements et fonctionnalités par défaut des éléments XUL. Et il n'y a pas vraiment d'alternative. HTML5 prévoit bien quelques balises pour les menus et commandes (pas encore implémenté dans Firefox), mais rien pour un équivalent des templates, des trees etc...

Trackbacks

Les trackbacks pour ce billet sont fermés.

Commentaires

1. vendredi 26 février 2010 à 16:00, par hhf

LA mort de XUL pour les développeurs web, et surtout champ libre pour Flex. Vraiment je comprend pas Mozilla, ils étaient précurseur sur les langage RIA, tout le monde se méne une guerre pour imposer sa technologie : Flex, Silverlight, JavaFX... Et Mozilla se retire. N'importe quoi.

2. vendredi 26 février 2010 à 22:01, par Daim

Comme il est précisé dans https://bugzilla.mozilla.org/show_bug.cgi?id=546857. Une bonne implementation de XBL2 et de la specification CSS3 concernant le flex box model voudra mieux qu'effectuer des contorsions pour supporter l'implémentation actuelle du XUL pour les applications web (CSS3 + XBL2 permettra largement d'avoir un dialecte XUL valable pour tous les navigateurs supportant les standards).

( IMHO, XUL est un formidable langage pour faire des applications desktop, en environnement priviligié, mais j'ai toujours eu le sentiment que son support pour des applications web était un 'effet de bords', interessant certe, mais sans vrai avenir sur le web dans la mesure ou il n'est actuellement supporté que sur les navigateurs basées sur gecko. )

3. samedi 27 février 2010 à 08:18, par Raph

Même sentiment que Daim... Pour moi XUL n'a jamais su s'imposer en temps RIA.

En revanche, Mozilla devrait encore plus appuyer son utilisation en Desktop, car c'est vraiment du bonheur pour moi de l'utiliser en version XulRunner. Dommage que certains aspects visuels de certains éléments (groupbox, tabs,...) ne soient pas parfaits selon les plateformes et le moteur de thème.

4. samedi 27 février 2010 à 09:49, par Pierre

C'est vraiment décevant ce que nous fait Mozilla en ce moment. C'est probablement pour rattraper plus facilement leur retard face à Chrome. Mais est-ce un bon choix ? Je ne sais pas, mais si à la fin on a juste un Firefox façon chrome avec 2 ans de retard à quoi cela peut-il bien servir ?

J'ai l'impression qu'ils vont surtout réussir à dégouter un grand nombre des contributeurs à Xulrunner et aux extensions si les technologies mises en œuvres ont un spectre d'utilisation de plus en plus réduit. D'ailleurs c'est déjà le cas, il y quelques années il y aurait eu plusieurs dizaines de commentaires sur ce billet et là quasiment aucune réaction.

C'est probablement la rançon du succès, avoir privilégié des fonctions très (trop) grand publique (Personnas, Vidéo... ) et être en retard sur des choses plus structurantes et décisives pour le web: multithreading et XBL2 (pouvoir enfin se débarrasser des frameworks javascript de composants HTML). C'est dommage qu'une fondation ai les mêmes travers que les sociétés commerciales.

J'espère seulement qu'ils auront l'intelligence de déjà implémenter XBL2 avant de supprimer Xul façon web.

5. samedi 27 février 2010 à 17:37, par Laurentj

@daim : pas tout à fait d'accord avec toi. Ok qu'avec CSS3 + XBL2 on pourra "simuler" XUL, mais

1) on ne pourra jamais implémenter tout ce que nous offrait l'implémentation native de XUL, en tout cas pas d'une manière performante et efficace (je pense aux trees, aux templates...). 2) une implémentation native est toujours mieux qu'avoir à ajouter à chaque appli une tonne de XBL et de feuille de style. C'est plus confortable de développer quand tout fonctionne "out of the box", et ça soulage les serveurs (bande passantes et cie).

Ce qui est le plus embêtant, ce sont les templates. ça évitait d'avoir à faire de l'ajax implicitement pour remplir des listes de données et générer des morceaux d'interfaces...

Et j'ai la même impression que Pierre. J'ai bien peur qu'au final, d'ici 2-3 ans, Firefox ne soit plus l'ombre de lui même, et n'aura finalement plus rien d'innovant, plus rien qui le démarquera vraiment de la concurrence.

6. dimanche 28 février 2010 à 03:37, par Attristé

Moi qui voulait inciter mon client (un grand compte, une banque) à utiliser Gecko pour XUL distant, et bien c'est râpé, l'application bancaire restera sous IE en mode HTA. J'ai même plus envie de proposer Prism. Merci Mozilla. :'-(

7. dimanche 28 février 2010 à 21:05, par Paul

Je suis vraiment déçu par vos réactions.

Je pense juste que vous avez une très mauvaise vision de se qu'il se passe chez Mozilla et que vous pensez savoir ce que l'on doit faire sans faire l'effort de comprendre et de vous *renceigner*.

Ça fait des années qu'on dit que:

  • Le XUL, c'est les extensions et XulRunner
  • Coté web, on veut des standards: HTML5
  • On pousse les standards pour qu'on faire des applications riches (par exemple le model de boite flex, DnD, File API, ...)
  • Mozilla ne va pas s'ammuser à introduire des technos NON STANDARDS

8. lundi 1 mars 2010 à 10:55, par Daim

Je le redis encore, XUL et XULRunner sont des formidables outils pour faire des applications desktop avec un navigateur embarqué, mais il ne faut pas confondre la plateforme applicative (au sens application desktop native) et le web applicatif qui lui doit se développer a partir des standards; je rejoins donc Paul tout a fait sur ce point.

Lorsque vous choisissez Gecko comme plateforme de dev, c'est du même ordre que de choisir QT+webkit ou GTK+webkit ou un autre framework pour vos applis, on n'est plus dans le domaine du web.

Dans un context de RIA (pour la comparaison avec Flex), vous êtes maître du choix de la plateforme client que vous imposez aux utilisateurs, dans ce contexte XUL marche toujours très bien. Et pour continuer la comparaison, ce n'est parceque XUL pose des problèmes de securité que les autres frameworks n'en pose pas (cf les derniers fixes de Flash).


        

9. lundi 1 mars 2010 à 11:38, par de passage

hye, moi qui ai développé des mini CMS...

On devrait faire une pétition !

10. mardi 2 mars 2010 à 00:05, par mumu

Si je me souviens bien, Prism s'appuie sur XulRunner ce pourrait-être une solution pour le web applicatif XUL si Mozilla le maintient.

11. mardi 2 mars 2010 à 16:08, par Paul

@mumu Je vois pas le rapport

12. mercredi 3 mars 2010 à 09:13, par Loïc

Salut, @Paul : ne soit pas déçu, je pense qu'il y a ici une brochette de codeurs attachés à cette techno que je pensais moi même intégrer dans les backoffice de mes développements afin d'enrichir l'interface utilisateur et surtout de proposer un environnement stable et réactif et pourquoi pas extensible par des tiers. Avec une telle annonce, c'est hors de question : je pense que nous sommes beaucoup à avoir besoin de stabilité dans les technologies que nous utilisons car le fait qu'elles avancent et disparaissent, ou rencontre des points de divergence (je pense à Symfony 2.0 qui n'aura rien à voir avec la v1 et qui va "forcer" les développeurs souhaitant capitaliser sur des solutions développées à sévèrement investir dans leurs refontes) tels que des acteurs ayant de petits moyens, il est très difficile - comprendre couteux - de suivre la musique et de retourner sa veste régulièrement au nom du sacro saint standard, une quête qui n'a pas de fin et qui nous pousse au consumérisme technologique. Donc oui, XUL m'attirait beaucoup pour l'alternative open-source de développement qu'il propose, et surtout pour le soutien que la fondation lui accorde. Si cela change, 2 options : soit il y a un remplaçant de talent, soit nous irons voir ailleurs. Après je comprends bien que Mozilla ne peut pas tout. Mais bon, il va falloir être très transparent sur le sujet sans quoi ça va faire des bulles... Loïc

13. mercredi 3 mars 2010 à 10:57, par Paul

@Loïc Toi t'as juste rien compris :)

1. XUL dans un backoffice, ça n'a rien d'extensible (pas plus que HTML) 2. On abandonne XUL remote, pas XUL platform (qui lui est extensible et stable) 3. On n'a jamais retrourné notre veste sur quoi que ce soit 4 ... plein de trucs, mais j'abandonne

14. mercredi 3 mars 2010 à 18:44, par Loïc

Paul, avec tout le respect que j'ai pour toi, parle moi meilleur, je suis quelqu'un de très important dans mon village. Ca mis à part, je te remercie pour ton éclaircissement "xul remote / xul platform", je pensais que tout xul était dans le sac. Bon sur ce, n'abandonne pas :) Loïc

15. mercredi 3 mars 2010 à 19:09, par Paul

@Loïc Désolé :) juste mare de devoir répéter 20.000 fois la meme chose. Passe le bonjour à ton village de ma part ^^

16. jeudi 4 mars 2010 à 15:19, par Laurentj

@loic j'ai pourtant bien indiqué dans la news :

>Il n'est absolument pas question de supprimer XUL pour les extensions ou les applications XULRunner.

17. dimanche 7 mars 2010 à 03:08, par Ner0lph

Ah ça, c'est dommage que XUL remote soit abandonné. Il pouvait permettre de faire des applications intranet riches. :-|

18. lundi 8 mars 2010 à 21:23, par Daim

@Ner0lph

Relit bien ce qui à été dis plus haut, il est *toujours possible* de faire des applications intranet riches.

19. mardi 9 mars 2010 à 15:13, par Ner0lph

En remote XUL ? Je parlais d'applications web, bien sûr, mais sur des intranets, pas internet.

Les commentaires pour ce billet sont fermés.


Copyright © 2003-2013 association xulfr, 2013-2016 Laurent Jouanneau - Informations légales.

Mozilla® est une marque déposée de la fondation Mozilla.
Mozilla.org™, Firefox™, Thunderbird™, Mozilla Suite™ et XUL™ sont des marques de la fondation Mozilla.