Je connais relativement bien Node.js, j'ai sûrement été parmi les premiers à m'y intéresser en France, j'ai commencé à jouer avec en 2009 alors qu'il n'était encore qu'en version 0.1, j'ai développé plusieurs applications node.js qui sont en production, etc.
Et j'ai un avis relativement mitigé dessus. D'un coté, il y a clairement une très bonne dynamique, plein de nouveaux projets, une communauté active. Et ça utilise JavaScript, le langage avec la plus forte concurrence entre les implémentations. V8 et compagnie bénéficient d'une force de frappe bien plus conséquente que tous les interpréteurs Ruby et Python réunis peuvent avoir et ça se ressent en termes d'optimisations.
Mais je n'ai pourtant pas souvent envie d'utiliser node.js. Pour faire des applications web complexes, on est vraiment loin de ce que peut proposer Rails, Django ou même les frameworks PHP. Node.js vise beaucoup plus les API REST et les communications serveur à serveur en HTTP ou avec d'autres protocoles.
Sauf que pour ce genre d'applications, je préfère utiliser d'autres langages de programmation comme Go. Le code node.js a trop vite tendance à être mal organisé, on se retrouve avec des callbacks dans tous les sens. Mais surtout, ça peut très vite devenir un enfer à débugger : on devrait avoir tel callback qui se déclenche mais, dans certaines conditions, ça n'arrive pas et là, bon courage pour trouver le bug. On ne peut pas poser de point d'arrêt ou de console.log sur du code qui n'est pas exécuté. On peut faire ça sur les fonctions qui enregistrent le callback mais on se retrouve avec beaucoup de bruits : plein de logs auxquels ils faut pouvoir rattacher un contexte.
Le partage de code entre client et serveur
Pour moi, avoir une même base de code qui tourne coté client et coté serveur est juste un mythe. Partager des templates, c'est facile, on peut même le faire avec d'autres langages. Par exemple, ça m'a déjà arrivé de partager des templates mustache entre du Ruby coté serveur et du JS dans un navigateur. On peut aussi concevoir de partager des règles de validation de formulaire entre les deux cotés (surtout si celle-ci peuvent être décrites en html5).
Par contre, aller plus loin n'est pas franchement une bonne idée. La manière de structurer du code complexe n'est pas le même entre le coté client (backbone par exemple) et coté serveur. Ce ne sont pas non plus les mêmes API. On peut faire tourner jQuery coté serveur mais je n'ai pas encore vu un cas où ça avait été concluant. L'accès aux données ne se fait pas de la même façon, ni la gestion de l'authentification ou des permissions.
Bref, partager du code entre client et serveur peut se faire à petite échelle. Mais vouloir avoir une seule application qui tourne aussi bien coté client que coté serveur est juste une fausse bonne idée qui peut vite se transformer en très mauvaise idée.
CoffeeScript
Je trouve que CoffeeScript est une grande avancée par rapport à JavaScript. Ça aide bien à structurer son code, à construire des classes plutôt que des fonctions en vrac. Ça apporte aussi des trucs totalement indispensables comme => (ça crée une fonction et ça bind le this à l'objet auquel la fonction est attachée, ça devrait être le défaut en JS).
Mais ce n'est pas parfait : ça rajoute une étape de compilation, ça complique un peu le débug (on arrive facilement à faire la correspondance entre du code Coffee et le code JS généré mais les numéros de ligne ne sont plus les mêmes ; heureusement SourceMap devrait résoudre ça) et surtout, la syntaxe basée sur l'indentation avec peu de parenthèses et d'accolades donne un style assez bizarre et difficile à relire. Quelques exemples assez courts pris sur un projet récent :
# Mon avis
Posté par Bruno Michel (site web personnel) . En réponse au journal Réflexions à propos de NodeJS et de Javascript plus globalement. Évalué à 10.
Sommaire
Mon avis sur node.js
Je connais relativement bien Node.js, j'ai sûrement été parmi les premiers à m'y intéresser en France, j'ai commencé à jouer avec en 2009 alors qu'il n'était encore qu'en version 0.1, j'ai développé plusieurs applications node.js qui sont en production, etc.
Et j'ai un avis relativement mitigé dessus. D'un coté, il y a clairement une très bonne dynamique, plein de nouveaux projets, une communauté active. Et ça utilise JavaScript, le langage avec la plus forte concurrence entre les implémentations. V8 et compagnie bénéficient d'une force de frappe bien plus conséquente que tous les interpréteurs Ruby et Python réunis peuvent avoir et ça se ressent en termes d'optimisations.
Mais je n'ai pourtant pas souvent envie d'utiliser node.js. Pour faire des applications web complexes, on est vraiment loin de ce que peut proposer Rails, Django ou même les frameworks PHP. Node.js vise beaucoup plus les API REST et les communications serveur à serveur en HTTP ou avec d'autres protocoles.
Sauf que pour ce genre d'applications, je préfère utiliser d'autres langages de programmation comme Go. Le code node.js a trop vite tendance à être mal organisé, on se retrouve avec des callbacks dans tous les sens. Mais surtout, ça peut très vite devenir un enfer à débugger : on devrait avoir tel callback qui se déclenche mais, dans certaines conditions, ça n'arrive pas et là, bon courage pour trouver le bug. On ne peut pas poser de point d'arrêt ou de
console.logsur du code qui n'est pas exécuté. On peut faire ça sur les fonctions qui enregistrent le callback mais on se retrouve avec beaucoup de bruits : plein de logs auxquels ils faut pouvoir rattacher un contexte.Le partage de code entre client et serveur
Pour moi, avoir une même base de code qui tourne coté client et coté serveur est juste un mythe. Partager des templates, c'est facile, on peut même le faire avec d'autres langages. Par exemple, ça m'a déjà arrivé de partager des templates mustache entre du Ruby coté serveur et du JS dans un navigateur. On peut aussi concevoir de partager des règles de validation de formulaire entre les deux cotés (surtout si celle-ci peuvent être décrites en html5).
Par contre, aller plus loin n'est pas franchement une bonne idée. La manière de structurer du code complexe n'est pas le même entre le coté client (backbone par exemple) et coté serveur. Ce ne sont pas non plus les mêmes API. On peut faire tourner jQuery coté serveur mais je n'ai pas encore vu un cas où ça avait été concluant. L'accès aux données ne se fait pas de la même façon, ni la gestion de l'authentification ou des permissions.
Bref, partager du code entre client et serveur peut se faire à petite échelle. Mais vouloir avoir une seule application qui tourne aussi bien coté client que coté serveur est juste une fausse bonne idée qui peut vite se transformer en très mauvaise idée.
CoffeeScript
Je trouve que CoffeeScript est une grande avancée par rapport à JavaScript. Ça aide bien à structurer son code, à construire des classes plutôt que des fonctions en vrac. Ça apporte aussi des trucs totalement indispensables comme
=>(ça crée une fonction et ça bind le this à l'objet auquel la fonction est attachée, ça devrait être le défaut en JS).Mais ce n'est pas parfait : ça rajoute une étape de compilation, ça complique un peu le débug (on arrive facilement à faire la correspondance entre du code Coffee et le code JS généré mais les numéros de ligne ne sont plus les mêmes ; heureusement SourceMap devrait résoudre ça) et surtout, la syntaxe basée sur l'indentation avec peu de parenthèses et d'accolades donne un style assez bizarre et difficile à relire. Quelques exemples assez courts pris sur un projet récent :
Dans l'ensemble, ça reste une grande avancée par rapport au JS de base.
Est-ce que l'on va retrouver Javascript partout ?
Je ne sais pas si on va retrouver javascript partout, mais c'est devenu un langage incontournable pour les trolls. Le dernier date, mettre ou ne pas mettre un point-virgule en fin de ligne, a violemment déchiré la communauté JS en deux camps. Ça a démarré avec https://github.com/twitter/bootstrap/issues/3057 puis c'est parti dans tous les sens. Je ne posterais qu'un seul lien pour chaque camp, mais vous pourrez sans mal en trouver plein d'autres : http://brendaneich.com/2012/04/the-infernal-semicolon/ vs http://mir.aculo.us/2012/04/16/writing-semicolon-less-javascript-the-for-people-who-want-to-get-stuff-done-edition/. Pour ma part, je suis dans le 3ème camp : faites du CoffeeScript !