Laurent J a écrit 2938 commentaires

dit-il avec une syntaxe totalement obsolète…

Petite précision. il manque un mot dans ton sujet.

Spoiler : PHP *est* un *mauvais* moteur de template.

• trop grande liberté, permettant de faire tout et n'importe quoi dans la "vue" (y compris du code métier qui devrait, dans un projet propre, se trouver dans des belles classes dédiées)
• pas de sécurité par défaut : il faut faire attention à échapper soit-même le contenu que l'on affiche pour éviter d'injecter du code XSS &co.
• moins lisible quand le template est complexe.

Et plein d'autres arguments que tu trouveras sur le web..

Si si, il y a bien le moteur JS de Gecko dans Servo. Sinon github, pour ne pas le citer, ne fonctionnerai pas du tout dans Servo.

Officiellement oui, Servo n'est qu'un truc expérimental. Et de toute façon, il n'est pas encore prêt.

Mais.

Vu l'état d'avancement, on peut dire qu'il a dépassé le stade de prototype. Le moteur en lui même fonctionne. Au niveau architecture, je pense que ça se stabilise. Il y a encore certainement du travail à faire au niveau optimisation. Mais ce qu'il reste surtout à faire (si j'ai bien suivi) c'est implémenter des API, des propriétés CSS, HTML et j'en passe pour avoir un moteur de rendu qui soit utilisable.

Il est donc probable que d'ici un an on ait une première version que l'on peut tester en réél (dans un navigateur à l'interface minimaliste).

Cependant un navigateur, ce n'est pas qu'un moteur de rendu : gestion des bookmarks, des mots de passe, des préférences, de l'impression, des addons, en plus d'outils de dev web, du mode private, du mode offline, et plein d'autres choses etc… Donc une fois Servo terminé, il restera du boulot.

Pour Mozilla donc, la question se pose déjà. Est ce que Firefox un jour switchera vers Servo ? pour l'instant très difficile à dire, et si j'en crois les mailing-list, Mozilla ne le sait pas lui-même. Une chose est sûre, ils veulent se débarrasser de XUL, XBL, XPCOM et autres trucs (qui ne seront pas implémentés dans Servo, c'est certain). Pour ça il faut se débarrasser du système d'extension XUL (c'est en cours), il faut migrer l'interface XUL vers du HTML ou du natif (et redevelopper plein de composants interne qui sont en XPCOM). La migration de l'interface est en discussion. Certains proposent plutôt de laisser continuer Firefox comme cela, tout en le faisant évoluer de manière à ce que la transition vers un "Firefox nouvelle génération" soit douce (en clair, il faut que les extensions soient prêtes, d'où les webextensions qui arrivent dans Firefox, qui proposeront une API qui s'abstrait totalement de l'API interne du navigateur, donc de Gecko). D'autres proposent de faire le ménage au fur et à mesure et redévelopper ce qu'il y a à redevelopper pour que ce soit compatible Gecko & Servo (cela veut donc dire migrer petit à petit des bouts d'interfaces de XUL vers HTML, de redévelopper des composants XPCOM en module javascript quand c'est pertinent etc..).

Une chose est sûre : cela va prendre beaucoup de temps, quelque soit la solution.

Maintenant il n'y a pas que Firefox Desktop. Il y a aussi Firefox pour Android, et Firefox OS. Ces deux produits n'utilisent pas XUL et autres trucs "deprecated" (l'interface pour FxAndroid utilise la techno d'android, et pour FxOS, tout est en HTML). Il est donc fort possible que ces deux logiciels remplaceront Gecko par Servo quand ce dernier sera suffisamment mature. Même si ça ne se fera pas en 5 minutes, il y a à priori moins de boulot à l'heure actuelle que pour Firefox Desktop (d'ailleurs on remarquera le port de Servo vers Gonk, le système linux de FirefoxOS : c'est une première étape franchie ;-) ).

Comme autre produit phare, reste Thunderbird. Là tout est en XUL, avec beaucoup de composants XPCOM en C++ (implémentation des protocoles de messageries…). Forcément, l'avenir de Thunderbird est lié à l'avenir de Gecko. Les devs de Thunderbird étudient donc la possibilité de refaire un Thunderbird tout en HTML pour l'interface, et même de redévelopper les différents protocoles en JS. (Qui c'est, verra-t-on Thunderbird sur FirefoxOS ? ;-)

En conclusion : Servo est encore expérimental (dans les faits et officiellement), mais je pense que ça deviendra à terme une vrai brique utilisable en "production". Même si Mozilla décide un jour d'abandonner Servo (ce dont je doute), vu le nombre grandissant de contributeurs externes, c'est un truc qui finira en prod de toute façon. Chez Samsung ou ailleurs.

Pareil, ce qui m’intéressait dans la hp48, c'est qu'on arrivait assez vite aux limites de la machine avec le RPL. Avec l'assembleur, on pouvait alors repousser les limites, et ça nous forçait à nous triturer les méninges pour imaginer de meilleurs algorithmes, pour optimiser la mémoire, pour optimiser les temps de calculs etc…

J'ai beaucoup appris sur la gestion de la mémoire, sur l'optimisation du cpu, sur ce qui étais préférable de faire pour avoir de bonne perf pour faire telle ou telle chose. Je me rendais alors mieux compte des "betises" que je faisais avec des langages plus haut niveau comme le C sur d'autres machines.

/me qui a toujours sa HP48 sur son bureau

ça fait tout de même plusieurs années que XUL est déprécié

pas du tout. Tu confonds XUL et XULRunner…

(tout dépend après ce que tu appelles "plusieurs années")

Toujours pour des questions de perfs.

Et j'ai oublié : aussi pour des questions de zooming. C'est rapide et simple. Sur les petits écrans, avoir un bon zooming est critique, et un système à tuile est très bien pour ça.

Oui, il ne faut pas tabler là-dessus, mais, connaissant particulièrement bien le projet, j'ai conscience de la quantité phénoménale de travail qu'il faut pour se débarrasser de XUL dans Firefox. En premier lieu : réécrire toute l'interface utilisateur (en html ?). Et si en html, créer de toutes pièces ce qu'il manque à HTML pour combler le gap avec XUL (et il y en a des choses à créer !!).

Alors à moins qu'un miracle arrive et que Mozilla puisse mettre 200 développeurs à temps complet rien que sur cette problématique (impossible à priori), pour arriver à proposer un firefox sans XUL dans un an minimum, j'estime que ça n'arrivera pas avant 3-4 ans. Sans compter le possible recul de la date d'interdiction d'installations des addons XUL.

Pour le reste de tes arguments : je n'ai pas dit le contraire. Je n'ai pas dit que les développeurs d'applis XUL ne devaient rien faire. Je pense même que les principaux intéressés (dont certains de mes clients), sont parfaitement conscient du problème (il y a longtemps que j'ai expliqué ceci à mes clients) et même que certains sont en train de préparer l'avenir .

J'ai simplement voulu dire qu'il n'y a pas d'affolement à avoir, et qu'il est encore grand temps de penser le futur de ces applis XUL.

Le rendu par tuile est en fait plus courant que tu ne le crois.

Par exemple Firefox pour Android utilisait à ces débuts un système de tuilage pour afficher les pages web, à cause du manque de perf (pendant le scrolling entre autre). La page web était donc rendue dans une fenêtre non affichée (genre dans un element iframe), et un element html canvas était utilisé pour le rendu à l'utilisateur, en utilisant un système de tuiles générée à partir du rendu de la fenêtre cachée. Et donc tout ça fait en JS :-). (On pouvait parfois se rendre compte de ce système de tuiles, quand Gecko mettait trop de temps à afficher les tuiles : on voyait alors brièvement un damier à la place des tuiles retardataires)

Maintenant, Gecko a un système de rendu par tuile en natif. Et malgré que le moteur de rendu de Gecko soit plus performant qu'à l'époque, le tuilage est toujours utilisé dans Firefox pour Android, et dans FirefoxOS pour afficher les pages web. (dans le about:config, preférence layers.enable-tiles). Toujours pour des questions de perfs.

Il y a eu en effet une forte mise en avant de XUL quand Mozilla a sorti XULRunner. Mais cette mise en avant a plutôt été faite par la communauté. À l'époque, c’était un truc plutôt expérimental chez Mozilla, mais il y a eu un engouement fort de la part de beaucoup de développeurs pour ce XULRunner (dont moi-même, et je suis probablement responsable de cet engouement en France avec xulfr.org) : on pouvait créer très facilement des applis en XUL et les livrer indépendamment de Firefox (donc pas comme une extension). Et il y a eu de ce fait beaucoup d'application utilisant XULRunner (ou basé sur un XULRunner modifié/recompilé).

Même si chez Mozilla il y avait au début une roadmap pour livrer des versions stables de XulRunner (laissant présager un suivi sur le long terme), je pense, avec le recul, que Mozilla a été surpris du succès, et qu'ils se sont rendu compte que ce succès ne convenait pas pour l'évolution de Gecko (obligé d'avoir des API gelées pour pas casser les autres softs par exemple). C'est pourquoi ils n'ont jamais fait de XulRunner un produit (comme pouvait l'être à l'époque un concurrent comme Adobe Air), et ils ont arrêté de dépenser de l'énergie sur XulRunner. Tout juste a-t-il été maintenu, avec des releases pour chaque nouvelle version de Gecko (grossièrement, XULRunner n'est qu'un main() autour de Gecko), mais ça suffisait pour les développeurs d'applis existantes.

Je crois que tu a raté quelque chose d'important : XUL c'est fini.

Je n'ai rien raté du tout. C'est moi-même qui a écrit le billet que tu pointes ;-)

XUL c'est fini, certes. Il serait, d'un point de vue industriel, illogique de vouloir faire une appli ou extension en XUL de nos jours. Mais la prise en charge de XUL dans Gecko et la prise en charge des extensions XUL sont deux choses différentes. Alors que la deuxième va disparaitre dans quelques mois (à priori), la première va mettre à mon avis quelques années à disparaitre de Firefox (le chantier est titanesque, pour remplacer tout ce qui est en XUL) et encore plus de Gecko à cause de Thunderbird et autre (un flag de compilation fera je pense la différence, comme il a existé par le passé). Donc on va pouvoir faire fonctionner les applis xul existantes pendant quelques temps encore. Ça laisse le temps de migrer vers d'autres technologies alternatives.

Oui cette extension ne fonctionnera plus, car je vois mal comment l'API de webextension va apporter les nombreuses possibilités que nécessite SQliteManager (entre autre, accéder à toute l'API pour attaquer une base SQLite….).

