Un gros Troll de plus sur Javascript 110


Un commentaire très pertinent de Kontre m’a interpellé dernièrement : si Javascript est si pourri, pourquoi tout le monde s’y intéresse ?

TD;DR :

L’inertie technique.

Il faut bien comprendre que PERSONNE ne s’intéresse à Javascript directement. Les gens s’intéressent passionnément à la programmation Web. Et il se trouve que, concernant la programmation côté client, il y a QUE Javascript de disponible.

Quand Ajax est arrivé, des mecs brillants ont rendu le Web plus interactif. Et ils ont utilisé ce qui était implémenté partout : Javascript. Pas parce qu’ils aimaient Javascript. Pas parce que Javascript était un bon langage.

Parce que c’était la seule solution dispo.

Avant, personne ne s’intéressait à ce truc. C’était un langage de script kiddies pour faire des flocons de neige sur les pages HTML. Et donc tout le monde se foutait royalement que ce soit de la merde. IE l’avait implémenté parce que Netscape l’avait fait. C’était alors un gros hybride qui tentait de rassurer les codeurs C et Java. Javascript était marketing, jusque dans le choix du nom. Puis IE6 a gardé le pouvoir pendant 10 ans, et du coup, tout le monde a suivi.

Personne n’a réfléchi. Personne n’a vu venir l’explosion du Web. Personne ne s’est dit “les gars faudrait peut être faire attention, le status quo pue la merde”. A cette époque, ça n’avait pas d’importance, on a mis les efforts de guerre ailleurs.

L’heure du Web 2.0 a alors sonné, et là les business ont eu besoin de puissance de feu. Mais c’était trop tard, il n’y avait plus qu’un seul truc hideux de dispo pour la prog…

Google a utilisé massivement les pages dynamiques, et devant le constat des performances misérables de la seule techno qu’il y avait a dispo, il a pondu chrome, et sa VM Javascript ultra performante. Si on avait appliqué la même techno à n’importe quelle autre langage, on aurait obtenu 10 fois cette vitesse.

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. Encore une fois, pas parce que Javascript était une techno dont ils étaient fondamentalement amoureux.

Parce qu’ils voulaient éviter d’écrire deux fois le même code côté client et côté serveur et que toute tentative de générer du Javascript n’a pas été satisfaisante. Et aussi parce que le besoin de faire de l’asynchrone se faisait sentir et que les Dev clients n’avaient pas envie d’apprendre un autre langage. Ben oui, l’asynchrone, vous croyez que pas que ça existe que sur JS quand même ? C’est aussi vieux que les premiers compilateurs. Les Devs clients connaissaient déjà le JS, et ça faisait du DRY, alors pouet.

Personne. J’ai bien dit, personne ! Ne s’est jamais extasié devant l’incroyable ergonomie de Javascript. Devant sa facilité de debuggage. Devant la qualité de sa doc.

Dessin humoristique sur la recherche de travail

Cherche Dev Javascript pour travailler sur projet innovant dans une start up à fort potentiel de croissance.

Ruby est un langage innovant and fun.

Python est un langage ergonomique and riche.

Php est un langage avec une super doc et une communauté noob friendly.

Lisp est un langage puissant avec un paradigme fonctionnel de référence.

Go est un langage propre avec une gestion de la concurrence très performante.

Javascript est juste là par hasard. Il ne dépasse aucun des langages ci-dessus en terme de ses qualités propres. Sa bibliothèque standard est risible. Il ne sert absolument à rien sans un framework côté serveur, et côté client il est parfaitement improductif sans une lib pour gommer les incompatibilités entre les implémentations.

Les docs sur JS sont éparpillées sur le Web. Les tutos sont déchirés entre tant de versions et de frameworks qu’on se croirait dans un script des frères wachowski.

Des notions de base comme les closures sont encore obscures pour la plupart des codeurs Javascript, alors qu’elles peuvent ruiner les perfs de votre programme ou créer des bugs énormes. Les projets innovants en Javascript sont tous faits par des gens hyper compétents parce qu’innover dans ce langage, ça demande une discipline de dingue tellement il offre d’opportunité de merder.

Javascript est un hack qu’on se traine.

C’est un bug legacy.

C’est un virus préinstallé dans les navigateurs.

Photo du film le dictateur

Ma Fureure, vous ne voulez pas utilisez le C# plutôt ? Naïne, toutes nos troupes sont déjà tatoués sur la fesse gauche, on va devoir y aller comme ça.

Oui il y a des produits à base de Javascript fantastiques. Oui les innovations techno Web actuelles intéressantes tournent toutes autour de Javascript de près ou de loin. Et oui, vous devez définitivement mettre les mains dedans parce que le monde du dev avancera en dépit de vos goûts. En tout cas, en dépit des miens, j’en ai bien conscience.

Mais ceci ne se fait pas grâce à Javascript. Ceci se fait en dépit de Javascript. Malgré le fait que c’est un langage au typage pourri, malgré son scoping dégueulasse, malgré l’absence des facilités modernes les plus basiques comme le passage d’arguments avancés ou un slicing décent.

Parce qu’il y a des gens très (TRÈS) bons qui ont eu Javascript comme contrainte, et qui en ont tiré le meilleur. Et c’est pas faute d’avoir essayé autre chose (Flash, GWT, Haxe…). Ces mecs sont incroyables, ce sont des Dieux vivant, Amen to them, mais Javascript reste à chier.

Et on va se le coltiner encore très, très longtemps.

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 !

Le VB est peut être pire que le JS, mais je m’en branle, je n’ai pas à y toucher.

Après cet argumentaire, je précise que je ne mettrai pas de tampon sur les commentaires, parce que je comprends bien que je ne peux pas lâcher une caisse et demander à tout le monde de respirer à fond et ne pas se plaindre.

Néanmoins, puisque cet article à des vocations thérapeutique – vous êtes tous un peu mes psy au fond (la confidentialité bloggeur / lecteur, ça marche ?) – voici un listing de tout ce que j’abhorre dans le Javascript.

)

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

Il y a tellement de merdes dans JS que les plus grands experts s’accordent sur le fait que la première chose à faire est d’apprendre la liste des choses à ne PAS utiliser.

En fait, Douglas Crockford lui même a écrit un bouquin complet rien que sur le sujet.

Je n’ai pas tout en tête, mais en vrac…

Ne pas utiliser l’opérateur ==, parce que :

''        ==   '0'           // false
0         ==   ''            // true
0         ==   '0'           // true
false     ==   'false'       // false
false     ==   '0'           // true
false     ==   undefined     // false
false     ==   null          // false
null      ==   undefined     // true
" \t\r\n" ==   0             // true

Notez que même === ne retire pas toutes les ambiguïtés :

> var a = { "abc" : 1 }
> a[[[["abc"]]]] === a["abc"]
true

Ne pas utiliser parseInt sans préciser la base sinon :

> parseInt('06')
6
> parseInt('07')
7
> parseInt('08')
0
> parseInt('09')
0
> parseInt('10')
10

Bien se souvenir d’utiliser var partout. En fait activer use strict dès que possible pour éviter l’insertion de ; automatiques.

Et ne pas utiliser la syntaxe de déclaration de variable sans var. Cependant, faites gaffe quand vous convertissez du code parce que :

> a = 1
1
> var a = 1
undefined

Encore une connerie. Mais vous avez l’habitude :)

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.

Phot d'un gant de vaisselle avec des pansements

Ce gant est fantastique, si vous ignorez tous les trous il vous permettra de faire la vaisselle aussi bien que tous les autres gants. Comme ça vous êtes jardinier ? Remarquez, j'avais créé le produit pour faire des touchers rectaux à la base, donc il est adaptable !

Faire du JS propre présuppose l’utilisation de design patterns

En l’état, on ne peut pas écrire du JS propre. Écrire la plus simple instruction Javascript est déjà écrire du code sale car toute variable devient globale. Il faut tout foutre dans un conteneur quelconque, souvent dans une fonction anonyme immédiatement appelée, mais il y a d’autres techniques (services avec injection de dépendance dans angularjs par exemple).

Pour être honnête, on commence à peine à savoir écrire des grosses applis Javascript propres côté client depuis quelques années. Ca a pris un temps fou de trial / error pour gommer petit à petit tous les aspects guedin de la techno et obtenir un socle utilisable.

Un autre truc : personne ne s’est mis d’accord sur l’utilisation des objets : prototypage, simulation d’héritage, instanciation ou pas, composition uniquement ? En tout cas vous devez en choisir un, et ne pas le merder.

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

Non seulement c’est du typage faible, mais en plus c’est du typage con

J’ouvre Firefox, je tape:

> {} + {} // Ceci n'est effectivement PAS un nombre
NaN
> {} + [] // logique IMPARABLE
0
> [] + {} // fuck la commutativité
"[object Object]"

Et après on va me dire que c’est juste l’API DOM qui est incohérente selon les implémentations. Mais non, tenez, même ça c’est cohérent. Je fais la même chose sous Node 0.8 (sur lequel j’ai par ailleurs déjà râlé):

> {} + []
'[object Object]'

On pourrait continuer longtemps avec ces saloperies, mais je finis sur un exemple qui résume bien tout le merdier :

> '5' + 3
'53'
> '5' - 3
2
> "Vous en étiez à... peau de couilles je crois ?" + 1
'Vous en étiez à... peau de couilles je crois ?1'
> "Vous en étiez à... peau de couilles je crois ?" - 1
NaN

Et vous pouvez toujours vous dire que si vous faites attention, vous n’aurez pas de problème, mais ça a des répercussions sur TOUT le langage, dans les recoins les plus vicieux :

> Math.min(null, 1234)
0
> Math.min('null', 1234)
NaN
> Math.min('1', 1234)
1

L’élégance d’un chameau bourré à la villageoise

On se déchaîne

Ruby :

coucou = """Ceci est une looooooooooooooooooooooooooooooooooooooooongue chaine !
Sur plusieurs lignes !
Et une autre !
Et une autre !
J'adore les sauts de ligne, c'est tellement lisible !!!
"""
puts coucou

Python :

variable = "foo"
coucou = """Ceci est une looooooooooooooooooooooooooooooooooooooooongue chaine !
Sur plusieurs lignes !
Et une autre !
Et une autre !
J'adore les sauts de ligne, c'est tellement lisible !!!
Et en prime voila une variable : %s !
""" % variable
print coucou

Javascript :

var variable = "foo";
var coucou = "Ceci est une looooooooooooooooooooooooooooooooooooooooongue chaine !\
Sur plusieurs lignes !\n\
Et une autre !\n\
Et une autre !\n\
J'adore les sauts de ligne, c'est tellement lisible !!!\n\
Et en prime voila une variable : " + variable + " !"
console.log(coucou)

C’est vrai que manipuler des chaînes, c’est pas la PUTAIN D’OPERATION INFORMATIQUE LA PLUS COURANTE DANS LE PUTAIN DE MONDE. PUTAIN.

Séquence émotion

Une autre opération qu’on fait 100 fois par jour : créer des séquences (fichiers, settings, données en base, etc), en récupérer une partie, itérer dessus, les transformer, etc.*

Soit la liste :

l = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

Récupérer les carrés des nombres paires de la moité supérieure de la liste ?

Python :

l = [x*x for x in l[5:] if x %2 == 0]

Ruby :

l = l[5..10].select{|x| x % 2 == 0 }.collect{|x| x * x}

Javascript (Ma que, gracieux comme oune popotamé):

var new_list = []
l.splice(0, 5)
for (var i = 0; i < l.length; i++) {
    if (l[i] % 2 == 0) {
        new_list.push(l[i] * l[i]);
    }
}
l = new_list;

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

Array.map arrive avec JS 1.6 et les arrays comprehensions avec la 1.7, que vous pourrez utiliser sur tous les navigateurs d’ici 2056. Ou alors juste sur le serveur, mais si c’est pour pas avoir le même code sur le client ou le serveur, pourquoi ne pas utiliser un langage qui possède tout ça et bien plus depuis 5 ans ?

DéLire

Lire un fichier ligne à ligne ? Une opération vraiment rare et compliquée…

Python :

for line in open('fichier'):
    print line

Ruby :

File.foreach('/etc/fstab') {|x| print x }

En JS… Heu, enfin avec NodeJS:

var fs  = require("fs");
fs.readFileSync('./input.txt').toString().split('\n').forEach(function (line) {
    console.log(line);
});

Ah oui, il faut installer un MODULE SUPPLEMENTAIRE pour gérer tout autre encoding que les variantes d’unicode.

PASramètre

Comment on fait ça en Javascript ?

def fonction(param, param2="valeur", **params):
    print param, param2, params
 
fonction(1, autre_valeur=2)

On fait pas. Du coup on se retourne vers la bonne vieille technique de “j’attends un objet en paramètre et je le fusionne avec un autre objet qui a mes valeurs par défaut”.

Photo d'un homme avec un chapeau giraffe

Dev JS qui essaye de comprendre pourquoi le callback anonyme de sa promise n'a pas rebindé correctement son this dans une closure . Oui cette phrase a parfaitement du sens en Javascript.

Javascript ça marche partout !

Node ne tourne pas sous Windows, excluant de sa pool d’apprentissage les 3/4 des foyers de la planète. Parce que je sais pas pour vous, mais moi, quand j’ai appris la programmation, j’ai pris le premier ordinateur qui m’est tombé sous la main et j’ai essayé. Parce que je n’y connaissais rien. Je ne me suis pas soucié de l’OS.

On me signale dans la comemntoreillette que j’ai dis une connerie.

Ah oui, et sans node, le Javascript on en fait quoi déjà ? Des Interface graphiques poussées comme avec QT ? Du calcul scientifique de haut niveau comme avec Scipy ? Du sys admin windows comme avec pywin32 ?

Ah non, en fait, on fait rien.

Deux structures de données devraient suffire à n’importe qui

Donc, vous avez les arrays. Et les objets. Et pour le reste, vous vous démerdez.

Des sets ? Des heaps ? Des tuples ? Des views ? C’est pour les petites bites tout ça. C’est tellement plus rigolo de réimplémenter la roue.

D’ailleurs, même les roues fournies sont carrées, juste au cas où vous vous sentiez trop à l’aise.

Qui se souvient des params de splice pour le slicing ? Vous, moi ? Nope. Jamais. C’est con parce que c’est AUSSI la seule manière d’enlever un élément au milieu d’un array sans laisser une case vide. On allait pas coder ça, ça sert pas souvent…

En parlant de trucs biens faits, mélanger une structure de données qui fait objet ET hashmap, quelle bonne idée ! Encore plus con que de mélanger les listes et le mapping en PHP. Tu veux récupérer les attributs de ton objet ? Paye ta boucle (et fait gaffe à la chaine de prototypage). Tu veux updater ton dico avec le contenu d’un autre. Écris ta méthode toi-même, c’est un truc dont on a pas besoin IRL.

Et tout est comme ça. Encore une fois, le langage tout seul te laisse à poil, il y a toujours un machin à recoder à la main à moins d’installer une (voir 2) libs pour avoir ne serait-ce que les trucs de base : faire un hash md5, générer un ID unique, filtrer des doublons sur un objet qui n’est pas une chaîne, et mon grand favoris, la division entière.

Ouai. La division entière n’est pas incluse de base en JS.

Or le JS, c’est typiquement le truc pour lequel on veut charger le MOINS DE CHOSES POSSIBLES pour que ta page s’affiche vite. Du coup on passe notre temps à créer des solutions de contournement avec de la mignification, des CDN qui aident à optimiser l’usage du cache, et tout le bordel.

Ah mais il faut utiliser coffeescript !

Oui donc pas Javascript. Point made.

Le langage est tellement à chier qu’on a inventé un autre langage pour le générer et pas avoir à s’en soucier. Et ensuite, on a inventé des libs pour automatiquement faire cette compilation pour le dev, et les outils pour le déployer. Et on a inséré dans les navigateurs une nouvelle technologie : le source map, parce que sinon c’était trop chiant à débugger. Qu’il faut aussi déployer pendant le dev. Et former les gens dessus.

Vous trouvez ça normal ?

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

Ouai mais ça fait un seul langage côté server et client

Oui, c’est pour ça que les gens s’y mettent. Encore une fois, ça n’a rien à voir avec les qualités de Javascript. Ca reste de la merde en boîte, mais de la merde unifiée.

Et encore, car si on a bien le même langage, on est loin d’avoir le même code. Le code serveur et le code client est, sauf dans les frameworks avancés comme météorjs, très peu partagé au final. Surtout que vous n’avez PAS la même version du moteur Javascript côté serveur et côté client.

Les libs externes bien conçues marcherons de la même façon par contre, ce qui est un avantage.

Encore une fois, la question n’est pas “est-ce que les gens doivent utiliser Javascript ?” La réponse à cette question est oui. Pas le choix.

Mais on ne l’utilise pas parce que c’est un bon langage. On l’utilise parce que c’est le status quo. Qui est tout pérave.

Arrête de baver et donne nous ta solution !

J’ai pas de solution parce qu’il n’y en a pas. C’est trop tard. Le Javascript et là et on l’a dans le cul. D’où ma frustration. La 1.7 va dans la bonne direction, mais le temps qu’elle soit adoptée partout…

Par contre si ce n’est pas trop demandé, arrêtez de mettre du Javascript partout. Limitez la contamination. Vous n’avez pas vu “28 jours plus tard” ? Il faut isoler le problème avant que la pandémie ne dévore l’humanité. Il y a des tas d’alternatives : Python, Ruby, Clojure, Go, Lua, etc.

Si vous faites un langage de scripting embarqué, si vous faites un outils de déploiement, si vous faites un premier binding pour votre outil… Ne donnez pas la prio à cette bouse. Quand je vois Gnome ou QT adopter le JS pour leur scripting, ça me met dans une rage folle. C’est de la connerie pure. Bordel, il y a un site appelé 99 bottles of beer avec des milliers de langages. Vous avez le choix !

C’est bien beau d’avoir le même langage partout, mais si c’est pour se trainer un boulet… Vous ne travaillerez pas plus vite.

D’ailleurs, vous n’aurez jamais le même langage partout. Vous aurez toujours à apprendre et utiliser 2 ou 3 langages. C’est un fait de la vie. Les humains ne parlent pas tous anglais ou chinois. Et les codeurs ne coderont jamais dans un espéranto, fusse-t-il fantastique.

Je sais, je sais, quand on vient du C, Javascript parait si facile, on se dit que c’est une amélioration de l’ergonomie au prix de la performance. Mais non, c’est comme acheter une 2 chevaux pour aller en ville à la place de son tracteur, alors qu’on vous avait proposé une smart ou une mini pour le même prix.

Par ailleurs, il y a une vie en dehors de la prog Web vous savez.

Si il n’y a pas de solution, ferme ta gueule alors

C’est mon blog, je fais ce que je veux. Na.

Photo d'un homme ayant son aspirateur coincé dans un ascenseur

Sam, passant directement du stade de la colère à la dépression dans son dueil de la programmation Web


Leave a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

