Commentaires

Envoyé par marc.collin

tel que déjà dit, tu peux déjà le faire en java, donc rien de nouveau

Pas vraiment, car les solution qui existe sont lourde et utilise la génération d'html coté serveur et l'envoie en AJAX, merci les petite connexion.
La, on parle d'avoir des entité JS coté serveur, les envoyer en API rest, la recup cote navigateur avec un match 1 = 1 facile et très léger niveau octet transmis.

Et on parle pas de trans-compilateur java > javascript qui font du code a vomir.

Même si je ne suis pas un fan de Node, je reconnait quand même cet avantage la ( et la gestion de flux qui est tous bonnement exceptionnel ).

Envoyé par bilgetz

Rien que les entités.
Au lieu de les définir des 2 coté, tu les définie qu'une seul fois et tu utilise des 2 coté.
Pouvoir utiliser du code et des object coté client et coté serveur peut te faire gagner du temps et être sur d'avoir un comportement pareil des deux coté.

tel que déjà dit, tu peux déjà le faire en java, donc rien de nouveau

Envoyé par martopioche

En quoi est-ce un avantage ?

Rien que les entités.
Au lieu de les définir des 2 coté, tu les définie qu'une seul fois et tu utilise des 2 coté.
Pouvoir utiliser du code et des object coté client et coté serveur peut te faire gagner du temps et être sur d'avoir un comportement pareil des deux coté.

Envoyé par baptistelebail

Mais l'idée d'avoir une stack (build, frontend et backend) entièrement sur le même language/ecosystème, en terme de productivité et de satisfaction : c'est un avantage assez monstrueux je pense.

En quoi est-ce un avantage ?

Envoyé par SylvainPV

J'ai beau être un fada de JS, je ne suis pas sûr que remplacer une stack JEE par du NodeJS soit toujours une bonne idée. On est encore loin d'avoir des solutions aussi industrialisées qu'en JEE. Je fais moi-même beaucoup de développement avec Node, que ce soit pour un usage serveur ou pour un usage local desktop avec node-webkit et Electron, et le principal reproche que j'ai à faire à la techno est la jungle des modules: pour faire des choses basiques comme de la manipulation de fichiers, il faut parfois recourir à 3, 4, 5 bibliothèques différentes : une pour étendre les fonctions de l'API fs de base, une pour la "promisifier", une pour ajouter des filename matchers, une pour faire les traitements en parallèle etc... on a pas vraiment de solution clé en main, et il semble que chaque grosse entreprise utilisant NodeJS a en interne plusieurs experts et un paquet de modules développés spécifiquement pour leurs besoins.

Pour avoir travaillé avec JEE et NodeJS, je pense que le développement NodeJS est plus souple et plus bas niveau, mais également plus délicat et nécessitant plus de compétences. Le temps d'apprentissage de Node pour un développeur front-end est plus important qu'on ne le croît. En résumé: gros investissement de temps et de ressources, facteur de risque assez important, et un outillage moins développé pour le run. Voilà pourquoi je ne pense pas que ce soit une bonne idée dans le monde de l'entreprise, surtout pour une migration d'un service existant. Certes, on peut se dire qu'il s'agit d'un investissement sur le long terme, mais je suis persuadé que l'arrivée de WebAssembly va bouleverser beaucoup de choses.

pour le peu que j'en es fait, ton témoignage et de nombreux autres me laisse penser que le gain vendu par certain est plus que du pipeau.

on tombe dans du bas niveau, on a besoin d'une tonne de librairie pour faire la moindre petite chose...

J'ai beau être un fada de JS, je ne suis pas sûr que remplacer une stack JEE par du NodeJS soit toujours une bonne idée. On est encore loin d'avoir des solutions aussi industrialisées qu'en JEE. Je fais moi-même beaucoup de développement avec Node, que ce soit pour un usage serveur ou pour un usage local desktop avec node-webkit et Electron, et le principal reproche que j'ai à faire à la techno est la jungle des modules: pour faire des choses basiques comme de la manipulation de fichiers, il faut parfois recourir à 3, 4, 5 bibliothèques différentes : une pour étendre les fonctions de l'API fs de base, une pour la "promisifier", une pour ajouter des filename matchers, une pour faire les traitements en parallèle etc... on a pas vraiment de solution clé en main, et il semble que chaque grosse entreprise utilisant NodeJS a en interne plusieurs experts et un paquet de modules développés spécifiquement pour leurs besoins.

Pour avoir travaillé avec JEE et NodeJS, je pense que le développement NodeJS est plus souple et plus bas niveau, mais également plus délicat et nécessitant plus de compétences. Le temps d'apprentissage de Node pour un développeur front-end est plus important qu'on ne le croît. En résumé: gros investissement de temps et de ressources, facteur de risque assez important, et un outillage moins développé pour le run. Voilà pourquoi je ne pense pas que ce soit une bonne idée dans le monde de l'entreprise, surtout pour une migration d'un service existant. Certes, on peut se dire qu'il s'agit d'un investissement sur le long terme, mais je suis persuadé que l'arrivée de WebAssembly va bouleverser beaucoup de choses.

Envoyé par baptistelebail

J'affectionne beaucoup Java et son ecosystème.
Mais l'idée d'avoir une stack (build, frontend et backend) entièrement sur le même language/ecosystème, en terme de productivité et de satisfaction : c'est un avantage assez monstrueux je pense.
Les points qui me rendent un peu réfractaire ;
- le langauge, JavaScript reste tout de même particulier bien qu'avec ES6 je commence à apprécier.
- 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.

possible de le faire depuis plusieurs années.... avec par exemple Gwt, OpenXava, vaadin, zk.


Serait bien de cité les avantages de nodejs avec à JEE

J'affectionne beaucoup Java et son ecosystème.
Mais l'idée d'avoir une stack (build, frontend et backend) entièrement sur le même language/ecosystème, en terme de productivité et de satisfaction : c'est un avantage assez monstrueux je pense.
Les points qui me rendent un peu réfractaire ;
- le langauge, JavaScript reste tout de même particulier bien qu'avec ES6 je commence à apprécier.
- 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.

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!

En gros voici comment chacun voit cette migration:
* Un responsable technique / developpeur: n'importe quoi sauf pour la partie UI, l'idéal c'est de garder la partie serveur en Java avec des réponse en JSON, et la partie UI en full JS
* Un manager: peut être une façon d'avoir plus de budget pour continuer à "manager" son équipe, si pas d'autres projets plannifiés
* Une boite de conseil: une migration qui s'impose pour suivre la veille technologique (continuer à gagner de l'argent ), sans parler de tous les avantages de JS (bla bla bla)

Rien que comparer un eco-système qui compte BCP d'année de maturité à un language tout récent est (pour moi) une grosse bêtise

Envoyé par vaild

autant je suis d'accord pour angular sur le front, autant passer d'une techno quelconque mais fonctionnelle sur le back à node me parait risqué (que ce sois du java, du php, ou n'importe quoi d'autre)...
pour un nouveau projet pourquoi pas node, mais pour un ancien je mettrai d'abord une phase de création d'API REST sur la techno existante, pour ensuite passer à angular en front, puis éventuellement une autre techno serveur (pourquoi pas node) avec les même process, ou virer les anciens traitements si on conserve le langage d'origine...

Ceci est également mon opinion. Que Java soit remplacé sur le front n'est même plus une question à se poser, c'est une démarche qui doit être envisagée et lors de toute évolution, le cout n'est pas bien supérieur au cout de maintenance... Si les promesses de l'architecte ne sont pas que du vent...

Cela va nécessiter d'adapter le back, mais migrer de techno... On est réellement dans le syndrome de l'informaticien qui se sent obligé de réparer ce qui marche...

Par contre, ce type de migration n'est pas une occasion de revoir le métier. Le métier est définit par le business et les process, pas par la techno.

Cette Article fait suite à un autre article, je m'attendais à voir des choses un peu plus concrètes ?

autant je suis d'accord pour angular sur le front, autant passer d'une techno quelconque mais fonctionnelle sur le back à node me parait risqué (que ce sois du java, du php, ou n'importe quoi d'autre)...
pour un nouveau projet pourquoi pas node, mais pour un ancien je mettrai d'abord une phase de création d'API REST sur la techno existante, pour ensuite passer à angular en front, puis éventuellement une autre techno serveur (pourquoi pas node) avec les même process, ou virer les anciens traitements si on conserve le langage d'origine...

Il y a des développeurs souhaitant passer de Java à une fullstack JS de leur propre chef , je ne sais pas si ça représente énormément de développeur, je suis développeur .net à l'origine mais je travaille sur un front-end actuellement full JS avec angular, je fais ça parce que c'est ce que m'a été demandé par le client, mais je n'envisage pas de faire ça toute ma vie.

Le JS est un langage trop particulier et très pauvre de base il demande souvent l'ajout d'un nombre incalculable de librairie pour être pleinement exploitable sur de gros projets, et le débogage est toujours aussi merdique, je sais que l'ecmascript 6 permet une bonne évolution de ce langage mais il ne fait que singer l'existant (pour plaire aux développeurs venant de langage orienté objet notamment), à terme avec WebAssembly sera-t-il toujours autant utiliser sur de nouveaux projets ? J'en suis moins sûr.

Je suis d'accord que angular peu apporter pas mal de souplesse au niveau Ui mais, après avoir testé NodeJs , le code est trop bas niveau même avec un framework , sur des projets de grande ampleur c'est se tirer un balle dans le pied.

Ce que j'aime avec JEE, c'est la normalisation.
Je veux faire de la persistance de données, de la validation, j'ai une implémentation liée à mon serveur ou je peux utiliser une implémentation plus complète.
Dans l'environnent Node, comment dois-je m'y prendre ? Fouiller dans la multitude de projets et trouver le meilleur en espérant qu'il ne soit pas abandonné ?
Concernant par exemple la persistance et la validation de données, existe quelque chose d'aussi complet qu'en JEE ?

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!

Bonjour,

Merci pour ton code, je pense pouvoir l'utiliser au besoin . Une seule remarque pour l'instant que je peux te faire est le manque des commentaires. Je ne vois pas comment un développeur amateur désirant utiliser le chiffrement dans son application pourrait facilement se retrouver avec un code sans explications qui vont avec. Ce serait génial si jamais tu associais quelques explications au code. Sinon, le code est intéressant à mon avis.

Merci

Christian Djo...

Et voici la suite : Comment migrer de JEE à Node.js + AngularJS
Bonne lecture

Autant je suis un gros fan de angular 1.0 pour la structuration qu'il procure, autant je suis surpris par Angular 2.0, on dirait que c'est un nouveau gars qui a repris tout à son compte et a décidé de détruire le travail d'un ancien groupe.
Tant pis je continue en Angular 1.0 sur mon site.
Java, c'est cool pour les classes et uml2.0.
Si des gars veulent chéquer mon site dans mes liens, je fais que du angular 1.3

Pour Java, que je connais assez peu, mais je pense qu'utiliser OpenJDK suffit amplement à se libérer des risques qu'Oracle fait planer sur cette technologie.


Pour C#/Net en revanche, pour connaître assez bien, je trouve que tu fais un raccourci "Microsoft => propriétaire" un peu trop rapide.
Juste à titre d'exemple, toute la stack web .Net est open-source sous licence Apache depuis une bonne année : il est possible de créer/migrer des applications ASP.NET sur *nix sans jamais avoir besoin de Windows et sans coût (à part le temps et le coût humain bien sûr).


Il est vrai que certains technologies peuvent être concernées par des licences propriétaires, mais il existe presque toujours une alternative libre afin de s'en sortir. Les moyens de développer avec des technologies open-source ne manquent pas, quelque soit le choix que l'on fait.