Il n'y a qu'une solution pour cette extension : être lancée comme toute application XUL. Et ça tombe bien, il y a un application.ini dans les sources. Ce qui veut dire que Sqlite Manager continuera à fonctionner avec Firefox, non pas en l'installant comme extension, mais en le lançant directement avec firefox --app sqlite-manager/application.ini. Il est possible aussi de le lancer avec XulRunner, mais c'est un programme qui est désormais mort : il n'y aura pas de XulRunner 41 et supérieur.

À noter aussi que Sqlite Manager est dispo comme extension pour l'éditeur Komodo et Thunderbird.

Alors je dis pas, une assoce/fondation peut aussi mal tourner, elle peut aussi fermer, etc. Mais les chances sont moindres car c'est normalement fait de telle sorte que les raisons que cela se produisent sont plus faibles.

Oh que non. De mon expérience, quand une association fonctionne bien, c'est souvent qu'il y a un noyau dur de personnes qui soutiennent le truc à fond, et souvent donc, tout repose sur ces personnes, même si il y a de nombreux membres. Et souvent le noyau dur ne se résume qu'à 2-3 personnes, qui ont le don d'être motivant, entrainant etc.. Qu'une de ces personnes du noyau dur parte (pour n'importe quel raison), et c'est la vie de l'association qui peut changer du tout au tout. Voir "mourir". Remplacer la personne "charismatique" qui part, c'est beaucoup plus difficile pour une association que pour une boite : la carotte est beaucoup moins grosse (pas de contrepartie financière souvent, donc il faut que le remplaçant soit vraiment motivé et ait suffisamment de temps pour s'en occuper).

