Skip to content

Instantly share code, notes, and snippets.

@DavidBruant
Last active December 13, 2017 13:40
Show Gist options
  • Star 4 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save DavidBruant/9549803 to your computer and use it in GitHub Desktop.
Save DavidBruant/9549803 to your computer and use it in GitHub Desktop.
Réponse à Un gros Troll de plus sur Javascript sametmax.com/un-gros-troll-de-plus-sur-javacscript/

C’est quand Google a enfin pu donner des perfs décentes – c’est à dire celles qu’ont d’autres langage depuis une décennie – à Javascript que les gens ont envisagé de l’utiliser sur le serveur.

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".

Javascript (...) ne sert absolument à rien sans un framework côté serveur

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 ?

côté client il est parfaitement improductif sans une lib pour gommer les incompatibilités entre les implémentations.

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 ;-)

Au cas où vous ne l’aurez pas encore compris, je vomis sur Javascript. Mais je code avec, et j’offre même des formations dessus, car je suis pragmatique. Les besoins de l’industrie, l’inertie technologie et le contexte social / technique / économique dictent bien plus souvent les standards que nous utilisons que leurs qualités intrasèques. Sinon nous n’aurions pas utilisé le format .doc ou les VHS. En fait, je ne détesterais pas autant Javascript si je n’en avais pas besoin quotidiennement. Je le hais du plus profond de mon âme justement parce que c’est non seulement une contrainte inamovible de mon métier, mais en plus une tumeur que les chercheurs annoncent voir grossir de jour en jour. Avec le sourire, les connards !

Bienvenue dans l'humanité ;-)

Les experts recommandent d’éviter la moitié du langage

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 ?

En fait activer use strict dès que possible pour éviter l’insertion de ; automatiques.

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

Cependant, faites gaffe quand vous convertissez du code parce que :

=> a = 1
1
=> var a = 1
undefined

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.

Ah oui, et ne pas utiliser les mots clés new ou with pour vos propres libs. Si, si, on bannit carrément des mots clés, c’est écrit dans le livre.

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.

Faire du JS propre présuppose l’utilisation de design patterns En l’état, on ne peut pas écrire du JS propre.

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.

Au fait, vous avez déjà essayé d’expliquer le prototypage à quelqu’un ? Bonne chance !

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

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.

Si tu additionnes des choux et des carottes, faut pas s'étonner. Si des fois, tu es fatigué, utilise TypeScript pour aider avec la discipline.

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

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.

que vous pourrez utiliser sur tous les navigateurs d’ici 2056.

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

PASramètre Comment on fait ça en Javascript ?

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.

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...

Vous trouvez ça normal ? Vous trouvez que c’est le signe d’un BON langage ?

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

Gros bisous,

David

@MoOx
Copy link

MoOx commented Mar 15, 2014

Merci pour ces éclaircissements David :)

@bleporini
Copy link

N'étant pas un expert JS , je ne contredirais personne sur les corrections techniques que tu apportes!

En revanche, concernant l'article, il ne faut pas jeter le bébé avec l'eau du bain car le fond met en exergue la dictature du JS sur le web.
Côté serveur on a que l'embarras du choix du langage et bien d'autres que JS permettent d'implémenter une conception asynchrone.
Côté client, on a pas le choix, juste l'embarras! Au mieux tu peux utiliser un langage qui sera "transpilé" en JS, et les exemples sont nombreux: CoffeeScript, TypeScript, GWT, Dart, ScalaJS et sûrement d'autres que je ne connais pas.
Si autant de monde dépense de l'énergie (d'ailleurs Google l'a fait deux fois!) pour éviter d'avoir à coder directement du JS, cela semble révélateur. Donc au mieux pour nous autres développeurs, on peut souhaiter que l'avenir du JS soit d'être du bytecode pour navigateur, les VM JS ayant maintenant de bonnes performances.
Comme tu le soulignes, JS vient avec son héritage et son utilisation a énormément évolué en 20 ans alors que le langage non (ou peu), ce qui est également extrêmement regrettable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment