J'ai fais du ménage, n'hésitez pas à m'envoyer un MP si jamais il y a des insultes

Il va falloir que j'apprenne le node.js moi

Lisarael merci, en effet j'avais pas vu que ma question avait déjà été posée
Sinon je vois que certains d'entre vous utilisent CoffeeScript, ça a quel(s) avantage(s) par rapport à du JS vanilla ?

Je suis allé voir sur Internet, et ça change radicalement la syntaxe en effet. Mais ça q l'air sympa

Le CoffeeScript est assez sympa, mais dans la réalité les gains ne sont pas si énormes. C'est intéressant de l'apprendre tout de même, c'est assez simple et peut-être que tu vas adorer. Par contre il faut connaitre le JS de toute manière.

Et puis si tu développes avec les frameworks des langages dont le coffee s'inspire (Ruby/Python/Haskell essentiellement), ça permet de rester dans un développement 'uniforme', sans avoir à changer radicalement de syntaxe entre les parties de l'application.
Pour du Ruby par exemple, avec le cycle de travail typique de Rails où on fait un peu 'tout' à la suite sur un élément puis on passe au suivant, c'est fatiguant de passer sans arrêt d'une syntaxe do/end et indentation à une syntaxe style C avec des accolades. Unifier le tout avec du Coffee permet d'alléger un peu le temps 'perdu' quand on cycle rapidement entre les langages.

Il faut se dire que CoffeeScript est à JavaScript ce que less/sass/Stylus sont à css : une syntaxe alternative qui ajoute des raccourcis et une prise en charge plus uniforme de certains aspects du langage.
Le CoffeeScript est très proche du python et du ruby, assez verbeux, facile à lire et à coder. Mais, comme dit plus haut, il vaut mieux bien connaître javascript avant de faire du Coffee (comme il vaut mien bien connaître css avant d'utiliser less/sass/Stylus).

Personnellement, depuis que je me suis mis à CoffeeScript, je fais tout mes développements ou presque avec.
Les deux seuls cas où je repasse au javascript "nature", c'est quand je dois donner cours, et quand je fais de la sous-traitance, où là je m'adapte au workflow de l'équipe que je rejoins.

Ce qui est intéressant avec CoffeeScript, c'est de prendre un peu de temps, au début, pour bien lire le code javascript généré : il est propre, clair, et utilise toutes sortes d'astuces pour optimiser au maximum le code final. C'est très instructif.

Enfin, tant qu'on parle de performances, les performances entre un fichier js "vanille" et un fichier coffee compilé, sont sensiblement égales : j'ai fait des tests il y a quelques temps, et en fonction des navigateurs, c'est parfois le js vanille qui est plus rapide (de très peu), parfois l'inverse. Un impact négligeable, donc.

Si vous voulez vous lancer et essayer CoffeeScript, je vous conseille le cours de CodeSchool, qui est très bien fait et ce boucle en une heure ou deux maximum (y a 5 ou 6 courts chapitres et les exercices qui s'y réfèrent).

Bah les cours de CodeSchool ont l'air vraiment bien, mais c'est carrément pas donné

Pas donné ?
Ça dépend comment tu t'y prends. Tu peux t'abonner pour un mois et arrêter juste avant le second mois. Du coup, tu peux rusher les cours sur un mois et en profiter pour télécharger les slides et vidéos des cours que tu as suivi, pour les garder comme archives.

Et si tu t'organises bien, sur un mois, y a moyen de te faire tous les cours du site, et donc de rentabiliser à crever ton abonnement.

Vu comme ça, 20$, c'est franchement pas cher

Bah je pense que ce que je vais faire c'est d'abord voir leurs cours gratuits, et si j'aime bien leur façon de faire j'essaierai de rusher comme tu l'as dit . Merci pour ces précisions

Je ne vais pas utiliser ce code mais juste pour savoir

Pourquoi ce code marche pour accéder à /jean/ ?

function user(app){
app.get('/jean/',function(req,res){res.end("yeah")
;});

return function(req,res,next){

res.write("ok");
next();
}
}

app.use(user(app));

Mais celui non ?

function user(app){

return function(req,res,next){
app.get('/jean/',function(req,res)
{res.end("yeah");});
res.write("ok");
next();
}
}

app.use(user(app));

Dans le second exemple, tu retournes une fonction, comme demandé, sauf que comme elle n'est assignée à aucune route, elle ne sera jamais appelée.

Ceci étant, à la relecture du code, je suis un peu perplexe... Faudrait tracer un peu pour voir ce qu'il se passe... "app" désigne quel module ?

J'ai défini app comme ceci :

var express = require('express');
var app = express();

La fonction retournée est bien appelée (car affiche "ok"), mais jamais je n'entre dans le "app.get"..

Alors qu'en plaçant cette instruction en dehors de la fonction retournée, cela fonctionne bien.

De toute façon j'utiliserai cette méthode pour les routes :
http://scotch.io/tutorials/javascript/learn-to-use-the-new-router-in-expressjs-4

--

Mais j'aimerais bien savoir techniquement où est mon erreur.

app.use() sert à déclarer des middlewares.
Idéalement, tu devrais éviter de déclarer des routes dans des middlewares, puisque ces middleware sont appelés pendant l'exécution d'une route.

Oui mais comme je l'ai dit je cherche juste à comprendre pourquoi cela marche dans un cas mais pas dans l'autre...

--

Quant à déclarer des routes dans un middleware, ce gars fait aussi dans cette vidéo.

http://vimeo.com/56166857

Et c'est qualifié de "meilleure approche" par "avetisk" : http://stackoverflow.com/questions/6059246/how-to-include-route-handlers-in-multiple-files-in-express

Dans le lien sur stack overflow, il déclare ses routes dans un module spécifique, pas dans un middleware. Et ça, on est d'accord, c'est bien (malgré tout, le post en question date un peu, et express a beaucoup évolué depuis).

Quant à ta question, c'est simplement pasque les middleware sont exécutés lors du traitement de la requête, au moment de la recherche de route qui répondent aux critères de la requête actuelle. Du coup, déclarer une route alors qu'on est en train de la traiter, c'est logique qu'il ne la voit pas.

Tes routes doivent être déclarée au chargement de ton process, pas lors du traitement de la requête.

Quant à ta question, c'est simplement pasque les middleware sont exécutés lors du traitement de la requête, au moment de la recherche de route qui répondent aux critères de la requête actuelle. Du coup, déclarer une route alors qu'on est en train de la traiter, c'est logique qu'il ne la voit pas.

D'ac, c'est l'idée semblable vers laquelle je m'étais orientée entretemps en testant ce code ci (qui marche)

Bref, il est clair qu'il s'agit uniquement de tests et rien d'autre pour visualiser le "parcours" de la requête.

--

var express = require('express');

var b = function(app){
return function(req,res,next){
var a = express();
a.get('/',function(req,res){res.end("middleware")}
);

return a(req,res,next);
}
}

var app = express();

app.use(b(app));
app.listen(4000);

Passer "app" en paramètre ne sert à rien dans ce code là. Mais c'est parce que j''ai remplacé "app" par "var a = express()"

Retourner un app(req,res,next) ne fonctionne pas, mais
a(req,res,next) oui.

Maintenant je comprends mieux pourquoi. (c'est tout ce que je voulais)

(malgré tout, le post en question date un peu, et express a beaucoup évolué depuis).

Tu as un exemple de comment c'est organisé aujourd'hui, pour les larges projets ?