j'ai un bon exemple en tête : l'apinc. Je ne sais pas où ça en ait aujourd'hui, mais quand j'étais membre il y a quelques années, l'association a connu des bas (moins de gens pour aider par exemple, le noyau dur moins motivé, moins de temps libre pour faire avancer le truc), et ces périodes n'ont pas été roses : des serveurs en panne, des services à la ramasse, par manque de temps, de budget etc (sans compter les délais pour aller au data-center pour aller changer un disque ou autre).

Bref, au final, une association c'est de mon point de vue, tout aussi fragile qu'une entreprise, voir même plus car au moins dans une boite qui fait de l’hébergement, tu as toujours des employés à plein temps pour gérer les machines, ce qui n'est pas le cas pour une association.

PS. d'ailleurs je ne raconte pas de conneries : L'apinc arrete l'hebergement web. Pas assez de moyens, pas assez de bras, pour offrir un service qui soit l'équivalent des offres commerciales en terme de qualité de service.

Pardonnez-moi cette question, mais quelle est la meilleur façon de rendre persistent tout ça, c'est à dire que ça se reconfigure automatiquement à chaque démarrage ? (sur ubuntu par ex)

Ça fait des années que Firefox inclus des services de google (anti-pisching, moteur de recherche) etc. Ça change quoi d'intégrer un service de plus ? Qui plus est désactivable ?

