Laurent J a écrit 2945 commentaires

PhantomJS embarque webdriver, qui implémente le protocole de Selenium. Il est donc possible d’exécuter les tests selenium avec phantomjs. Il sera possible de le faire avec SlimerJS dans les prochaines versions.

notamment parce qu'il leak en tout sens.

PHP ne leak plus depuis bien longtemps.

Dans de vieilles versions (4.x, et probablement 5.0, 5.1), PHP avait des problèmes de fuites mémoires. Mais ça a été corrigé depuis longtemps à priori.

Maintenant, si un script PHP leak, cela peut aussi être de la faute du script en lui même qui créé des objets ayant des dépendances circulaires par exemple, et qui ne sont pas déréférencé correctement par le développeur.

Il y a même depuis la version 5.3 des fonctions pour forcer le garbage collector.

Quant à la possible mort de PHP, ça me fait doucement rigoler…

Est-ce qu'il y aurait une version de Javascript qui intègre l'encapsulation de manière native par exemple ?

Oui, les versions récentes des moteurs JS qui implémentent Ecmascript 5, grâce à certaines méthodes de Object, avec lesquels tu peux indiquer si une propriété est "visible", en lecture seules, "enumerable" etc…

Et sinon y a moyen de cacher la saleté de manière plus classique en jouant avec les scopes (exemple ).

Si on comprend et maitrise la "philosophie" objet de JS, y a moyen de faire pas mal de chose.

tu vas me répondre point par point et ça va durer toute l'après-midi ?

Ah ba je peux :-) Mais bon j'ai pas tout mon temps non plus. Bon là je le fais, parce que le gars il connait juste le javascript "web" de papa, et pas le "vrai" javascript moderne (comme bon nombre de dev d'ailleurs).

No Built-In Array Iterator

Faux. forEach, map, every, some etc... Et ça fait en plus partie de Ecmascript 5 (es5), implémenté partout à priori.

No Libraries

plus ou moins Faux. CommonJS, RequireJS et autre systèmes de modules, ça existent ;-) … Et Ecmascript 6 apporte un système de module natif si je ne me trompe pas.

No good way of controlling for/in access to properties

Faux. l'objet Object contient un certain nombre de méthodes pour définir des propriétés énumérables, en lecture seule ou pas (defineProperties) etc.. Là aussi, de l'es5.

typeOf null == "object"

pas testé.

Variables are global unless declared local.

Oui. Sauf si on utilise le mot clé let (Ecmascript 6) plutôt que var. Implémenté depuis des années dans SpiderMonkey (utilisable pour les extensions)

Octal integer literals

oui c'est pas cool en effet

Tu en as d'autres ? :-)

PS: pas mal de truc Es6 sont implémentés depuis pas mal de temps dans SpiderMonkey.

Bref, la bible, c'est ici [https://developer.mozilla.org/en-US/docs/JavaScript/Reference]

pour peu qu'on manque un peu de rigueur

C'est aussi très facile de faire des trucs crad en C++ ou en python…

J'ai peur de voir sur les desktops les mêmes horreurs que celles que l'on voit sur les sites www.

Ce n'est pas le même contexte, pas le même environnement, pas les mêmes possibilités. Bref, pas les même API… Tu as déjà codé en JS dans des sandbox, en dehors du web, par exemple avec NodeJS, PhantomJS (ou SlimerJS :-)) etc.. ?

quand on connait tous les problèmes dont souffre le langage

Quels problèmes exactement ? Tu parles du JS des années 90 ?

Le langage possède tout un tas de fonctionnalités modernes (closure, generator …).

là, on ne parle justement pas du web, mais d'applications natives.

Oui, et ? Ça fait 10 ans que je fais des applications desktop en JS (XulRunner), avec du code manipulant des composants binaires (XPCOM, jsctypes …), je ne vois pas vraiment de souci… Ça apporte énormément de souplesse.

Sympa qu'il y ait un nouveau moteur JS pour le standard EcmasScript.

Bonne chance toutefois pour qu'ils rattrapent les perfs de V8 ou de SpiderMonkey, c'est loin d'être simple.
(les deux ont maintenant des perfs quasi équivalentes, depuis quelques jours avec Baseline dans SpiderMonkey ).

Baseline arrive un peu tard pour Qt. Dommage parce que SpiderMonkey a l'avantage sur V8 d'avoir une partie d'Ecmascript 6 implémenté :-)

mais l'aspect objet de JAvascript est assez rudimentaire, sans compter le côté moins rigoureux de celui-ci par rapport à un langage comme Java ou C++

L'aspect "rudimentaire" de Javascript n'est pas un problème. Dans les navigateurs, les objets que tu manipules dans une page web (les éléments DOM etc), sont des objets mappés sur des objets C++.

