Sauf à Redmond et dans la silicon valley. Ce qui est malheureux...
Vous auriez dit Berkely, MIT, Columbia j'aurais été un peu d'accord. Encore que j'aurais gentillement dit que l'INRIA et Le Polytechniceum de Lausanne jouait dans une cours pas très loin. Mais honnêtement alors que Microsoft s'apprète (avec beaucoup de mal apparament) à sortir son douxième produit basé sur le même kernel, que SGI agonise et passe sous Linux et que SUN vend des architectures AMD64 peut-on vraiment encore citer les US comme le fleuron de la recherche appliquée ? Les US brevètent, çà oui, mais pour ce qui est d'inventer par contre ... Pour l'instant on se contente surtout d'améliorations (dans la mesure ou l'implémentation est pas trop buguée.)
parce que XUL, c'est une nouvelle manière de réaliser des interfaces graphiques
Indépendamment de la technique invoquée, la manière n'est en elle même pas très nouvelle. Certains générateurs de rapports et dans une moindre mesure certains logiciels de RAD utilisent des approches comparables.(L'utilisateur "décrit" son interface dans un langage, et ca description est compilée puis rendue à l'écran).
Parce que Gecko est multi plateforme, que XUL est portable.
XUL est très moyennement portable de ce que j'en ai vu, et pour ainsi dire pas porté du tout. A ma connaissance hors de gecko point de salut et point de XUL (arretez-moi si je me trompe) donc XUL ne fait que profiter des plateformes sur lesquels tourne Gecko...
Parce que coté applis web, ça te permet d'être beaucoup plus productif et d'avoir une appli plus reactive et légère que tous ces trucs en ajax.
A deux conditions tout de même : a) que le navigateur connecté soit un gecko et b) que la machine qui fait tourner l'appli XUL ait assez de mémoire/ressources (dit sans intention de troll, mais je ne vois pas comment le formuler autrement).
Quoi que l'on puisse reprocher à Ajax ou aux technos "DHTML Plus" au niveau des temps de réponse, ça met rarement une machine à genoux (à moins de coder n'importe comment) et ca marche pas trop mal en applications intranet. Ceci étant je n'ai jamais vu d'applications professionelle de XUL (à part NVU peut-être si il y en a dedans) et ma réticence vis à vis de l'occupation des ressources vient peut-être d'erreurs grossières dans les applis XUL que j'ai vu tourner.
Parce qu'un XUL like est en voie de normalisation au W3C
A mon sens, ca irait plutôt contre vous çà. Le "Layer Like" sorti par le W3C au bon temps d'HTML 4 il a fait très mal aux inventeurs du layer. De plus même si c'est normalisé dans tous les sens, ca ne veut pas dire que ca sera utilisé. XForm est normalisé depuis près d'un an etpersonne ne semble décidé à se jeter dessus. De même le moteur Gecko peine clairement avec les CSS2/3 (et on ne va ni parler d'internet explorer ni parler de DOM parcequ'on va encore facher du monde).
Bref, on en revient toujours à la même question qu'est-ce que ca apporte en vrai ?
Bref -> capitalisation du savoir faire, possibilité de réutiliser toutes ces compétences ailleurs. Surtout que XUL est copié dans pas mal de lib (faut voir le nombre de lib en java qui permettent de faire du xul-like..).
Le problème étant que dans le cadre d'une appli Java, je vois tout l'intéret d'un XUL like. Pouvoir initaliser/gerer/modifier ses beans (ou ejb, ou MMO) à coup de tags modifiables dynamiquement par des scritps c'est très sympa, mais c'est fondamentalement extensible. Je prend les tags dont j'ai besoin, je rajoute avec du code les tags qui manquent et je fais un prog qui me convient. Pas besoin de plonger dans les profondeurs de Gecko si des impératifs de place m'obligent à couper els fonctionnalités qui ne me servent à rien. Celà vient peut être de ma culture de dev (ou peut-être parceque je suis encore trop "proche du système") mais un système de Tags prédéfini, difficilement extensible et lié de manière très forte à une techno spécifique çelà ne me tente que moyennement.
ref, tu m'a l'air d'avoir emis un avis sur XUL sans même te documenter. Gecko et XUL sont des technos d'avenir, c'est un fait. Tous les indicateurs le prouvent (que ce soit du coté de la standardisation, que du coté de l"'industrialisation").
Détrompe-toi, sans être un initié des arcannes de XUL je me suis penché sur la question assez sérieusement. Grosso-modo j'avais besoin d'un moteur de rendu assez rapidement et j'ai voulu savoir si en prenant une solution XUL+Gecko je pourrais un jour me débarasser de Gecko (pour le remplacer par un autre moteur de rendu). En ce qui concerne les technos d'avenir, j'en ai essuyé 3 de pleins fouet (HTML-Web, Java et XML et consors) A chaque fois il fallait tout casser pour refaire dans "la techno d'avenir", indépendamment de si c'était pertinant ou pas. Si il faut apprendre XUL parceque le client veux qu'on lui fasse ses livres de comptes en XUL, je le ferais. De même que je fais aujourd'hui des parseurs XML/XSLT en lieu et place de convertisseurs de formats de données en Java.
Comment tu vas vite en besogne. Généralise pas. Corrige : "Parce que pour l'instant elle n'a rien pour *me*plaire." Mais ce n'est pas vraiment étonnant, vu que tu semble plutôt interressé par tout ce qui est système.
Honnêtement les RAD m'interressent aussi beaucoup, mais j'ai l'impression (le préjugé ?) assez nette que le temps que je gagne à créer l'interface en XUL je le reperd dérrière à configurer Gecko et à compiler le tout avec XULrunner.
La complexité impliquée pour compiler uen application comme Mozilla, NVU ou même plus récamment SongBird me laisse pantois et un peu frileux vis à vis des technos utilisées.
La techno est répandue. Je ne sais combien de dizaine de millions de gecko installés sur les postes à travers le monde, ce n'est pas insignifiant tout de même.
Vous êtes bien assis ? Parceque si c'est insignifiant. Une techno n'est significative qu'une fois que l'on commence à s'en servir. Il y a sur terre des millions de machines sous Linux qui pourraient utiliser les ACL Posix, mais qui ne le font pas. Le reflexe de la planête entière est de claquer du sudo à toutes les sauces alors que cette commande idiote aurait du disparaitre. La plupart des distrib n'ont même pas de packages complètement à jour. Donc les ACL Posix sous Linux c'est insignifiant. De la même façon en 5 ans sous Mozilla puis Firefox je n'ai quasiment jamais utilisé d'autre XUL que celu fournit de base à l'installation. J'ai du aller une fois sur un site en XUL et j'ai peutêtre mon plug-in de download qui exploite XUL. Je ne sais pas si on peut considérer celà comme significatif, et je pense sincèrement que mon expérience sous Moz est assez facilement généralisable.
Et puis la santé financière de la boîte va bien. Inutile de diffamer, merci. (Tu crois qu'on embaucherait si on allait mal ??).
Je ne parle en aucun cas de la santé financière de l'entreprise,mais de son assise. Un groupe comme Total, même en plein déficit a une bien meilleure assise financière que DI en pleine période de bénéfices reccords. Soyons clair est-ce que vous avez une bonne trèsorerie ? est-ce que le fond de roulement est OK, est-ce que vous être assurés comme il faut en cas de procès/catastrophe/maladie/fuite d'infos ? En d'autres termes si demain pour une raison X ou Y ca commence à aller mal (très) combien de temps vous survivez ?
Que vous le vouliez ou non un cadre qui quiterait sa grosse boite confortable mais soporifique pour venir bosser avec vous serait assez probablement en prise de risque. Ceci étant l'aventure vaut peut-être le coup, mais ca reste une aventure.
Justement XUL, rentre dans cette section... M'enfin ça tu le découvrira quand tu te sera vraiment renseigné sur la techno.
Comme vous vous permettez une pique de conclusion : je fais de même.
Je voulais du Web 2.0 qui marche, celui avec l'ajax tout lent.
[^] # Re: J'adore
Posté par Jerome Herman . En réponse au journal L'informatique française va mal!. Évalué à 10.
Vous auriez dit Berkely, MIT, Columbia j'aurais été un peu d'accord. Encore que j'aurais gentillement dit que l'INRIA et Le Polytechniceum de Lausanne jouait dans une cours pas très loin. Mais honnêtement alors que Microsoft s'apprète (avec beaucoup de mal apparament) à sortir son douxième produit basé sur le même kernel, que SGI agonise et passe sous Linux et que SUN vend des architectures AMD64 peut-on vraiment encore citer les US comme le fleuron de la recherche appliquée ? Les US brevètent, çà oui, mais pour ce qui est d'inventer par contre ... Pour l'instant on se contente surtout d'améliorations (dans la mesure ou l'implémentation est pas trop buguée.)
parce que XUL, c'est une nouvelle manière de réaliser des interfaces graphiques
Indépendamment de la technique invoquée, la manière n'est en elle même pas très nouvelle. Certains générateurs de rapports et dans une moindre mesure certains logiciels de RAD utilisent des approches comparables.(L'utilisateur "décrit" son interface dans un langage, et ca description est compilée puis rendue à l'écran).
Parce que Gecko est multi plateforme, que XUL est portable.
XUL est très moyennement portable de ce que j'en ai vu, et pour ainsi dire pas porté du tout. A ma connaissance hors de gecko point de salut et point de XUL (arretez-moi si je me trompe) donc XUL ne fait que profiter des plateformes sur lesquels tourne Gecko...
Parce que coté applis web, ça te permet d'être beaucoup plus productif et d'avoir une appli plus reactive et légère que tous ces trucs en ajax.
A deux conditions tout de même : a) que le navigateur connecté soit un gecko et b) que la machine qui fait tourner l'appli XUL ait assez de mémoire/ressources (dit sans intention de troll, mais je ne vois pas comment le formuler autrement).
Quoi que l'on puisse reprocher à Ajax ou aux technos "DHTML Plus" au niveau des temps de réponse, ça met rarement une machine à genoux (à moins de coder n'importe comment) et ca marche pas trop mal en applications intranet. Ceci étant je n'ai jamais vu d'applications professionelle de XUL (à part NVU peut-être si il y en a dedans) et ma réticence vis à vis de l'occupation des ressources vient peut-être d'erreurs grossières dans les applis XUL que j'ai vu tourner.
Parce qu'un XUL like est en voie de normalisation au W3C
A mon sens, ca irait plutôt contre vous çà. Le "Layer Like" sorti par le W3C au bon temps d'HTML 4 il a fait très mal aux inventeurs du layer. De plus même si c'est normalisé dans tous les sens, ca ne veut pas dire que ca sera utilisé. XForm est normalisé depuis près d'un an etpersonne ne semble décidé à se jeter dessus. De même le moteur Gecko peine clairement avec les CSS2/3 (et on ne va ni parler d'internet explorer ni parler de DOM parcequ'on va encore facher du monde).
Bref, on en revient toujours à la même question qu'est-ce que ca apporte en vrai ?
Bref -> capitalisation du savoir faire, possibilité de réutiliser toutes ces compétences ailleurs. Surtout que XUL est copié dans pas mal de lib (faut voir le nombre de lib en java qui permettent de faire du xul-like..).
Le problème étant que dans le cadre d'une appli Java, je vois tout l'intéret d'un XUL like. Pouvoir initaliser/gerer/modifier ses beans (ou ejb, ou MMO) à coup de tags modifiables dynamiquement par des scritps c'est très sympa, mais c'est fondamentalement extensible. Je prend les tags dont j'ai besoin, je rajoute avec du code les tags qui manquent et je fais un prog qui me convient. Pas besoin de plonger dans les profondeurs de Gecko si des impératifs de place m'obligent à couper els fonctionnalités qui ne me servent à rien. Celà vient peut être de ma culture de dev (ou peut-être parceque je suis encore trop "proche du système") mais un système de Tags prédéfini, difficilement extensible et lié de manière très forte à une techno spécifique çelà ne me tente que moyennement.
ref, tu m'a l'air d'avoir emis un avis sur XUL sans même te documenter. Gecko et XUL sont des technos d'avenir, c'est un fait. Tous les indicateurs le prouvent (que ce soit du coté de la standardisation, que du coté de l"'industrialisation").
Détrompe-toi, sans être un initié des arcannes de XUL je me suis penché sur la question assez sérieusement. Grosso-modo j'avais besoin d'un moteur de rendu assez rapidement et j'ai voulu savoir si en prenant une solution XUL+Gecko je pourrais un jour me débarasser de Gecko (pour le remplacer par un autre moteur de rendu). En ce qui concerne les technos d'avenir, j'en ai essuyé 3 de pleins fouet (HTML-Web, Java et XML et consors) A chaque fois il fallait tout casser pour refaire dans "la techno d'avenir", indépendamment de si c'était pertinant ou pas. Si il faut apprendre XUL parceque le client veux qu'on lui fasse ses livres de comptes en XUL, je le ferais. De même que je fais aujourd'hui des parseurs XML/XSLT en lieu et place de convertisseurs de formats de données en Java.
Comment tu vas vite en besogne. Généralise pas. Corrige : "Parce que pour l'instant elle n'a rien pour *me*plaire." Mais ce n'est pas vraiment étonnant, vu que tu semble plutôt interressé par tout ce qui est système.
Honnêtement les RAD m'interressent aussi beaucoup, mais j'ai l'impression (le préjugé ?) assez nette que le temps que je gagne à créer l'interface en XUL je le reperd dérrière à configurer Gecko et à compiler le tout avec XULrunner.
La complexité impliquée pour compiler uen application comme Mozilla, NVU ou même plus récamment SongBird me laisse pantois et un peu frileux vis à vis des technos utilisées.
La techno est répandue. Je ne sais combien de dizaine de millions de gecko installés sur les postes à travers le monde, ce n'est pas insignifiant tout de même.
Vous êtes bien assis ? Parceque si c'est insignifiant. Une techno n'est significative qu'une fois que l'on commence à s'en servir. Il y a sur terre des millions de machines sous Linux qui pourraient utiliser les ACL Posix, mais qui ne le font pas. Le reflexe de la planête entière est de claquer du sudo à toutes les sauces alors que cette commande idiote aurait du disparaitre. La plupart des distrib n'ont même pas de packages complètement à jour. Donc les ACL Posix sous Linux c'est insignifiant. De la même façon en 5 ans sous Mozilla puis Firefox je n'ai quasiment jamais utilisé d'autre XUL que celu fournit de base à l'installation. J'ai du aller une fois sur un site en XUL et j'ai peutêtre mon plug-in de download qui exploite XUL. Je ne sais pas si on peut considérer celà comme significatif, et je pense sincèrement que mon expérience sous Moz est assez facilement généralisable.
Et puis la santé financière de la boîte va bien. Inutile de diffamer, merci. (Tu crois qu'on embaucherait si on allait mal ??).
Je ne parle en aucun cas de la santé financière de l'entreprise,mais de son assise. Un groupe comme Total, même en plein déficit a une bien meilleure assise financière que DI en pleine période de bénéfices reccords. Soyons clair est-ce que vous avez une bonne trèsorerie ? est-ce que le fond de roulement est OK, est-ce que vous être assurés comme il faut en cas de procès/catastrophe/maladie/fuite d'infos ? En d'autres termes si demain pour une raison X ou Y ca commence à aller mal (très) combien de temps vous survivez ?
Que vous le vouliez ou non un cadre qui quiterait sa grosse boite confortable mais soporifique pour venir bosser avec vous serait assez probablement en prise de risque. Ceci étant l'aventure vaut peut-être le coup, mais ca reste une aventure.
Justement XUL, rentre dans cette section... M'enfin ça tu le découvrira quand tu te sera vraiment renseigné sur la techno.
Comme vous vous permettez une pique de conclusion : je fais de même.
Je voulais du Web 2.0 qui marche, celui avec l'ajax tout lent.