oui et non. Il y a 3 types d'extensions :

• les extensions XUL classique : accés aux api internes, au DOM XUL de l'interface, et on peut utiliser le système d'overlay pour ajouter des éléments XUL (on écrit donc du XML XUL pour injecter des boutons ou autre dans l'interface).
• les extensions XUL sans redemarrage : idem que extensions XUL classique, sauf qu'on ne peut pas utiliser le système d'overlay (de manière automatique). Mais on peut encore accéder au DOM XUL directement.
• les extensions faites avec le SDK : pure JS, exécutées dans une sandbox, avec accès à une API cachant les API internes, et permettant de modifier l'interface sans toucher directement au DOM. Exemple : une API pour "ajouter un bouton dans la toolbar". Avantage : que l'interface soit faite en XUL, HTML ou Java (pour Android), l'extension peut fonctionner. Inconvénient : beaucoup moins de liberté dans la modification de l'interface. Mais pour 90% des extensions, ce n'est pas embêtant.

Est-ce qu'il y a des cas qu'on ne peut que traiter avec un générateur?

je n'en ai pas en tête.

Mais, dans ton cas où tu implémentes ta fonction forEach, syntaxiquement, ce n'est pas reconnu par JS comme étant un générateur, quand bien même ton forEach serait "lazy". Ton forEach n'est pas une manière standard de faire un Iterateur.

D'ailleurs avec ton implementation de forEach pour les nombres premiers, je ne suis pas vraiment fan. Par exemple, je veux récupérer les 10 premiers nombres premiers. Je suis obligé de faire

var primes = createPrimes();
var i = 10;
var sum = 0;
try {
   primes.forEach(function (np){
       // do something with np
       sum += np;
       // finished ?
       if (--i == 0) {
           throw new Error("stop")
       }
   });
}
catch(e){
   // ne pas oublier le catch, sinon...
}

Alors que si createPrimes() retournait un iterateur ou génerateur

var primes = createPrimes();
var i=0;
var sum = 0;
var np = primes.next();
while ( --i>0 && !np.done){
    // do something with np
    sum += np.value;
    // next...
    np = primes.next();
}

Pour moi la solution avec iterateur/générateur me semble plus compacte et lisible…

Le problème de l'implémentation de ton objet séquence, c'est que ta séquence ne fonctionnera pas avec Map, WeakMap, Set etc.

Implémenter une méthode forEach sur un objet représentant une séquence, ne le fait pas reconnaitre pour autant comme une séquence JS, et donc ne le rend pas utilisable avec les fonctions/structures syntaxiques manipulant des itérables. Concrètement, l'objet "itérable" peut se faire ainsi passer pour un Array. Par contre un objet simple implémentant foreach, non.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Iteration_protocols

En d'autres termes, Iterable et Iterator spécifie une manière standard de faire des objets iterables. Tu peux voir ça comme une interface. Un peu comme en PHP (et d'autres langages…), où un objet qui implémente l'interface Iterator, peut être passé à toutes les fonctions qui manipulent des array.

En plus l'intérêt de la deuxième forme est qu'on peut implémenter facilement le forEach pour éviter d'avoir un état mutable dans sequence ce qui permet de partager la valeur entre plusieurs threads sans se casser la tête. La forme avec yield n'a pas cet avantage.

yield n'est pas obligatoire pour faire un Iterable en JS. Ton objet peut être imutable. Tout ceci dépend de ton implementation.

Je ne vois aussi pas trop l'intérêt des itérables, puisque JavaScript est un langage fonctionnel et que la bibliothèque standard propose des tableaux qui savent faire reduce ou forEach la fonctionnalité des itérables me semble un peu superflue, et demande de comprendre des nouveaux concepts (comment marche le 'yield') alors qu'utiliser reduce ou forEach rentre dans le cadre normal du langage.

L’intérêt c'est de rendre un objet qui puisse être parcouru comme un tableau, et donc qu'on puisse en donner une instance à du code qui sait itèrer sur un tableau classique. Cela encapsule donc la manière dont sont structurées les données de l'objet, et le code utilisateur n'a ainsi pas besoin de connaître cette structure pour itérer sur les "éléments" de l'objet.

