Ca m’empeche pas quand je vois une situation de merde d’essayer d’y remedier.

Je ne t’ai pas beaucoup vu sur es-discuss et les autres mailing-lists de standards ;-)

Deja, je pense pas avoir les competences pour.
Ensuite, je developpe pas (plus) en JS, donc bon…
Enfin, sur mon temps libre, je prefere faire des trucs marrants que de meprendre la barbe avec d’autre barbus. :P Genre developper mon script pour Codingame. D’ailleurs, j’y retourne, allez hop.

On pourrait résumer cette réponse (à part quelques points encore une fois) à “C’est pourri mais c’est normal et il faut faire avec”.

Oui. Il n’y a aucun débat sur le fait que JS est nul au niveau langage et même certaines API legacy genre le DOM (il y a un peu plus de débat sur d’autres aspects notamment doc, écosystèmes, communautés, etc.)

Ca m’empeche pas quand je vois une situation de merde d’essayer d’y remedier.

Je ne t’ai pas beaucoup vu sur es-discuss et les autres mailing-lists de standards ;-)

Mouahahahah. J’adore quand un spécialiste explique combien son outil est une grosse merde MAIS sic “il faut vivre avec” WTF! Le divorce c’est pas pour les chiens!

C’est un peu par erreur que je suis devenu spécialiste. Un peu comme Noëlie, mais pas tout pareil.
Il n’y a pas de divorce. Le web est bâti sur le principe de backward-compatibilité (pour des raisons économiques) et les navigateurs ont des dilemmes moraux dès qu’ils vont peut-être casser un site web (le lien que je donne, c’est vraiment juste un récent. Un parmi les 200 qu’ils ont par jour), donc on ne peut pas améliorer le langage en enlevant les merdes. Donc, il faut apprendre à éviter les pièges.

La réponse est bonne, mais le mec en met des tartines pour justifier chaque point et comment faire avec/ne pas se faire mordre, ce qui confirme bien que c’est un mauvais langage :).

Le mec te confirme :-) Mais on vit beaucoup mieux dès qu’on a accepté le truc. C’était un peu l’objet de mon propos. Si on espère que JS soit bien, on ne se créé que des frustrations. Pour vivre heureux, il faut accepter passer la colline de frustration qui consiste à dire que le JS c’est de la merde. En haut de cette colline, on peut alors réfléchir à comment on fait quand même des trucs, comment on se facilite la vie.

C’est même pas tant le fait que ça soit asynchrone qui prime mais le fait que ça soit non-bloquant

Oui. Je me fatigue, je fais toujours la confusion.

Et si le JS avait gardé ses perfs d’origines, personne n’aurait levé les yeux sur node, asynchrone ou pas.

Discutable, mais bon, on ne saura jamais.

Qui fait du Javascript avec Rhino ?

Je soupçonne que Google App Script et ses .gs, ça soit du Rhino en-dessous (avec des APIs à eux en plus… avec I/O bloquante -_-#). Mais oui, JS sans Node.js n’a pas grand sens.

L’article est là pour pointer à quel point le JS est un langage pourri. La raison pour laquelle il l’est (une dette technique colossale), ne change pas ce point. Et le prix à payer est très lourd. C’est toujours chiant de devoir se coltiner un boulet alors qu’il y a de meilleurs outils à côté.

Rejoins-moi de l’autre côté de la colline :-) Rester frustré ne sert à personne ;-)

Le problème de new n’est pas pour les experts, c’est pour les non experts. En effet, Javascript ne lève aucune erreur si on oubli new

Il n’y a pas de notion de constructeur dans le langage. Juste des fonctions et selon l’envie du moment, on décrète que c’est un constructeur ou pas et donc on décide de l’appeler avec new ou pas. Mais c’est plus une convention entre développeurs. C’est pour ça qu’il ne lève pas d’erreur.

Debugger en JS, et c’est encore plus vrai quand on est pas expert, est une vrai torture comparé à la concurrence.

