Reprise du message précédent :
Mouarf

Question probablement très bête, mais j'ai un trou :
 

 
Comment :
 
- centrer img dans le <div> (text-align sur le div, best practice ?)
- faire en sorte que <img> fasse 100% de sa taille de base (pas plus) si <div> est assez grand, mais que si <div> est plus petit que la taille de base de l'image, <img> fasse la taille de <div> et ne déborde pas.

 
 
Commme ça?: https://jsfiddle.net/myavafej/2/

exactement
 
Merci, c'est parfait

Dites vous connaissez une alternative à l'iframe ?
 
Google chrome ne prend pas en compte l'iframe de son code google calendar...
 
Je trouve ça bizarre mais bon quand on ne réfléchit pas à tout ça arrive !  
 
une idée ?

 
ça dépend complètement de ce que tu cherches à faire déjà.

Juste intégrer un google calendar à un site sous google chrome. Ca fonctionne sous firefox et IE ( à vérifier) mais pas sous chrome.

 
effectivement, j'ai lu plusieurs articles sur les events, j'aurai encore appris des choses. C'est plaisant le JS je trouve
 
Merci  

Petite question sur le .gitignore en passant:
 
je dois définir le chemin complet à partir du repository ? ou si je met "node_modules/**" il va aussi chercher ce dossier dans les sous dossiers ?

Tu peux juste ignorer le dossier, ça va ignorer tout son contenu récursivement. / est relatif à la racine de la working copy, donc /node_modules/ va ignorer le dossier node_modules qui est à la racine de la working copy (et par extension tout ce qui est dedans récursivement, git ne versionne pas les répertoires, donc ignorer un répertoire est équivalent à ignorer son contenu) alors que node_modules/ va ignorer tous les répertoires node_modules de la working copy.

Jusqu'a un certain point, quand t'arrives sur des gros projet JS, et que tu te tappes des callback hell + un scope qui se ballade partout n'importe comment.
 
Bonne chance
 
Après, sur des projets de quelques ko, ca reste cool indeed, mais sur du très gros, ouch faut que des mecs bon dans l'équipe sinon t'a vite fait de faire des truc tellement immonde...

 
Effectivement, je suis loin d'en arriver là

Pour ça ya des solutions Genre les promesses Quand t'y goûtes, tu peux pas revenir en arrière. J'veux pas faire de spam, mais c'est plutôt bien expliqué dans ce livre : http://www.editions-eni.fr/livres/ [...] 32c8f.html

Et si tu veux t'y mettre, je suggère Bluebird, qui est une bonne lib de promesses : https://github.com/petkaantonov/bluebird

edit : et une ressource en ligne pas mal : http://promise-nuggets.github.io/

Les promises sont une réponse parmi d'autres mais c'est très loin de tout régler
 
L'un des trucs d'ailleurs qui m'a fait lâcher ce projet, était la relative facilité à faire purement crasher node au moindre truc qui l'emmerde.
Couplé au fait qu'en fin de compte, par défaut, il a rien (pas de logger digne de ce nom, pas de temporisation de certaines ressources), et que donc tu te retrouves avec un projet qui part en sucette au moindre petit truc...
 
Bon, je suis reparti sur du python, du php, du java, du plus solide en fin de compte. Le JS, en heavy sur le client par contre.
 
Ca me rappelle ce commentaire d'un mec sur AMD: "if your app is simple, you don’t need build tools or module loading. If your app is more sophisticated, you’ll need both; so why not let the build tools handle the packaging for you?"
 
Pour moi les promises sont en plein dedans. Si ton projet est petit (en terme de ligne/complexité), un Node.JS + express par exemple fera l'affaire, et t'aura pas besoin des promises. Si ton projet est gros, t'a de bonne chance que Node.JS soit pas du tout taillé pour, dans sa façon de construire les modules, de les partager & co. Et donc les promises ne seront qu'un rocher pour cacher le cachalot du dessous...
 
EDIT: et pour le côté client, t'a déjà des framework nettement plus adaptés, pelle melle ExtJS et Qooxdoo en tête.
 
PS: malgré l'aigreur de ce post ( ), je suis pro JS. Qui passe ici d'ailleurs au Paris JS ? Ca fait quelques temps que j'y suis pas retourné.