110 thoughts on “Un gros Troll de plus sur Javascript

  • Uhsac

    Petite erreur je crois

    Sinon nous n’aurions pas utilisé pas le format .doc ou les VHS

  • Syl

    Putain Sam, t’as vraiment le chic pour me faire tomber de haut!

    Je me suis récemment mis au développement web, et après de (très) grosses réticences envers le JS, que j’ai toujours trouvé syntaxiquement dégueulasse au possible, j’ai fini par m’y mettre.

    Au début, je cherchais tous les moyens possibles pour éviter le JS (avec des Brython ou autres rapydscript), puis je me suis dit qu’après tout, je n’avais pas le choix et que si on arrivait à porter le moteur d’Unreal en Js, c’est que j’étais de mauvaise volonté et qu’il fallait que je me sorte les doigts du fion.

    Bref, je me suis reconditionné pour aimer le JS comme Winston pour Big Brother…

    …mais alors là!!!! Quand je vois les exemples que tu as mis dans ton article ( le ‘5’+3 et ‘5’-3 entres autres)….non, je peux pas, c’est au dessus de mes forces!! Je peux pas coder en JS!!!

    J’ai d’abord cru à une blague, et non, c’est bien vrai!!

    Comment des boites comme Google, qui ont une influence délirante sur le web, qui ont la capacité de réunir des mecs comme Guidon Van Rossum, Rob Pike, et Ken Thompson, n’ont pas pu pondre un remplacement à cette bouze infâme???

    Non, là, vraiment, je comprend pas!

    Et comme tu disais, la contamination est déjà trop répandue…même si on passait à autre chose, va dire aux milliers de dev web de re-coder leurs libs/sites dans un autre langage!

    C’est désolant…

  • Yosko

    Je ne suis pas un grand codeur. Comme tout le monde j’écris de la merde. Pourtant, j’aime bien m’appliquer, organiser mon code, faire en sorte qu’il respire le propre. Au moins à mes yeux.
    Je ne comprenais pas pourquoi je n’arrivais pas à le faire en Javascript, alors que j’avais su le faire en C, C++, PHP, et même VBA (beurk).

    Tout ça pour dire : merci. Merci de m’aider à comprendre quelque chose que je ne touchais que du bout des doigts depuis quelques temps. Et merci pour le “Dev JS qui essaye de comprendre pourquoi le callback anonyme de sa promise n’a pas rebindé correctement son this dans une closure” :D

    Comme Syl, j’ai voulu l’éviter le plus longtemps possible, mais m’y suis mis récemment, et je commence à comprendre ma douleur petit à petit…

  • moato

    Arrg, ça donne pas envie de s’y mettre :p
    Quels sont les dèsavantages d’utiliser brython où autre langages de substitution?

    sinon:
    Go est un propre -> Go est un langage propre

  • cym13

    Tant qu’on est à peu près dans le sujet, j’ai le sentiment que c’est exactement la même chose avec java hors du web. Y-a-t-il vraiment des avantages à utiliser java (hormis le fait que tout le monde pousse à l’utiliser) ? (hors troll c’est mieux même si je ne crache pas sur une occasion de rigoler)

  • Violete

    Perso je concatène toujours avec le . comme ça pas de soucis mais j’avoue qu’avec le + c’est abuzay. Après ça vient du typage. Perso je préfère ça à celui du java où on passe son temps à ce demander si on va mettre des chiffres ou des lettres dans sa variable… Toujours trouvé ça con aussi.
    Après pour la non gestion des fichiers, j’avais lu un truc comme quoi ça avait rapport avec la sécurité chais plusquoi (ça fait longtemps me rappelle pas trop donc je vais éviter de développer sinon il risque de sortir de ma bouche un immonde flot de conneries :().

  • Topic

    un script des frères vachoski wachowski

    Ouais mais ça fait un seul langage côté serveur et client => News en rapport.

    @Syl Comment des boites comme Google, … n’ont pas pu pondre un remplacement à cette bouze infâme??? => Il l’a fait avec Dart

  • Cédric

    Pour info, NodeJS éxiste pour windows.

    Sinon oui, tout est très vrai, we’re fucked, et si d’autres alternatives envisagées par certains pourraient être un point de départ à un changement progressif (NaCl pour n’en citer qu’une), la réticence (oui je suis poli) des membres du w3c de l’ecma group rend pour le moment tout mouvement dans ce sens improbable. Pour le coup je me rangerais aujourd’hui plutôt dans le camp de Matthew Butterick qui appelle carrément au démantèlement du W3C (attention l’article est trèèès long et porte principalement sur la typographie) et qui propose de remplacer tout ce bazar de standardisation foireuse, où chaque acteur fait ce qu’il veut dans son coin et freine les apports des autres, par des implémentations libres gérées par la communauté, les gros acteurs pourraient continuer à se la mesurer sur les performances et tout le monde serait content.

  • Chassegnouf

    Ce qui précède est un message de la part du représentant officiel de ceux qui viennent ici pour les topics de cul -_-

  • Sam Post author

    Merci à tous pour vos corrections. Je réponderai aux comments un peu plus tard, steam est de nouveau disponible :D

  • Bre

    Dart = support uniquement Chrome ou les autres browser via cross compile to JS
    Donc pas encore la solution parfaite, loin de la

  • lieo

    Uhm, pour utiliser le Js tous les jours, il y a du vrai dans son fonctionnement alambiqué et éloigné face aux langage “normaux”.
    Mais le tableau n’es pas si noir que ce qui est décris, une fois qu’on a pris le coup, tout à une raison.

    Par exemple le “+” qui ajoute string/nombre, le “-” qui soustrait que nombre (qui ce retrouve déjà dans d’autre langage).
    Ou encore le 0 + “1” qui fais un parseInt automatique, le parseInt qui par défaut utilise la base qui semble le plus logique (sachant que “06” faut le chercher, car il faut lui donner une string).

    Au delà de sa syntaxe pas forcément concise face à du Python qui a des outils très puissants et du code qui peu être très court, il reste lisible et clair (et il existe tellement de lib’ puissante pour combler les fonctions manquante comme underscore, require, et j’en passe).
    Pour la doc aussi, il y a Mozilla qui fait un excellent travail, jQuery qui reste unifier (malgré quelque petites fonctions qui bouge).

    Il a l’avantage d’être rapide pour des tests, tu ouvre ta console chrome et tu code ce que tu veux, t’as accès à tes variables (si tu les mets en global pour le debug).
    T’as plusieurs outils pour pister la mémoire, débuguer, vérifier les erreurs.

    J’ai à ce jour croisé quasi aucun langage, qui d’un clin d’œil ce lance, t’écris deux trois bouts de code et ça fonctionne.
    Après je peux comprendre qu’on ne puise pas l’aimer, il a rien d’un vrai langage, tout peut sembler bidouille, mais ça à un coté amusant.

    Ps: je sais j’ai fais un gros paver, mais fallait bien que quelqu’un le défende un peu ! :D

  • Vincent

    SALUT! J AI TROUVE SA GENIAL>!!

    UNE PETITE QUESTION?!

    SI TU TRAVAILLAIS TOUT LES JOUR AUTEN SUR PHP, NAURAI TU PAS LE MEME DEGOUT??

    PT ETRE TU ES SIMPLEMAN AIGRI!! ^^

    a+

  • Réchèr

    Y’a qu’à coder une VM python en javascript.

    Les gens qui coderont ça vont en chier, et perdrons probablement leur cerveaux, mais une fois fait, ce sera tout bénèf’ pour le reste du monde.

  • IxDay

    Hop, hop, hop

    Et bien, moi je passe par là pour cracher dans la soupe. J’ai évidemment une grosse préférence pour python, et la version 3.4 va juste tout déboiter. Mais j’aime aussi le JS (pas sur la tête), par contre je ne l’aime qu’avec angular, donc pour ceux qui râlent, je les invite à essayer ce magnifique framework (qui est une perle d’ingénierie), après ça l’utilisation de jQuery vous filera des boutons.

    Ah oui, malheureusement pour vous après le dev client, puis le dev serveur, voici le dev desktop, qui en plus se paye une pub de malade avec ceci ceci ou encore ça voir même celui-ci, comme on dit Haters gonna hate

    Voili Voilou, allez gros poutou

  • Geekingfrog

    Très bon article !! Et pourtant je suis à temps plein node.js. Et je répète à longueur de temps ce que tu racontes dans cet article.
    Je pense que JS n’a eu qu’un truc réussit: les fonctions (closures).
    Et pour ceux qui veulent se moquer de JS, le mini talk hilarant de Gary Bernhardt: https://www.destroyallsoftware.com/talks/wat

    Après, avec ES6, il va y avoir beacoup de truc mieux (ça va ressembler pas mal à python nottament), mais comme tu dis, l’adoption va prendre du temps, ou alors tu passe par une étape de compilation. Le traceur de google permet nottament d’écrire du JS next-gen et de le compiler vers du natif.

    Ma prédiction c’est que JS va disparaitre d’ici une dizaine d’année, pour être remplacé par d’autres languages (typescript, dart, ???). De façon interne, ces languages viseront probablement toujours JS (ou asmJS) mais ça sera devenu invisible pour la majorité, et javascript sera vraiment devenu le nouvel assembleur.

  • Syl

    @Topic: Merci pour la découverte! J’ai beau détester Google pour tout un tas de raisons, il faut reconnaitre qu’ils sont doués pour réunir les talents (bon évidemment, c’est une question de moyens). Je viens de me mettre au Go et faut avouer que pour ce qui est de la rapidité de compilation, de la propreté/standardisation du code et de la gestion des co-routines, c’est bluffant! Du coup, c’est avec enthousiasme que je vais m’intéresser à Dart!

    @Bre: Apparemment, ça a évolué et ça tourne partout.

  • scaringella

    Et oui ….. tout d’accord ….
    J’ai fait du pascal su pc à l’école; OK.
    J’ai fait du C sur unix après; OK on fait TOUT ce qu’on veut.

    Y zont voulu me faire du C++; Pour quoi faire? J’ai dit. C c’est mieux, et c’est pas à chier comme C++; VA CHIER j’ai dit.

    Y zont voulu me faire faire du … Java … J’ai dit VA CHIER c’est de la merde du même ordre que C++.

    J’ai fait du python avec du QT et toutes les libs de malades. J’ai dit: tiens un langage, un vrai, un tatoué.

    Y zont voulu du JS. J’ai dit va chier!

    Y zont voulu un système de contrôle. J’ai cherché. J’ai fait le proto en Erlang en deux semaines sans avoir connu le lanagage avant ni avoir fait de fonctionnel avant. J’ait dit: tiens ça fait trois langages qui servent à quelque chose. Y ZONT PAS VOULU! Y ZONT TOUT FAIT EN C++ ET EN JAVA en …. 2 ans ….

    YA RIEN A FAIRE QUAND LES CONS SONT LES PLUS NOMBREUX!!! ET C’EST LE CAS!!!!

    Et le HTML ET LE CSS C’EST PAS DE LA MERDE EN BOITE ???

  • Syl

    Et là, naïvement, je cherche “Angular Dart”, et je tombe sur….AngularDart!!!!!

    Et ben voila! J’ai trouvé mon trio gagnant: Python+Go+Dart.

  • Erase

    Le Javascript :’)

    Le truc qui a fait que je me suis mis au dév Oueb pour finalement en faire mon taf.

    Le truc qui me fait le plus cogiter, frissonner, qui fait que merde “chui fier de mon ptit pâté d’code”.

    Le truc à partir du quel j’ai pu faire mes projets les plus fabuleux.

    Le truc qui fait pleurer mes yeux quand je vais sur des forums d’entre aide oueb.

    Le truc sur lequel je bossais avec mon laptop sur les genoux lors de mon repas de mariage.

    Et pourtant, le truc que j’utilise le moins souvent au quotidien.

    Le JS, c’est comme la sodomie. Pour être efficace, ça doit être avec utilisé parcimonie, dans un cadre d’utilisation défini, mesuré et contrôlé (et avec une petite tape sur les fesses).

    Merci Sam pour ce fabuleux article qui balaye mine de rien un large spectre. L’ensemble, historique-technique-spécificité-retours perso donne beaucoup de cohérence.

  • nicoo

    Sinon, il y a Eliom, un langage statiquement typé, basé sur OCaml qui permet d’écrire le code client et le code serveur ensemble, et le tout est compilé vers du code natif pour la partie serveur, et vers JS pour la partie client.

    Ça permet d’avoir des trucs assez cools ; par exemple, lorsqu’on génère du HTML, le système de type permet de garantir qu’on produit du HTML5 valide, conforme aux recommendations du W3C.

  • Eliot

    Merci pour cet article et les bouts de codes. Je détestais déjà JS, mais je ne savais pas que c’était à ce point là…

    A quand un article sur le PHP et ses limitations (par rapport aux concurrents actuels) ?

  • Bronco

    J’ai ri, mais j’ai ri… mes collègues de boulot se demandaient pourquoi ^^
    Je suis assez de l’avis de Yosko.

    C’est vrai que le comportement de JS te conduit parfois à des recherches indianajonesques pour trouver ce qui couille…

    Javascript: (nom commun) “langage de programmation dans lequel ce qui devrait logiquement fonctionner ne fonctionne pas sans que la logique ne puisse vous permettre de comprendre pourquoi.”

  • Erase

    Mais non Bronco, ‘faut simplement voir les choses différement…

    Par exemple, un truc qui te parait improbable et/ou impossible à jeun te semblera beaucoup plus logique une fois bourré. Pour le JS, c’est pareil.

    Conclusion : pour bien développer en Javascript, développons bourré. Si si, ça marche.

  • Zanguu

    Cool l’article, mais il est où le troll ?
    Parce que là y’a rien qui porte à polémique, tout le monde est bien d’accord avec toi… A part peut être lieo qui a voulu faire le troll du troll.

    @lieo, sinon tu installes python (et si tu prend python portable c’est aussi long/complexe que d’installer un navigateur), tu utilises le IDLE et tadaaa, tu peux direct tester tes bouts de code.

  • openhoat

    Ca pique aux yeux :

    “PERSONNE ne s’intéresse à Javascript directement” => si si, on est nombreux depuis 2 ans à coder du JS hors navigateur.

    “C’était un langage de script kiddies pour faire des flocons de neige sur les pages HTML. Et donc tout le monde se foutait royalement que ce soit de la merde”
    On l’utilisait effectivement comme un skid, mais c’est l’usage qu’on en faisait qui était de la bouse, pas nécessairement le langage lui-même.
    Il y a aussi pas mal de skid avec python ou ruby, en fait avec tous les langages un peu sympa, assez puissants, rapides et faciles (ce qui élimine souvent Java)

    “Javascript était marketing, jusque dans le choix du nom” => oui le nom est une erreur historique, génératrice de confusions, mais bon c’est qu’un nom on s’en moque aujourd’hui que ça s’appelle MespompesScript

    “Si on avait appliqué la même techno à n’importe quelle autre langage, on aurait obtenu 10 fois cette vitesse.” => affirmation vague, non vérifiable et gratuite… (à peu près la même chose avait été dite en 1996 sur les VMs Java, on voit où ça a mené)

    “Devant sa facilité de debuggage. Devant la qualité de sa doc.” => je ne me suis jamais extasié devant la facilité de debuggage de n’importe quelle techno (c’est déjà arrivé à quelqu’un ?), c’est un leure et un argument massue souvent mis en avant sans élément objectif de comparaison (par exemple y a-t-il réellement plus de bugs avec JavaScript…); quant à la doc je ne comprend pas le point ou alors il faudrait définir “qualité”. On est sur le registre de l’impression… ce qui ne diminue pas l’intérêt du propos, mais c’est juste subjectif.

    “Sa bibliothèque standard est risible. Il ne sert absolument à rien sans un framework côté serveur, et côté client il est parfaitement improductif sans une lib pour gommer les incompatibilités entre les implémentations” => le côté éclaté de l’éco-système est justement un avantage.
    Avoir tout dans le langage serait une erreur, en fait je retournerais l’argument : quitte à utiliser moult frameworks et libs (c’est une réalité quelque soit le langage), autant que l’API portée par le langage soit la plus légère possible.
    Reste l’aspect cross-browser, oui c’est un problème (qui diminue avec le temps), mais si on avait remplacé JS par un super autre langage quelqu’un me dit dans l’oreillette qu’on aurait eu les mêmes problèmes, liés en fait aux éditeurs de navigateurs.

    “Les docs sur JS sont éparpillées sur le Web. Les tutos sont déchirés entre tant de versions et de frameworks qu’on se croirait dans un script des frères wachowski.” => oui internet, le logiciel libre, l’open source, tout ça c’est le bordel et ça ne convient pas à tout le monde.

    “Javascript est un hack qu’on se traine.” => je trouve ça plutot valorisant. aucun rapport mais l’email aussi…

    “Malgré le fait que c’est un langage au typage pourri” => merci pour l’explication on comprend mieux d’un coup
    “…comme le passage d’arguments avancés ou un slicing décent.” => pas de souci pour le passage de paramètres avancé, il suffit de le coder une fois avec ces doigts.

    “Et on va se le coltiner encore très, très longtemps.” => je l’espère sincèrement, on se coltine bien Java depuis 18 ans.

    En réalité, JS est un langage exigeant faussement facile qui nécessite d’aimer le bricolage, l’artisanat, et ce n’est pas contradictoire avec l’industrialisation, la productivité et la qualité (non non ce n’est pas sale).
    C’est aussi bizarrement l’un des langages les plus stables qu’on ait connu.
    Mais je comprend qu’on puisse ne pas aimer, dans ce cas il suffit de dire “moi j’aime pas”.
    S’agissant de Douglas Crockford, ce qu’il dit ou pense est de moins en moins parole d’évangile, ça l’a été mais maintenant il y a d’autres voix, et Crockford est loin de faire l’unanimité (exemple avec jslint et jshint).
    Cet article est basé sur une vision qui est restée campée sur le JS du navigateur des débuts, ce qui explique pour partie le ressenti négatif.
    Les pratiques de dev JS ont beaucoup changé, les codeurs aussi et se sont adaptés.

  • Erase

    @openhoat > Tu as eu la patience de l’explication que je n’ai pas eu. Réponse pertinente qui rejoint totalement ma position.

    “En réalité, JS est un langage exigeant faussement facile qui nécessite d’aimer le bricolage, l’artisanat, et ce n’est pas contradictoire avec l’industrialisation, la productivité et la qualité (non non ce n’est pas sale).”

    <3

  • Sam Post author

    @cym13 : pour Java, difficile de le dire. On peut tout faire avec, ses perfs sont maintenant excellentes et il y a un grand pool de dev. Mais que peut on faire en Java qu’on ne peut pas faire plus facilement et aussi bien avec une autre techno ? L’intégration d’outil corporate et la prog android peut être, mais après…

    @Mathieu : j’en doute. Dart est très très jeune, le temps qu’il devienne aussi mature que le reste des outils, ils se seront amélioré aussi.

    @lieo: dans tous les langages haut niveau tu écris 3 bouts de code et sa fonctionne.

    @openhoat: si on retire nodejs, est-ce qu’honêtement du coderais en Javascript à part dans le browser ? Pourtant il y a d’autres implémentation comme rhino. Tu ne t’interesse pas à JS pour le JS. Tu t’y interesse pour nodejs.

    C’est normal, NodeJs est un produit fantastique. Mais c’est confondre nodejs et javascript comme certains confondent DOM et javascript. NodeJS est un très bon produit, ça ne rend pas javascript meilleur pour autant. Et ça va à l’encontre de l’argumentation “c’est bien le coeur est léger” parceque finalement tu as une dépendances comme tous les autres : nodejs.

    De plus, tu dis t’y intéresser pour des choses “dehors du navigateur”. Mais on est très loin en JS de faire ce que font les autres langages : la 3D pour le cinéma, du processing de grand nombre pour les banques, des centaines de scripts d’admin système, des utilitaires graphique pour windows, des systèmes de régulation de réseaux pour le société de transport, des pilotes de périphérique, de l’embarqué, de la simulation biologique…

    Encore une fois, en dehors de nodejs et de la prog web, personne ne fait intensément du JS.

    Evidement, il y a bien quelques projet ici et là mais en perl 6 aussi.

    Après qu’il y ai des binding js pour tout, je suis 100% pour. Mais c’est pas la première techno à adapter.

    Quand à l’affirmation qu’on aurait le mêmes problèmes d’implémentation disparates avec une autre techno, je dis non.

    Python possède des tas d’implémentations : pypy, iron python, jython, etc. Elles ont un haut degré de compatibilité car la politique autour du developpement du langage et sa standardisation (à travers des PEP) a été très bien faite.

    Javascript ce n’est pas juste un langage mal foutu, c’est un standard très mal dirigé.

    Ta citation de “on code le passage d’argument une fois et c’est bon”, c’est exactement ce que je reproche au JS. Il faut tout se taper à la main. L’accessibilité du langage aux débutants est vantée, mais pour avoir fait des formations JS, PHP et Python, je peux t’assurer que le JS est beaucoup plus dure à enseigner.

  • foxmask

    @cym13 : pour Java, difficile de le dire. On peut tout faire avec, ses perfs sont maintenant excellentes et il y a un grand pool de dev. Mais que peut on faire en Java qu’on ne peut pas faire plus facilement et aussi bien avec une autre techno ? L’intégration d’outil corporate et la prog android peut être, mais après…

    hélas, plein de choses ne sont pas faisable autrement qu’avec java.
    Je n’ai pas l’impression qu’on voit sortir un équivalent à jEE (Java Enterprise Edition) dans n’importe quel langage, ce qui du coup élague vite le terrain pour laisser la place aux applications du monde financier en premier lieu.
    Aussi, en moins “énorme” ne serait-ce que Cocoon un Framework à base de composant de pipelines, permet l’aggregat de flux de toute nature et de n’importe où sur la planete, pour le rendre où et comme on veut. Comme on est des ouf on peut produire des flux XML pas _que_ en java, mais bien dans le langage qu’on veut et Cocoon se chargera de piquer votre flux pour en faire ce que vous voulez pour/dans votre biz/workflow etc.
    Il y a tant de domaines où java est que le classer dans les cases web/android/intégration est un erreur.
    Le dernier truc en vogue avec Java est OSGi.

    PS : j’aime pas java ni ne code avec (suis qu’admin jEE), je ne fais que raconter ce que j’ai croisé pendant une période de ma petite carrière

  • Plop

    En fait y’a tellement de mauvaise fois…

    Si je reprend la réponse au premier commentaire conduisant à ce post :

    Pour le Javascript, c’est simplement que ça a été implémenté dans IE qui a ensuite eu le monopole.

    Oué, mais non. Javascript (anciennement LiveScript, qui d’ailleurs a été développé pour tourner côté serveur) est surtout arrivé avec Netscape Navigator 2. Et vu la bataille qu’il y avait c’est Microsoft qui a copié pour l’implémenter sous le nom de JScript. Si tu veux taper tape sur Netscape.

    Php est un langage avec une super doc et une communauté noob friendly.

    Oué enfin Php est là où il en est pour une raison principale : l’inertie technique. Php est un mauvais langage avec un mauvais runtime. Mais on continue à faire du Php… parce que les gens font du Php. Bravo.

    Des notions de base comme les closures sont encore obscures pour la plupart des codeurs Javascript

    Ok, donc en fait tu critique Javascript en parlant de gars qui ne savent pas coder en Js et donc écrivent de la merde ?

    Ne pas utiliser l’opérateur ==

    Ben non, il n’est pas dit de ne pas utiliser ==. Ce qui est dit c’est que == et === doivent être utilisés, et pas uniquement ==. Il y a plein de cas où == est valide, et des cas où il faut utiliser ===. Et d’ailleurs c’est pareil en Php si on veut coder proprement.

    Ne pas utiliser parseInt sans préciser la base

    Et alors ? En quoi préciser un argument est un problème ?
    D’ailleurs :

    jsc
    >>> parseInt('06')
    6
    >>> parseInt('07')
    7
    >>> parseInt('08')
    8
    >>> parseInt('09')
    9
    >>> parseInt('10')
    10

    Tu remarquera que d’une part ça dépend de l’interpréteur et d’autre part c’est quelque chose qui a changé puisque désormais (c’est dans la norme si je ne me trompe) c’est un parseInt en base 10 qui est réalisé sans argument.

    Mais bon, venir taper parce que les développeurs ne sont pas foutus de lire la doc du langage…

    Bien se souvenir d’utiliser var partout

    Heu… oué et alors ?
    Etrangement si je ne déclare pas mes variables en c++ ça ne fonctionne pas, c’est vraiment de la daube.

    Ah oui, et ne pas utiliser les mots clés new ou with pour vos propres libs

    J’aimerais bien voir l’explication du new pour les libs…

    Un autre truc : personne ne s’est mis d’accord sur l’utilisation des objets : prototypage, simulation d’héritage, instanciation ou pas, composition uniquement ? En tout cas vous devez en choisir un, et ne pas le merder.

    Rien à voir. Encore une fois c’est un problème de développeurs, par de langage. Le truc c’est que la majorité des développeurs qui font du js aujourd’hui n’ont jamais essayé de comprendre le langage, qui est un langage à prototype et non à classe. Donc beaucoup tentent de simuler des classes sur un langage qui n’en a pas. C’est balot c’est pas génial.
    Pourtant, utiliser les propotypes est plutôt simple et ça marche tellement plus facilement.
    Mais bon, c’est comme si j’essaie de faire des classes en lisp, ça va être un poil plus pourri tout d’un coup…

    {} + []

    J’aimerais bien voir un exemple avec un vrai cas où on écrirait ça. Ok ça devrait simplement être jeté mais franchement…

    Lire un fichier ? Une opération vraiment rare et compliquée…

    Oui c’est sur que comparer la lecture d’un fichier entre des langages fait pour s’exécuter directement sur un poste ou un serveur et un langage fait pour s’exécuter dans un navigateur c’est malin…

    def fonction(param, param2="valeur", **params):
        print param, param2, params
     
    fonction(1, autre_valeur=2)

    Ça donnerait en gros ça :

    function fonction(param, param2) {
      console.log(param, param2 || "valeur", Array.prototype.slice.call(arguments, 2));
    }
    fonction(1, 2);
  • null

    Le top ce serait d’avoir du java sans script dans les navigateurs.

  • herison

    >> Des notions de base comme les closures sont encore obscures pour la plupart des codeurs Javascript
    C’est pourtant primordiale quant on utilise un langage fonctionnel, Si l’on peut considérer JS comme un langage fonctionnel. C’est plus un hybride n’y pleinement fonctionnel n’y pleinement objet.
    Si l’on regarde C++, c’est un langage impératif (le c) qui a évolue vers l’objet et maintenant prend du paradigme fonctionel avec l’ajout de lamda tu peux faire aussi du duck-typing si tu utilise que des templates. Au final, c’est souvent déguelasse de mélange des paradigmes. Et oui effectivement le besoin d’asyncrone ne justifie pas forcément l’emploie de JS.

  • openhoat

    @Erase ;-)

    @Sam c’est vrai que je trouve nodejs passionnant, mais ça n’enlève rien au fait qu’au quotidien je fais bien du javascript, que ce soit avec node ou autre je me pose les mêmes questions, je cherche même parfois les mêmes solutions aux mêmes problèmes posés, donc je ne comprend pas le sens de ta question, je vois node comme un moteur qui me permet d’utiliser pleinement le langage JS.
    “Encore une fois, en dehors de nodejs et de la prog web, personne ne fait intensément du JS.” => je ne peux contredire cette évidence, c’est vrai que si on enlève les runtimes d’un langage il ne sert plus à rien (comme la VM Oracle ou Dalvik de Java, ou les interpréteurs Python ou Ruby)
    Je ne m’intéresse pas à JS pour le JS mais pour ce que je peux faire avec, comme je m’intéresse aussi à Python (pas pour python mais pour ce que je peux faire de puissant et simple avec), donc tu as raison mais c’est une banalité.
    C’est vrai qu’en JS on est loin de faire la même chose qu’avec les autres langages majeurs, mais les lignes bougent et plutôt vite je trouve.
    Cette accélération récente des usages autour de JS rend le langage beaucoup plus intéressant.
    Et Node est un moteur, pas un framework web, c’est juste le lien minimal vers V8 avec un peu d’API autour.
    Donc, hors web (front ou back) aujourd’hui quand j’ai un outil à développer en ligne de commande, il m’arrive de plus en plus souvent de choisir JS pour le coder et le résultat est le plus souvent très satisfaisant; il m’arrive aussi de coder des applis lourdes multi plateforme avec JS (certes propulsées par webkit je te vois venir…).
    “Quand à l’affirmation qu’on aurait le mêmes problèmes d’implémentation disparates avec une autre techno, je dis non.” => là n’est pas la question; python est top mais ça n’aurait pas empêché un éditeur de navigateur d’implémenter un interpréteur moisi et qui se comporterait différement de ses copains pour gérer DOM par exemple, le problème n’est pas le langage.
    Là où je te rejoins pour avoir aussi formé à JS et d’autres langages, c’est que d’autres langages sont beaucoup plus simples à enseigner dans le sens où ils sont mieux structurés (plus carrés), et font moins appel à notre côté “hacker”, mais là aussi en cadrant correctement les choses ça se passe bien (pour apprendre, de mon point de vue, Python est nettement au dessus du lot).

  • Eric

    dsl même pas fait gaffe, je suis sous windows, je return su OS X (et rassurez bvous bientôt chez les fous.

    Baon, je copie/colle et je me casse.

    Puitain de merde mais c’est un putain de trou du cul ce M$

  • Rebolon

    Pour parseInt, depuis Ecmascript 5 il est en base 10 par défaut.

    Pour Dart il semble que sur des gros projets le cross compilateur n’est pas au point. A surveiller car il y a peu de retour d’exp là dessus.

    Sinon, oui il y a des aberrations en JS, mais dans PHP il y en a aussi (et dans plein d’autres langages aussi, faut être lucide). Et puis utiliser Java pour faire du web, c’est pas déjà en soi une aberration.

  • kik

    Allez, j’apporte ma p’tite pierre : le JS est mon langage préféré, et j’ai en utilisé un paquet. Pourquoi ?
    – D’abord, parce qu’il est interprété (c’est plutôt pas mal pour débugger)
    – Ensuite, il bénéficie de fonctions uniques, comme les fonctions anonymes, la possibilité de s’auto-modifier.
    – On peut en faire pas mal de choses sympas : des appels synchrones ou asynchrones, des animations, tracer des graphiques…

    Pour le typage, suffit d’être logique, on n’ajoute pas une chaîne à un nombre. Que les résultats soient illogiques là-dessus ne me dérangent pas.

    A mon avis, si ce langage n’est pas toujours bien perçu, c’est parce qu’il est exigeant, nécessite de bien connaître les navigateurs (encore que beaucoup de monde utilise des frameworks) et évolue régulièrement (on a à présent les rotations d’images, les SVG…).

  • Naouak

    Première ligne, première chose à redire :

    Il faut bien comprendre que PERSONNE ne s’intéresse à Javascript directement.

    Je suis tombé à l’époque sur Node.js parce que j’aime le javascript et parce que je voulais en faire coté serveur.

    Allons lire la suite mais ça commence mal.

  • StyMaar

    Heureusement qu’on est vendredi. ^^
    Mais sache qu’il existe des gens qui aiment vraiment le JavaScript, et qui en font par pur plaisir :)

    l = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
    Récupérer les carrés des nombres paires de la moité supérieure de la liste ?

    En vrai ça peut simplement s’écrire comme ça :
    l.map(function(a,b){return a*a}).slice(5);

    Et franchement, là faut m’expliquer en quoi c’est moins élégant que le code Ruby que tu proposes pour faire la même chose ;)

  • Swizz

    Je partage totalement ton avis.
    Et pourtant, je fais petit à petit de JavaScript mon fer de lance.
    Me vendant de plus en plus comme un Dev’ JS.

    Le plus ridicule dans tout ça, c’est qu’on commence à s’habituer au fait de faire des tests du genre : “0” == 0.
    Et même à s’étonner lorsque ça ne fonctionne pas sur nodeJS.

  • Seris

    Bon, encore un troll non réfléchit avec un dev’ qui ne sait même pas se servir du langage ^.^
    Juste comme ça :

    l = [x*x for x in l[5:] if x %2 == 0]
    var l = (function(){ var s=[];for(var i = 0; i &lt; 10; i++){ s.push(i); } return s; })();

    Faisable en une ligne en JS, voilà au revoir :3

  • kontre

    J’ai quand même une remarque sur [] + {}. Ouais, on ne veut jamais faire ça intentionnellement. Seulement ça doit pouvoir arriver “assez facilement” en cas de bug ou de donnée d’entrée malformée. Au lieu de râler, JS va continuer son petit bonhomme de chemin en utilisant un résultat complètement incohérent venu de nulle part. Et ça plantera 200 lignes plus loin, mange ton debug. Ça fait peur !

    Sinon, y’a aussi Haxe pour faire du JS, et qui se compile en pal mal d’autres langages (Flash, NekoVM, PHP, C++, C# et Java).

  • Sam Post author

    @Plop: je parle de netscape dans l’article man… Quand à “==”, il est bel est bien recommandé par tous de l’éviter dans tous les cas. Pour l’argument, c’est juste un exemple d’une API mal pensée. Pour var, c’est juste complètement inutile et tient du bricolage. new c’est simplement que si on l’oublie, ça fait une erreur silencieuse, alors que tout objet ne s’instancie pas forcément dans ce langage. Et non je ne critique pas les codeurs merdiques, je critique le langage pour être basés fortement sur des features difficiles à maitriser pour faire des choses basiques, comme incrémenter un compteur. Enfin, si le JS est fait pour le nav, nodejs ne l’est pas, donc pas d’excuse.

    @openhoat : nodejs n’est pas l’unique runtime de javascript. Pas plus que cpython l’est. Si tu me retire cpython, je peux continuer à faire tout ce que je faisais en Python avant, et plus de choses que tu peux faire avec nodejs maintenant.

    @kik: ruby et python sont des langages interprétés, plus facile à debug que js, qui ont eux aussi une forte d’introspections et toutes ces features. Mais en plus ont peut faire plus que de la prog Web.

    @David Bruant: tu veux que je le publie en tant qu’article ? Tu t’es fais chier pour l’écrire, ça mérite de la visibilité pour le droit de réponse.

    @Naouak : effectivement j’aurais du dire, personne qui a de la pratique avec des langages décents ne s’y intéressent.

    @StyMaar: ça ne retourne pas la même chose tu ne filtre pas les nombres paires. Mais quand bien même, ce n’est pas dispo sur les navigateur, donc so long pour le côté DRY, et donc si ce n’est pas pour ça, autant utiliser un autre langage sur le serveur qui fait ça et bien plus.

    @Seris: ceci ne fait absolument pas la même chose. Et je code tous les jours en JS, merci.

    Je plussoie @kontre. Il ne s’agit pas d’une feature désirable, il s’agit d’un état de propreté général qui permet ou non de s’en sortir facilement le jour où il faut détecter une comportement aberrant dans un programme.

  • Sam Post author

    @ObnoxiousJul : la technical debt explique effectivement bien la moitié du problème, l’autre moitié étant le choix du js côté serveur alors que quelqu’un aurait pu prendre un framework asynchrone en ruby, python (ou erlang, quitte à échanger l’ergonomie pour des perfs de fou, autant aller jusqu’au bout), et le rendre ergonomique.

    Twisted possède des perfs de l’échelle de Nodejs depuis longtemps. C’est pas très ergonomique par contre, mais ça peut se changer. Mais non, on a investie dans le JS.

  • ObnoxiousJul (@ObnoxiousJul)

    @sam: la deuxième moitié est la religion, le coté sectaire en informatique.

    On est sensé être ingénieur. On est sensé être au moins livrer aussi fiablement qu’un “artiste” (metteur en scène, chorégraphe) dans un domaine où l’imaginaire domine.

    On y arrive pas avec moults outils (dont l’agile). Comment?

    On ne mesure plus. On ne conçoit plus, on n’as plus de sens objectif et critique.

    Si on mesurait les effets de la perte de localité dans le code (callbacks waterfall immonde en node JS) sur la maintenabilité d’une optimisation prématurée (l’asynchrone est une optimisation prématurée), alors peut être que l’on pourrait arrêter node JS.

    On a les métriques (temps de développement, maintenance incluse, niveaux de services, couts réccurents, couts des bugs …)

    On peut compter, mais même quand on le fait on ne regarde pas les chiffres, pourtant on a le Big Data dans la bouche et sous les yeux. Et on se prétend ingénieur? Scientifique?

    Pourquoi, ou plutôt comment?

    On croit. Juste on croit, sans plus vérifier ni mesurer. Voilà ton deuxième problème: la perte de l’esprit critique.

  • karl

    “la réticence (oui je suis poli) des membres du w3c de l’ecma group rend pour le moment tout mouvement dans ce sens improbable.”

    W3C != Ecma. Deux groupes différents de standardisation.

    Pour la petite anecdote, l’élément SCRIPT et l’élément LINK pour les styles ont été conçus pour être langage agnostique. Cependant, comme le support d’un nouveau langage dans un moteur de navigateurs a toujours de nombreuses conséquences sur la stabilité, les régressions, l’interopérabilité, on se retrouve avec le choix la contrainte de maintenir l’existant déployé et de porter sa croix pour les futurs développements du JS.

    Donc oui c’est improbable qu’il y ait un autre langage mais pas à cause des organismes de standardisation mais par contraintes pragmatiques d’interopérabilité. Un peu comme si on disait dès demain on arrête la voiture, cela pollue, c’est vraiment un outil pourri dans plein de circonstances avec plein de conséquences. Pas possible, la voiture se transformera en partie par législations, innovations, et crise fondamentale (plus de pétrole), mais elle ne s’arrêtera pas avant que quelquechos de bien mieux et compatible avec le contexte courant fonctionne.

    En passant le DOM avait été conçu aussi pour être IDL et les toutes premières specs étaient souvent accompagnées de deux implémentations une en Java et une en JavaScript. Et maintenant elles sont décrites avec WebIDL qui est orienté ECMAScript (donc JavaScript).

  • Sam Post author

    @ObnoxiousJul: absolument. D’autant que beaucoup de dev nodejs que je connais n’ont pas à maintenir le projet une fois qu’ils l’ont terminé. Ils n’ont pas à le documenter, à trouver les dev pour le faire évoluer, à refactoriser la base de code ou changer de version de tech, former les nouveaux arrivant dessus, etc. C’est du one shot, alors tout va bien. Quand on me dis, “tu n’as qu’a utiliser underscore ou lodash”, je vois que ces personnes n’ont pas conscience du coût du rajout d’un lib __pour un truc AUSSI basique__. Il faut choisir la lib (investir du temps dans ce choix), la déployer, la maintenir, former des gens dessus. J’adore utiliser des nouvelles libs. Je le fais tout le temps. Mais ça a un coût. Un coup qu’on ne doit pas à avoir à payer pour des trucs de base.

  • Vincent

    Un article rempli de fautes et rempli de conneries.
    Rien que, par exemple :

    var coucou = "Ceci est une looooooooooooooooooooooooooooooooooooooooongue chaine !" +
    "Sur plusieurs lignes !\n" +
    "Et une autre !\n" +
    "Et une autre !\n" +
    "J'adore les sauts de ligne, c'est tellement lisible !!!\n"
    console.log(coucou)

    devient :

    var coucou = "Ceci est une looooooooooooooooooooooooooooooooooooooooongue chaine !\n\
    Sur plusieurs lignes !\n\
    Et une autre !\n\
    Et une autre !\n\
    J'adore les sauts de ligne, c'est tellement lisible !!!\n"
    console.log(coucou)

    Et j’en passe…

    Effectivement le JS propose des concepts parfois alambiqués, soit, mais tellement puissants. Je suis d’accord qu’on puisse vouloir critiquer le JS, mais pas lui cracher dessus. Quand je vois que tu oses écrire “le JS était nul, puis on a ajouté Ajax et les gens ont kiffé”, j’ai véritablement envie de te dire de la fermer. Ajax existait depuis le début, seulement à l’époque personne n’en voyait l’intérêt. C’est avec facebook & co que c’est devenu à la mode.
    Pour le côté Asynchrone, une fois de plus je pense (je dis bien je pense, je ne connais pas tout) que tu as tort.
    En soi, 99% des langages sont asynchrones dans le sens où ils tournent sur des processeurs “ordinaires” qui gèrent l’ordonnancement des processus, donc, mise à part les opérations atomiques, il n’y a aucune garantie de la stricte séquencialité des opérations. On parle d’asynchrone avec JS simplement parce-qu’il est monothread. Et ça, c’est véritablement peu commun ! Donc oui, il faut faire avec. Gérer le parallélisme, etc.
    Ca + le prototypage font de ce langage un langage particulier. On aime ou on aime pas, mais il reste cool.
    T’y connais-tu en réseau ? Sais-tu que IP est de la grosse merde à chier ? Sais-tu que TCP est technologiquement minable par rapport à ce qu’on sait faire ? Sais-tu que pourtant ça fait 40ans qu’on utilise TCP/IP pour accéder à des sites web tels que le tien ? L’informatique est en perpétuelle évolution, on ne peut pas tout jeter à la poubelle et dire au monde entier de se procurer les mises à jour à chaque nouveauté. Alors on s’adapte on bricolant des solutions qui se basent sur celles d’avant, beaucoup moins performantes, etc. Ca limite grandement l’avancée, mais c’est comme ça. Le C peut évoluer en toute tranquillité tant que les quelques milliers (millions ?) de développeurs C mettront à jour leur compilo. Le JS ne peut évoluer que si les 6 milliards d’utilisateurs mettent leur browser à jour.

    Je pense, sans vouloir te juger, que tu n’as absolument pas la prétention de pouvoir écrire un article sur JS. Pour ma part, je sais que je ne remettrai pas les pieds sur ton blog de si tôt.

  • Sam Post author

    @vincent: oui c’est un peu mieux, mais c’est toujours moins bien. Et ce n’est qu’UN exemple, j’aurais pu en mettre 1000. Le formatage de chaîne avec des variables (besoin d’un langage de template en JS), le traitement des opérations ensemblistes, l’absence de générateurs… Je pense, sans vouloir te juger, que tu n’as aucune connaissance dans un autre langage que le JS. Ensuite, la fin de ton argumentation, c’est le résumé du début du mien. Donc en gros tu est d’accord avec moi.

  • molokoloco

    Un bon troll, assez constructif ;)

    Ca me semble cependant important de parler aussi de l’API HTML5
    Liste de toutes les méthodes/propriétés des l’objets “window” et “document”
    http://jonathansampson.github.io/browser-data/
    Par exemple je serais curieux de voir un exemple d’autre langage ou un débutant peut, en 1h, exploiter une webcam et faire des effets vidéo sur l’image (cf. getUserMedias)
    Si un débutant peux faire ca, vous imaginez ce qu’un expert peut faire ???
    L’API DOM https://developer.mozilla.org/en-US/docs/Web/API/document#Methods …etc

    En vrac, 7 manières de changer la position d’un élément http://jsperf.com/csstext-vs-style/22 et 13 manières d’itérer sur un Array numérique… http://jsperf.com/native-loop-performance/16

    Un langage qui laisse le choix…

  • Jean

    J’utilise parfois ce langage, pas pour faire du web côté client ou du serveur, mais pour scripter sous Windows. Étonnant à première vue… mais c’est le seul langage digne de ce nom nativement installé sur cette plateforme depuis XP (oublions donc PowerShell) permettant d’écrire un code de manière lisible et efficace.

    Quant à l’article, je me suis bien marré et on peut trouver certaines similitudes avec PHP.

  • Sam Post author

    @molokoloco: oui c’est la vrai force du JS dans le browser, son interactivité multimédia facile et puissante. Il a pas que des défauts. Mais en même temps, ce n’est pas une question du JS, c’est une question du browser, on aurait pu implémenter un autre dialecte pour faire ça.

    @john dow: le lien a été mis à jour dans l’article.

  • Clem

    Le JS ne peut évoluer que si les 6 milliards d’utilisateurs mettent leur browser à jour.

    @vincent, Cet argument ne tient plus, aujourd’hui la plupart des navigateurs sont mis a jours automatiquement au moins 1 fois par mois.
    on pourrait très bien imaginer qu’un langage autre langage (ruby, python, …) soit standardisé pour le web, il suffirait juste de lui ajouter une API DOM.

    On pourrait également imaginer de réfléchir à des alternatives à CSS ou HTML. Ce n’est pas pars-qu’ils sont libres qu’il est légitime qu’ils ai un monopole.

  • ObnoxiousJul (@ObnoxiousJul)

    @vincent okay en dehors du troll, on peut reconnaître que JS est un bon langage … fonctionnel. Parce que son concepteur a juste pris les fondamentaux du scheme et pour que personne ne “crie arg cette merde de LISP” il lui a donné une syntaxe à la C. http://functionaljavascript.blogspot.ca/2013/03/introduction-to-functional-javascript.html

    Le troll actuel est de l’utiliser en OOP et dans des paradigmes pour lesquels il n’est pas fait.

    Pour en revenir à TCP/IP on est d’accord que c’est pas la panacée, mais rebâtir des couches réseaux sur du TCP/IP ouat da fouc!!

    Prenons le cas classique des flux temps réels synchronisés pour lesquelles on a besoin d’une faible latence mais où les drops de packets sont acceptables (voix, video …) ben http2.0 ne répond pas aux contraintes notamment parce que l’on est encapsulé dans du TCP.

    Ce qui rend la synchronisation de flux pour des valeurs non percetibles de décalage des flux aux humains impossibles (>14ms). Par construction.

    TCP est stateful, alors que HTTP est stateless => on se casse les pieds à recréer la logique de session (stateful) … ça paraît pas un poil délirant? Ah non, c’est oauth2.0. Avec des sessions infinies (4H vs 20 minutes usuellement en web server side avec les librairies habituelles).

    On rajoute des couches de complexité énorme avec des objectifs qui sont incompatible avec les couches de bases (dont HTTP) utilisées.

    Moi, je crois que l’on est parti pour l’explosion de la bulle WebX.0.
    À trop s’appuyer sur des technos branlantes, un jour on va se prendre un incident majeur qui va générer une grosse instabilité sur le réseau.

    @molokoloco qu’HTML5 existe, ne veut pas dire que les implémentations seront convergentes. Cf la guerre des browser dans les années 90 + les implémentations de CSS 3D transforms qui ne donnent pas les mêmes résultats sur tous les brouteurs webs.

  • akersof

    ObnoxiousJul a dit:

    Le troll actuel est de l’utiliser en OOP et dans des paradigmes pour lesquels il n’est pas fait.

    Tout est dit.
    Même parmit python certains ont emit des doutes sur le pattern classe/heritage classique dans des gros projets, et ont compris sa limite, et ils se font troller, tel que le framework twisted qui utilise d’autres patterns tel que les “promises” (deferred) et favorise la composition via les zope interface.
    Autre système de pensée apparement on aime.. ou on troll :)

  • amz3

    J’utilise l’OOP pour faire de l’UI ça me va très bien, pareil en Javascript (en moins bien bien sur).

    @akersof Twisted/Zope non-OOP. gros LOL. Tu sais pas de quoi tu parles on dirait.

  • akersof

    @amz3: je parlais d’heritage de classe, pattern totallement utilisé à tort et à travers par les users python et non pas de oop si tu relis ma phrase tu comprenderas. J’avancais ca pour dire que twisted à longtemps été critiqué justement car il utilise des “nouveaux” patterns qui sont pas tres utilisé dans le wild, tel que les promises et la composition, tel que javascript qui ne possede pas en realité d’heritage de classe car les classes n’existent pas.
    C’est toujours un peu lourd de se faire contredire par quelqu’un qui reprend une phrase, la sort de son contexte. Tape toi un “gros LOL” en lisant ca plutot: delegation instead of inheritance

  • Bob

    Pas loin de la soixantaine maintenant, j’en ai vu passer des technos ! Il n’y a pas de règles : certaines technos prometteuses comme les applets Java sont passées à l’oubliette, alors que des technos comme Windows ont prospéré.

    Quand UNIX a commencé à se répandre dans les années 80, il faisait pâle figure à côté de VMS. VMS était l’OS maison de DEC, constructeur leader derrière IBM, et son OS était unanimement réputé comme particulièrement bien pensé, efficace et performant. Ses processeurs étaient de la même veine.

    DEC est mort en 1998, racheté par COMPAQ fondé 1982. COMPAQ a construit son business sur le PC, architecture torturée s’il en est. L’adressage paginé des processeurs INTEL est tout simplement une horreur comparé à l’adressage linéaire des processeurs Motorola. Et pour couronner le tout, COMPAQ livraient ses PC sous Windows, qu’il était difficile à l’époque de qualifier d’OS !

    Aujourd’hui, le paysage informatique est composé d’architectures PC qui tournent sous UNIX ou WINDOWS…

    Cela fait longtemps que j’ai arrêté de me lamenter. L’âge peut-être ? Mais j’aime toujours l’Informatique. Alors si tu n’es pas capable de “faire contre mauvaise fortune, bon coeur“, je ne vois qu’une solution : change de métier ;-)

    Il n’y a que deux sortes de technologies : celles qu’on maitrise et celles qu’on ne maitrise pas.

    Bob

  • Sam Post author

    Non, il n’y a que deux sortes de technos : celles dont tout le monde se plaint et celles que personne n’utilisent.

  • ObnoxiousJul (@ObnoxiousJul)

    @sam et les technos auxquelles nous tordons trop le bras.

    Désolé de le dire, mais le messaging avec des choses comme zmq (ou tout autre techno de messaging) est plus adapatée que HTTP avec XMLHTTPpartialrequest.

    Autre chose: du stateless pour faire du transactionnel, ben ça oblige de réimplémenter une couche connectée sur un protocole qui ne l’est pas.
    C’est exactement comme faire du transactionnel sur des bases distribuées (genre mongo).

    C’est en terme d’ingénieurie comme bâtir un gratte ciel sur une couche de maison en pilotis sur un marais.

    On tord trop le bras à des technos qui à la base ne sont pas mauvaises

  • Sam Post author

    Tout à fait. J’ai vu un protocole toshibar dernièrement qui prétendait être 30 fois plus performant que tcp/IP, tout en ayant la même tolérance aux erreurs.

  • G-rom

    Heureusement que tu as annoncé que c’était un gros Troll ;)

    Perso je fais du JS dans mon taff de tous les jours et j’étais réticent au début, surtout que j’étais côté back et en python avant. Assez d’accord sur la partie on fait des appli web en JS parce que c’est le seul langage dispo.

    Par contre l’éco système évolue super vite et ça commence à devenir très plaisant de dev côté front. Si si je vous jure. Voir la naissance et l’évolution de quelque chose, qui effectivement part avec beaucoup de désavantage, partir vers quelque chose qui essaye de prendre le meilleur de partout avec une communauté super sympa, bin ça fait zizir, et y participer encore plus.

    Allé pour troller, npm Vs. pip, npm wins ;)

  • kwirrittud

    Une chose qui m’embête à propos du JS, c’est que depuis quelques mois ou années il y a des sites web ENTIERS qui obligent à le laisser activé pour lire le site. (Dernier en date : https://NSA-Observer.LaQuadrature.Net )

    Déjà c’est chiant cette contrainte car tout sauf user-friendly, ensuite c’est mauvais pour le SEO et l’accessibilité, et puis ça cache parfois la volonté de vous suivre à la traces… Quel dommage que des sites très bien se basent désormais sur JavaScript! :'(

  • molokoloco

    @kwirrittud Un bon gros paté de troll ^^ “A bas les webApps vive la page !”
    Si ca te plais de naviguer dans linx et VIM, tu peux découvrir http://casperjs.org
    Moi mon job c’est de faire des sites interactifs et je me sens pas de me limiter au :hover et :focus des CSS… lol
    T’es trop vieux peut être ? ;)
    Tu connais le motion design, le multimédia, le design, l’ergo utilisateur, webRTC, canvas, webGL, la dataViz, etc etc etc ? T’as déjà fait un site dans ta vie ? Cela te parle le multiscreen responsive (oui tu as raison, comme du texte quoi ;), l’intégration vidéo ?
    Pour ton infos Google aussi processe le JS sur les pages. Même les bots y arrive alors pourquoi pas toi ?
    Et pour ne pas être tracké par les tiers, désactive les cookies et change ton IP souvent… pour le reste https://adblockplus.org/en/firefox et https://addons.mozilla.org/en-US/firefox/addon/donottrackplus/ (aussi sous Chrome)
    Niveau tracking, JS n’est pas beaucoup plus coupable que le log apache quand il est absent…

  • G-rom

    @sam Si si toujours. C’est pas parce que pip et venv sont dans la 3.4 que ça change énormément de chose. Faut toujours venvwrapper ou bien connaître venv (perso je ne sais plus faire sans venvwrapper), faut toujours se galérer pour packager, …

    Avec npm bin… par défaut ça installe en local, pas en global, et c’est super facile de publier un package. 2 gros points majeurs qui poutrent.

  • Sam Post author

    Je m’inscris en faux pour le coup. D’abord, venv n’est pas du tout obligatoire pour pip installer quoique ce soit, avec -U ça s’installe en local aussi. Ensuite publier un package n’est pas difficile du tout. Par contre c’est très très très mal documenté.

  • G-rom

    En local par rapport à l’utilisateur, soit $HOME. npm installe en local du projet, d’où une cohabitation plus facile de différents projets sur ton PC out of the box.

    Pour retrouver le même comportement avec pip soit tu modifies une var d’env à la main à chaque pip install -U soit tu utilises venv.

    J’adore python mais pour le coup je suis réaliste sur ce gros défaut. Il n’est pas encore venu le jour où on pourra se passer de venv.

  • jc

    Petite typo dans le code :
    {} + [] // Ceci n'est effectivement PAS un nombre
    devrait être :
    {} + {} // Ceci n'est effectivement PAS un nombre

  • Vorkosigan

    Mais que conseillez-vous à un débutant ? Dart de Google, TypeScript de Microsoft ou autre chose ? Merci !

  • molokoloco

    Moi j’apprend à mes élèves les bases du html/css : indispensables. Ensuite, initiation JS, puis jQuery, puis, de nouveau, approfondissement du JS. Que le débutant se dirige ensuite vers des frameworks tels que Angular, Ember, jQuery mobile, Android, IOS ou watever… Pour moi, cela reste une base à connaître par tous les devs, ne serait-ce que pour rédiger leurs docs (Même le code markdown requiert un minimum de connaissance W3C).

    jQuery est de loin la plus simple des librairies JS. Il facilite grandement l’écriture du code, tout particulièrement grâce au chainage des méthodes et aux “shortcuts”. Les débutants ont le plaisir de voir des résultats rapidement, en quelques lignes de codes… les experts font des plugins avancés que tout à chacun peut utiliser sur son site facilement et simplement. Grace aux events et aux data/élément les plugins jQuery sont très modulaires et s’intègrent parfaitement les uns les autres. L’appel des plugins jQuery se fait par l’intermédiaire d’un objet souple passé en argument, leurs paramètres par défauts sont idéals et très facilement customisables. etc. Je recommande ;)

  • Sam Post author

    @Vincent: j’ai travaillé sur PHP pendant pas mal de temps, et c’est la raison pour laquelle je me suis mis à Python : raz le bol.

  • dssdsdsdsdsd

    Il manque un \n ici :

    var coucou = "Ceci est une looooooooooooooooooooooooooooooooooooooooongue chaine !" +

  • ObnoxiousJul (@ObnoxiousJul)

    @Vorko(r)sigan (Mike) de continuer à lire Mc Mustor Bujold :)

    Il faut avoir le même état d’esprit que Mike dans la saga, vif, inventif, avoir un poil de confiance en soi, de l’humour et penser de manière hétérodoxe.

    Pour ça avoir des sujets d’intérêts variés, lire, écrire, éventuellement un talent de repli au cas où au bout de deux ans tu t’aperçois que tu n’es pas bon en informatique.

    Apprendre un langage informatique est un ordre de grandeur plus simple qu’apprendre une langue étrangère. Mais c’est le même principe, tu dois pouvoir exprimer ta pensée de manière fluide dans un système linguistique non familier.

    Mais avoir le raisonnement logique et l’intuition du fonctionnement de la machine prends des années, tranquillement.

    Va juste à ta vitesse en admirant le paysage (comme postgresql ou python développent) au lieu de viser à être performant dès le début (à la noSQL, PHP ou mysql).

    Fais toi plaisir, la vie est trop courte :)

  • amz3

    @akersof désolé, j’ai lu trop vite. MERCI pour le lien, justement je veux apprendre Zope & Twisted.

  • ghusse

    Par contre, le "use strict" n’a RIEN à voir avec les points-virgules.

    La doc de mozilla sur le mode strict:

    1) En mode strict, il est impossible de créer accidentellement des variables globales
    2) Le mode strict fait en sorte que les assignations qui échoueraient dans le silence autrement lèveront aussi une exception
    3) Le mode strict fera que le fait d’essayer de supprimer des propriétés non-supprimables lèvera une exception.
    4) Le mode strict requiert que toutes les propriétés nommées dans un objet littéral soit unique.
    5) Le mode strict requiert que les noms de paramètres de fonction soient uniques.
    6) Le mode strict interdit la syntaxe octale.

    Le framework bootstrap par exemple utilise le mode strict pour ses fichiers javascript, tout en ne mettant pas les points-virgules.

  • Cyril

    Certains exemples de code sont inexacts car vous vous fiez à ce que la console de Chrome affiche. Ex: quand on fait “var a=1″, Chrome affiche “undefined”, mais a est bien égal à 1, il n’y a rien d’illogique côté JavaScript

  • Vincent Vallet

    Bonjour à tous,

    J’apporte quelques remarques provenant de ma modeste expérience sur javascript.

    Déjà je ne pense pas que les problèmes que l’on rencontre aujourd’hui viennent d’une techno ou d’un langage mais plutôt de son utilisation.

    La preuve avec votre exemple :

    var coucou = "Ceci est une looooooooooooooooooooooooooooooooooooooooongue chaine !" +
    "Sur plusieurs lignes !\n" +
    "Et une autre !\n" +
    "Et une autre !\n" +
    "J'adore les sauts de ligne, c'est tellement lisible !!!\n"
    console.log(coucou)

    Il est clair que ça peut être écrit de meilleur manière :

    var coucou = "Ceci est une looooooooooooooooooooooooooooooooooooooooongue chaine !\n\
    Sur plusieurs lignes !\n\
    Et une autre !\n\
    Et une autre !\n\
    J'adore les sauts de ligne, c'est tellement lisible !!!\n"
    console.log(coucou)

    Quand au choix de laisser les sauts de lignes explicitement ce n’est pas aberrant car la représentation d’une chaîne dans le code n’a pas pour objectif d’être la projection parfaite de son rendu à l’écran.

    Vous dites dispenser des cours en javascript et même temps tout le monde est d’accord pour dire que le langage n’est pas forcément aisé à appréhender ….. pas sûr que cela aille mieux si déjà nos chers instructeurs ne connaissent pas assez bien le langage (sur lequel ils trollent par ailleurs).

    Sur certains points ok, le js n’est pas d’une prévisibilité (ou d’une logique) extraordinaire comme sur cet exemple :


    {} + []

    Et la réaction de bon nombre de personne est :

    Mais putain qu’est ce que c’est que ce gros langage de merde !
    Et vive Python, Java & cie !

    Personnellement ma réaction serait plutôt :

    Mais quel encu** de développeur de mer** de fils de p*** peut écrire une telle connerie ?????

    Encore une fois l’intelligence n’est pas dans les outils mais dans ceux qui les utilisent.

    La preuve, car dans n’importe quel langage (y compris Python) on peut écrire ça :


    if(condition) {
    instruction
    }
    else {
    // rien ici, empty block
    }

    Ca n’a aucun sens et pourtant aucun langage ne gueule …. où est le problème ? Doit-on tenir par la main tous les développeurs ?

    Mon impression sur le javascript : finalement encore assez jeune car son essor est récent, beaucoup d’améliorations à venir …. tout n’est pas si noir.
    Ceux qui n’y arrivent pas attendent souvent tout de leur IDE, sans aucune réflexion sur le langage qu’ils utilisent.

    Quant à Dart : sur le principe oui mais ce ne sera pas évident avant plusieurs années, de plus Java était censé écraser PHP, GWT devait arrêter Javascript ….. résultat ils sont encore là (et GWT est carrément en train de mourir).

    Beaucoup d’autres remarques mais ça ne tiendrait pas dans un commentaire :)

    A bientôt
    Vincent

  • Emrys

    Je suis d’accord avec beaucoup de chose. Et je suis complètement d’accord pour dire que JS est vraiment horrible mais je trouve certains exemple un peux forcé comme la comparaison entre python, ruby et javascript pour la manipulation de liste. Evidement que cela est flagrant javascript n’utilise pas du tout de paradigme fonctionel alors que Python si. Et c’est bien ce qui rend python si puissant. Je te met au défit de faire la même chose en une ligne propre de code en C++ ou en Java. C’est impossible car ils n’implémente pas non plus les listes par compréhension ni même les manipulation basique de liste… pourtant ce ne sont pas des mauvais langage loin de la (même si certain discuterons ce fait pour Java).

    Après JS reste extrèmement sale. Tous les types sont conssidéré comme des flottants en mémoire, des nombres à virgule. Or, même aujourd’hui, aucun langage ni ordinateur n’est capable de géré sans erreurs les flottants. C’est une problématique qu’essaie de résoudre nos plus brillants mathématicien et qui ne semblerai trouver qu’un léger signe d’espoir dans les ordinateurs quantiques… Alors imaginer un langage entièrement basé sur des flottants ? C’est ridicule…

    Sur ceux pardonner ma sans doute très mauvaise orthographe mais je suis fatiguer et je ne me sens pas le courage de me relire !

  • Guillaume

    Super article, tu cites globalement tous les points qui m’ont fait éviter ce langage depuis depuis des années.
    Par contre je comprend pas bien pourquoi tu présentes des alternatives en fin d’article alors qu’il semblait pourtant en début d’article que JS n’avait pas d’alternative… ?

  • François de Campredon

    Il faudrait peut être un tout petit peu s’intéresser a un language apprendre a le maitriser avant de parler pour dire ce genre d’absurdité.
    Le JavaScript est loin d’être parfait mais c’est un language intéressant hybride entre un language fonctionnel et orienté objet. Ce n’est pas parce qu’il casse vos habitudes pa rapport au outils que vous êtes habitué a utilisé qu’il est un ‘virus’.
    Je suis persuadé qu’il existe le même genre de billet pour tous les languages qui ont été créé et il on tous un point commun:
    Aucun intérêt.

  • Val Entin

    Ah oui, et sans node, le Javascript on en fait quoi déjà ?

    Ca fait plus de 10 ans maintenant (2003) que Adobe a commence a integrer javascript a ses principaux outils (Photoshop, Illustrator, Aftereffect, Indesign, Acrobat, etc..) pour les automatisations et ce, bien avant la creation de Node.js et du Common.js en general (2009).

    Preuves a l’appui:
    http://www.adobe.com/devnet/scripting.html
    http://en.wikipedia.org/wiki/Adobe_Photoshop_version_history#CS_.288.0.29

    Tous ces outils sont tres largement utilises, je ne pense pas m’avancer si on parle de 90% du monde de la presse, de la photo et de la video.

    Un developper JS permet en quelques lignes de code de sauver enormement de temps et d’argent pour permettre une livraison extrement rapide de contenu video ou photo avec un l’habillage graphique, application des filtres, traitement des photos automatises, etc…

    Ce qui serait extrement couteux et tres peut maintenable si on demandait de le faire a un developpeur Phyton, Ruby, C# ou C++

    Beaucoup de boites de prod utilisent javascript pour l’affichage informatif des videos de sport ou de poker sous aftereffect, les webtv etc…

    Apres, beaucoup d’autre outils utilisent tres largement javascript:
    Unity3D pour l’edition de jeux video qui propose c# ou javascript pour tes projets
    Autodesk Autocad pour les architectes, designers
    etc, etc, etc…

    Pourtant, il n’y a pas de navigateur, pas de dev system…

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

    Vous n’avez pas vu “28 jours plus tard” ? Il faut isoler le problème avant que la pandémie ne dévore l’humanité.

    C’est bien beau d’avoir le même langage partout, mais si c’est pour se trainer un boulet… Vous ne travaillerez pas plus vite.

    Oui, c’est certain qu’en C++ on se prend vachement moins la tete pour compiler une application cross plateforme avec les differents sdk…

    Moi quite a choisir, je prefere developper mon api avec des outils comme bracketshell, cordova/phonegap,appcelerator, question productivite et portabilite, je pense que ca bat tous les records.

    Maitenant qu’on peut gerrer l’affichage par GPU, avec webgl ou CSS3D, les api Javascript / CSS / HTML5 vont tres bientot atteindre les performances des application natives, tout en gardant un contenu referencable, semantique et accessible…

    Regarde du cote de famo.us.

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

    Je pense que ca doit etre aussi facile que pour un prof d’IUT ou BTS d’expliquer la notion des pointeurs et de la gestion de la memoire en C++ lors de son premier cours, tous les eleves vont commencer par le regarder avec des yeux ronds, et il va fare des schemas et des explications avec des cas pratique et petit a petit, tout le monde commence a comprendre.

    La meme en ce qui concerne la POO, les design pattern.
    Bref, faut bien que le metier rentre.

  • Sam Post author

    Comparer Javascript à C++, c’est comme comparer une raquette de badminton et une raquette de tenis, ça n’a pas de sens.

    Et les quelques exceptions que tu sites dans l’usage du JS en dehors du WEB ne sont rien comparés aux centaines de milliers d’usage de l’informatique qui n’est pas Web.

  • pouet

    Bien que cela me peine de l’admettre, je suis relativement d’accord sur le fait que la comparaison avec Python n’est pas valable. Le dev Python c’est un peu comme jouer à un jeu vidéo avec des codes de triches : c’est très amusant mais c’est du grand n’importe quoi. Python c’est le paradoxe de la liberté : comme python n’a que très peu de restrictions et n’implémente pas de paradigmes précis (on peut faire du fonctionnel, de l’objet, du MVC, etc.) on est facilement tenté d’utiliser des solutions hybrides. Et c’est là que le bât blesse. Comme les restrictions de sécurité qui existent naturellement avec d’autres langages (typage fort, scoping fin avec la notion de public, private etc.) n’existent plus, tout élément du langage appartient à une soupe informe et imprédictible. La version 3 introduit trop tard la notion de “new-style object”, mais le mal est déjà fait. En examinant une variable sur une ligne de code au hasard, impossible de deviner de quoi on parle puisque l’on traite chaînes, nombres, objets, fonctions, classes et modules comme une même entité floue dotée d’attributs. Même l’examen des méta-données ne permet pas de déterminer de façon absolue la nature d’un objet, car tout peut être redéfini récursivement, décortiqué et remodelé au runtime, opérateurs, propriétés d’objets mais aussi classes elles-mêmes (il est possible de créer dynamiquement des classes autant que de redéfinir la classe d’un objet). À l’utilisation c’est jouissif et cela permet de faire du code fun mais je ne voudrais pas bosser sur un projet à 1M lignes de codes en Python, puisqu’il faudrait paradoxalement redévelopper artificiellement d’innombrables tests de sécurité pour se prémunir d’utilisations détournée de code, ce qui arrive presque forcément dans un projet géré en équipe, surtout si le projet se maintient sur une longue période de temps et que l’équipe change en cours de route (un contexte normal d’entreprise, quoi)…

  • Sam Post author

    Je lis souvent cet argument. Pour avoir bossé sur de gros projets Python (un coup de CLOC me sort 3132 fichiers pour 517995 lignes de Python dans mon dossier de travail), je ne partage pas cette expérience.

    On sait presque toujours sur quelles types on travail. Une variable a une portée limitée, un contexte et un nom bien choisi. Les rares cas où on ne sait pas, la docstring et les comments suffisent à y répondre. Toutes ces données, tu les as déjà dans un langage statiquement typés. De temps en temps il m’arrive de me demander quel type cette variable est, mais c’est très rare, et ça se répond avec le debugger en 1 seconde puisqu’il n’y a pas besoin de recompiler.

    Le typage statique, ça apporte niveau performance, mais niveau sécurité, facilité de dev, ça n’est pas le plus que tout le monde veut vendre. Si on a des bons devs, le code est clair, documenté et testé. Tout va bien, statique ou pas statique. Si on a des devs de merde, le typage statique ne te sauvera pas du naufrage.

    C’est un faux problème.

    Le seul VRAI problème que j’ai rencontré avec le typage dynamique, c’est dans l’enseignement. Il faut faire comprendre aux gosses que les variables ont un type, et qu’ils doivent savoir lequel, à tout instant. Comme c’est pas marqué en gros devant, c’est pas évident.

  • Gring

    Le typage statique en tant que garde fou n’est intéressant que lors de la compilation. On pourrait très bien avoir des moteurs javascript de dev qui gueuleraient dès qu’une variable change de type.

    En javascript, lorsque l’on touche aux Canvas, on a soudainement un type strict correspondant à du uint8, c’est un peu foireux.

    Le problème avec le typage dynamique, avec Javascript et PHP, c’est que l’on y met des valeurs provenant de bases sql, qui ont des type numériques stricts (uint64 par exemple), qui risquent d’être arrondis en passant au type vague “number”. Pour des id, par exemple, ça fait tâche.

    Sinon, rien à voir, mais aujourd’hui on a beaucoup de “développeurs” qui savent programmer “en jQuery” (sic), mais pas en Javascript. Je trouve ça ennuyeux de charger toute une lib pour parfois 3 ou 4 lignes de code utile…

  • Sam Post author

    Dès que tu veux faire un script de plus de 10 lignes qui touche au DOM en JS, ne pas utiliser un truc style jQuery, c’est un paris très très risqué. Les chances que ça ne marche pas sur Chrome, Firefox et IE sont énormes. Notamment, toute la gestion des événements ou de l’ajax est un enfer en cross browser.

  • Gring

    C’est vrai, j’utilise aussi jQuery dans ces cas là. (Ceci dit, si tu t’arraches les cheveux une fois, après c’est réglé, tu gardes ton code dans un coin).

    En revanche, il y a beaucoup de plugins jQuery qui ne font que paraphraser les ajouts récents de Javascript (Il m’est arrivé d’intervenir pour remplacer du jQuery par du natif pour résoudre des problèmes de dégradation gracieuse).

    En fait, c’est le principe qui m’ennuie un peu. Dans la plupart des cas, on utilise jQuery juste pour écrire avec une syntaxe plus jolie. Ce genre de trucs devrait se faire à la (trans)compilation et pas à l’exécution. Ça serait super un compilateur jQuery qui n’exporterait que les parties utilisées…

  • Sylvain Pollet-Villard

    Haha je me suis bien marré en lisant cet article. Bizarrement, je suis un grand fada de JavaScript, j’en écris depuis maintenant dix ans et ce langage m’éclate toujours autant. Pourquoi je l’aime ? Peut-être parce que j’ai eu l’impression de devoir le réapprendre une dizaine de fois, et que je l’ai vu grandir, passer des scripts flocons de neige à des frameworks qui font le café, des scènes 3D tavucébo ou encore du serveur et des OS pour téléphones. La plupart des problèmes évoqués dans l’article sont bien réels, simplement on apprend à passer à côté et à se construire par-dessus le langage ses design patterns et ses bibliothèques pour retrouver un confort de codage. Oui, c’est probablement ça qui me plaît avec JavaScript, le fait qu’il soit bancal et qu’on doit pas mal bricoler autour. Une voiture qui file tout droit en silence, c’est top, mais une qui roule en zig-zag avec les suspensions qui couines, c’est bien plus marrant. Quiconque a maté les concours du JS1K reste bouche bée devant ce langage de noobs qui devient complètement ésotérique entre les mains d’experts. Tiens, j’ai écrit ça aussi : http://sylvainpv.developpez.com/tutoriels/javascript/coder-6-caracteres/ ; oui vous pouvez le dire, WTF, mais un WTF ça suscite beaucoup d’intérêt totalement injustifié, et surtout, du FUN :)

    Si je devais retenir tout ce qui me plaît dans le JavaScript et le transposer dans un langage plus “solide”, je pense qu’il s’agirait de Python. Mais tout langage a ses forces et faiblesses, et la force de JavaScript est sans aucun doute son omniprésence sur le Web, comme l’a très bien souligné l’article.

  • Nami-doc

    Salut, je fais partie de l’équipe CoffeeScript (et LiveScript — tu peux me ping sur github) et j’aimerais que tu arrêtes de poster des articles sur ton blog. Je ne te connais pas, c’est ton 1er article que j’ai lu, mais tu m’as clairement l’air incompétent. Juste, citer PHP comme un bon langage a imiter, ou alors dire que les closures sont une fonctionnalité avancée … Faut pas s’étonner de pas trouver de taf en france :/.