Aller au contenu | Aller au menu | Aller à la recherche

Mot-clé - javascript

Fil des billets - Fil des commentaires

dimanche, avril 1 2012

jsDatasource, a component for XUL templates

I just released publicly a new version of a component : jsDatasource.

This component allows to use javascript objects as datasource for XUL templates. You can use it in your own extension or XUL applications. It becomes easy to use XUL templates with js datasources!

I started this component in 2009, for a software, ZoomCreator, when I worked for Zoomorama. Even if it was written under a free licence, I didn't release it at this time (well, I had so much work..). And for a recent customer project, I need it with some improvements, like the support of recursion or the support of sorting. So I improved it, and I just open a public repository :-)

I hope it will help some XUL developers :-)

vendredi, mars 16 2012

Un serveur pour des tests ? Node.js bien sûr !

Pour une grosse extension pour Firefox (un projet client), j'ai réalisé entre autre chose un composant qui agit sur des pages web. Pour tester ce composant (avec des tests unitaires bien sûr !), j'avais besoin d'un serveur web servant des pages HTML statiques.

J'avais bien pensé à apache, mais ça m’embêtait de déployer toute une artillerie comme WAMP, surtout sur la machine de travail que l'on me prête, pas très performante (et sous windows mais bon, c'est une autre histoire... :-) ). Et puis ça m’embêtait de configurer un serveur web tout court. Donc exit aussi Nginx.

Bref, je voulais un truc très simple, très light. Je me suis alors tourné très vite vers node.js. Téléchargement, lancement de l'installateur, click, click, c'était installé.

J'ai choppé ensuite un script JS implémentant un serveur http de fichiers statiques, pour node.js, comme on en trouve par dizaine sur le web. Une ligne de commande plus tard, j'avais un serveur qui écoutait patiemment le port 8080.

En moins de 5 minutes, j'étais prêt à écrire mes tests. J'ai trouvé ça génial :-) Ça c'est de la productivité !

jeudi, octobre 14 2010

Le moteur Javascript de Firefox rattrape son retard

Connaissez-vous http://arewefastyet.com/ ? C'est un site mis en place par l'équipe des développeurs du moteur javascript de Mozilla, SpiderMonkey. Il permet de suivre l'évolution des performances de ce moteur, en exécutant deux tests : sunspider et v8bench.

Il y a quelques jours, SpiderMonkey avait dépassé Apple Nitro (le moteur js de webkit) sur v8bench. Depuis hier, il est sur le point de le dépasser sur sunspider ! Il reste maintenant à battre le moteur de Google, V8. (Ce sont les versions de développement de ces moteurs javascripts qui sont testés)

Arewefastyet ? v8bench 20101013 arewefastyet ? sunspider 20101013

Légende: courbe violette : spidermonkey (Tracemonkey + JaëgerMonkey); courbe rouge : apple nitro. courbe verte : google v8. courbe noire : spidermonkey (JaëgerMonkey seul)

À noter que ces résultats sont obtenus en lançant les tests non pas dans un navigateur, mais avec les versions "autonomes" des moteurs javascripts (hors navigateur donc). On a donc ici des performances pures, qui ne sont pas impactées par d'autres choses comme un moteur de rendu ou des scripts d'autres sites etc. Il est évident donc que vous n'obtiendrez pas des résultats comparatifs du même ordre, en les lançant dans un navigateur.

C'est ainsi que ce n'est pas encore parfait du coté Mozilla, puisqu'on obtient encore des écarts en lançant ces tests avec Firefox. Probablement que les tests dans Firefox sont biaisés à cause de l'exécution de code JS en dehors de la page de tests, puisque l'interface de Firefox est développée en partie en javascript.

Cependant, les améliorations entre Firefox 3.6 et Firefox 4 sont énormes, et les performances des moteurs javascripts des principaux navigateurs (IE9, Chrome, Safari et Firefox 4) sont maintenant équivalentes. On arrive à des différences qui ne seront pas perceptibles par l'utilisateur.

Je pense que d'ici quelques mois, on aura atteint les limites sur les améliorations dans les moteurs javascript.

la bataille des navigateurs va pouvoir aller se focaliser sur d'autres sujets :-) (accélération matériel etc..)

vendredi, novembre 13 2009

Javascript coté serveur