Je ne vois pas en quoi utiliser JS est gênant. Surtout que le but ici, si j'ai bien compris, c'est de proposer un environnement de développement pour l'UI, plus simple que C++. Donc il faut un langage plus simple, moins complexe que C++. Et pour moi JS est idéal. Tu fais de l'objet sans t'embêter avec la gestion de pointeurs, de template ou de je ne sais quoi d'autres.

Si JS ne te convient pas, tu as la possibilité de rester en C++..

Pour ton histoire de bug sur le search engine, bonne nouvelle, c'est résolu : https://bugzilla.mozilla.org/show_bug.cgi?id=738818

(et non, ce n'est pas parce que tu as gueulé sur linuxfr que ça s'est corrigé)

J'en avais déjà parlé sur un autre journal. Bon, alors, techniquement, ce n'est pas abandonné, c'est implémenté. C'est à dire que Gecko, a la faculté d'ouvrir une page web dans un process séparé.

Ainsi en XUL, il y a l'attribute remote sur la balise browser (celle qui affiche une page web) qui permet d'indiquer si la page doit être traité dans un processus séparé ou non. Il y a la même chose sur la balise iframe HTML (mais utilisable seulement pour les applis certifiés pour Firefox OS).

Bref, dans Gecko, un process par onglet, ça fonctionne, et c'est largement utilisé dans Firefox OS (et Firefox Mobile je crois, je n'ai pas vérifié).

Ce n'est pas utilisé dans Firefox Desktop car, à mon avis :

• sur un desktop, on a plutôt tendance à ouvrir plein d'onglets, il en résulte une occupation mémoire plus importante (cf Chrome). Sur mobile, il y a peu d'onglets ouverts en général, donc la différence d'occupation entre avec ou sans process séparé est faible, par contre ça apporte d'autres avantages d'avoir des process séparés (meilleur traitement en cas de crash, vélocité probablement…), c'est pourquoi ils sont utilisés sur le mobile. Et puis dans Firefox OS, il ne faudrait pas qu'une appli fasse planter tout le téléphone, ce serait balo :-)
• Dans Firefox, on ne peut pour l'instant pas activer ce fameux attribut remote sur les balises browser de chaque onglet, car il y a quelques soucis à régler avant. En effet, cela change la façon d'accéder au contenu de la page web depuis une extension et depuis surtout le code de l'interface de Firefox (je rappel que l'interface de Firefox est entièrement en XUL et javascript). Bref, il faut faire de nombreux changements dans le code de l'interface pour manipuler le contenu d'un onglet, et mettre à jour de nombreuses extensions.

Et vu que nombre d'extensions sont maintenant déclarées "compatible" par défaut, et que nombre d'extensions ne sont pas maintenus ou pas compatible pour dialoguer avec un contenu dans un process séparés, et bien, si le out of main process est activé dans Firefox, à la prochaine version ça va péter de partout, ça va faire plein d'utilisateurs mécontents.

Bref, cela nécessiterait beaucoup de ressources à Mozilla pour "éduquer" les développeurs d'extensions à la nouvelle API, beaucoup de ressources pour adapter les milliers de lignes de code de l'interface de Firefox.

À priori tout de même, en regardant les sources de l'interface, j'ai l'impression que petit à petit ils adaptent le code, mais ça va prendre encore du temps. Il y a plus important à faire pour le moment dans Firefox et Gecko.

Rust n'est pas un langage web.

Je suis extrêmement content de cette décision et des choix effectués !

La diversification dans les moteurs de rendu augmente après une baisse inquiétante. Il va moins y avoir de "faux" standards.

Le fait de cacher les nouveautés non stable est aussi une très bonne chose, et je pense la meilleure solution pour le développeur web : il ne sera pas tenté, comme c'est le cas actuellement, d'utiliser des trucs pas fini, pas standardisé, non dispo dans les autres navigateurs. Bref, il fera du code plus propre et meilleur pour ses utilisateurs.

je viens de retrouver la pref effectivement.

C’est Google quoi que tu fasses

chez moi, j'ai sélectionné duckduckgo parmi les moteurs de recherche, et ça recherche chez duckduckgo dans la barre d'URL (et pas de recherche)

C'est bien de ça que je parle.

peut-être qu'on ne parle pas de la même chose, mais là, tout de suite, maintenant, sans rien changer dans la conf, je change juste le moteur de recherche dans la liste à droite, et je tape n'importe quoi dans la barre d'URL, il va lancer une recherche via le moteur de recherche que j'ai sélectionné (duckduckgo par ex).

Et j'ai beau regardé les logs des requêtes HTTP, pas de google à l'horizon.

