Comme le titre l'indique, j'ouvre sur ce sujet dans l'optique d'avoir vos retours concernant node.js.
Après avoir fait pas mal de tests en interne et développant actuellement une application via node et me suis heurté à quelques difficultés inattendues :
Un système asynchrone qui m'a plusieurs fois apporté son lot de surprises et cela certainement par manque d'habitude. La peur de se retrouver avec un retour "undefined"
Un certain temps d'adaptation concernant la gestion des sessions : surtout entre express et socket.io (io.of('/page').authorization...).
Ca n'engage que moi mais j'ai l'impression que node tend a simplifier les choses compliquées (websocket...) et à compliquer les choses simples (sessions...).
Il semblerait également et encore une fois ça n'engage que moi que si l'on ne fait pas certains efforts inhabituels, on peut vite se retrouver avec un code spaghetti.
En revanche, le nombre impressionnant de modules à disposition m'a simplifié la tache sur plusieurs aspects :
Async pour arranger mon problème de requêtes DB sur un système asynchrone.
Mongoose pour une communication très intuitive avec mongoDB.
Nodemailer pour les envois automatiques d'e-mails : celui-ci m'a vraiment impressionné par sa simplicité.
Socket.io qui simplifie grandement la gestion des websockets même si j'ai eu du mal avec les sessions au départ.
Il y a pas mal de modules de validations de saisies, j'utilise actuellement sanitizer mais suis certain qu'il y a beaucoup mieux dans ce domaine.
Un retour sur les modules que vous utilisez et conseillez dans certains cas pourrait également m'intéresser (hors classiques comme express).
Personnellement je ne comprends absolument pas qu'on veuille à ce point faire du JavaScript. Ok, tout le monde n'a pas envie de passer par un langage raisonnable pour faire du web client… encore que j'ai vraiment du mal. Mais réécrire son code serveur avec, je ne comprends pas. JavaScript est un langage horrible.
Cela dit, c'est assez clair qu'un grand nombre des utilisateurs de Node.js sont juste des webbeux qui ne connaissent rien d'autre — ils sont éventuellement passés de PHP à JavaScript pour leur code serveur, et, comme on dit, entre la peste et le choléra…
Personnellement je ne comprends absolument pas qu'on veuille à ce point faire du JavaScript. Ok, tout le monde n'a pas envie de passer par un langage raisonnable pour faire du web *client*… encore que j'ai vraiment du mal. Mais réécrire son code serveur avec, je ne comprends pas. JavaScript est un langage horrible.
Cela dit, c'est assez clair qu'un grand nombre des utilisateurs de Node.js sont juste des webbeux qui ne connaissent rien d'autre — ils sont éventuellement passés de PHP à JavaScript pour leur code serveur, et, comme on dit, entre la peste et le choléra…
Quelle alternative au Javascript, pour dynamiser et assister là où le HTML et CSS(3) ne peuvent agir, tout en travaillant côté client. Ne travailler qu'avec des langages serveur en ne pouvant que recharger les pages (plutôt que les seules données nécessaires) est lourd (je pense à ajax).
Personnellement j'utilise encore php, je me suis pas mis à la mode du node.js (je met à jquery d'abord, j'ai un train de retard). Quelqu'un pourrait m'expliquer l'utilité d'apprendre ce nouveau langage.
- Quels sont les avantages principaux? (imemax a l'air de parler de rapidité)
J'avoue que j'ai du mal à comprendre l'utilité de NodeJS, je l'ai utilisé dans différents projets perso histoire de tester la bête et finalement je suis déçu car je n'y trouve aucune utilité réel.
Je suis bien d'accord... il devrait le rendre plus rigoureux et on se retrouverait moins souvent avec des erreurs bizarre. (Par exemple hier mon animation ne marchait pas, j'ai mis une demi heure à trouver le ; manquant, en php il l'aurait trouvé tout seul...)
Je suis bien d'accord... il devrait le rendre plus rigoureux et on se retrouverait moins souvent avec des erreurs bizarre. (Par exemple hier mon animation ne marchait pas, j'ai mis une demi heure à trouver le ; manquant, en php il l'aurait trouvé tout seul...)
Et encore, PHP est extrêmement laxiste lui-même, et n'apporte que très peu de garanties de fiabilité. Aujourd'hui on a des langages beaucoup plus fiables et élégants que ça, qui savent faire beaucoup plus que te dire « tiens tu as oublié un ; ». Par exemple, Ocsigen (pour OCaml) est capable de te dire que tu as des liens morts, ou qu'un formulaire et le code qui sert à le traiter sont incompatibles, et donc tu n'as pas besoin de tester ton application pour te rendre compte de ces problèmes. C'est un gain de temps et de fiabilité.
Imemax a écrit:
Quelle alternative au Javascript, pour dynamiser et assister là où le HTML et CSS(3) ne peuvent agir, tout en travaillant côté client.
Côté client il y a plein d'alternatives comme CoffeeScript, Dart, Elm, Roy ou même OCaml (avec Ocsigen) qui sont prometteuses, et déjà plus ou moins utilisées. Je veux dire… la liste est longue. Je ne suis pas fan de Dart ou CoffeeScript, mais je pense que les besoins du JavaScript moderne (au sens des applications qu'on essaye de faire aujourd'hui en JS) rendent intéressantes les méthodes qui ont été éprouvées pour des applications « classiques », par exemple le fait de passer par un compilateur qui va détecter automatiquement un certain nombre de tes erreurs.
Ne travailler qu'avec des langages serveur en ne pouvant que recharger les pages (plutôt que les seules données nécessaires) est lourd (je pense à ajax).
Je ne suis pas sûr de comprendre — mais si tu parles des websockets, elles n'ont pas été apportées par Node.js. Il y a des technologies qui les proposent depuis plus longtemps, et qui, même avant ça, permettaient déjà d'écrire des services web plus performants qu'avec PHP. Il y a aussi des alternatives au modèle asynchrone proposé par Node.js, qui est un peu brutal à utiliser : Erlang, Ocsigen, Go…
Je pense que le cours de M@teo21 lui-même démontre les faiblesses de Node.js : le code n'est pas particulièrement élégant (les callbacks imbriqués c'est juste une nouvelle forme de code spaghetti), il est très différent de ce que les gens connaissent déjà (donc on ne peut pas dire « il suffit de connaître JavaScript pour aborder Node »), et le code client et serveur sont somme toute très différents (ce qui contredit encore une fois ce qu'on entend souvent sur le sujet).
Et encore une fois, ça n'est pas parce que tu écris du JavaScript qui est accepté par le framework que tu as des garanties à son sujet : tu ne sais pas à quel point il peut être bugué ou non, tu ne sais pas si tu n'as pas fait d'erreurs de types, qui ne seront par conséquent détectées qu'en testant exhaustivement ton application…
Je peux facilement comprendre que l'on ne trouve aucun intérêt à un langage x ou y mais de là à se permettre de juger ses utilisateurs (sans aucune argumentation) semble inutile.
Ce sujet a dans un premier temps été créé pour ceux qui ont réellement testé node et pas forcément pour les allergiques à javascipt. Si vous ne supportez pas javascript, il serait bien entendu surprenant de passer à node.
Après, que cette solution soit appréciée ou non ne pose aucun problème seulement argumenter sa position est un minimum. Dire simplement que vous avez trouvé node décevant sans indiquer les raisons de cette déception n'apporte rien pour personne.
Je peux facilement comprendre que l'on ne trouve aucun intérêt à un langage x ou y mais de là à se permettre de juger ses utilisateurs (sans aucune argumentation) semble inutile.
J'ai juste dit que les développeurs web avaient eu tendance à ignorer tout ce qui existait avant Node.js, et à faire comme si Node avait été innovant à sa sortie. Je ne pense pas qu'ils l'aient fait par malhonnêteté, je pense que c'est vraiment une question de milieu et qu'ils n'ont jamais été très curieux avant ça (et qu'ils ne le sont pas forcément davantage maintenant). Tu dirais que tu n'es pas d'accord ?
Après, que cette solution soit appréciée ou non ne pose aucun problème seulement argumenter sa position est un minimum. Dire simplement que vous avez trouvé node décevant sans indiquer les raisons de cette déception n'apporte rien pour personne.
Je trouve que j'ai déjà copieusement argumenté. Il ne s'agit pas (seulement) d'une affaire de goûts, on ne fait pas du Node.js juste parce qu'on aime JavaScript, ou alors c'est justement cette situation qui souffre d'un défaut d'argumentation. Quand on prend le temps de se renseigner, on peut s'apercevoir qu'il y a des langages qui sont mieux foutus que JavaScript, et ça n'est pas juste une affaire de goûts, c'est avant tout une question de productivité et de confort de développement.
Il existe bien entendu un certain nombre d'alternatives à node.js comme Ocsigen ( js_of_ocaml) que tu as cité, je ne dit pas le contraire.
Après, à chacun de choisir l'utilisation de tel ou tel outil. Personnellement j'ai fait ce choix temporaire (on ne sait jamais) pour son système non-bloquant, sa communauté très active, son système de paquet (npm) et surtout afin de n'avoir qu'un seul écosystème - le système de callback me convient parfaitement en passant.
Après c'est vrai que le système asynchrone m'a beaucoup piégé au départ et que je n'ai pas réellement trouvé de communauté française.
Le deuxième point ne te visait pas mais c'est un point de vu discutable : on peut très bien choisir de passer par node.js simplement parce que l'on aime javascript mais surtout dans l'optique d'un écosystème unique.
Au final, je trouve que c'est effectivement une affaire de goûts
Il y aura toujours d'éternels débats entre les adorateurs de tel ou tel langage. Les mecs qui font du C++ crachent sur ceux qui font du java, et inversement. Ceux qui font du PHP crachent sur tout le reste. Ceux qui font du javascript n'ont pas le temps, ils sont déjà bien assez occupés à faire marcher leurs programmes.
Oui javascript a plein de défauts, mais il n'en reste pas moins un langage robuste quand on sait s'en servir. Le débutant ou autre brutasse qui code comme il coupe des arbres (à la hache) aura du mal à débugger, à faire tourner des trucs; mais quand on utilise les bons outils, et qu'on sait ce qu'on fait, rien n'empêche d'avoir les mêmes résultats en terme de fonctionnalité ou de maintenabilité.
Des callbacks à ne plus savoir qu'en faire: utilise des promises ou async.
Un typage inexistant et une coercition dégueulasse: utilise des === et vérifie les variables avant de les utiliser
Un ; oublié: Lève les yeux, la stacktrace de l'erreur te fournit largement de quoi résoudre ton problème
Tu as besoin d'une phase de compilation pour te dire qu'un formulaire est incompatible avec son traitement serveur: C'est bien, tu as enlevé les roulettes à quel âge pour faire du vélo? Dans les projets dignes de ce nom il y a toute une batterie de test qui vérifie ce genre de choses, le faire dans une phase de compilation est redondant. Quelque soit le langage ou outil utilisé, il est nécessaire de tester exhaustivement une application.
Un chose est certaine, si tu veux faire tourner un truc en front, tu devras te mettre au javascript (utiliser des langages compilant en javascript ne font pour moi que renforcer node, en lui ajoutant plus de flexibilité. Ici on parle de node, pas du javascript), alors au lieu d'avoir à gérer un autre outil, certaines personnes soucieuses de leur efficacité ont préféré travailler avec les mêmes outils côté serveur aussi.
Wallmart, Paypal, Uber... si ces mastodontes prennent le temps de reconstruire leurs outils avec node.js c'est au départ pour des problématiques de performances, mais également pour avoir à gérer des développeur polyvalents pouvant passer de back à front sans soucis particulier.
En entreprise, former une personne est une perte de temps non négligeable. Les personnes efficaces en Erlang, personnellement j'en connais pas, alors que des dév compétents en javascript, il y en a un paquet. Le choix est vite fait.
L'argument évoquant les différences entre le javascript client et le javascript serveur est pour moi sans aucune validité. En effet tu n'as pas de require('trucMachin') sur le client. Horrible.
Oui certains aspects sont différents, mais toutes les fondations du langages sont les mêmes, plus besoin de changer de syntaxe toutes les 30 minutes. En plus la majorité des outils sont utilisables des deux côtés, que ce soient loadAsh, les promises, async, moment, ou même n'importe quelle dépendance avec requireJs.
Débuter sur node est compliqué, les problématiques d'asynchronicité font qu'on s'emmêle vite les pinceaux, mais de toute façon avec n'importe quel langage, mêmes les plus stricte, c'est le développeur qui fera la qualité de son produit au final.
Node est un outil comme un autre, qui présente de très bonnes performances, des fonctionnalités qui n'ont rien à envier aux autres acteurs du marché, et une communauté large et croissante.
Personnellement je ne travaille plus qu'avec cet outil depuis 2 ans, et ne compte pas changer mon fusil d'épaule pour le moment.
J'interviens juste pour dénoncer le cliché comme quoi les devs Web ne sont pas curieux. Perso je préfère le Web, mais ça m'empêche pas d'avoir des compétences dans des langages "non-web". Je pense que c'est une généralisation de dire que les devs Web ne sont pas curieux. Si vous pensez qu'on utilise tous Node.JS partout sans réfléchir, c'est peut être vrai pour certains, mais ça dépend. La plupart du temps, on réfléchit à l'outil que l'on va utiliser, et il s'avère que Node est particulièrement bon dans plein de domaines. node-webkit permet par exemple de faire des applications imitant des clients lourds en JavaScript, avec ou sans Node.
Développeur Front-End freelance disponible pour contrats ! En guerre contre l'utilisation abusive de jQuery.
Je me permet de déterrer le sujet étant moi même en training intensif dans l'objectif de devenir Expert sous Node / V8 Engine. Moi même angelist et puriste de JavaScript (je déteste la syntaxe, sans TypeScript je deviens fou). Je suis expert en front mais je me dirige plutôt maintenant vers du C++ (Jeu-vidéo, divers besoins en alliance avec Node).
Point sur JavaScript :
Tout d'abord Javascript est un langage qui possède un style très expressif propre à lui (ce qui permet d'abstraire des codes de manière très efficace et danse là où des langes comme JAVA ou C# seront comme vous dites beaucoup plus strict et limité) ce qui impactera positivement nos frameworks, SDK et API. De plus Javascript est un langage orienté événements (et c'est bien ici où l'on voit tout l’intérêt des collections / callbacks). Un style qui lui donne d'ailleurs une grande valeur dans le monde du Scripting (un peu comme LUA ou PERL [sans les références Xd] ).
Javascript c'est aussi un langage très accessible (et oui on n'aura pas comme sur Python un tas de collections pour les arrays etc.) C'est un choix d'accessibilité mais aussi de gain de performance au niveau du JIT (V8 ou Chakra). C'est des détails que beaucoup de développeur ne prennent pas non plus en compte...
Si vous souhaitez quelque chose de plus maintenable il vous suffira de travailler avec TypeScript qui vous apportera le typage nécessaire tout en gardant la flexibilité de JavaScript (sinon ça sert à rien... Autant faire du JAVA ou du C# à partir de là).
Donc arrêtez donc de vouloir un Javascript qui n'est en rien Javascript (dans toutes architectures il y a des choix cruciaux qu'il faut comprendre). C'est comme si vous demandiez à MongoDB de rajouter des jointures -_-' mdr. Pour tout le reste n'oubliez pas que Javascript (ECMAScript) évolue tous les jours (ES6, ES7, ES8... Sans parler des drafts en phase 3,2, 1 qui sont plutôt cool).
D'expérience chez les développeurs il ressort souvent l'impression que lorsque qu'on passe de Javascript à un autre langage c'était comme si on nous menottait les mains pour nous empêcher de librement écrire notre code. Naturellement cela se traduit par une instabilité et un manque de maturité (mais Javascript n'est en rien mature ... C'est une réalité observable aussi bien en Front qu'en Back).
Après c'est comme tout (on à de l'affinité ou non).
NodeJS :
Avant tout de chose sans JavaScript il ne serait pas possible de gérer des programmes à exécution Asynchrone de manière aussi efficace au niveau du JIT. (Faite du ERLang pour test lol). Donc c'est débile de vouloir un langage comme C# ou JAVA (et d'ailleurs c'est bien pour cela qu'on Transpile Typescript hein :D).
La technologie elle est pas faite pour de la Business logic mais du traitement massif d'I/O (Serveur http avec lourde charge, Serveur TCP/UDP, Communiquer avec une base de donnée, etc...) Cela ne veut pas dire que NodeJS est plus efficace que Python (exemple) dans le traitement de l'I/O en lui même, cela veut juste dire que NodeJS est la technologie la plus efficace pour traiter plusieurs I/O en même temps. Par contre oui Ruby on rails sera bien meilleur lorsqu'il s'agit de faire de la Business logic :)
Non l'Asynchrone ne marche pas par magie... Ce qui est mono-thread c'est l'event loop... Mais derrière il y a des workers threads (voir libuv pour plus d'informations sur le sujet). Il y a des sujets sur internet sur l'efficacité de libuv à gérer le tout (c'est vraiment passionnant et intéressant).
Sans parler du faite que beaucoup de dev C++ commence à grandement apprécier le mix bas niveau / haut niveau ( Récolte et calcule en C++ , Gestion du programme en full Asynchrone en Node et JavaScript : Un combo dévastateur ). En terme de maintenabilité, charge humaine, performance etc.. c'est sans équivoque.
Et pour vous faire plaisir je vais vous dire que dans 10 ans on recherchera bien plus de développeur ECMAScript que de développeur JAVA et .NET... NodeJS va prochainement devenir incontournable dans le monde de la télécommunication, de la supervision, etc. (tous qui nécessitent des infrastructures qui requièrent des gestions massives des I/O). Je parle même pas du front avec les projets du type Houdini -_-' et des nouvelles architecture Webcomponents avec ES6. (Ont est loin de l'époque avec la vielle API du DOM ou c'était la galère...).
Bref et là j'ai même pas parlé des applications cross-platform avec Electron. Même un gamin de 8 ans il peut te pondre une app sans complexe maintenant :)
C'est court (sûrement pas complet) mais voilà je voulais intervenir Si vous avez des critiques et des feedbacks (ou des remarques sur des choses que j'aurais loupé n'hésitez pas). Je me ferais un plaisir de défendre et débattre les points forts de Node.
Cordialement,
Fraxken
- Edité par fraxken 5 novembre 2016 à 22:28:36
GENTILHOMME Thomas, Expert et Evangelist EMCASCript/Node.JS
Tu as fait un long discours, le mien sera très court :
JS est chiant à coder (oui) et assez difficile à appréhender. Par contre je suis convaincu que le langage va s'imposer pour sa disponibilité (une fois de plus) .
Pour Node, je constate que certains suivent le cours juste pour l'utilisation des sockets. Par sur qu'en enlevant ce chapitre ils soient autant intéressés.
Perso de mon côté c'est devenu extrêmement chiant de développer en Java, C#, etc. En terme de syntaxe depuis ES6 on est assez proche de Java et C# et c'est selon moi pour le meilleur, mais en terme de manière de fonctionner, V8 coule dans mon esprit comme un ruisseau chatoyant là où quand je retourne sur d'autres langages j'ai l'impression qu'on me demande de crocheter un cadenas avec les les yeux bandés.
Difficile à appréhender ? Peut-être, mais une fois toutes les règles emmagasinées, l'efficacité dans le développement s'en retrouve affecté bénéfiquement.
Manifestement le tutoriel présent sur le site est assez critiquable: très peu complet, un titre un peu mystique, outdated sur bien des points. Je ne le prendrai personnellement pas comme référence.
Quant au sockets, PHP supporte ça maintenant paraît-il.
@Getzel
Le topic est vieux, le sujet est tout à fait d'actualité !
C'est un peu too much, même avec la complétion, je pense qu'il y a moyen de faire mieux. Après quand on vient du C# ou PHP on est un peu déstabilisé avec cette notion de Prototype par exemple. L'environnement de travail aussi, même avec un IDE + console web. Mais oui on s'y fait et prend du plaisir avec.
Pour le cours, celui d'origine (SdZ) me semble le meilleur. Enfin pour les sockets ils sont disponible dans la plupart des langages.
Quand à Node, je le trouve séduisant mais je ne vois pas encore de réels projets connu reposant sur son architecture ou de jeux célèbres, donc je ne sais quoi en penser.
Faut surtout arrêter de confondre Javascript et DOM API / Vanilla Js (Hors de cela la DOM API elle est explicit, et c'est avec des API comme celle là qu'on maintient un projet sérieusement) Argumente moi ce que tu ne comprend pas dans cet commande ? ... Après avec Node on a un maintenant un support full ES6 sous le flag harmony (donc plus besoin de prototype).
Après niveau IDE il y a Visual studio code et Atom (qui possède tous deux d’excellente suite d'outils). C'est pas encore parfait, mais ça prend en maturité au fure et à mesure.
Pour les projets faut pas déconner il en a une tonne super connus comme la NASA, Netflix, Uber, Paypal etc...
GENTILHOMME Thomas, Expert et Evangelist EMCASCript/Node.JS
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Je ne suis plus modérateur, ne me contactez plus pour des demandes, je n'y répondrai pas.