Ça commence à faire pas mal d'année que je fais du javascript, non seulement pour le web, mais aussi dans les applications XUL. Ce qu'il y a d'intéressant à utiliser Javascript avec le XUL, c'est qu'on peut se lâcher, et utiliser tout le potentiel du javascript de la plateforme Mozilla, comme les générateurs et iterateurs, les propriétés et méthodes avancées sur les objets de base (comme sur Array). Même si je ne suis pas fan de certaines constructions syntaxiques[1].

Et depuis quelques jours j'ai une lubie : pourquoi ne pas utiliser javascript coté serveur, en remplacement de PHP par exemple ?

Et j'ai découvert sur wikipedia qu'il existait quelques dizaines de projets de générateurs de pages web à base de javascript. La majorité de ces projets reposent sur les moteurs JS de Mozilla :

  • SpiderMonkey, le moteur (en C) utilisé dans Firefox 3/Gecko 1.9.0 et précédent
  • Rhino, un moteur en java

Ceux à base de SpiderMonkey m'intéresse plus particulièrement. Je ne les ai pas encore tous regardé, mais jslibs semble sympa, dans la mesure où la dernière version ne repose plus sur SpiderMonkey, mais sur TraceMonkey, le moteur JS accéléré de Firefox 3.5.

Pour faire le choix d'un de ces projets, il va falloir regarder de plus près les API proposées. En effet, il faut savoir qu'un moteur JS ne fait qu'exécuter du code, et ne contient nativement que quelques objets primitifs comme String, Array, Date, Math... C'est au code embarquant de "brancher" des bibliothèques ou fonctions C sur des objets JS (faire des wrappers donc), pour enrichir l'API utilisable dans le code JS. Ce que fait d'ailleurs un navigateur, pour les objets window, document, les objets DOM etc.

Reste aussi à faire quelques benchmarks, pour voir si ça vaut vraiment le coup par rapport à PHP, Python ou autre..

Notes

[1] disons que depuis la publication de ce billet, j'ai un avis moins tranché :-) On s'y fait

mardi, novembre 10 2009

Et le meilleur moteur javascript est....

On voit circuler ces slides sur des astuces pour les perfs en javascript, et on y voit notamment que les résultats de Firefox par rapport aux autres moteurs, notamment V8, ne sont pas folichons.

Cependant, comme beaucoup de benchmarks, ces résultats sont sujets à cautions, d'autant plus qu'ici :

  1. On ne sait absolument quelles versions de chaque moteur sont mises en comparaison
  2. Comparer SpiderMonkey, moteur d'ancienne génération (Firefox 3.0 et précédent), à V8, ce n'est vraiment pas "fair play". Il aurait pu prendre au moins TraceMonkey (Firefox 3.5). À moins qu'il confond dans les noms, mais ça m'étonnerai, car pour les quelques tests que j'ai effectué avec son script, les résultats de TraceMonkey sont plus proches de V8 que de IE (dernières versions stables des navigateurs).

Et puis bien sûr, aucune mention d'Opera.

Enfin, c'est bien beau d'avoir un moteur rapide, encore faut il qu'il soit en conformité avec la spécification Ecmascript. Ce qui est encore loin d'être le cas pour certains d'entre eux.

vendredi, août 29 2008

Drag and drop HTML5 dans Firefox

Après les améliorations qui viennent d'être apportées sur le moteur Javascript qui fait repasser Gecko 1.9.1 devant Webkit au niveau des performances de l'execution des scripts JS, voici que Neil Deakin (développeur Mozilla de son état), vient de terminer l'implémentation de l'API drag and drop de HTML5.

On peut donc apporter des fonctions de drag'n'drop dans une page web, tout aussi facilement que ce que l'on peut faire avec des bibliothèques comme jQuery. Sauf qu'il n'y a plus besoin de charger des kilos de scripts JS :-)

Lire la suite...

jeudi, mai 31 2007

Bad syntax in Javascript 1.8

Mozilla developers improve day after day Javascript. It's a good thing to improve a language. But I think those who made this improvements in Mozilla should stop smoking the carpet right now.

Improvements in javascript 1.6 (Firefox 1.5) were good, although I'm not a fan to pass a callback function to each array function. I would prefer to have a real support of array with for each statement like the foreach statement in PHP instead of to have this for each statement which return not only elements of the array, but all all the properties of the array object. However E4X was a good improvement in Javascript 1.6.

They began to do crazy things with javascript 1.7 (Firefox 2).