j'y passe plus, chaque fois je rentre bourré et le lendemain je me rappelle meme pas de ce qui y a été présente.

 
C'est parce que demain c'est ferié, on est déjà vendredi c'est ça
 
1/ Facilité à crasher Node
2/ Pour le debugger, Node Inspector déboîte bien, pas à repprocher des choses sur le sujet.
3/ En parlant de projet, le notre (Xen Orchestra) commence à être quand même bien gros. Mais on modularise bien et je vois pas du tout ce que tu rencontre comme problème. On fait que du Node à 100% depuis début 2013, donc je pense qu'on aurait rencontré des soucis depuis le temps... par contre on a lâché PHP qui faisait bien chier avec ses libs pourries. D'ailleurs, tout est Open Source, donc tu peux même aller voir si tu veux ! https://github.com/vatesfr/
4/ Node.JS pas taillé pour un gros projet, franchement non, je suis pas DU TOUT d'accord Faut effectivement se sortir de la vision Java monolithique. Peut être un problème de perception ou de mauvaises pratiques ?
 
Après on peut trouver des défaults sur le côté client, avec Angular par exemple. C'est pas top (pas très organisé au final), même si au final ça fait l'affaire.

 
 
1/ http://blog.nodejitsu.com/keep-a-n [...] h-forever/
 
Voila, le simple fait que cette merde de forever (le PIRE truc jamais inventé sous node), existe, montre bien que oui, crasher node c'est easy.
 
Allez un autre pour la route: http://shapeshed.com/uncaught-exceptions-in-node/
"With this approach you simply let your application crash in the event of an uncaught exception and use a tool like forever or upstart to restart it (almost) instantly. Because node will write the exception to STERR your can redirect this to a log file that you can use it to assess errors at a later time."
 
Non, non, non et re-non. le QOS de merde que tu te tappes avec ce genre d'idée...
 
Cela dit oui, binder à l'arrache le process uncaught ca passe, mais que c'est laid dans l'idée que ce soit pas de base foutu
 
2/ Le passage "par défaut, il a rien", le par défaut, était important, c'est sur que si tu commences à bourinner du NPM dans tous les sens tu vas l'avoir ton système cool. Sauf que de base techniquement ya largement mieux ailleurs.
Tiens un bon exemple, get/set de cookies "sans bibli": http://stackoverflow.com/questions [...] ttp-server
Bon on est dans la catégorie du passable. Certes je n'ai jamais dit qu'il n'y avait pas moyen d'avoir un truc cool du côté de NPM.
 
Sauf qu'on en reviens à ce que je disais, je critique pas plus que ca node, je fais juste le point sur le fait que d'un côté on te vende "un truc rapide" avec "du IO async trop cool", et de l'autre, tu te retrouves avec what millier de NPM, qui en fin de compte sont loin de la rapidité espérée... C'est cet espèce de double language qui est utilisé tout autour de node et de son écosystème qui me dérange, node de base a rien, donc oui, c'est perf, ah oui mais node de base, gère pas HTTP Cache, ah et il gère pas la compression gzip, ah et...
Bon, avec express et un paquet de NPM comme dit tu l'as au final, mais les perfs ne sont définitivement pas celle que tu avais en début de course.
 
 
3/ J'irais zieuter
 
4/ Démontre moi que node est aussi bon que java pour, par exemple, structurer un webservice.
 
T'a d'un côté node et express pour le duo le plus connu, de l'autre java et Jersey. Ben Jersey + Java ca structure largement plus, et ca, quand t'a une équipe correcte mais pas non plus une dream team, ca change radicalement la qualité du projet. En l'état, actuellement, le projet tourne sous Jersey avec Morphia pour le link MongoDB.
=> Le pire c'est que le projet dont je parle tous les gus étaient pro JS loin devant, le passage node + express a donc été tenté lors du refacto du projet, et ca a largement raté suite à un soucis de structure du projet, qui certes aurai pu être géré en amont, mais qui pour autant ne serait jamais arrivé côté Jersey justement (et d'ailleurs il n'est pas arrivé côté Jersey ).
 
 
PS: et là je suis devenu l'ennemi de tous les JSiens, alors que j'aime beaucoup ce language, c'est juste cet espèce de cul entre deux chaises qui tourne autour de node et en fin de compte le rend bien moins intéressant qu'il n'y parait.
Je me fais le diable un instant de cette techno en somme