Tu veux un fichier texte pour les options de Firefox ? Très bien. Édite le fichier prefs.js qui est situé dans ton profil.

C'est pas parce qu'il y a une interface pour modifier facilement de prefs.js que ça en fait un logiciel pourri.

Tu as réussi à l'enlever de la liste des moteurs de recherche, mais, zut, quand tu veux utiliser la barre d'URL pour ta recherche (plus simple: F6 et voila, et puis elle est plus grande cette barre après tout) voila que ce fichu moteur que tu n'aimes pas rapplique au quart de tour.

Je ne sais pas où tu as vu ça. Ce que tu tapes dans l'URL utilise le moteur de recherche que tu as sélectionné, pas google.

si mozilla a planqué cette option, pourtant pas sensible, dans la page des paramètres internes, c'est parce qu'ils dépendent de google

Ou c'est peut-être aussi… qu'elle n'existe pas tout simplement :-p

même avec les bidouilles à la asm.js, on n'atteindra jamais la vitesse du code natif.

certes, mais on s'en approche. Aujourd'hui, c'est "seulement" 2 fois plus lent, mais il y a encore de quoi faire des optimisations dans l'implem de asm.js.

le navigateur bouffe une quantité non négligeable de RAM.

Oui, mais c'est surtout à cause des sites web. J'ai vu une présentation de conf dernièrement, qui montrait que statistiquement, le poid moyen d'une page a "grossie" de 44% en un an ! Beaucoup de dev web sont des gorets, qui utilisent des libs à tout va sans réfléchir (et avec tout ces bloatwares de framework js qui pullulent, c'est pas prêt de s'arreter…). Des pages web à 1Mo pour afficher 2 textes, merde quoi.

ça va encore plus inciter les développeurs à rendre les jeux injouables hors ligne.

En quoi ? Si leur jeux sont lourds, ils ont tout intérêts à utiliser App-cache et cie, sinon bonjour leur bande passante. Et ils peuvent packager sous forme de web-app.

le web, c'est aussi une excellente plateforme de tracking et de publicité.

malheureusement oui… mais il y a des extensions pour éviter toutes ces merdes.

donner un accès direct au matériel à une page web est un trou de sécurité énorme. Rien qu'aujourd'hui j'évite les démos webgl, car elle provoque souvent des plantages et autres écrans bleus.

le trou de sécurité n'est pas si énorme que ça. il y a quand même pas mal de mécanismes pour éviter l’apocalypse. Maintenant, pour les crash, faudrait voir exactement d'où ça vient (driver graphique moisi ? ou carte incompatible ?). Les implémentations sont jeunes. Et puis perso, j'ai pas d'écrans bleus sous linux ;-)

tu proposes quoi de mieux, à part un fichier texte que la plupart ouvrira avec word ?

mais en terme de communication, néant, ils n'en parlent jamais dans les communications générales, comme si ce projet leur faisait honte.

ce n'est pas une histoire de honte. C'est juste pas une priorité pour eux. point barre. C'est la même chose pour SeaMonkey etc..

Et puis figure toi que le département marketing de Mozilla, n'a pas non plus les moyens de communiquer sur tout. Mozilla n'est pas Google.

Actuellement, leur discours donne vraiment l'impression qu'ils n'en ont rien à faire de l'Internet, et qu'ils ne se soucient que du Web.

Bah oui puisque leur domaine c'est le web. En reprenant mon analogie, un plombier ne va pas communiquer sur le papier peint. Son truc, c'est la plomberie. Il communique donc sur la plomberie.

Maintenant, encore une fois, tu présupposes des choses ("ils n'ont rien à faire de l'Internet") alors qu'on voit clairement que tu ne t'informes pas du tout sur les actions de Mozilla.

Désolé, j'aurais du mettre le lien vers les vidéos, qui est pourtant accessible depuis la page wikipedia, sachant que le documentaire a été "libéré" sous une licence CC.

Bref, téléchargez ici http://clickmovement.org/content/code-rush-download . Il y a des liens cassés, mais ça doit bien se trouver sur l'un des dépôts indiqués.

Gniiii ?? Alors maintenant c'est la faute à Mozilla si il y a des fournisseurs qui violent la neutralité du net ???

Te rends-tu compte de la débilité de ton raisonnement ?

Mozilla propagent dans beaucoup de communications la confusion entre Web et Internet

Non, ils parlent du web tout court.. C'est toi qui fait le mélange et extrapole…

À une époque ils développaient aussi un logiciel de messagerie. Je crois que c'est encore le cas, mais la mode c'est le Web donc il ne faut pas en parler, c'est ça ?

Tu sais, Ensuite, Thunderbird est certes encore un projet vivant, soutenu par Mozilla, mais est développé par la communauté.

