Open source et architecture logicielle

Envoyé par r_benarbia

Pensant long terme: Je ne comprend toujours pas pourquoi ce langage peux remplacer Java surtout avec son écosystème? Merci de me changer d'avis!

Je pense que c'est rentable à long terme au niveau du coût et du temps gagné :
- Rapidité d'exécution
- Faible consommation des ressources, du coup pas besoin d'avoir une bête de course pour l'exécuter
- Rapidité dans les développements (pas besoin d'attendre les compiles de maven ou gradle ou autre), il y a même des outils qui existe pour séparer les couches proprement, minimiser les JS et le CSS : grunt, brunch...

Pour ce qui est des modules NodeJS, yen a beaucoup qui sont maintenus (express, mongodb, mysql, ...). Niveau risque, si on choisit bien ça reste limité.

J'ai toujours été intrigué par la nuance des avis autour de JavaScript, pour certains c'est le messie pour d'autre une misère, j'ai donc cherché à étudier ce langage de plus près. J'ai commencé à faire du "JavaScript" (oui je met entre guillemet vous allez comprendre pourquoi) lorsque j'ai eu besoin de pousser la richesse de mes clients légers, je me suis donc jeté sur du jQuery car ce dernier est une boite à outil (aussi lourde soit-t-elle pour certains) qui n'est pas négligeable lorsqu'on voit les patterns qu'offre ce dernier pour manipuler le DOM ou à quel point certains navigateurs sont à la ramasse (pas besoin de citer de nom, je pense que vous connaissez la réponse). A mes débuts je ne faisais pas du JavaScript mais du jQuery comme si ce dernier était LE langage et JavaScript son substitut. Avec le temps j'ai voulu en apprendre plus sur JavaScript, par curiosité et aussi par plaisir finalement, et on se rend compte que JavaScript (DOM exclu) n'est le plus mauvais langage du monde... mais il n'est pas sans défaut ! (je vous en citerais 2)

En ce qui concerne le langage de base, le typage implicite est pour moi un problème :
Après avoir gouté plusieurs langages implicitement typés (Python, PHP, JavaScript), j'en suis venu à la conclusion personnelle qu'un langage prévisible est un langage qui indique le maximum d'erreur pré-compilation, un langage explicitement typé aide forcément. Bien sûr le typage implicite n'est pas un problème lorsque le projet est géré et maintenu par 1 personne, cette personne sait forcément ce qu'il fait, mais lorsque vous avez un projet avec plusieurs développeurs, soit ces développeurs pensent tous de la même manière (ce qui est rare), soit celui qui passe derrière va recréer des roues sans le savoir. Bien sûr certains vont me parler de type hinting en PHP et plus récemment Python (PEP 484) mais il ne faut pas oublier que c'est quelque chose de facultatif et limité aux paramètres de fonction/méthode.

Un autre problème pour moi est que JavaScript n'est pas aussi "enseigné" que les autres langages :
Je ne dis pas que les tutoriels/exemples n'existent pas, il y en a de plus en plus (bons et mauvais attention ), mais si cette tâche avait été accompli plus tôt et pas suite aux engouements de Google (grâce à ses SaaS ou V8), il n'y aurait pas des gens à dire encore aujourd'hui que JavaScript n'est pas un langage objet, et j'ai fait un jour parti de ces gens là parce que je ne comprenais pas. Il y a très clairement eu un problème de communication au niveau de la programmation orienté prototype ainsi que la syntaxe pour créer des objets (que ce soit avec les functions ou object literal) dès le début je pense, maintenant Brendan Eich n'est pas trop contenant parce qu'on ajoute une syntaxe avec des class dans ECMAScript. Bref là où je veux en venir c'est que le risque avec JavaScript, c'est qu'il vaut mieux avoir une équipe d'expert que des bidouilleurs (je ne nierais pas que je suis moi-même bidouilleur des fois).

Je ne vais pas lister tous les autres problèmes de JavaScript ici, mais s'il y a une chose qui aurait pu être vraiment bien avec JavaScript c'est qu'il aurait finalement pu être le langage full stack. Vous imaginez n'avoir qu'un seul langage à gérer pour toutes les couches d'une application même si c'est du JavaScript (avec une pointe de HTML/CSS tout de même pour la Vue) ?

• Vous souhaitez faire du front ? Du JavaScript avec AngularJS1
• Vous souhaitez faire du développement mobile ? Du JavaScript avec PhoneGap/Cordova
• Vous souhaitez faire du backend ? Du JavaScript avec NodeJS

Un développeur qui maitrise JavaScript sera content, le patron aussi parce qu'il n'aura qu'un type de spécialiste à recruter, tout le monde est content... mais bon pour moi JavaScript n'est clairement pas la solution... si je reprend les 3 éléments de la liste, pour AngularJS2 on voit très clairement la volonté de ses créateurs de laisser tomber JS pour un langage plus typé et orienté classe (donc Java TypeScript), le second Apache Cordova n'a toujours pas convaincu certains concernant les richesses/performances :

Source: commitstrip

, et enfin avec tout ce que les autres plus haut ont cités notamment en ce qui concerne le manque de spécification/standardisation coté serveur par rapport à Java EE...

Je ne doute pas qu'il y aura toujours à l'avenir une base de code JS, des développeurs JS, de nouveaux projets JS (et encore, tout dépend de l'évolution d'ECMAScript)... la question qu'il faut se poser c'est : une fois que JS n'aura plus le monopole frontend (je ne prends pas en compte les langages transpilés), qu'on pourrait développer "nativement" avec d'autres langages grâce au projet WebAssembly, combien de développeurs tourneront le dos à JS ?

@+

Envoyé par r_benarbia

Pensant long terme: Je ne comprend toujours pas pourquoi ce langage peux remplacer Java surtout avec son écosystème? Merci de me changer d'avis!

Je ne milite pas ici pour remplacer JAVA par JavaScript. J'ai d'ailleurs pris dans le premier fil les précautions d'usage pour dire que JAVA (JEE), C# (.NET) et PHP étaient de formidables écosystèmes. Je dis simplement que certains projets ne nécessitent pas d'utiliser un outil aussi puissant que JEE. Je remarque également qu'utiliser un outil de cette puissance pour un projet ne le nécessitant pas, induit un gaspillage de CPU de RAM mais également et surtout de compétences pour l'administration de ce fameux écosystème. Je ne vais pas proposer ici de métriques pour définir une limite à partir de laquelle Node.js présente un ROI positif car c'est bien une équation qui est à résoudre par l'architecte. Pour ma part je remarque que les sociétés qui ont adopté Node.js pour les projets à faibles contraintes de moins de 60 hommes*jours estiment se trouver dans le seuil de rentabilité.

Quant au langage lui même, je concède que JAVA est plus propre que JavaScript. Néanmoins, JavaScript présente l'avantage d'être nativement destiné au web, quand Java nécessite l'ajout de nombreuses choses pour être full web.
Et si JAVA est plus propre que JavaScript, je ne suis pas certain que PHP puisse se prévaloir du même argument.

Ma réflexion était simplement de regarder JavaScript comme un des plus récents écosystèmes "full-stack", et qu'à ce titre, on doit évaluer la pertinence de son usage. C'est un fait, le monde avance et on ne pourra pas garder les mêmes outils pendant 30 ans. Il y a 25 ans, je développais en Cobol car c'était et ça reste un excellent langage, mais heureusement que nous n'avons pas sacrifié ses successeurs sur l'autel de la stabilité et de l'immobilisme.

Envoyé par baptistelebail

- comme dit précédemment, les modules Node n'ont pas la même stabilité/normalisation que les specs JEE. L'idée de baser son projet sur des modules qui peuvent être abandonnés n'importe quand, c'est pas rassurant.

C'est effectivement un aspect non négligeable de la problématique liée à Node.js
Mais on le retrouve dans l'écosystème JEE (hors norme), pour GWT notamment, qui devait permettre au développeurs JEE full JAVA d'éviter de mettre les mains dans JavaScript pour faire de l'AJAX sans le savoir. Et puis les gens qui ont voulu faire du GWT pur échapper à JS ont dû comprendre la notion de fonction de CallBack et ont fini par être pédagogiquement amenés vers JavaScript.

Mais pour répondre sur le fond, il me semble que l'architecte doit faire une veille technologique lui permettant d'écarter les modules les moins pérennes.

Envoyé par mangobango

Alors... de mon point de vue je ferais, avant même d'envisager de changer de backend, un "audit" des modules NodeJS à utiliser. L'écosystème autour de Node est suffisamment immature pour investir un peu de temps à tripatouiller avec les différentes solutions. Pour ma part j'ai perdu BEAUCOUP de temps avec Loopback. Je cherchais un Django-like et Loopback avait à peu près cette promesse. Mais à l'usage, il y avait des bugs de framework qui se mêlaient à mes propres bugs... situation complexe.

Après vraiment vraiment vraiment avoir trouvé les outils pour supporter le changement (et être certains des bénéfices d'un tel changement), alors peut-être.

Mais à priori, pas

Daniel

Merci Daniel pour ces précisions techniques,
Tu as parfaitement raisons et ton exemple est concret.
Mais je me rappelle que nous avions les mêmes questionnement en 2003 sur J2EE EJB 123 ou pas .....
Aujourd'hui encore, certains se posent des questions sur les meilleures bibliothèques à utiliser ainsi que leur inclusion dans le standard. Certains même, prétendent que Oracle menace l'avenir de JAVA. Et pourtant java continue son aventure depuis 20 ans

Envoyé par autran

Et puis les gens qui ont voulu faire du GWT pur échapper à JS ont dû comprendre la notion de fonction de CallBack et ont fini par être pédagogiquement amenés vers JavaScript.

Bien évidemment, c'est JavaScript qui a introduit la notion de CallBack...

Envoyé par redbullch

Bien évidemment, c'est JavaScript qui a introduit la notion de CallBack...

Me suis fait la même remarque! Mais je reconnais à Javascript son talent pour nous faire utiliser des callbacks à toutes les sauces. Je suis pas linguiste mais c'est pour moi une rustine apportée par un langage pensé synchrone pour un monde asynchrone.

Autran: Comme a été dit plus tôt, il y a aussi une expertise à avoir dans les technos ciblées ET dans la base de code existante. Je pense que ta prochaine question sera de savoir comment tu dois t'y prendre au niveau RH Il y a de grosses boîtes qui se sont plantées dans une telle manoeuvre, en explosant les dates butoires.

Une lecture : http://www.hervekabla.com/wordpress/...tion-de-la-v5/
Haha, c'est un peu marrant comment fin 90 ils découvrent C++, alors que tout le monde se fait farcir le noyau par Java, "ze langage" (je me demande si S&V Junior n'en parlait pas d'ailleurs)

Daniel

Perso j'aurai une question pour les personnes qui justement portent des applications non triviales de backends Java vers NodeJs.

L'un des choix de java dans mon entreprise, outre les performances et l'écosystème bien fourni, s'explique par la possibilité de gérer finement la synchronisation. J'ai l'impression que sur les systèmes du style Node, chaque fois que quelqu'un évoque le besoin d'un lock on lui balance un sermon comme quoi les locks c'est mal et ça va à l'encontre de la philosophie de Node.js etc... semblant prétendre qu'il existe aucun cas d'utilisation valide dans lequel on aurait besoin d'éviter un race condition ou d'empêcher l'accès à des ressources qui sont en cours de modification ou de rechargement.

En gros, sitôt qu'on sort du cas où l'application est stateless et data-centrée (style blog avec mysql), je vois assez mal comment on s'en sort. On peut certes profiter du système de transaction d'une base de donnée pour assurer une partie, mais c'est toujours limité à ce que propose ce système externe. Qu'en est-il si on a des opérations à faire de façon synchrone sur le file system sans forcément pouvoir compter sur un SGBD pour gérer l'accès aux ressources? Plus généralement pour n'importe type d'IO qui implique un lock ReadWrite (plusieurs readers simultanés, un seul writer exclusif) style sur un système de stockage composé d'une arbo de fichiers à même le file system?
Le seul début de solution que j'ai pu trouver à ces problèmes est d'utiliser un système de lock manuel basé sur Redis, et ça a pas l'air d'être un système beaucoup "repris" sur le net.

Donc est-ce qu'on pourrait admettre que dans certains cas, suivant le type d'application (+ ou - fortement stateful), le type de ressources et les besoins en partage (gros cache etc...), il faille admettre que ce soit mieux de rester sur un système java avec des bons gros singletons tout dégueulasses qui scalent pas mais qui sont lockés et accessibles en nanosecondes? Plutôt que de passer vers des architectures plus asynchrones qui scalent mieux mais pour lesquels il peut devenir complexe de gérer finement l'odre d'opération sur certains type de ressources partagées?

Attention je dis pas que gérer des accès concurrents sur des structure en mémoire en java ce n'est pas problématique. hein

Bonjour _skip,

Comme je le précisais dans le billet précédant, cette migration ciblent des applications qui feraient l'objet d'un redéveloppement rapide. Et je précisais également, combien je reconnaissais que

la technologie JEE permet de faire face à la montée en charge en clonant les «*tiers*» (aussi appelé scalabilité) ou en offrant des mécanismes presque intrinsèques de sécurisation de l'application.

Donc il y a de fortes chances pour que les applications que tu développes dans ta boîte (telles que tu nous les décris) ne soient pas éligibles à un passage sous Node.js.

L'exemple que tu cites me permets de rebondir sur cette notion d'opportunité de migrer ou non un portefeuilles. Chaque langage arrive avec son écosystème qui lui confère un niveau d'adéquation vis à vis de certains types de besoins. Et c'est à l'architecte de définir cette cartographie des applications candidates ou incompatibles à une telle migration. Je pense que c'est ce que l'on appelle la bonne gouvernance technique.

Mais je rappelle que pour rendre ce genre d'arbitrage technique, l'architecte doit être d'un niveau de compétences suffisant dans le domaine du développement.

Techno hype ou eprouvee ?

http://sametmax.com/la-communaute-js...tte-technique/

Salut je suis entrain de cree une Plateform dont j'ai besoin de pouvoir aussi migrer un portefeuille virtuel. Alors j'ai besoin des ressources php pour mener a bien ce projet. A noter que je suis encore debutant en pho