Quant à connaitre l'utilisation de yield (et par conséquent les générateurs), il est important d'en comprendre le concept : cela permet de générer une liste d’élément à la demande : si on itère sur une liste d'éléments, on génère juste les éléments demandées, et pas toute une liste dont on n'est pas sûr qu'elle soit entièrement utilisée. Cela peut faire donc économiser énormément de mémoire et de traitements.

D'autres préféreront être hyper configurables, ce qui nécessite de proposer une foultitude d'options, et a pour conséquence d'être plus difficiles à prendre en main (KDE).

Sérieusement, tu as regardé les dernières montures de KDE avec plasma ? Franchement le temps où les panneaux de config de KDE étaient des tableaux de bords de Boeing 747, c'est fini.

Faut arrêter avec les "KDE plus difficile à prendre en main". C'est juste totalement faux aujourd'hui. Bien au contraire.

Je ne place pas FireFoxOs dans la même catégorie car il se place clairement sur le bas de gamme et tente de s'imposer dans les non occidentalisé

La stratégie de Mozilla à ce sujet a changé il y a peu. Ils ont annoncés qu'ils vont se tourner vers des téléphones plus performant, et donc se tourner vers des marchés "plus riches".

tous vos correspondants pourront lire vos messages sans effort

bah non justement, ça devient au contraire bien plus casse gueule.

Transformer un texte en image, c'est une très mauvaise idée pour l'accessibilité (et l'accessibilité n'est pas réservé qu'aux aveugles).

Ton texte en image devient vite illisible si on veut zoomer dessus (parce qu'il faudra alors jouer avec les barres de défilement), ou si on veut le faire lire par lecteur d'écran (obligé de faire de l'OCR dessus…).

Et il y a les problèmes de l'impression (image trop étroite ou trop large -> retaillage ou découpage sur plusieurs pages), de la citation du contenu en dehors du client mail (obligé de tout recopier, c'est d'un pratique…) etc..

Tiens d'ailleurs, pour répondre "en ligne" (donc en découpant le texte) : impossible.

Et puis ça ne doit pas être drôle de recevoir un nième mail d'une discussion, avec tout l'historique : l'image va être "un peu" lourde… Super l'image de 800 x 15000 \o/.

Bref, cela a bien plus d’inconvénients que tu ne le crois, tout en ne résolvant pas le problème de la confidentialité (OCR..)

Par contre qu'est-ce qu'il y a à reprocher aux autres que tu cites ?

Ils font des "bundles". Ils empaquettent donc les softs dans leur propre installateur qui va installer le logiciel et des merdes d'adware et cie.

Ni toi.

Perso moi si. (et mon passe-temps n'est pas la mécanique).

Et personne ne prétend que ce soit nécessaire pour utiliser une automobile.

Un peu quand même, si on ne veut pas être en infraction (la nuit) : http://vosdroits.service-public.fr/particuliers/F19459.xhtml

il n'est pas obligatoire d'avoir une boîte d'ampoules dans le véhicule, mais il faut pouvoir changer immédiatement une ampoule défectueuse sous peine d'être sanctionné en cas de contrôle.

Les deux parties de la phrase sont en contradiction selon moi, car si il faut pouvoir changer immédiatement une ampoule, il faut pouvoir en avoir des neuves sous la main. Et il faut donc aussi savoir changer l'ampoule.

C'est con ces petites choses mine de rien. Mais ça peut tuer…

C'est vraiment n'importe quoi ce gouvernement.

Je rappelle qu'une majorité de députés, de gauche comme de droite ont voté pour cette loi. (et ça va être pareil au sénat).

s/ce gouvernement/cette classe politique.

Avant de mettre du Rust dans Firefox OS, il devraient débugguer la pile réseau, mon geeksphone révolution m'affiche parfois 4 barres et la 3G alors qu'il n'a pas de réseau,

C'est probablement à Geeksphone qu'il faut aller te plaindre. Ils ne maintiennent pas beaucoup leurs OS, et leurs drivers sont pas tip top. Plus je met à jour mes 2 geeksphone, plus ça plante (ce qui n'est pas le cas avec mon flame par exemple).

Et puis c'est peut être aussi juste un bug graphique. Par exemple, sur mon flame (en FxOS 2.1), la barre du haut (où est affichée l'état du réseau) n'est pas toujours à jour. Il semble en effet qu'il y ait 2 barres: une pour le desktop, et une autre pour toutes les applications. Celle du desktop est toujours ok, alors que celle affichée quand tu es dans une appli ne l'est pas toujours.