Tu ne l'as surtout jamais utilisé.

J'ai un projet en prod pour les pompiers, utilisé h24/7.Au pire,  Relancer un process n'est pas couteux si c'est prevu de base , et le service ne se relance qu'en cas d'erreur imprevue.
 
Node de base ne gere pas grand chose, mais npm est la, et je ne vois pas le lien entre modules npm et perfs . Tu as aussi la possibilité ( que je préfere) de ne pas avoir node en front, mais d'avoir un nginx qui fait la distribution entre les micro service , qui fait la compression et ger le cache

Tu compares un node nue a java plus une pile de merde, super utile.

Apache est du même principe, tout seul il ne fait que répondre à tes requêtes HTTP, rien d'autre, faut lui greffer php, rewrite, etc etc.

Justement c'est le qualité de node, c'est simplement une implem Javascript (V8) sur à un moteur d'I/O (libuv). Un peu comme le C++ qui à une lib standard très petite (qui fait le minimum), après il faut greffer (ou créer) les outils dessus.
 
Pour le probleme du crash, c'est pareil en C++ par exemple si tu ne rattrapes pas une exception.
 
Par contre je te rejoins qu'en termes de gros projects, le JS n'est pas vraiment adapté (il a jamais été prévu pour ca, et ES6 essaie juste de rétrofitter des fonctionnalités classiques dedans)
 

Tout ceci est très intéressant

En fait j'ai déjà entendu ces reproches chez des clients qu'on a formé. Ils avaient une culture .NET avec tout intégré dans un gros framework, et leurs expérimentations sur Node n'ont pas été concluantes. D'ailleurs c'est valable pour toute culture semblable (Java, PHP avec Zend etc.)

Node est, comme dit plus haut, volontairement modulaire. Oui, il faut utiliser npm, oui il faut trouver la lib qui correspond à ses besoins, et oui c'est un travail qui n'existe pas pour les gros framework : tu as une grosse lib pour parser le XML, une autre pour autre chose etc. Et pas de « choix » si j'ose dire.

À l'inverse, Node embrasse la culture de la programmation orientée composants : tu vas séparer tout ton programme en briques. Alors sans aller dans les buzzwords, comme « micro-services », je trouve que cette approche « composants » est vraiment excellente, pour plusieurs raisons (avec exemple concret chez nous) :

 * maintenance bien plus aisée (on le vit au quotidien avec XO depuis qu'on a bien modularisé : c'est VRAIMENT 100x mieux à maintenir !)
  * simplification du travail en équipe : même si on est pas nombreux, ça aide à dispatcher sur ces petites briques.
  * réutilisable : il s'avère que des modules qu'on a dev pour XO ont été réutilisés pour des soft à côté (lib de comm RPC en JSON par exemple), comme notre système de MAJ pour notre Appliance. Du coup on connait bien le module (hahaha) et ça a été enfantin de le reprendre !
  * testable : c'est plus facile de rendre testable si tu l'as pas fait au départ, un petit module que le même code plongé au milieu d'un énorme bouzin monolithique
  * plus interopérable : comme tu fais des petites modules, tu penses dès le départ à les faire parler entre eux. Du coup, ça retombe sur le coté réutilisable.

Je peux comprendre ton point de vue général, parce que c'est contre ta culture.

À noter que les gens qu'on a formé ont changé d'avis après la formation, car ils ont compris le changement de paradigme. Mais je respecte tout à fait l'autre vision des choses, ça ne me gène pas. C'est juste qu'il faut pas prendre Node pour Java.

Ça me rappelle un peu le débat Linux vs Windows, dans le fond

P.S : on utilise pas forever, on a notre appli Node qui tourne en prod chez environ ~3000 entreprises différentes, et ça roule (oui, c'est pas du SaaS, donc on a réellement notre programme qui tourne chez le client, sans le moindre contrôle dessus, a part les demandes de support si ça merde, ça tombe bien c'est plutôt calme)

P.S 2 : on utilise ES6 avec Babel.

Ok je reprend
 