Maintenant, je ne suis pas porte-parole de Mozilla, je ne suis pas communiquant, et donc tu me pardonneras les oublis que j'ai pu faire dans cette news, n'est-ce pas ? Parce que si il fallait que je liste tous les projets de Mozilla (développés ou supportés), il m'aurait fallu écrire 3 pages, et je n'ai pas eu le temps.

J'aurais préféré un Internet qui reste ouvert, mais j'imagine qu'on ne peut pas attendre de Mozilla qu'ils voient autre chose que les ports TCP 80 et 443…

Mozilla, ils s’intéressent au web. Ils concentrent leurs efforts sur le web. À moins que tu ais quelques centaines de millions de dollars à leur passer, non, ils ne vont pas et ne peuvent tout simplement pas résoudre tous les soucis qu'il y a sur Internet, ils ne peuvent pas améliorer tous les protocoles de la terre. C'est comme si tu demandais à un plombier de faire de refaire la tapisserie d'une salle de bain. Chacun son job…

Note cependant qu'ils se sont impliqués sur les problèmes les plus grave (SOPA, PIPA etc…). Donc oui, ils militent pour un internet ouvert.

Ouvre chez gandi une boite mail au lieu d'un alias. Un coup de imapsync pour copier tes mails de ta boite SFR vers ta boite Gandi. Et voilà :-)

Personnellement, je n'ouvre jamais de boite chez mon FAI, celui-ci pouvant changer.

ou le navigateur entier dans le cas de Firefox à moins que ça n'ai été réglé depuis

ça fait en fait un bon moment que cela a été réglé… dans Gecko. Mais pas appliqué à Firefox Desktop. Cette fonctionnalité était le projet Electrolysis, pour ceux qui s'en souviennent.

Dans une application XUL (comme Firefox), dans Gecko, on a à disposition une balise pour afficher une page web.

 <browser src="http://site.com">

c'est en gros une iframe plus évoluée au niveau propriété/methodes. Depuis Firefox 4/Gecko 2 , il suffit de faire

 <browser remote="true" src="...">

pour avoir la page web qui s’exécute dans un processus séparé et il y a aussi

 <iframe mozbrowser remote> 

pour les webapp.

Donc dans Gecko, on a la possibilité depuis longtemps d'afficher une page dans un process séparé, que ce soit en XUL ou en C++. Et c'est largement utilisé dans Firefox Mobile (sur Android) et dans Firefox OS.

Pourquoi ce n'est pas appliqué à Firefox Desktop :

• Sur le desktop, ça ne semble pas apporter énormément : augmentation de la mémoire utilisée etc.. Surtout avec les travaux de "parallélisation" dans le moteur de layout par exemple qui ont eu lieu et qui ont permis d'améliorer les choses indirectement (ex: OMTC même si ce truc n'est pas encore actif je crois dans la version desktop).
• lancer une page web dans un process séparé, implique une nouvelle manière pour les extensions XUL pour accéder au contenu de la page web (passages de messages plutôt que de manipuler directement le contenu). Même si des extensions utilisent déjà la nouvelle API, le passage définitif au multiprocess pour les pages web va casser bon nombre d'extensions.
• Et cela ne cassera pas seulement les extensions, mais aussi Firefox : il faut réécrire énormément de choses dans l'interface de Firefox. C'est un long travail qu'ils ont à peine commencer. Et comme ils ont d'autres priorités en ce moment comme Firefox OS etc…

Je t'invite à te renseigner sur la façon dont sont implémentés les moteurs JS d'aujourd'hui. En gros, JIT, compilation à la volée et j'en passe. Une grande partie du script JS devient donc du pure code assembleur optimisé aux petits oignons. Au résultat, tu as un truc extrêmement performant. Oui. Clairement.

Maintenant, il y en a qui confondent le language Javascript et toutes les API que proposent un navigateur, en particulier le DOM. Et un programme en JS qui manipulent du DOM à tire-larigot, oui, en définitive, ça sera plus lent qu'un programme C++ qui manipulent un DOM à tire-larigot, tout simplement parce qu'en C++ il n'y a pas cette couche de "binding" entre le mode JS et le monde C++ (langage dans lequel est implémenté le DOM). Mais voilà, le DOM ne fait pas parti de JS.

Donc oui, le Javascript, le language, est extrêmement performant. La frontière entre du C et les implémentations de langages comme JS devient de moins en moins grande, quoique t'en dise.

Suffit de regarder comment tourne Firefox OS sur des terminaux qui ont des perfs de merde. Franchement, ça vaut pas le coup de se lancer dans du dev en C (qui est par nature plus long à faire que du dev en JS) pour beaucoup de type d'appli.