Ouvrir la navigation secondaire

Ce billet a plus de deux ans. S'il contient des informations techniques elles sont peut être obsolètes.

Précédent WebDev's Digest - Novembre 2009
Suivant Bonne année 2010 ! Rétrospective 2009

Le présent et le futur de JavaScript

Une intervention d'oncle Douglas Crockford, c'est toujours un succès.

Les retardataires peuvent se tourner vers :

Aujourd'hui le thème de la séance est The State and Future of JavaScript et c'est toujours un plaisir de voir une intervention de Crockford surtout quand on dispose d'une transcription complète du texte de la vidéo. Le thème est donc l'état et le futur de JavaScript. L'intérêt d'écouter cet homme réside entre autre dans le fait qu'il est un insider du process de standardisation du langage et c'est un point sur lequel il s'étend pendant sa présentation en revenant notamment sur la guerre interne qui s'est déroulée entre ES3.1 et ES4 dont Adobe a fait les frais. Son point de vue est forcément subjectif mais c'est toujours très intéressant de savoir comment les choses se déroulent et les rapports de force en jeu.

J'aime bien Crockford car il n'a pas la langue dans sa poche et parce qu'il est grave quotable :)

Morceaux choisis de la transcription avec des liens ajoutés par moi. Si vous voulez un truc moins lourd, regardez les slides de la présentation.

A propos de l'appellation JavaScript ou ECMAScript

I'm talking about JavaScript, but I really should be talking about ECMAScript. JavaScript is a trademark that's owned by Sun Microsystems, or possibly by Oracle [...] We really should be calling it ECMAScript, which I find really difficult because it's such an awful name.

A propos du process de standardisation

The committee had been working for several years pursuing a design that had begun at Netscape in 1999. That project had been abandoned, but was restarted again because of the big interest in Ajax.

All this time ECMA was really worried, because ECMAScript is the most successful product at ECMA. [...] ECMA demands consensus, and properly so. So the ECMA Secretary General and the ECMA President both began attending our meetings, which was really nice because with that adult supervision there, everybody started behaving more. Civility was restored and we were able to agree on more stuff.

A propos d'ES5

While that was going on, we were able to finish ES3.1 [...]. It is now a candidate to become the fifth edition of ECMAScript. We chose not to call it the fourth edition because there's an understanding in the world about what ES4 is, and what we were doing was nothing like that. So to avoid that confusion we skipped to the next whole number, so it's ES5. That goes before the General Assembly in December and I'm optimistic that it will be approved then. If so, it will become the next ECMAScript standard.

One company has stated its intention to vote against it, and that company is IBM. The issue is decimal arithmetic.

Et oui, le fameux Floating Point. S'ensuit une longue partie technique à propos de l'implémentation de la représentation des nombres à virgule flottante dans ECMAScript où l'on aborde l'IEEE 754, ses révisions et les multiples pistes étudiées pour améliorer ce point. Et puis on peut lire une petite pointe d'humour :

So it was really difficult to write programs that would be portable across all of those computers. Today is doesn't much matter because it's all Intel, so who cares...

A propos de la prochaine évolution du langage, ES6, nom de code Harmony

We're not calling it ES6 because we want to avoid names which suggest that something is inevitable, or pre-approved, or has some status which it has not earned yet, such as HTML 5 or something like that.

...et des wannabe ninjas (N.B. pire que des wannabe blogueurs) :

[...] there's a lot of pressure on us to suck less, which turns out to be really hard to do. There are so many wannabe ninjas out there who are taking the bad parts and the awful parts and showing how they can do all these clever things with them, and doing that means that we can't remove those awful features. Now, you could argue that they deserve to have their programs broken, or their legs broken...

They've been asking us to do things like add 'goto' to the language. [...] I don't want to be bringing it back, I think that would be a terrible thing.

Everybody thought that the Java VM was going to be the VM of the internet, but it turns out that JavaScript language is the VM of the internet.

Basically, we'll have Caja's strength native in the language itself, which would be a wonderful thing.

We still have to fix the DOM, because the DOM is still crap, but at least there's a good chance we can fix the language now. The DOM, incidentally, is going in exactly the opposite direction of what we need in order to make it safe for all of us, so that's another problem.

Let and const are already available in Firefox but they're not available in IE 6, so as long as you care about IE 6 you cannot use them.

A propos des brevets logiciels

So one of the lessons is that patents and open systems are not compatible. I think the solution to that incompatibility is to close the Patent Office.

The success of an enterprise should depend on the quality of its goods and services and its ability to execute efficiently, and not on a capricious Government office. The patent system made sense in the 18th and 19th century, it really did. They helped us to become a very innovative country, made us very good in manufacturing and process, but it has long outlived its usefulness and we need to change it. Patents can be attractive in that if you can get a patent and then snag a competitor with it, you can get some free money, and that's attractive. But you can get snagged on someone else's patent, and then you have to pay it back. There's a good chance that both of you are going to get snagged by a patent troll. So it's gambling, basically. It's a casino, and you hope that at the end of the day you win, but in the long term you lose. Nobody wins except the lawyers.

A propos d'HTML5

The thing I'm particularly concerned about is that the DOM API is just awful. I mean, who's made miserable every day by the DOM API? The reason that YUI exists, mainly, is to deal with that; because it's such an awful API we need something more expressive and more reliable in order to write our applications. It's wonderful that JavaScript is such a powerfully expressive language that a remarkably small amount of it can implement YUI and turn the DOM into something good. I would like to do that, I would like to figure out what the DOM API should have been, what it needs to be to allow us to write applications, and also to think about it in terms of security — how can I put a third party component on a page and allow it to fully interact with everything else on the page, including advertising, and not compromise us anymore? From my view, W3C is moving in exactly the wrong direction for accomplishing that goal. If it were up to me we would stop that and we would start over with HTML 4.2, and get smarter about it. But I don't think that's going to happen. Damn.