Generators can be useful, but conceptually, it begins to introduce some things that can be disruptive for a "normal" web developer (you know, one of these thousand of thousand web developers who made millions of web site). And it is difficult in a complex function to distinguish a normal function from a generator because the difference is only the use of this small keyword yield.

Iterator is a good thing, but I don't know why we should catch an exception to know when the iterator stops. That sucks. (Interface like PHP iterators is better IMHO).

The goal of array comprehensions is to make easy initialization of array. It would be a good thing if the syntax didn't sucks too.

var ten_squares = [i * i for (i in range(0, 10))];
var evens = [i for (i in range(0, 21)) if (i % 2 == 0)];

Sorry but it is unreadable. Good luck for those who will maintain such code. Look at this example pointed by John that we can do in Javascript 1.8 (Firefox 3):

dict([s, [u for (u in unitlist) if (u.contains(s))]] for (s in squares))

I think this is a good example of unmaintainable code. No specific keywords, no really separators. I'm sure it will be a nightmare for maintainers.

In his post, John Resig shows other things like this horrible "expression closures" feature. I don't see any advantage to write function(x) x * x instead of function(x) { return x * x; }. It is less comprehensive, less readable.

I think only nerds will play with this "features", and "normal" developers and geeks will continue to use javascript 1.5. There is an evidence : in all javascript file of Firefox 3 and other Mozilla products in the trunk, i don't find any use of let, yield or other features of Javascript 1.7.

Glazou gave me only one advantage of this new features : web/XUL developers won't have to use JS obfuscators...

mardi, novembre 7 2006

Adobe dépose du code dans Mozilla

C'est énorme ! Adobe vient de libérer le code source de sa machine virtuelle ActionScript 3 !!! Oui, oui, le même moteur qui exécute les scripts ActionScript 3 dans Flash 9 !

Et.. et... intégré dans Mozilla ! En trois licences s'il vous plait : MPL, GPL, LGPL ! (c'est déjà dans le trunk, bien qu'il reste du développement d'intégration à faire dans spidermonkey).

Les raisons : travailler main dans la main avec Mozilla afin de faire évoluer plus vite la norme EcmaScript et d'avoir une implémentation complète du langage.

Et pour les développeurs, cette machine virtuelle, qui traduit le code javascript en byte code ou directement en langage machine, cela va permettre d'avoir de bien meilleures performances lors de l'execution des scripts javascript, que ce soit dans les pages web, les extensions, ou même les applications XUL comme, au hasard, Firefox !

Vivement Firefox 3 !

Pour en savoir plus : lire la news sur xulfr

Update : il s'agirait plutôt de Firefox 4 en fait..

vendredi, juin 2 2006

Site de HOP : trop dopé à l'ajax

update : parce que cela choquait certains, le titre de ce billet a été modifié et la dernière phrase de ce billet supprimé.

L'INRIA a sorti un nouveau langage/framework pour réaliser des applications "web 2.0", HOP. (Un nom bien web 2.0 tiens...).

À lire la documentation, ce langage ne m'enthousiasme pas vraiment. Il a l'air d'avoir des mécanismes qui facilite en effet la déclaration de l'attachement d'une action coté client au service web coté serveur. C'est pas mal, mais coté syntaxe, faut aimer. Mais bon, le débat n'est pas là. Il est ailleurs. Le site.

Le site en lui même est fait avec HOP bien sûr, et c'est là que l'on voit la débilité de l'usage inconsidéré d'Ajax. Le contenu de ce site est simplement de l'information, de la documentation. Rien qui ressemble de prés ou de loin à une application. Mais les auteurs semblent avoir oublié quelque chose. La simplicité, l'efficacité. Oublions les énormes avantages qu'apportent de bêtes pages html du web 0.1 dans le cadre d'un site informatif, et faisons tout en ajax.

Résultats :

  • il m'est impossible de vous donner un quelconque lien vers l'une des "pages" de ce site. Même pas vers un exemple hello world, ou la page téléchargement. Rien. Nada.
  • Il va être impossible pour les moteurs de recherches d'indexer son contenu. (pour un site de documentation, c'est tout de même fort...)
  • Accessibilité : proche de 0 j'imagine.
  • Pages lourdes (pour le contenu qui y est présenté...)
  • En dehors d'un navigateur graphique avec javascript activé, point de salut.