Oui. Mais ça s’améliore dans les navigateurs. Node.js reste lamentable et c’est assez triste. Mais tout le monde est au courant, donc des gens bossent sur la question.

C’est de pire en pire avec les nouveaux frameworks. Par exemple, j’utiliser Angularjs. Comme pour faire quelque chose de propre avec JS, ça demande pas mal d’abstraction et de magie, les messages d’erreurs sont incompréhensibles. C’est pareil avec Amber, backbone, spine… A chaque erreur, on doit, non pas regarder SON code, mais le code source du framework, pour voir le problème.

Là, c’est plus un problème des frameworks que du langage. Depuis récemment, les frameworks créent des extensions aux devtools pour leur framework. En gros, si tu utilises Ember, tu te mets aussi l’addon qui va bien et tu peux débugger les abstractions Ember directement. On en est au début, mais c’est prometteur.

On ne peut pas en JS. En JS, il faut d’abord apprendre la syntaxe du langage, et ensuite apprendre 3 tonnes de bonnes pratiques et patterns. En prime, il n’y a aucune doc centralisée pour vous dire comment faire.

“centralisée”, ça va être compliqué, mais ce repo est un début https://github.com/rwaldron/idiomatic.js/
Je recense aussi les trucs pourris du langage https://github.com/DavidBruant/ECMAScript-regrets (un par issue).
Niveau outillage automatisé, je conseille eslint https://github.com/eslint/eslint/
TypeScript aussi fait du super boulot à garder le code sain et apporte très souvent d’excellents messages d’erreur.

Et non, ce lien ne permettra jamais à un de mes élèves de comprendre le prototypage.

Le lien tout seul non, mais assisté de cet outil, j’ai expliqué la notion en formation, les gens ont compris (j’ai créé l’outil spécifiquement pour ça).
En complément : https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Inheritance_and_the_prototype_chain

Ce paragraphe est à lui seul une argumentation en ma faveur. Des features qui arrivent “dans le future”, donc un langage sur lequel tout le monde est d’accord qu’elles manquent. Mais qu’on ne pourra utiliser que dans 2, 3 ans.

Nan, avec TypeScript ou Traceur, on peut utiliser la plupart des syntaxes ajoutées dans ES6 dès aujourd’hui. Et ça compile vers ES3 (donc compatible IE8). Je l’ai fait dans un vrai projet pour un client il y a un peu moins d’un an. Ca s’est bien passé.

Quand aux polyfills, j’ai du mal à voir comment suggérer du monkey patching comme rusting pour un manquement essentiel du langage peut mériter une smiley.

Quand Brendan Eich conçoit le langage et l’implémente en 10 jours, il sait qu’il n’aura pas le temps de tout faire proprement, alors il ouvre au Monkey patching en se disant que les gens rajouteront leurs propres trucs.
Le fait que Array.prototype.map ne soit pas implémenté dans IE8 n’est pas un manquement du langage. Il existe une spec, tous les autres navigateurs l’implémentent (IE8 a quand même implémenté une version toute pourrave de Object.defineProperty, ils auraient pu rajouter des trucs plus utiles).
La possibilité de faire des polyfills est une chance, surtout dans le contexte des navigateurs qui ne veulent pas partir comme IE8.

D’autant que les polyfills posent un AUTRE enorme problème pour quelqu’un qui n’est pas expert (comprendre, qui ne passe pas 1h par jour à se tenir au courant) :

– quel polyfill utiliser ?

es5-shim https://github.com/es-shims/es5-shim (ou es5-sham si tu comprends et acceptes les limitations)
Sinon, plus généralement, la veille a été faite : https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills

– dois-je le faire à la main ?

Non.

– dois-je plutôt utiliser une lib ?
– si oui, lodash, underscore, jquery ?

