La lame de fond nodejs


En ce moment côté star­tup et inno­va­teurs, les déve­lop­peurs javas­cript ont le vent en poupe. Pour autant, je ne crois pas que Javas­cript côté serveur soit le rouleau compres­seur qu’on veut nous faire croire.

La syntaxe du langage est honnête, mais a large­ment autant de points néga­tifs que de points posi­tifs par rapport à l’exis­tant ailleurs.

Si je résume, on me dit que Javas­cript a

  • Une grosse base de déve­lop­peurs à cause de son utili­sa­tion dans les pages web
  • Un runtime exis­tant sur quasi­ment toutes les machines
  • La possi­bi­lité d’avoir un seul langage côté client et côté serveur
  • Un système de proto­type
  • Un système d’event loop, api asyn­chrones et call­backs sur nodejs

La base d’uti­li­sa­teur est un facteur très impor­tant, mais sur ceux ci une frange très mineure peut se récla­mer d’avoir une bonne connais­sance de Javas­cript. Le niveau moyen est même presque pire que sur PHP. Si on se contente de ceux qui font plus de quelques lignes et qui pour­raient passer côté serveur, la base utili­sa­teur n’est plus si fantas­tique que cela. PHP ou Java en ont proba­ble­ment autant si ce n’est plus.

On trouve de quoi exécu­ter Javas­cript même sous Windows, mais au final on va instal­ler une machine virtuelle dédiée. Encore une fois, si on parle de côté serveur, Linux et autres BSD sont une bien meilleure cible et là Python ou Ruby sont par défaut, PHP est déployable faci­le­ment, Java est presque partout. Je n’ai jamais entendu dire que l’un des trois premiers souf­frait d’un frein à cause de la néces­sité d’ins­tal­la­tion sur telle ou telle machine.

La possi­bi­lité d’avoir un seul langage n’est pas à négli­ger, mais au final coder du Javas­cript pour une page web dans le navi­ga­teur n’est pas comme coder du Javas­cript pour nodejs : Les API, les perfor­mances, les besoins, tout ça est diffé­rent. Même sans ça, les partages de code entre client et serveurs reste­ront anec­do­tique, Java en a fait l’ex­pé­rience il y a long­temps. Reste la syntaxe qui est la même, et évite un nouvel appren­tis­sage, mais c’est assez faible. L’ex­per­tise dans un langage est prin­ci­pa­le­ment liée à l’API et à ses impli­ca­tions, la syntaxe de base s’ap­prend rapi­de­ment.

Le système de proto­type est effec­ti­ve­ment une des spéci­fi­ci­tés de Javas­cript par rapport aux langages courants. Ceci dit c’est un point incom­pris par quasi­ment tous les déve­lop­peurs au point que tous essayent de recréer arti­fi­ciel­le­ment un système de classe au dessus du système de proto­type. Le résul­tat est d’ailleurs un peu bancal. En théo­rie le système de proto­type ça peut être génial. Dans la réalité, sauf pour une petite mino­rité, c’est un gros point noir. Diffi­cile de consi­dé­rer ça comme un avan­tage.

Il reste un point, parti­cu­lier : Tout l’en­vi­ron­ne­ment Javas­cript côté serveur s’est construit autour d’un système asyn­chrone bourré de call­back. S’il est facile d’y faire de la program­ma­tion spaghetti, c’est aussi une grande force et la plus grande spéci­fi­cité du langage.

Avoir un système d’évent loop avec des accès asyn­chrones c’est réali­sable sur les autres langages, mais ça prend du temps. Il faut refaire tout un jeu de biblio­thèques. Les quelques essais actuels sont limi­tés, complexes à mettre en oeuvre, et surtout n’ont pas eu le coup de projec­teur qui a lancé nodejs.

Et c’est un peu ça l’idée : Rien n’em­pêche Ruby, Python ou Java de créer une biblio­thèque équi­va­lente à nodejs. S’il y a une vraie valeur ajou­tée, alors ça se fera. À ce moment là, à part le coup de projec­teur, Javas­cript n’aura plus de quoi prétendre être en avance. Ça restera un bon langage, avec une excel­lente machine virtuelle, qui méri­tera proba­ble­ment d’être côté serveur, mais pas plus que les autres. Je ne vois pas ce qui justi­fiera la lame de fond que certains imaginent.