Conclusion : Un site et une techno à oublier pour faire des sites normaux informatifs. (de toutes façons, peu de chance que les gens s'y intéressent, puisque le site ne peut être référencé correctement..).

jeudi, juin 1 2006

Du js dans katepart

Dans la dernière version du composant d'édition de texte, katepart (utilisé par Kate, KDevelop etc..), on peux scripter l'editeur avec du Javascript. Trés sympathique ça :-)

mercredi, mai 24 2006

JS1.7 : Destructured Assignment

Dans Javascript 1.7 (Firefox 2.0), on va avoir :

Ce deuxième point est rien d'autre que l'équivalent du list en php :

function f() {
   return ["Jerry", 5, true];
}
var [a, b, c] = f();
// -> a="jerry", b=5, c=true

D'autres choses sont prévues dans Javascript 1.7, mais les Mozilliens sont peu bavards sur le contenu exact. Certainement des bouts de Javascript 2.0 dedans.

jeudi, avril 6 2006

Big Daddy vous indexe

Google a annoncé (le 1er Avril semble-t-il, mais ce n'est pas un poisson) le lancement de son nouvel indexeur, de nom de code Big Daddy.

Vous avez sûrement dû remarquer dans les statistiques de votre site la venu d'un certain navigateur appelé GoogleBot. C'est le robot indexeur de Google. Son principe est simple : il s'agit d'un programme qui fait de simples requêtes http GET vers des liens qu'il connaît. Il récupère le contenu brut de la page web, indexe son contenu, récupère les liens qui s'y trouvent et les suit.

Cette technique simple a toutefois une limite : tout ce qui est généré dynamiquement dans la page est totalement ignoré, car l'indexeur n'exécute pas le javascript. En effet, pour faire un robot indexeur qui exécute le javascript, il faut construire un arbre DOM représentant le document, et appeler un moteur Javascript. Et si on veut pouvoir suivre les liens qui sont appelé en javascript (du style, les liens <a href="javascript:window.open..."), il faut que le robot "clique" sur le lien, donc gère aussi les événements DOM.

En clair : réaliser ce genre de robot d'indexation revient à développer un "vrai" navigateur. C'est pour cela que cela n'a probablement pas été fait jusqu'à... il y a quelques jours chez Google.

Big Daddy c'est donc ça : un robot indexeur qui est aussi un vrai navigateur. Et pour cause : il est basé sur Gecko, le moteur de Firefox.

On comprend mieux maintenant certains rapprochements entre Google et Mozilla. Il ne s'agissait pas d'un GBrowser, mais d'un robot d'indexation d'un nouveau genre. J'imagine qu'ils ont du faire des traitements qui font (en trés gros) des document.getElementsByTagName("a"), et qui envoient des évènements DOM "click" sur les éléments trouvés, une fois que la page a été chargé (et donc le code JS executé).

Les conséquences ? Pour les points positifs : une indexation des contenus qui échappaient jusqu'à présent à googlebot. Pour les points négatifs : ça va être plus dur de persuader les développeurs web à rendre leur site accessible : ils vont pouvoir mettre de l'Ajax partout, faire du code crade. On ne pourra plus brandir l'argument "pense à google le plus connu des aveugles du web, si tu ne rend pas ton site un minimum accessible, tu seras moins bien référencé". Et pour cause, il est beaucoup moins aveugle maintenant :-/

Il doit aussi y avoir d'autres conséquences au niveau référencement. Mais je ne connais pas assez les techniques de référencement pour l'affirmer.

Mise à jour : quelques liens

mercredi, avril 5 2006

XForms vs Ajax : 1 - 0

XForms fait de plus en plus parler de lui. Et pour cause : il rend totalement obsolète l'utilisation d'ajax dans les formulaires html classique. (oui j'enfonce le clou aprés mon billet Ajax est déjà obsolète ;-) ). XForms apporte en effet une plus grande souplesse, une plus grande facilité de développement, une meilleure accessibilité et qui plus est, permet de faire des formulaires plus puissants.

Lire la suite...

dimanche, novembre 6 2005

Faire de l'Ajax sans le savoir

Dans un billet précédent, "Ajax est obsolète", j'expliquais que pour moi, Ajax n'est pas une solution d'avenir car trop complexe et trop bas niveau (le fameux xmlhttprequest).

J'avais alors émis l'idée d'avoir plutôt des balises spécialisées, interpretées directement par le navigateur, qui se chargeraient des opérations bas niveau et avec lesquelles on aurait juste à indiquer des informations minimales dans des attributs comme l'URL du service web à invoquer. Elles permettraient donc de faire de l'Ajax sans le savoir, sans avoir à taper des lignes de codes javascript complexes. Exactement en fait comme la balise HTML <a> ou <form>, qui utilisent finalement une forme d'Ajax sans que vous le sachiez : elles ont une url dans un attribut, elles envoient des données via xmlhttprequest à cette url, et elles modifient (ou plutôt remplacent) la page courante à partir du contenu de la réponse reçue.

J'avais donné alors l'exemple de la balise template en XUL qui est parfaitement dans cet esprit : on cache ce qui est bas niveau (xmlhttprequest), on permet d'éviter l'usage du javascript. Le résultat est alors une techno simple à utiliser pour développer, économe en temps de dev, de débuggage, et économe en bande passante ou en ressource système (il n'y a pas 50ko de scripts à executer puisque les balises sont directement interpretées par le navigateur).

Je voulais commencer à faire une bibliothèque JS qui permettrait de vous montrer concrétement mon idée. Mais en fait d'autres l'ont fait avant moi. Je suis en effet tombé, au hasard du surf, sur l'offre de backbase. Ce qui est intérressant sur ce site, c'est le code source de leur page. Que voit-on ? Des balises <include>, <event>, <buffer>, des attributs behavior, followstate etc.

On devine alors aisément à quoi elles servent : inclure des morceaux de pages à des endroits précis, qui sont éventuellement rechargés à l'apparition d'évènements particuliers, déclenchés par des actions spécifiques de l'utilisateur. En clair : vous avez le même résultat que ce que l'on fait en Ajax, mais sans avoir à écrire une seule ligne de code javascript. Quelques balises et quelques attributs bien placés, et vous voilà avec une interface utilisateur dynamique.

Exactement donc dans le même esprit que la balise html <a>, <form>, ou la balise XUL <template> : simplicité, efficacité. Bref, une techno accessible à tout développeur web, et pas seulement aux geeks.

Ce qu'a fait Backbase a toutefois un inconvénient : avoir une page utilisant leurs balises nécessite d'inclure leurs fichiers JS qui sont volumineux. Ce javascript sert à parser la page, et à interpreter les balises et attributs. On a donc une page lourde et longue à charger mais aussi longue à s'éxecuter.

Cependant, imaginez que le navigateur puisse interpreter nativement des balises du même style que celles de Backbase. Là je pense qu'on pourra vraiment parler de web 2.0 (ou 3.0 ?) ;-) (tout en résolvant une partie des problèmes d'accessibilité posés par Ajax).

lundi, mars 21 2005

C'est le printemps sur Openweb !

Le printemps est synonyme de reveil, renouveau, renaissance. Il en va de même pour le deuxième anniversaire d'Openweb.eu.org cette année. Grâce à de nouveaux arrivants dans l'équipe de contributeurs, le site n'est plus à l'abandon. Vous pouvez lire d'ailleurs le billet qu'à écrit Laurent Denis à propos de cet anniversaire, et puis bien sûr, aller lire les nouveaux articles sortis aujourd'hui.

Quant à moi, je vais aussi refaire un come-back puisque j'envisage d'écrire un article sur Ecmascript (donc JavaScript). C'est un sujet peu développé sur openweb, et surtout sur lequel il y a beaucoup d'a priori. Je le vois en lisant les remarques de ceux qui découvrent XUL & cie sur http://xul-fr.org. En effet, javascript est l'un des piliers principaux d'une application XUL, et provoque trés souvent une méfiance : Quoi, javascript ? Bof ! On ne peut pas utiliser autre chose ?.

Cette méfiance est due bien souvent à une méconnaissance du langage, à sa mauvaise réputation (conséquence de sa mauvaise utilisation dans les pages web en général) et au mélange entre le langage en lui même et les objets fournis par les navigateurs (c'est trés souvent ce dernier point qui provoquent des incompatibilités, ce n'est pas JavaScript).

Bref, Javascript a mauvaise presse. Je tenterais donc, dans la limite de mon temps libre (comme toujours), de corriger le tir et de montrer que Javascript n'est pas un langage de script plus mauvais qu'un autre, et que l'on peut faire des choses trés évolués avec. D'ailleurs, Google, dans ses applications (de mail, de cartographie et autre) en fait un usage important, et je m'amuse de la réaction de beaucoup de personne étonnées que l'on puisse faire des choses pareils avec du JavaScript (preuve que peu de développeur web le connaisse vraiment).