Les libs ne rajoutent pas leur polyfills mais ont inventé leur équivalents (principalement parce qu’ils ont commencé à une époque où on n’avait pas vraiment compris la notion de polyfill).

Pour des features de base, on est déjà obligé de prendre ce genre de décisions. Ce n’est pas une bonne chose du tout.

Histoire, legacy, regrets, colline ;-)

Oui encore un truc super chiant. Tous les moteurs ont leur numéro de version qui n’est pas calqué sur la spec ECMASCRIPT et c’est du travail de trouver les correspondances.

Aucune importance. Versions ECMAScript comptent, le reste, c’est à jeter.

Car Javascript est aussi un langage mal standardisé.

Alors, c’est compliqué de répondre à ça. En court, c’est : non, oui, non.
ECMAScript est très très bien standardisé, genre choquant. Les différences d’implémentations ECMAScript sont restées très subtiles, même sur les vieux IE et connues seulement des gros nerds (des trucs liés aux tableaux non-denses ou l’ordre d’énumération de for-in dans des conditions un peu ésotériques).
Le DOM est une autre histoire avec Microsoft qui s’est senti pousser des ailes et proposer des choses encore pire que ce que le W3C avait pondu (sauf quelques bons trucs genre .innerHTML ou les iframes).
Tous les standards ont connu une période de gel pendant/suite à la guerre entre les navigateurs grossièrement entre 1999 et 2009, mais le support des standards qui existaient a convergé quand même sur les parties communes.
Historiquement, il a manqué un gros morceau concernant comment les APIs W3C étaient exposées en terme d’ECMAScript (lié au fantasme ancien que les APIs seraient universelles et exposées dans plusieurs langages, genre Java, lol). Ce trou est en train d’être comblé avec une spec qui s’appelle WebIDL.
L’effort actuel est standard est assez beau, je conseille de s’y intéresser, je me demande si d’autres langages ou écosystèmes sont aussi productifs dans leur capacité à se mettre d’accord sur des features bien conçues.

Nope, pas sur IE8 sans polyfill

Bah utilises un polyfill :-) T’es quand même pas à 20 lignes de JS près…

Bref, j’espère que coffeescript ne gagnera pas.

Personne ne gagnera. Les gens qui font du coffee vont continuer. Les gens qui font du TypeScript vont continuer, etc.

Je préfererais 100 fois qu’ils réparent les erreurs du JS et qu’on puisse l’utiliser proprement. Ce qu’ils sont heureusement en train de faire. Mais c’est lent.

Ils ne peuvent pas réparer les erreurs, par contre, ils peuvent les cacher et encourager des meilleurs patterns. C’est aussi ce que fait ES6 (de manière encore plus lente, mais c’est pour notre bien).

Et si le Javascript pouvait aussi se taper des API synchrones, ce serait cool aussi. Parceque l’asynchrone, c’est hyper dur de former des gens dessus, et tout n’a pas besoin d’être async. En fait, à part pour la prog événementielle, on en a rarement besoin, donc comme paradigme par défaut, c’est chiant.

Tu fais référence à Node? Parce que toutes les APIs async ont un équivalent avec le suffixe -Sync, genre fs.readFileSync.
Sinon, c’est un très bon défaut tant que l’oeil humain est sensible à des temps de l’ordre de 100ms, que l’on tape sur des serveurs sur un autre continent et que la vitesse de la lumière reste une barrière infranchissable ;-)
Le sauveur de l’asychrone sans prise de tête, c’est les promesses, mais le concept ne décolle que depuis ~2 ans et donc, Node.js avait déjà fait le choix des callbacks. Je ne fais rien d’asynchrone sans promesses. Heureusement, ça arrive bientôt par défaut dans les navigateurs (et polyfills en attendant, évidemment)

J’adore le petit Clippy ;-)

Nan, c’est parce que Ryan Dahl a compris l’importance de la programmation asynchrone et que les gens qui font du JS sont déjà dans le moule de l’asynchrone et que c’était donc une communauté facile à convaincre.
C’est juste une bonne coïncidence qu’au moins une VM très performante est dispo.