Déjà tu parles à un gus qu'a fait une bonne 20 aine d'articles sur node vers la v0.4/0.6 et qui suit depuis ce stade son dev, donc je suis pas trop un débutant Tout ce que tu me dis ça va de soit que je le sais déjà
 
Reprenons, je reprend le projet dont j'ai parlé plus haut puisque c'est celui qui réellement pour moi était celui qui atteignait une taille critique pour avoir un point intéressant de comparaison, je te passe tous les projets alacon que j'ai sous node, ils sont bien trop petit pour avoir le moindre intérêt -et effectivement ceux là profitent largement de la modularité de node qu'on se le disent-.
=> Encore une fois, j'aime beaucoup node, mais non, ya un stade ou je repasse sur autre chose, une sorte de point critique ou je sais que cette modularité va plus m'emmerder que m'aider.
 
Donc, t'a d'un côté node, et de l'autre java, je passe php qui dispose tout de même d'un concurrent sérieux (laravel). Pour du webservice, les "stars" du côté de node c'est clairement express, du côté de Java c'est clairement Jersey.
 
Du côté de node, tu as NPM, du côté de Java, maven -pour le plus connu-, passons, NPM est largement devant, cela dit, maven ça tourne quand même hein.
Je te passe au passage le fait d'utiliser NPM pour servir du Java ca se fait très bien
 
Donc, faisons une comparaison assez rapide:
 

 
Ca c'est du express.
 

 
La différence est pas bien flagrante, a l'avantage de express cependant. Je passe les imports toute personne intelligente connait Ctrl + i et consort sur eclipse et compagnie. Allons plus loin: nesting resources:
 

 
Le nesting n'existe pas sous express, tu dois aller chercher un module, par exemple: https://github.com/tpeden/express-resource-new
Qui donc commence déjà à ressembler beaucoup à un joli début de callback hell, que tu vas t'empresser de corriger avec un promises/whatever.
 
Côté java:

 
 
Multiplie ça avec une 50 ène de ressources (donc GET/POST/PUT/DELETE pour chacune, avec du nested) et voila, t'a un exemple de projet qui c'est cassé la gueule avec Node, justement grâce à sa gestion qui n'a aucune structure de base. Et du côté Java ça a tenu, parce que quand t'a une URL du genre /user/:id/company/:id Le mec moyen, pas forcément super briant, ils sait quand même ou aller chercher, il faut juste qu'il ouvre CompanyResource.java, et s'il cherche un bug, il part de UserResource pour aller voir pourquoi dans ce cas, le passage  à CompanyResource merde  
 
Maintenant rajoute la maintenance par dessus: ta ressource change de nom, ben bien le bonsoir avec express, avec Java, tu touches une ligne.
 
Et pour la modularité, les deux sont modulaires, si tu veux servir du JSON avec Jersey, t'ajoute 3 lignes dans la maven, tu veux de la validation automatique, ben t'a oval qui pareil va te donner en quelques lignes dans maven ton truc, de l'envoi de mail, idem.
 
Je te l'accorde cela dit que Maven est moins bien que NPM, rien à redire là dessus, sauf que beaucoup de projet java aujourd'hui s'installent aussi facilement que du NPM    
 
 
Pour terminer, le choix de Node à ce moment là était pour profiter de l'async et surtout du web socket qui nous intéressait fortement, puisqu'on a des parties temps réel sérieusement critique. Mais finalement vu que le projet c'est cassé la gueule, on c'est simplement rendu compte que Java le faisait tout aussi bien: https://github.com/Atmosphere/atmosphere
 
 
Maintenant la modularité. Ben chez nous on a foutu une 10ène de jetty qui servent tous un WS autonome, un Haproxy devant, voila, chaque brique est réutilisable, chaque brique sert un point précis de l'ensemble, et derrière cette dizaine de jetty, le haproxy créé un front unique pour tous les projets. Ce qui, a mon avis, n'a rien à envier à ce que pourrait proposer node dans sa modularité.
Et dans le cas de portion de code, encore une fois avoir un manager local pour les packages local maven, ca nous a pris 2j a faire, et ca tourne aussi bien que du NPM depuis un repos GIT perso.
Genre on fait mvn-local install monSuperPackage
Il va chercher dans notre git, et l'install en local. Mieux, on utilise package.json donc ca s'installe aussi avec NPM si un mec tombe sur un bug ou autre.
 
 
Bon, je sais bien que tout le monde déteste Java, mais Java a changer au même titre que tous les autres langages, et si votre seule expérience c'est du gros mainframe Spring, c'est sur qu'on ne parle en fin de compte pas du même Java hein.
 