23 réponses à “La lame de fond nodejs”

  1. Comme bien souvent dans les technos web, il ne faut pas négliger l’accessibilité à la technologie. PHP nous l’a prouvé en devenant un langage majeur malgré des fonctionnalités limités juste grâce à sa simplicité de déploiement.

    Pour avoir proposer une formation Javascript à des ingénieurs logiciel, je peux dire que le langage est très difficile d’accès. Entre les closures, les callbacks, le prototype, il y a pleins de notions à réapprendre avant d’être à l’aise dans l’écriture et la lecture de code Javascript.

    J’ai peur que même la supériorité technologique ne soit écrasé par la vague du nombre d’utilisations de solutions simples et efficaces comme Ruby on Rails ou Django. La simplicité génère du volume qui génère automatiquement de l’efficacité, plus qu’une simple « révolution » technologique.

    C’est ce qui a amené PHP devant tous les autres, Ethernet devant ATM, VHS devant Betamax, LCD devant Plasma.

  2. Le fait d’avoir un unique langage n’est pas important pour le partage de code, qui effectivement est anecdotique. Par contre ce qui est intéressant c’est le focus, on n’a plus à faire l’effort intellectuel de basculer d’un langage à un autre, d’une API à une autre, etc… On utilise les mêmes paradigmes et la même syntaxe. C’est ça la vraie valeur ajoutée de ce point.

    Quant au niveau de connaissance JS moyen, c’est vrai, mais justement il grimpe en flêche vous avez du vous en rendre compte quand-même… ce n’est pas un hasard, c’est justement parce que ces connaissances sont bien plus sollicitées, et le niveau de qualité et de maîtrise général s’en ressent. Il faut être un spectateur averti pour s’en rendre compte par contre…

    Les librairies pour les « autres langages » dont tu parles existent déjà. gevent, twisted… aucune n’a le même succès. Java propose également une API asynchrone similaire. Ça n’a pas pris autant non plus. Pourquoi ? Parce que cette question est totalement secondaire. D’ailleurs cette API est très critiquée, beaucoup préfèreraient des « Promises » ou même des coroutines.

    Ce qui explique le succès grandissant de Node.js ce sont 3 points :

    1. L’existant. Pour faire du scraping de site on peut réutiliser jQuery une fois qu’on a récupérer le DOM. Pour manipuler les dates, on peut utiliser momentjs des deux côtés. Faire de la validation de schéma JSON, idem. Générer des UUID, idem… Une quantité innombrable de librairies dont on avait l’habitude ou qu’on découvre sont utilisables côté serveur et client. C’est la partie non anecdotique du « partage de code », et qui donne un coup de boost impressionnant au démarrage.

    2. La communauté est impressionnante. C’est le même « genre » de développeurs qui font des libs incroyables sous Ruby, mais cette fois ils sont plus nombreux, ils sont parfois « powered by Google »… On a parlé de Mozilla ? Ah non, tiens tu iras leur dire que Node est juste « un truc en plus ». JS c’est leur langue natale, alors une fois dispo sur le serveur avec une belle API, c’est un peu plus qu’un outil anecdotique.

    2,5. La communauté est celle du web. Vous avez remarqué comme tous les nouveaux outils du développeur web commencent par « npm install » ? Ce n’est pas vraiment un hasard, ni une « petite mode passagère ».

    3. npm. C’est la première fois, mine de rien, qu’un gestionnaire de package résout le « dependency hell ». Et ça n’est pas grâce à un coup de génie de son concepteur, mais à l’isolation permise par JavaScript (là encore, la question du langage en lui-même prend toute son importance). Sans compter qu’il est devenu, par sa simplicité et son mode de fonctionnement anarchique, le gestionnaire préféré de plein de gens qui ne sont pas forcément des outils « serveur » (ender, bower…).

    Ce sont ces trois points : l’existant, la communauté, et npm, qui font le succès de Node. Et les deux derniers sont bien partis pour durer, et sont bien dus à JavaScript-le-langage.

    Depuis 15 ans le langage commun du Web c’est JavaScript, et aujourd’hui il explose, vous pensez vraiment que ça ne sera que passager ? Ou alors vous considérez que le Big Bang c’était un truc passager aussi :P

    • Je n’ai pas dit que c’était anecdotique, juste que côté serveur ça ira AMHA rejoindre python, php et ruby. Ni plus ni moins.

      Pour le 1. je suis désolé mais c’est un faux argument. Très peu de développeurs avant nodejs utilisent momentjs, font de la validation de schéma json, génèrent des uuid. Je ne suis d’ailleurs pas certain d’avoir croisé un jour ces trois libs côté client. Du coup non, le fait d’avoir la même API côté client ne peut expliquer la vague nodejs. Peut être que ça pourra dans un moment, mais pour l’instant ceux qui se mettent à nodejs réapprennent ces libs de zéro au contraire, donc c’est plutôt un frein qu’un accélérateur.

      2. Plus nombreux les dev js ? si on se restreint à ceux qui font du dev poussés ? je n’y crois pas une seconde. Pas par rapport à java ou php. Tiens d’ailleurs, regardons Mozilla, combien de leurs serveurs sont sous php ou python et combien sont sous node. Et comme tu dis, on parle là d’une communauté très spécifique qui tourne depuis des années essentiellement autour de javascript. Bref, bon exemple, mauvais point AMHA.
      Sors dans les lycées et les DUT, il y a bien plus de gens qui ont joué avec PHP et fait des vrais applis que de gens qui ont fait du JS pour autre chose que des trucs vraiments basiques liés aux formulaires ou à la recopie de 20 lignes de jquery.

      2.5: Je n’ai pas vraiment remarqué. C’est vrai pour certains, faux pour d’autres. Est-ce que tu n’as pas un effet d’attention du fait que tu gravites justement autour de ces technos ? Et puis oui, il y a un effet fort en ce moment, donc forcément plus d’attention. Ce que je ne crois pas c’est que cette attention va renverser l’existant plutôt que s’y ajouter.

      3. Euh, Bundle sous ruby, Composer sous php font ça très bien. Je ne connais pas assez python, .net ou java pour nommer les équivalents mais je suis certain qu’ils existent. Là je suis vraiment certain que tu as un biais d’attention du fait que tu es « dedans ».

      > Depuis 15 ans le langage commun du Web c’est JavaScript, et aujourd’hui il explose, vous pensez vraiment que ça ne sera que passager ? Ou alors vous considérez que le Big Bang c’était un truc passager aussi :P

      Passager non, mais pas « le grand soir », oui. Je pourrai d’ailleurs te retourner l’argument. Ruby, Python, PHP sont là depuis des années aussi, tu crois qu’on va tout remettre en cause juste parce qu’on a redécouvert javascript ?

      Sans compter que Javascript à 15 ans c’est comme comparer PHP/FI avec le PHP 5.5 d’aujourd’hui : rien à voir.

    • Il y a je pense ici un problème de pratique qui explique sans doute quelques fausses idées. Par contre au milieu il y a une vraie grosse erreur (et une méconnaissance d’un problème pourtant commun et important) : je t’invite à te renseigner sur la notion de « dependency hell » et comment node la résout, car mettre composer au même niveau fonctionnel c’est un peu osé ;)

    • Je crois que chacun a surtout sa lorgnette.

      Je ne dis pas que la solution de node n’est pas meilleure ou ne couvre pas des cas différents mais si tu crois que les gens vont passer en masse à Node à cause de sa gestion des dépendances je pense que tu te mets le doigt dans l’oeil jusqu’au coude, et même un peu plus loin.
      Les Composer et autres bundle couvrent 90% des besoins courants. L’intégration de dépendances conflictuelles arrivent, pas si souvent mais ça arrive. Par contre considérer que c’est un problème central des developpeurs applicatifs côté serveur actuellement, là aussi c’est osé.

      Chaque langage a ses spécificités. PHP a ses types faibles, Ruby a sa métaprogrammation et ses blocs. Certains iront certainement vers Node à cause des dépendances, peut être est-ce ton cas, mais probablement pas significativement plus en masse que ceux qui vont vers Ruby pour sa métaprogrammation. Tout ça c’est finalement assez anecdotique parce que dans les problématiques de création d’une application, ça représente assez peu de choses.

    • 1) Vous avez déjà du croiser ses libs sans vous en rendre compte. Merci RequireJS qui compile toutes tes dépendances en 1 fichier ! Et au contraire, les « noobs » de NodeJS ont très bien compris qu’une grande partie des libs front marche en back :)

      2) J’ai vu de très bon devs JS/PHP/Python/Whatever sortir de DUT/BTS ou même sortir d’un BAC. Le diplome ne caractérise pas le niveau du développeur. J’espere que vous n’êtes pas du genre à penser qu’un bon dev doit forcément avoir BAC+5 !

      3) Composer plante souvent : a cause de github (too much access), a cause d’une mise a jours foireuse d’un package, a cause d’une dépendance mal comprise… Je ne connais pas Bundle par contre. Mais NPM a réussi là ou d’autres on pas mal de soucis : bien gérer les dépendances sans s’arracher les cheveux et planter pour un rien !

      Mais je ne pense pas non plus que Node va tout changer du jours au lendemain : PHP a encore un bel avenir devant lui, Ruby/Python sont de plus en plus demandés par les entreprise… Mais Node réussi dans le fait de pouvoir rapidement sortir un prototype fonctionnel d’une application/api/… sans perdre trop de temps !

      Et pour revenir sur le CallBack Hell de Node : il suffit juste de bien penser son code et tout est résolut !

    • Euh, mais là le débat dérive tout à fait hors sujet. Je ne suis pas en train de comparer ou critiquer les mérites ou les défauts de JS et ses libs. Clairement il y a des avantages, là n’est même pas la question. Le contraire aurait été même franchement étonnant.

      Juste pour le 2, il va falloir réfléchir à où j’ai pu même approcher les propos que tu me prêtes.

      Juste sur la conclusion : la capacité à sortir rapidement un prototype fonctionnel c’est justement ce qui a très longtemps (et encore maintenant) été mis en avant pour qualifier PHP vis à vis du reste de l’écosystème. C’est aussi ce qui a provoqué la vague Rails à l’époque. Bref, reveillez-vous si vous pensez que c’est l’argument ultime, surtout si vous contrebalancez certains points moins positifs avec un simple « il suffit de bien coder ».

    • « Il suffit de bien penser son code » : oh ben, s’il suffit de bien travailler on n’a plus besoin de formation et le langage n’a plus besoin d’être accessible :-)

  3. La vague Javascript est bien en marche. Tu ne parles ici que du serveur et du navigateur, mais Javascript est partout :
    – téléphones (FFOS, Tizen, PhoneGap)
    – OS (Windows 8, Gnome 3)
    – électronique (Arduino)
    – embarqué (RaspberryPi)
    – serveur (NodeJS dans le cloud, sur dédié, pour du web ou du SMTP, du CLI whatelse ?).
    – dans le Chrome de nombreux logiciels (navigateurs pour les extensions Opéra, Webkit, Firefox, pour Thunderbird, SunBird whatelse ?).

    Et demain, ça sera la télé, la voiture, le frigo, les routeurs etc… Pour des raisons simples, notamment, mais non-exclusivement :
    – Javascript est connu. Tu trouves que beaucoup de développeurs Js sont des noobs. Je suis ok avec toi. Mais c’est pas la peine d’être un champion du prototype pour faire quelques lignes de codes Javascript pour modifier le comportement d’un logiciel. Mais en même temps, la Js rockstar va pouvoir s’éclater les moignons à développer des applications hyper évoluées. Javascript est connu parce que c’est le passage obligé pour faire du web. Le web emporte tous les pans du secteur logiciel, il ne faut pas s’étonner que le ras de marée Javascript soit à la hauteur de son épicentre.
    – Javascript est prévu pour : le but de Javascript est d’être intégré dans des logiciels tiers, c’est donc pour cela qu’il est privilégié par la plupart des plateformes.
    – Javascript est puissant et fiable : la compétition des navigateurs fait rage, et c’est Javascript qui en profite grâce à toutes ses implémentations qui le tirent vers le haut et la performance.
    – Javascript est fait de compromis : Tu as Microsoft, Mozilla, Google et Apple qui doivent s’entendre sur l’évolution de Javascript. Tu as pas un dictateur bienveillant ou un lead développeur qui fait un caca nerveux pour imposer sa vision du projet.

    Le truc, c’est qu’en étant développeur Javascript, tu peux tout faire et tu es sûr que ton langage passera pas aux oubliettes simplement parce que c’est la norme dans le navigateur. Je peux me tromper, mais parier sur Javascript, pour un développeur, c’est s’assurer un emploi à vie.

    Bref, pour moi, la vague Javascript est bien là. Va-t-elle s’imposer sur le serveur ? Sûrement, à 90%.

    • Euh, non mais soit c’est une caricature ?

      Que je ne crois pas à la déferlante majoritaire et que d’autres soient en désaccord on peut le discuter. Je le fais avec Nicolas Chambrier, même si probablement nous garderons deux visions différentes.

      Par contre, 90% ? sérieusement ? je ne suis même pas certain qu’il soit pertinent de discuter.

      Tes arguments sont tous valables pour PHP, Java, Ruby, Python, sauf peut être le dernier mais on peut en donner d’autres. Alors non Javascript ne passera pas aux oubliettes, mais si tu crois vraiment aux 90%, alors il faut regarder autour de toi et relativiser ce que tu vis.

  4. C’est marrant de voir l’enthousiasme des nouveaux développeurs sur Javascript. Comment cette nouvelle technologie va révolutionner le monde de la programmation et s’imposer comme nouvelle solution à tous les problèmes.

    C’est le même enthousiasme que nous avions sur Java, puis PHP, puis Ruby, puis Python.

    Finalement, Javascript ne sera qu’un outil parmi d’autres dans la sphère du développeur web. Si la vague NoodeJS peut pousser les développeurs à mieux connaitre ce langage, tant mieux, mais ça ne révolutionnera pas le développement web.

    Aucune technologie ne l’a jamais fait seul. There is no silver bullet.

  5. Merci Edas pour ce billet, j’accroche tout à fait à cette vision :)

    Pour répondre à plusieurs commentaires-ci dessus, particulièrement sur le point « communauté », en effet, une majorité du développement JS à l’heure actuelle est d’un niveau peu poussé et passer à du développement côté serveur, particulièrement sur du bas niveau, c’est une autre paire de manche.
    Je vois particulièrement le problème à mon poste actuel : on fait du JS bas niveau pour de l’applicatif interne (et non pour du web). Et les problèmes qu’on rencontre (bugs bas niveau, comportements tordus des moteurs JS …) ne sont, la plupart, pas encore connus de la communauté JS, car les seuls à faire vraiment des dev’ poussés dans ce langage, ce sont les développeurs des frameworks : une minorité.

    Donc il est un peu « tôt » pour parier sur une hégémonie de JS, surtout quand on voit Google & Co’ chercher à développer des alternatives pour pallier au grand age de JS.

    Donc oui, c’est excitant de voir le JS, si longtemps sous-estimé, acquérir ses lettres de noblesses. Mais pas de précipitation ;)

  6. Quelques rappels historiques :
    – avoir le même langage côté client Web et côté serveur Web, on a déjà eu ça, à la fois côté Netscape (avec LiveScript renommé JavaScript), et à la fois côté Microsoft (avec VBScript) ; donc technologiquement c’est du déjà vu
    – JavaScript côté OS on a déjà vu y’a des années quand Apple a fait la nique à Konfabulator (avec au passage l’API propriétaire Canvas qui est devenue magiquement standard quelques années après dans un magnifique processus *communautaire* (ahem))
    – npm ne résoud pas le Dependency Hell, aka unification des versions des bibliothèques partagées, vu qu’il fait sauter la notion de partage ; c’est en effet un effet de bord du « modèle de programmation JavaScript » basé sur… l’include à l’exécution… c’est-à-dire qu’on a exactement le même en PHP en faisant attention à ne pas taper dans l’espace de nommage global, et on a le même genre de fonctionnalité en Java avec la hiérarchie de classloaders (ou pire / mieux encore avec OSGi)
    – en même temps, la notion de bibliothèque en JavaScript pourrait être un poil plus propre si on avait des espaces de nom, mais, curieusement, ça a été mis à la poubelle par cette merveilleuse alliance de développeurs de navigateurs qui a réussi à ne pas s’entendre avec (à l’époque) le plus important développeur de runtime JavaScript hors navigateur : Adobe

    Ceci étant dit, il faut toujours qu’il y ait un langage qui fasse le buzz, en ce moment c’est JavaScript pour une partie de l’internet, tant mieux pour les zélotes insupportables de node.js, moi j’attends Golo, parce que c’est quand même celui qui a le nom le plus prometteur.

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

    • Je n’aime pas les arguments d’autorité, mais je pense qu’un tour sur mon CV ou une recherche sur mon nom dans votre moteur de recherche favori pourrait vous faire prendre conscience que le bashing n’est pas approprié.
      Si vous pensez que mes réflexions sont celles de quelqu’un qui n’a que quelques lignes de js dans les pattes, qui n’a pas testé sérieusement, qui n’a pas compris les bibliothèques à base de fermetures lexicales, c’est que vous partez d’un préjugé bien méchant sur le fait que quelqu’un qui n’a pas votre avis est forcément un incompétent ou un ignorant.

      Bref, si vous parliez du fond au lieu d’avancer comme seul argument que « si l’auteur testait un peu il se rendrait compte », peut être que ça aurait un peu de pertinence. Là en plus d’être insultant, vous êtes à côté de la plaque

    • Il n’y a pas (de volonté de) bashing dans mon commentaire, ou une quelconque remise en question de vos compétences. C’était vraiment un commentaire sincère dans le but de faire avancer le schmilblick et de partager mon expérience sur le sujet. Mes excuses si mon expression maladroite vous a crispé.

      Pour être moi-même un bon routard du développement depuis quelques décennies, je sais aussi à quel point on peut « s’enfermer l’esprit ». A force de pratiquer une techno ou une « manière de faire », on finit par intérioriser un peu trop ses paradigmes propres, et avoir tendance à ne plus voir que par ce point de vue là.
      J’en parle d’autant plus facilement que ce fut mon cas concernant le JS que je n’avais toujours considéré que comme un langage brouillon, qui ne sortait jamais du cadre d’un browser, qui était la pour un peu de ‘sugar’ dans une page web, qui ne permettait pas grand chose pour du b’eau’ code bien organisé avec de beaux patterns dedans, etc…
      Bref, ce « quelqu’un qui n’a pas votre avis » que vous évoquez, c’est pas un « idiot » ou un « ignorant » pour moi: c’est justement moi il y a pas plus tard qu’il n’y a pas si longtemps.

      Partant de là, j’ai eu l’occasion de découvrir le JS autrement (dans un contexte de scripting dans de l’application métier), ou on se retrouve totalement en dehors de toute problématique web, browser, DOM, etc. Ca a été l’occasion de (re)découvrir le JS en tant que langage ‘pur’ sous un angle et un éclairage clairement différent.

      Et enfin j’ai renoué plus récemment sur des projets avec des problématiques web. Et cette utilisation précédente du JS dans un autre contexte m’a permis d’aborder la découverte de NodeJs, je pense, dans un autre état d’esprit et sous un autre angle.

      C’est ce que je veux dire quand je conseille de tester par soi-même de façon plus approfondie. C’est tout l’inverse de dire « si l’auteur testait un peu il se rendrait compte ». Ce que je veux dire, c’est que (pour moi) changer cet angle de vue qui permet de prendre l’ampleur de la valeur ajoutée de ces nouveaux concepts demande un temps d’adaptation pour – un peu – désapprendre certains réflexes.

      Voilà pour l’état d’esprit de mon comm précédent.
      Conernant le fond, il me semble l’avoir déjà un minimum évoqué dans mon commentaire de 500 mots. Si je dois garder une chose, c’est cette évolution de l’architecture même des responsabilités dans un service web:

      Si on reprend l’architecutre « trois tiers », on a les technos actuelles (par exemple du LAMP) qui sont globalement organisées comme suit:
      – la couche data, côté serveur (une bonne base MySQL + des fichiers d’assets: CSS, images, contenu statique, …)
      – la couche logique, côté serveur (le ‘controlleur’ PHP par exemple)
      – la couche présentation, en grande partie côté serveur (la ‘vue’ en PHP) qui génère du HTML qui sera transmise au client
      – le rendu lui même (sous couche de la couche présentation) qui sera peu ou prou la seule chose dévolue au client: à partir du code HTML généré par le serveur et transmis au client, le browser va faire le rendu à l’écran.

      Pour reprendre mon comm précédent, c’est l’analogie avec le ‘terminal léger’, le citrix: un client qui ne fait que du rendu, et presque tout le reste a été pré-mâché par le serveur.

      NodeJs pour moi, c’est glisser vers une réorganisation pour faire migrer plus de responsabilités du côté du client:
      – la couche (accès aux) data, reste côté serveur
      – la couche logique, n’est plus (seulement) côté serveur, mais elle arrive du côté du client. C’est lui qui à partir de la récupération sur le serveur des données (quasi)brutes issues de la couche data du serveur va exécuter la logique chez le client.
      – la couche présentation migre également du côté client: il récupère parmi les assets les templates et autres vues écrites en JS et c’est lui qui va construire l’HTML (ou plutôt le DOM) qui composera la page. Ce n’est plus le serveur qui s’en occupe.

      – la partie ‘rendu’ de notre couche présentation reste évidemment côté client.

      On voit au travers de cet exemple le ‘gap’ entre les deux approches.

      A noter que la couche data, dans le cadre de besoins d’applicatif ‘offline’ est également déportée partiellement du côté du client: ce dernier est capable de gérer une copie d’une partition des données stockées côté serveur et de les synchroniser avec le serveur quand on est en ligne.

      Avec cette nouvelle organisation, on se retrouve avec les même paradigmes que les applications de bureau dites ‘client lourd’: tout se passe côté client, il ne reste plus guère que le stockage, l’accès et le contrôle des données qui reste côté serveur. Tout le reste, y compris la construction du contenu de l’interface, la logique métier, etc.. peuvent être traitées en local côté client, pour plus de réactivité, un allègement de la charge côté serveur, une meilleure homogénéité, une capacité à gérer de l’offline, etc…

      Dans ce cadre, je ne suis pas d’accord par exemple avec l’affirmation comme quoi  » les partages de code entre client et serveurs resteront anecdotique ». On voit bien au contraire que la grosse majorité du code va être commune (logique métier, couche présentation).
      En ce sens, avoir une unicité de langage des deux côtés devient un point essentiel ; on est au delà de la seule problématique de savoir si « la syntaxe qui est la même » permet de diminuer à la marge l’effort global. C’est un besoin central de cette nouvelle façon d’organiser les responsabilités entre le client et le serveur.

      PS: à propos de « la base de développeurs » et la montée en compétence, ce n’est pas pour moi un argument. Le passé a montré que ce qui faisait réellement bouger les lignes sont les innovations majeures dans l’architecture et l’organisation du code, pas dans telle ou telle spécificité de tel outil technique.
      Les dernières grandes évolutions, ce sont par exemple l’avènement de la programmation orientée objet (plus de 30 ans, ça rajeunit pas), et la démocratisation massive de l’emploi des design patterns dans le quotidien du développeur (MVC, etc…).
      C’est pourquoi je ne pense pas que « la lame de fond » soit en fait tant reliée à NodeJs que ça. Elle est surtout reliée aux changements plus profonds de paradigmes que j’ai essayer d’illustrer ci-avant ; NodeJs n’étant qu’un outil qui s’avère un des premier à pousser ce paradigme aussi loin.

    • Ah mais je parlais d’un tout autre sujet. Le changement de paradigme avec déport de plus de travail sur le client maintenant que le navigateur est une boite à outils avec des API évoluées, nous sommes d’accord. Cela ne change pas grand chose à la techno serveur. Ton appli très javascript client, elle peut être servie par à peu près n’importe quoi. En fait justement, le serveur se restreint, ce qui rend la techno serveur encore moins importante et différenciante. Je parlais de Node.js lui-même, pas de ce glissement vers les webapp. C’est peut-être là que vient la divergence. Pour moi les deux (webapp, et le fait d’utiliser node.js côté serveur) sont totalement indépendants.

      Le seul point que je vois dans le commentaire c’est le partage de code client/serveur. J’ai vécu pas mal d’archi avec client/serveur sur le même langage, et l’histoire a plutôt montré qu’il y a peu de code applicatif commun (même si ça peut utiliser la même syntaxe et les mêmes bibliothèques techniques). Le fait que tu parles au futur (la grosse majorité du code *va* être commune) le montre d’ailleurs un peu. Quel que soit le paradigme, chaque partie (serveur, client) a sa propre responsabilité. Il est rare qu’ils fassent exactement la même tâche, et quand ça arrive ce ne sont pas avec les mêmes contraintes (forme des données sources, performance, sécurité, etc.). Pour l’instant j’entends l’argument mais j’attends de voir : Ca semble plus idéologique (on parle du futur ou de cas spécifiques, mais peu de gens le montrent en retour d’expérience).

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.