C'est standard tout ça ? Ni sur Toutjavascript.com, ni sur W3schools.com je n'ai trouvé de trace à ce sujet.
Ces deux sites ne sont pas forcément de très bonnes références. Je recommande plutôt d'utiliser Mozilla Developer Network. Pour naviguer facilement, DocHub est bien pratique (il reprend le contenu de MDN).
Je n'ai pas accroché à Dart. Il y a des trucs sympas mais, dans l'ensemble, c'est très lourd et pas très pratique. Ça fait vraiment penser à un JavaScript codé par des dévs Java qui sont passés à coté de tous les langages modernes (Ruby, Python, Scala, Clojure, Go, etc.).
Question bonus (encore) : existe-t-il des éditeurs qui savent faire de la complétion sur du coffeescript ?
Perso, j'utilise Vim et il fait de la complétion bête et méchante (pas d'analyse du code).
n'est-ce pas un sérieux problème si on veut avoir un code maintenable et pérenne ?
C'est effectivement un problème. J'ai déjà converti du code Coffee en JS pour bien comprendre ce qu'il faisait, mais ça reste suffisamment rare pour ne pas être bloquant.
Là où je bosse (af83), on a pas mal de projets avec du code JS et on commence aussi à en avoir quelques uns avec du coffee. Clairement, on préfère tous reprendre le code en coffee à celui en JS. Dans un cas, on a même utilisé js2coffee pour convertir le JS en Coffee avant de retravailler dessus. Et même s'il a fallu repasser à la main pour nettoyer un peu le code, on a trouvé ça efficace et on réutilisera très certainement cette technique sur d'autres projets.
utilises-tu des choses comme http://jashkenas.github.com/docco/ pour commenter ? Si oui, c'est pas un problème pour commenter les classes (j'ai toujours trouvé que le literate programming avait des problèmes avec la programmation objet)
utilises-tu des frameworks avec coffee (voir des frameworks non écrit en coffee) ? Si oui, comment gérer les multiples solutions d'héritages et de création d'objets ? Je pense par exemple à http://bolinfest.com/coffee/)
J'ai déjà utilisé Coffee dans des contextes très différents : en node.js, pour faire des plugins jquery, avec Backbone, etc. Et dans l'ensemble, ça se passe bien. Il faut dire que la plupart des frameworks ne reposent pas sur l'héritage et la création d'objets mais plus sur des fonctions.
En quoi l'utilisation est laxiste ? Les derniers trolls sur le point-virgule sont surtout des personnes qui n'ont jamais appris correctement le javascript et qui écrivent un code dépendant de la mise en forme (et donc qui foire dès qu'on le minifie)
Le troll est loin de toucher que des personnes qui ne connaissent pas bien le JS. Dans un camp (les ; à chaque fin de ligne), on trouve Brendan Eich, le créateur du langage, et Douglas Crockford (jslint, JSON). De l'autre coté, on a Isaac Z. Schlueter, actuel mainteneur de node.js, et Thomas Fuchs (Prototype, Scriptaculous, Zepto).
D'ailleurs, le code en question était valide, c'était le minificateur de Douglas Crockford qui était en faute.
Oui il y a des choses étranges, mais l'histoire de == === est loin d'être complexe
C'est quand même loin d'être simple. Il y a même un cas où a === a renvoie false.
Si on veut garder des datas sous le coude entre deux requêtes: dans un web-serveur classique, on doit passer par un fichier ou une DB quelconque, avec Node.js on peut le stocker en ram aussi longtemps qu'on veut (bon, aussi avec les complications que ca peut impliquer, mais dans certaines situation c'est très pratique).
Ça veut quand même dire que les données ne seront pas partagées entre les différentes instances du serveur. Du coup, je me suis rarement servi de cette technique. Est-ce que tu pourrais expliquer quelle genre de données tu stockes en RAM ?
Si on a des contraintes de scalabilites très fortes, avec des requêtes tres simples
Mon expérience me dirait justement le contraire. Sous de fortes charges, j'avais plutôt constaté que nodejs avait tendance à leaker de la mémoire et à avoir des connexions en erreur. Est-ce que tu pourrais partager ton expérience à ce sujet ?
Il est super pour des programmes avec IO et évènements (il est fait pour ça)
Dans une certaine mesure, oui, mais il est aussi très survendu.
J'avais fait des benchmarks pour faire un serveur HTTP en mode long-polling capable d'avoir une centaine de milliers de connexions ouvertes en attente. Sur ce scénario totalement tourné IO et événements (aucun calcul), node.js était très loin de la libev en C ou des serveurs Erlang (Mochiweb, cowboy). Et ce, que ce soit pour la charge, la consommation mémoire et, plus important, le nombre de clients en erreur.
Petite remarque en passant : la version CoffeeScript n'est pas tout à fait équivalente à la version JavaScript. Si alert venait à renvoyer false, le lien serait suivi pour la version JS mais pas pour la version Coffee. En effet, dans la version coffee, la valeur de la dernière instruction est automatiquement retournée et, quand on renvoie false à un listener jquery, ça stoppe la propagation de l'événement.
C'est pourquoi, je recommanderais plutôt cette version Coffee :
makeClickCallback=(a)->()->alert"Vous avez cliqué sur le bouton d'id #{a}"null$(document).ready()->$('#nimportequoi').clickmakeClickCallbacka
Et de manière plus générale, quand on structure son code avec des classes, c'est souvent une bonne pratique de renvoyer @ pour pouvoir facilement chaîner les appels.
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 :
Mosh est fait pour les connexions de faible qualité (wifi, 3G, etc.). Il va beaucoup mieux se comporter que ssh sur les pertes de paquet et aura une latence plus faible. Pour ceux avec une connexion filaire, ssh+screen marche très bien et mosh n'apportera rien de plus.
# Corrigé
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Typo sur http://linuxfr.org/proposer-un-contenu. Évalué à 2 (+0/-0).
C'est le bon endroit pour remonter ce genre de bugs. Merci.
[^] # Re: Essai
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi mise en forme ```text. Évalué à 2 (+0/-0).
Bon, ```text fonctionne, je ferme l'entrée.
# Essai
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi mise en forme ```text. Évalué à 2 (+0/-0).
[^] # Re: Il manque une faiblesse !
Posté par Bruno Michel (site web personnel) . En réponse au journal Réflexions à propos de NodeJS et de Javascript plus globalement. Évalué à 4.
Ces deux sites ne sont pas forcément de très bonnes références. Je recommande plutôt d'utiliser Mozilla Developer Network. Pour naviguer facilement, DocHub est bien pratique (il reprend le contenu de MDN).
[^] # Re: 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é à 2.
Je n'ai pas accroché à Dart. Il y a des trucs sympas mais, dans l'ensemble, c'est très lourd et pas très pratique. Ça fait vraiment penser à un JavaScript codé par des dévs Java qui sont passés à coté de tous les langages modernes (Ruby, Python, Scala, Clojure, Go, etc.).
Perso, j'utilise Vim et il fait de la complétion bête et méchante (pas d'analyse du code).
[^] # Re: Syntaxe de JavaScript ?
Posté par Bruno Michel (site web personnel) . En réponse au journal Réflexions à propos de NodeJS et de Javascript plus globalement. Évalué à 2.
Non, les
()
sont là comme liste de paramètres à passer à la fonction qui va être retournée. L'équivalent dans le JS est return function() {.[^] # Re: 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é à 3.
C'est effectivement un problème. J'ai déjà converti du code Coffee en JS pour bien comprendre ce qu'il faisait, mais ça reste suffisamment rare pour ne pas être bloquant.
Là où je bosse (af83), on a pas mal de projets avec du code JS et on commence aussi à en avoir quelques uns avec du coffee. Clairement, on préfère tous reprendre le code en coffee à celui en JS. Dans un cas, on a même utilisé js2coffee pour convertir le JS en Coffee avant de retravailler dessus. Et même s'il a fallu repasser à la main pour nettoyer un peu le code, on a trouvé ça efficace et on réutilisera très certainement cette technique sur d'autres projets.
Non, je n'utilise pas. Mais ça doit se faire sans trop de problème : le même auteur a bien fait http://documentcloud.github.com/backbone/docs/backbone.html .
J'ai déjà utilisé Coffee dans des contextes très différents : en node.js, pour faire des plugins jquery, avec Backbone, etc. Et dans l'ensemble, ça se passe bien. Il faut dire que la plupart des frameworks ne reposent pas sur l'héritage et la création d'objets mais plus sur des fonctions.
Pour Google Closure, je n'ai pas testé.
[^] # Re: Il manque une faiblesse !
Posté par Bruno Michel (site web personnel) . En réponse au journal Réflexions à propos de NodeJS et de Javascript plus globalement. Évalué à 4.
Le troll est loin de toucher que des personnes qui ne connaissent pas bien le JS. Dans un camp (les ; à chaque fin de ligne), on trouve Brendan Eich, le créateur du langage, et Douglas Crockford (jslint, JSON). De l'autre coté, on a Isaac Z. Schlueter, actuel mainteneur de node.js, et Thomas Fuchs (Prototype, Scriptaculous, Zepto).
D'ailleurs, le code en question était valide, c'était le minificateur de Douglas Crockford qui était en faute.
C'est quand même loin d'être simple. Il y a même un cas où
a === a
renvoiefalse
.[^] # Re: Même avis que toi
Posté par Bruno Michel (site web personnel) . En réponse au journal Réflexions à propos de NodeJS et de Javascript plus globalement. Évalué à 5.
Pourtant, Google y travaille. Ça s'appelle Native Client (NaCL). Quelques liens :
[^] # Re: Mon expérience
Posté par Bruno Michel (site web personnel) . En réponse au journal Réflexions à propos de NodeJS et de Javascript plus globalement. Évalué à 5.
Ça veut quand même dire que les données ne seront pas partagées entre les différentes instances du serveur. Du coup, je me suis rarement servi de cette technique. Est-ce que tu pourrais expliquer quelle genre de données tu stockes en RAM ?
Mon expérience me dirait justement le contraire. Sous de fortes charges, j'avais plutôt constaté que nodejs avait tendance à leaker de la mémoire et à avoir des connexions en erreur. Est-ce que tu pourrais partager ton expérience à ce sujet ?
[^] # Re: IO OK / CPU KO
Posté par Bruno Michel (site web personnel) . En réponse au journal Réflexions à propos de NodeJS et de Javascript plus globalement. Évalué à 7.
Dans une certaine mesure, oui, mais il est aussi très survendu.
J'avais fait des benchmarks pour faire un serveur HTTP en mode long-polling capable d'avoir une centaine de milliers de connexions ouvertes en attente. Sur ce scénario totalement tourné IO et événements (aucun calcul), node.js était très loin de la libev en C ou des serveurs Erlang (Mochiweb, cowboy). Et ce, que ce soit pour la charge, la consommation mémoire et, plus important, le nombre de clients en erreur.
[^] # Re: Syntaxe de JavaScript ?
Posté par Bruno Michel (site web personnel) . En réponse au journal Réflexions à propos de NodeJS et de Javascript plus globalement. Évalué à 5.
Petite remarque en passant : la version CoffeeScript n'est pas tout à fait équivalente à la version JavaScript. Si alert venait à renvoyer false, le lien serait suivi pour la version JS mais pas pour la version Coffee. En effet, dans la version coffee, la valeur de la dernière instruction est automatiquement retournée et, quand on renvoie false à un listener jquery, ça stoppe la propagation de l'événement.
C'est pourquoi, je recommanderais plutôt cette version Coffee :
Et de manière plus générale, quand on structure son code avec des classes, c'est souvent une bonne pratique de renvoyer
@
pour pouvoir facilement chaîner les appels.# 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.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 :
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 !
[^] # Re: []
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Mosh, the Mobile Shell. Évalué à 4.
Mosh est fait pour les connexions de faible qualité (wifi, 3G, etc.). Il va beaucoup mieux se comporter que ssh sur les pertes de paquet et aura une latence plus faible. Pour ceux avec une connexion filaire, ssh+screen marche très bien et mosh n'apportera rien de plus.
[^] # Re: Et ?
Posté par Bruno Michel (site web personnel) . En réponse au journal Juste un bug idiot.. Évalué à 4.
Je confirme : https://github.com/nono/linuxfr.org/blob/master/lib/lfmarkdown.rb#L76-81
[^] # Re: Et ?
Posté par Bruno Michel (site web personnel) . En réponse au journal Juste un bug idiot.. Évalué à 4.
Pourtant, il me semblait bien avoir codé le remplacement des espaces par des espaces insécables avant les caractères de ponctuation double.
[^] # Re: Et ?
Posté par Bruno Michel (site web personnel) . En réponse au journal Juste un bug idiot.. Évalué à 4.
Je me permets de faire un peu de publicité pour un billet de blog que j'ai écrit récemment à ce sujet : Les espaces insécables pour les codeurs.
# Non
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Lien vers la tribune sur la page d'accueil . Évalué à 2 (+0/-0).
Non, il n'est pas prévu de remettre un lien vers la tribune sur la page d'accueil pour le moment.
# Patch accepté
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Ajouter la balise meta viewport. Évalué à 3 (+0/-0).
Merci pour le patch, je l'ai accepté. Cf https://github.com/nono/linuxfr.org/commit/055ebfbc318dae1cd32fc8639df64c27dd6b65ce
[^] # Re: Code
Posté par Bruno Michel (site web personnel) . En réponse au journal DLFP nous espionne ! Et c'est pas beau à voir.. Évalué à 3.
Oumph a pris 3 captures d'écran :
# Code
Posté par Bruno Michel (site web personnel) . En réponse au journal DLFP nous espionne ! Et c'est pas beau à voir.. Évalué à 3.
Si certains veulent voir le code qui a servi pour ce poisson d'avril, ça se passe par là : https://github.com/nono/linuxfr.org/commit/16c5e7c
# Lecture recommandée
Posté par Bruno Michel (site web personnel) . En réponse au journal Gérer sa paperasse quand on est une feignas^W^W un programmeur. Évalué à 2.
Pour aller (vraiment) plus loin, je conseille la lecture de Your life uploaded.
[^] # Re: HS
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Coloriser la sortie d'une commande arbitraire. Évalué à 8.
Il y a par exemple TermKit. J'avais vu d'autres terminaux dans le même style, mais pas moyen de remettre la main dessus.
# Cf
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Raccourcis-clavier écrasés. Évalué à 2 (+0/-0).
Cf http://linuxfr.org/suivi/ctrl-t-dans-le-champ-de-commentaire-empeche-d-ouvrir-un-nouvel-onglet
# Doublon
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Ctrl+T dans le champ de commentaire empêche d'ouvrir un nouvel onglet. Évalué à 3 (+0/-0).
Cf http://linuxfr.org/suivi/raccourcis-clavier-ecrases