Avec une solution comme ca, on tout ce qu'il faut, et une structure largement plus propre de base    
 
 
J'en reviens à ce que je disais: j'aime le JS, je suis pas débutant loin de là, que ce soit sous node ou en front end j'ai déjà aidé pas mal de repo à faire du code bien plus propre/moins de bug, mais non, Node ne sait pas tout faire, et sa modularité, qui fait sa force, lui fait aussi défaut, puisque tu te retrouves avec des kms de projet qui emmène node là ou il n'aurait jamais du aller. A commencer par le calcul mathématique, comme chacun sait: http://stackoverflow.com/questions [...] -algorithm
Ou encore, cet article, si vous suiviez node depuis la v0.5 environ, vous avez certainement lu celui là: http://pages.citebite.com/b2x0j8q1megb
Ou encore: http://zef.me/blog/4561/node-js-an [...] event-loop
Oui, les maths avec Node, ca montre vite une limite.
 
=> Et c'est là ou arrive à un soucis: quand tu installes 14 NPM et consort, c'est modulaire, oui, sans nul doute, est ce que tu as la moindre idée s'il n'y a pas un bottleneck dans le tas ? Un loop locker qui se ballade, que tu activeras qu'une fois sur 50, et qui boum; mettera ton serveur en deny of service pour 2 sec ? Tu n'en a pas la moindre idée.
 
 
Bref, j'en reviens à ce que je disais, node pour des pti trucs, admettons, je vois bien l'idée, j'en fait moi même pas mal. Node pour du plus sérieux/lourd, j'ai jamais dit que c'était pas possible, je dis simplement que le choix est pas forcément si intelligent que ca, en reprennant justement les différents points énoncés au dessus, mais en les tournant exactement à l'envers, car en fin de compte, ta conaissance des modules que tu installes, et que tu utilises, est fort probablement proche du zero absolu.
 