Node.js massacre beaucoup d’autres langages en performance grâce à l’asynchrone, pas grand chose d’autre, sûrement pas la “vitesse du langage”.

L’asynchrone existe avec des tas d’autres langages. Twisted existait avant nodejs, Erlang aussi. Et si le JS avait gardé ses perfs d’origines, personne n’aurait levé les yeux sur node, asynchrone ou pas.

En effet, ça ne sert à rien d’avoir un super framework asynchrone si il passe 30% du temps sur le rendu des templates. Les gens prennent la VM de chrome comme quelque chose de normal maintenant, mais il faut se souvenir à quel point Javascript était incroyablement LENT. Vraiment. Très. Lent.

On compare des choux et des carottes. Un langage (syntaxe, sémantique) ne sert à rien. Il faut toujours des trucs en plus. Dans un contexte web, à quoi sert Ruby sans Rails ?

NodeJs, ce n’est pas juste une VM, c’est une framework. Ruby permet de faire des choses avec sa stdlib. Python permet de faire énormément de chose avec. Sans framework. Autre chose : Python est aussi utile avec ses autres implémentation (Jython pour la JVM, Pypy pour du JIT, IronPython pour tourner sur .net, etc). Qui fait du Javascript avec Rhino ? La prog JS serveur est complètement dépendante de Node, en plus d’être dépendante d’une runtime javascript.

Le web est un pari ambitieux qui a des coûts. Mais il faut aussi comprendre les enjeux du web. Aucun téléphone ne sort sans navigateur web aujourd’hui. Ca n’est même pas une discussion. Ca a des coûts qui vont avec. On peut rêver d’un autre monde, mais essayons d’avancer dans celui qu’on a entre temps ;-)

…

Bienvenue dans l’humanité ;-)

On est d’accord sur ce point, j’avais juste besoin de passer mes nerfs sur quelque chose. Ca va mieux maintenant.

Du fat d’être langage du web et de la contrainte de backward-compat du web, JS ne peut pas se débarrasser de ses bad parts. J’ai donné un talk sur le sujet. Être efficace en JS nécessite de comprendre un peu son histoire et les pièges à éviter. C’est le coût d’être le langage du web. Mais c’est bien le web, non ? Ca vaut le coup, non ?

Ce n’est pas l’objet de l’article. L’article est là pour pointer à quel point le JS est un langage pourri. La raison pour laquelle il l’est (une dette technique colossale), ne change pas ce point. Et le prix à payer est très lourd. C’est toujours chiant de devoir se coltiner un boulet alors qu’il y a de meilleurs outils à côté.

wtf? N’importe quoi ! La spec ECMAScript 5 est la référence pour les différences entre strict et “sloppy” mode. Pour des ressources un peu plus digestes :
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions_and_function_scope/Strict_mode
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions_and_function_scope/Strict_mode/Transitioning_to_strict_mode

…

Mais c’est quoi ce business de la désinformation !!
a = 1 est une expression qui permet de faire a = b = 1, donc sa valeur est la valeur de la sous-expression de droite. var a = 1 n’est pas une expression (if(var a = 1){} est une SyntaxError), donc le REPL se contente de retourner undefined, mais ça n’a aucune importance en pratique.

J’ai dis de la merde. Mea culpa.

Douglas Crockford est une seule personne. On a le droit aussi de ne pas être d’accord. Utiliser with, c’est souvent se tirer une balle dans le pied, d’où le bannissement dans le strict mode. Mais new, c’est plus une question de style. Je suis assez expert JS, j’utilise new et je le vis bien.

Le problème de new n’est pas pour les experts, c’est pour les non experts. En effet, Javascript ne lève aucune erreur si on oubli new :

> function test(){}
undefined
> test()
undefined
> new test()
{}

