« la notion de bibliothèque en JavaScript pourrait être un poil plus propre si on avait des espaces de nom »

Pour dire ça, c’est que vous n’avez strictement rien compris à la logique de la gestion des librairies sous Javascript et l’emploi des closures qui permet d’arriver à un niveau d’indépendance bien plus élevé que l’emploi des Namespaces.

Pour revenir à l’article, le Javascript en tant que langage propose une souplesse et une efficience de développer sans nulle autre pareille.

S’il y a trois choses à regarder de près quand on vient de langages plus classiques (C/C++, Java, PHP, etc…), ce sont les closures, les fonctions anonymes et les capacités de réflexivité. Mais pas juste en comprennant les concepts et en lisant deux exemples ‘foo bar’ de 10 lignes pour chacun. Non, en comprenant tout l’intérêt que ça représente dans l’organisation même du code et toutes les conséquences et les possibilités que ça entraîne derrière. Et ça ne s’apprend qu’en pratiquant au minimum quelques semaines à plein temps pour un développeur déjà chevronné.

Pour l’unicité du langage des deux côtés (cli & srv), il faut comprendre que plus les choses avancent, plus la partie client embarque de la logique métier et se rapproche d’un client lourd qui s’exéctuterait dans le contexte du navigateur. Regardez en détail comment fonctionne des frameworks pour les Single Page Applications (AnularJs, Mustache, …), avec un MV* complet côté client, et le serveur qui ne sert que de garde fou (assurer la cohérence des données) et de fournisseur de données brutes (JSON des deux côtés, tout est fluide) ; avoir la même logique métier écrite une seule fois change complètement la donne.
Ce changement de paradigme n’est pas anodin, il est à peu près aussi important que la différence entre:
– un terminal léger (citrix) qui ne fait qu’afficher ce que lui dit un serveur central qui calcule tout (métier, rendu, …) et qui constitue le web actuel (en PHP par exemple, une page va s’occuper à la fois de la logique métier, l’accès aux données, et le rendu du HTML final, à peu de choses près).
– une application ‘client lourd’, ou le serveur central n’est plus qu’un fournisseur de données brutes (ressources, réponses à une query vis à vis d’une BdD) que le client utilisera pour tout construire de son côté, y compris générera le code HTML via des templates lui-même. C’est ce vers quoi on migre.

Bref, il est extrêmement complexe d’expliquer dans un article, un billet, un commentaire, à quel point NodeJs bouleverse la façon même dont ont conçoit une architecture web.
Par contre pour un développeur qui a de la bouteille, il est relativement rapide de comprendre les enjeux énormes quand on met réellement les mains de le cambouis pour un projet réel pendant quelques semaines.

Je ne peux donc que conseiller à ces derniers de tester par eux-même avec un vrai ‘hands-on’ concret, pas juste en lisant en diagonale trois ou quatres tutos sur le site du zéro.

My 2 cents.