Et donc, a ce jeux là, je préfère encore un truc certes un peu plus lourd (enfin cela dit allez pas comparer Spring et Jersey Jersey est plus proche d'une modularité à la node que du mainframe lourd à la Spring hein ), mais qui au moins, t'a une certitude sur la perf potentielle, parce que tu passes pas ta journée à installer des biblis dont une est tellement connue que tu es sur, mais toutes les autres tu n'en sait rien...

C'est dommage que j'ai pas le temps de répondre sur le détail technique (semaine pro peut être !), mais dans les grandes lignes :

 * je suis d'accord pour dire que la modularité est à double tranchant, même si chez nous l'avantage est >>>> aux inconvénients
  * j'ai jamais dit que je détestais Java, juste que c'est une autre façon d'aborder la conception
  * sur la modularité, je crois qu'on parle pas à la même échelle. On fait pas que du web chez nous, donc ça peut être des modules vraiment tout petits (genre des plugins, cf notre plugin LDAP pour XO qui fait moins de 150 lignes : https://github.com/vatesfr/xo-serve [...] c/index.js )
  * je reste pas d'accord sur le fait que Node est fait que pour des petits projets ou des trucs « moins sérieux ». À moins de définir une limite, nous on a pas croisé de « mur » (alors qu'on l'a eu sur PHP).
  * et je reste convaincu que c'est la même débat "Linux vs Windows" style, et que t'es plus sur le paradigme du « tout intégré » que celui de choisir des briques. C'est pas un reproche, j'insiste, c'est juste une autre façon de voir les choses.

 
 
J'attends avec plaisir ta réponse
 
Je rajoute un truc, sur lequel on a pas eu débat. La on a parlé du code, mais quid du process de recrutement sur un projet node ?
 
J'ai pu voir de mon côté que en fin de compte, il est préférable de laisser le JS a quelques gus, plutôt que de former tout le monde, car rien que la notion de prototype et les différences qui existent avec de l'objet, sont complètement absente, y compris chez des mec se présentant comme ´senior js ´...
 
Je me suis d'ailleurs posé la question de comment un projet angular par exemple peut se passer de ce côté là... La majorité des gens on fait 5 lignes de jquery a tout cassé, et donc quand tu leur présente le ´state of the art´ en js, les 3/4 sont complètement largué en 20sec top chrono...

Ca c'est facile, en 10 secondes tu demandes si le gars connait les closures / prototypes / vanillaJS, si oui, il pourra se débrouiller si non, là...

Et tu dégages combien de temps pour jeter 95% des gus

 
Je vais faire de mon mieux pour te répondre, mais je te promet rien vu mon taff
 
Bonne question pour le recrutement, à laquelle j'ai la réponse \o/
 
En effet, j'ai recruté un profil qui n'avait JAMAIS utilisé Node ni Angular. Juste un peu de JQuery, sinon c'était un dev PHP avant, dans une grosse boîte. Sachant qu'on est une startup, et que c'était notre premier salarié, tu imagines bien la pression à rater le recrutement  
 
On l'a fait partir d'une feuille blanche pour réaliser notre portail de vente directe de notre software, Angular, Node, LevelDB. Livré 1 mois plus tard, maintenu depuis mais bien extensible et ça roule bien. Depuis il est sur Xen Orchestra et les outils autour, avec encore 30% du temps à améliorer le portail (gestion des revendeurs etc.)
 
Donc la réponse est : pas de soucis pour le recrutement, il faut juste des gens curieux et passionnés. Je pense même qu'on peut retourner l'argument : c'est un facteur d'attraction de bosser sur ces technos.
 
Forcément, tu vas pas trouver de senior dev avec 10 ans d'XP sur une techno qui a pas cet âge

pas envie de répondre à tout, mais juste à ton principal exemple
pourquoi tu n'utilise pas app.use ou ( plus sexy et plus recent en express 4 app.mountpath ) ?

Juger node sur ce qu'il valait en version 0.4, est un peu la même chose que je pas aimer java a cause de swing

Autant que je sache express 4.x a un an jour pour jour si j'en crois les news de publication... On était déjà donc sur node 0.8 mini
 
Mais revenons, app.mountpath est effectivement la réponse d'express 4.x a ce soucis, en moins bien quand même, t'a plus de flexibilité du côté de Jersey, mais yen a d'autres, laravel aussi a plus de flexibilité...
 
Et pour app.use, bon, c'est le foure tout du framework donc passons. Surtout quand on parle de manque de structure hein

App.use est prévu exactement pour ton cas , non ?

Tu peux utiliser en conjonction avec app.param pour centraliser la logique de traitement des user

Que ce soit clair, il y a des choses pour lesquels node montre ses limites , mais pas tant que ce que tu peux dire

Dans mon code, les routes sont coupées par modules, avec chacun sa responsabilité + des lib partagées ( app.param, session, helper de  templates )

Oui et non, je suis entrain de te parler de la difficulté de faire travailler plusieurs personnes sur un projet sous node, d'une façon générale du manque de structure inhérent node, causant dans beaucoup d'équipes des soucis, et pas mal d'abandon de projet pur et simple.
=> Bref, une difficulté supplémentaire là ou d'autres, certes plus rigides, offres des choses sur ce point de vue là.
 
Tu me réponds app.use, certes effectivement prévu pour mon cas, mais un foure tout sans nom, ou chacun va y aller de son pti app.use pour pas retapper 3 lignes.
 
Et donc on en arrive à ce que j'ai dit plus haut: oui, mais en fait non, c'est un foure tout ce truc, et quand je te parles de structure de projet, app.use, c'est l'anti structure par excellence
 
EDIT: mais d'ailleurs tu focalises sur express parce que je prend comme exemple celui là, on peut en choisir un autre, les soucis de clarté de structure est inhérent à node plus qu'a express

 
Hey tu croyais que cette attaque frontale non argumentée sur angular allait restée impunie ?    
 
En se bougeant les fesses un minimum, on peux pondre une archi modulaire très bien organisée avec une structure de dossiers/fichiers qui n'a pas à pâlir face aux mastodontes server-side.
Surtout que les notions de bases d'angular (controllers, services, factory, templates, filters, etc) guident bien niveau structuration. Ca + les outils de packaging qui vont bien, ça me change pas trop de mes dev java (android) coté organisation carré.
 
 

Personnellement, je pense que d'avoir un projet modulaire simplifie le travail à plusieurs mains :  

• deux personnes bossent sur des parties différentes ? les impacts son minimes
• deux personnes bossent sur le même projets ? les merges sont relativement simples parceque le scope l'est aussi

Ajoute à ça deux ou trois tests, un dvcs et 90% de tes problèmes disparaissent avec des bonnes pratiques pleine de bon sens.
 
 
Cette approche n'a pas grand chose d'imposé en node, ou d'interdit avec une autre techno au passage. Tu peux aussi utiliser un framework plus vérouillé qu'express qui reste de très bas niveau. Au même titre que tu choisis un FW pour faire du java ou du PHP
 
Je ne fais que répondre à tes exemples. Mais tu peux surement me donner un exemple plus explicite qui rendrait un projet nodejs illisible dans l'absolu et en arrêtant de passer des problèmes de js, a ceux de node a ceux de surcouches.
 
Après, si ce que tu veux me faire dire est " j'ai des dev expérimenté en java, je choisi donc de bosser en java" , ça peut s'entendre, et c'est toujours mieux que du VB6 ou du cobol. Mais ça n'a rien à voir avec le langage, tu auras autant de mal à les passer en PHP ou .net, et il y a de très bons articles à lire sur le sujet, comme ceux de paypal.
 

Je pense que ce qu'il veut dire est qu'il y a pas mal de notions proches en angular (par opposition a ember par exemple qui est beaucoup plus structuré) , laissant plein de chemins différents pour réaliser la même fonctionnalité :  ou tracer la limite entre provider et service, entre directive et module+controller, .... + le fait que les scopes peuvent aussi grosir assez vite vers des trucs indigestes
Mais ici aussi, ça se règle assez bien

 
Oups, j'ai pas été clair, pardon Cf en dessous :
 

 
Voilà c'était ça. Il y a beaucoup de subtilité à cause de notions proches. D'ailleurs les dev d'Angular l'ont dit eux-même (j'ai plus la source en tête sorry).
 
La doc est pas toujours au top non plus, surtout pour expliquer ces subtilités. Bref, c'est un peu « sur-compliqué » mais c'est pas si grave

 
Alors que tu aurais choisi Ember, ca t'aurait obligé à t'organiser.

 
 
C'est surtout pas grave puisque tout part à la poubelle avec Angular 2.0

 
Je dis pas le contraire On est parti sur Angular à l'origine, on va pas tout refaire maintenant Surtout que ça reste quand même potable
 

 
Bah oui, ils ont pris du recul. Ils auraient rien changé que t'aurait dit « regardez ça bouge pas c'est dla merde et ça reste de la merde »

 
C'est pas genre l'idée 0 de l'informatique Genre ca fait 20 ans que les mecs font de l’obsolescence par eux même, comme des grands .
 
Tous les 4 matins, t'a le droit à un nouveau logiciel de la mort qui fait la retouche d'image qui va bien que l'autre faisait pas, et ca fait 20 ans que si un mec sort pas l'update de la mort qui re-scratch tout, les mecs disent "oui mais lui il évolue encore, alors on va utiliser celui là "
 
Techniquement d'ailleurs, ya pas grand chose que Java 1.4 ne savait pas déjà faire par rapport à Node, et ya pas grand chose que c++ ne savait pas déjà lui même faire par rapport à Java 1.4 Et ça recommencera dans quelques années, parce que la techno parfaite n'existe tout simplement pas

J'ai jamais dit qu'il y avait une techno parfaite.

Il y a une techno qui est plus ou moins adaptée à :

* ta façon de coder
* les besoins réels derrière

Node+NPM c'est de la programmation orientée composant (façon de faire) qui sait bien gérer les I/O avec des concepts intéressants (besoins). Et ça tourne partout (navs, OS, serveurs maintenant etc.)

D'où sa popularité.

Mais c'est pas une réponse à TOUS les besoins, j'oserai jamais prétendre un truc pareil