Ca pose le même problème que :

J’ouvre Firefox, je tape [] + {}

J’écris ça quotidiennement aussi, ça m’aide beaucoup pour écrire des interfaces facilement utilisables par les utilisateurs. [] + {} créé aussi des méta-promesses qui permettent de faire de l’asynchrone un peu plus rapide que la vitesse de la lumière.

Le problème n’est pas la difficulté intrinsèque posés par ce genre de détail, c’est que quand (et pas SI) il y aura un bug, ça va rendre le truc hyper chiant à debugger. Debugger en JS, et c’est encore plus vrai quand on est pas expert, est une vrai torture comparé à la concurrence.

Un langage, ce n’est pas juste des fonctionalités métiers, c’est aussi :

– la lisibilité
– la facilité de debug
– la communauté
– la doc

Le Js à la communauté, mais pêche beaucoup sur les 3 autres points. Il ne faut pas se faire l’avocat du diable. Que ce soit une techno qui fasse le boulot, tout le monde est d’accord. Mais on passe notre temps de dev à la tordre dans tous les sens pour ce faire.

C’est de pire en pire avec les nouveaux frameworks. Par exemple, j’utiliser Angularjs. Comme pour faire quelque chose de propre avec JS, ça demande pas mal d’abstraction et de magie, les messages d’erreurs sont incompréhensibles. C’est pareil avec Amber, backbone, spine… A chaque erreur, on doit, non pas regarder SON code, mais le code source du framework, pour voir le problème.

Je ne dis pas que ça ne m’arrive jamais de devoir jeter un coup d’oeil dans les entrailles de Django pour comprendre l’origine d’un problème, mais c’est rare. La stack trace est clair, les messages d’erreurs sont généralement assez directes, et surtout, le langage n’a pas de trucs bizarre comme les problèmes vus plus hauts qui transforment parfois la chasse aux bugs en une décente dans l’imaginarium du doctor parnassus.

En français aussi, il y a des figures de style. En l’état, on peut écrire du JS propre. Je veux bien admettre que ça exige beaucoup plus de disciplines que d’autres langages, mais ça s’arrête là. Encore une fois, JS est obligé de porter le poids de son histoire parce que c’est le langage du web.

http://davidbruant.github.io/ObjectViz/

Là c’est de la mauvaise foi. Outre que le français est une langage qui évolue organiquement depuis près des siècles et JS un langage artificiel technique qui est à peine majeur, on peut écrire du français propre et lisible sans figure de style.

On ne peut pas en JS. En JS, il faut d’abord apprendre la syntaxe du langage, et ensuite apprendre 3 tonnes de bonnes pratiques et patterns. En prime, il n’y a aucune doc centralisée pour vous dire comment faire.

Et non, ce lien ne permettra jamais à un de mes élèves de comprendre le prototypage. C’est aussi difficile à expliquer que les metaclasses en Python. Sauf que les metaclasses, c’est pas une notion essentielle.

chaines multilignes

Ca arrive dans ES6 https://gist.github.com/lukehoban/9303054#template-strings

list compréhension à la Python

ES6 : https://gist.github.com/lukehoban/9303054#comprehensions
Implémenté dans Firefox et dans la Nightly depuis la semaine dernière.

Et encore, je suis cool, je mets un code JS qui utilise l.length directement dans la boucle et pas de variable pour l[i].

Nan, mais c’est bon, on est en 2014, plus besoin de ces conneries :-) Y’en a jamais eu besoin, c’était juste de la micro-optimisations de gens qui pensaient que ça avait un impact significatif après qu’ils aient fait un micro-benchmark sur le sujet.

Array.map arrive avec JS 1.6 et les arrays comprehensions avec la 1.7…

Cute :-)
Array.prototype.map, on peut le polyfiller

Ce paragraphe est à lui seul une argumentation en ma faveur. Des features qui arrivent “dans le future”, donc un langage sur lequel tout le monde est d’accord qu’elles manquent. Mais qu’on ne pourra utiliser que dans 2, 3 ans. Quand les autres langages

Quand aux polyfills, j’ai du mal à voir comment suggérer du monkey patching comme rusting pour un manquement essentiel du langage peut mériter une smiley. D’autant que les polyfills posent un AUTRE enorme problème pour quelqu’un qui n’est pas expert (comprendre, qui ne passe pas 1h par jour à se tenir au courant) :

– quel polyfill utiliser ?
– dois-je le faire à la main ?
– dois-je plutôt utiliser une lib ?
– si oui, lodash, underscore, jquery ?

Pour des features de base, on est déjà obligé de prendre ce genre de décisions. Ce n’est pas une bonne chose du tout.

JavaScript 1.6, 1.7, ça n’existe pas. C’est des gens chez Mozilla, ils étaient bourrés (Brendan Eich a continué à boire même après avoir créé et shippé JS en 10 jours), ils ont donné des numéros de version, après le mot “JavaScript”, mais c’était pour rire (c’était lié au numéro de version de SpiderMonkey, moteur JS de Firefox). Seuls les numéros de spec d’ECMAScript ont un sens un peu sérieux.

Oui encore un truc super chiant. Tous les moteurs ont leur numéro de version qui n’est pas calqué sur la spec ECMASCRIPT et c’est du travail de trouver les correspondances. Car Javascript est aussi un langage mal standardisé. Comme je le disais ailleurs, les différents implémentation de Python ont beaucoup moins ce problème. La standardisation a été bien mieux foutue. Après, le Javascript se tape le boulet IE et donc la vision très conceptuelle de collaboration de Microsoft donc ceci explique cela. Et c’est plus dur de faire collaborer des grosses boîtes que des structures open source.

.map tu peux l’utiliser depuis des années. Les array compréhension, ça marche sur Traceur

Nope, pas sur IE8 sans polyfill, qui fait 30% de notre trafique.

Tiens https://gist.github.com/lukehoban/9303054#default–rest–spread
J’ai utilisé ça en TypeScript (mais ceux qui préfèrent Traceur peuvent aussi choisir ça) sur un vrai projet qui tourne sur de vrais mobiles il y a presque un an.

C’est aussi une tendance actuelle

Ah mais il faut utiliser coffeescript !
Oui donc pas Javascript. Point made.

Jeremy Ashkenas, inventeur de CoffeeScript le décrit en disant “it’s just JavaScript”. Je dis ça…

Oui et microsft a dis “it’s not a bug, it’s a feature”. Une phrase marketing n’est pas un fait. Le coffescript ne tourne pas nativement sur les navigateurs ou sous node.

Et le pire, c’est que j’ai horreur de la syntaxe de coffeescript. C’est une amélioration pour plein de chose, mais un grand pas en arrière pour d’autres choses. Par exemple, la déclaration des fonctions a été tellement dépouillées de délimiteurs que le cerveau est obligé d’analyser le contexte de l’instruction pour comprendre ce qui se passe. Cela augmente fortement la charge cognitive lors de la lecture d’un code coffeescript, et on lit un code bien plus souvent qu’on l’écrit. Bref, j’espère que coffeescript ne gagnera pas. Je préfererais 100 fois qu’ils réparent les erreurs du JS et qu’on puisse l’utiliser proprement. Ce qu’ils sont heureusement en train de faire. Mais c’est lent.

Et si le Javascript pouvait aussi se taper des API synchrones, ce serait cool aussi. Parceque l’asynchrone, c’est hyper dur de former des gens dessus, et tout n’a pas besoin d’être async. En fait, à part pour la prog événementielle, on en a rarement besoin, donc comme paradigme par défaut, c’est chiant.

Aucune importance. C’est ce qu’on a, il faut vivre avec, bon gré mal gré.

Gros bisous,

David

Ouai. Snif. Calin.