Node.js <> VB.NET

Version imprimable

09/04/2019, 20h06
mchurlet

Node.js <> VB.NET

Bonjour,
Je veux développer une application en utilisant des bibliothèques Nodes.js sur Git.
Je programme en VB.NET et donc je suis en train de me former sur Node.JS en utilisant l'EDI Visual Studio Community 2019 pour pouvoir comprendre comment utiliser ces bibliothèques.
J'aimerais savoir s'il est possible de récupérer les valeurs des programmes Node.js dans VB.NET et si oui, comment faire.
Pouvez-vous me mettre sur les rails ? Ça me ferais gagner beaucoup de temps si je pouvais développer mon interface en VB avec mes rudiments de node.js ?
09/04/2019, 21h30
Engiwip

Quitte à utiliser Nodejs Pourquoi ne pas se mettre à TypeScript ? tu restes Microsoft.

transition en douceur.
typsecript client et server.
09/04/2019, 22h04
Beginner.

Citation:

Envoyé par mchurlet

J'aimerais savoir s'il est possible de récupérer les valeurs des programmes Node.js dans VB.NET et si oui, comment faire.

Je ne suis pas sûr d'avoir compris mais peut-être que cela rejoint un problème qui s'était posé à moi alors apparemment cela dépends du module, si par exemple le module écrit le résultat dans un fichier eh bien il faut récupérer ce fichier ou si (comme c'est souvent le cas j'ai l'impression) il écrit le résultat dans le stdout eh bien il faut récupérer ce flux de sortie...

Je dis ça car en java j'avais vu un exemple où le module était exécuté avec node.js avec une fonction qui permet de récupérer la réponse (stdout)...

C'est une question importante mais curieusement on trouve peu d'explication sur cet usage...
09/04/2019, 23h17
Songbird

Bonjour,

Citation:

Quitte à utiliser Nodejs Pourquoi ne pas se mettre à TypeScript ? tu restes Microsoft.

Je ne vois pas tellement le rapport avec la question (?).

Citation:

J'aimerais savoir s'il est possible de récupérer les valeurs des programmes Node.js dans VB.NET et si oui, comment faire.

Qu'est-ce que tu entends par "récupérer" ?

Si tu souhaites effectuer tes traitements avec Node.js et récupérer le résultat pour les afficher dans une vue écrite en VB.NET, il te suffit d'envoyer des requêtes http (par exemple) vers un serveur géré par node.

Citation:

Envoyé par Beginner.

...j'avais vu un exemple où le module était exécuté avec node.js avec une fonction qui permet de récupérer la réponse (stdout)...

Oui, c'est un peu l'idée.
Mon programme node.js récupère des flux comme
Code:

1 2 3 4 5 6 7 8 9 10 websocket.on('message', websocketCallback); ce qui renvoie { type: 'done', side: 'sell', order_id: 'fca5413f-5894-4883-8644-63e2e95baa70', reason: 'filled', product_id: 'ETH-USD', price: '172.11000000', remaining_size: '0.00000000', sequence: 6507623431, time: '2019-04-10T00:14:10.405000Z' }
Donc, si je pouvais récupérer directement ce flux dans une variable tableau VB.Net, je pourrais traiter les données dans le langage que je connais mieux.
Je vais continuer à apprendre Node.js et javascript. Je commence à entrevoir ses possibilités et c'est prometteur.
Ça vaut la peine d'investir un peu de temps.

Citation:

Envoyé par Songbird

Si tu souhaites effectuer tes traitements avec Node.js et récupérer le résultat pour les afficher dans une vue écrite en VB.NET, il te suffit d'envoyer des requêtes http (par exemple) vers un serveur géré par node.

C'est effectivement une solution intéressante.

Merci pour vos réponses qui m'aident beaucoup.

10/04/2019, 02h32
mchurlet

Citation:

Envoyé par Engiwip

Quitte à utiliser Nodejs Pourquoi ne pas se mettre à TypeScript ? tu restes Microsoft.

Visual studio intègre TypeScript je crois bien.
10/04/2019, 03h02
Songbird

De rien, et tant mieux. Amuse-toi bien ! :)
10/04/2019, 09h34
Marco46

Citation:

Envoyé par Engiwip

Quitte à utiliser Nodejs Pourquoi ne pas se mettre à TypeScript ? tu restes Microsoft.

transition en douceur.
typsecript client et server.

TypeScript n'a pas grand chose à voir avec VB.NET ou CSharp. Ajouter TypeScript à la transition c'est juste se rajouter du taf. Pour apprendre TypeScript il faut vraiment très bien maitriser le JavaScript vanilla.
10/04/2019, 13h51
Engiwip

Citation:

Envoyé par mchurlet

Visual studio intègre TypeScript je crois bien.

oui et ce n'est pas insurmontable.
10/04/2019, 13h56
Engiwip

Citation:

Envoyé par Marco46

TypeScript n'a pas grand chose à voir avec VB.NET ou CSharp. Ajouter TypeScript à la transition c'est juste se rajouter du taf. Pour apprendre TypeScript il faut vraiment très bien maitriser le JavaScript vanilla.

pas d'accord . il y a la possibilité de penser composant .
faut pas en rajouter non plus sur la difficulté .
le discours de maitriser le Javascript pour ecrire du Typescrit je ne vois pas sur quel paradigme c'est fondé. Encore un dogme.

puis il y a un plus grand fossé entre C# et javascript qu'entre C# et Typescript.

Microsoft a ma rescousse
https://msdn.microsoft.com/en-us/magazine/jj883955.aspx

a+ marco.
10/04/2019, 14h54
Marco46

Il est bien cool ton lien, paragraphe 3 :

Citation:

TypeScript isn’t a new language. It’s a superset of JavaScript—a powerful, typed superset, which means that all JavaScript is valid TypeScript, and what is produced by the compiler is JavaScript.

En d'autres termes, pour apprendre TypeScript il faut apprendre JavaScript + TypeScript.

Pour ce qui est des exemples du billet que tu as fournis, je vais me répéter parce que je le répète à chaque discussion avec des novices mais TypeScript transpile par défaut en ES3. Donc une version de JS qui a 20 ans.

Quand tu transpiles vers une version récente de JS, la transpilation consiste à tout simplement supprimer les informations de typage.

Citation:

Envoyé par Engiwip

le discours de maitriser le Javascript pour ecrire du Typescrit je ne vois pas sur quel paradigme c'est fondé. Encore un dogme.

Le paradigme de la logique. Comme TS = JS + Types c'est quand même pas trop con d'apprendre le coeur du langage d'abord.

Ensuite un projet TS vient s'insérer dans un écosystème existant dont la plupart des dépendances sont écrites en JS directement avec un support TS via les typings ce qui fait que les patterns utilisés sont la plupart du temps ceux de JS et non ceux d'un TS orienté objet.

TS n'est pas du C# ou du Java à la sauce JS. Il vaut mieux éviter d'utiliser les mêmes patterns que dans ces langages. C'est une des raisons de l'échec d'Angular. Ils ont essayé de faire du Java côté client. Grave erreur.

Citation:

Envoyé par Engiwip

pas d'accord . il y a la possibilité de penser composant

Et pas en JS ? Elle est bien bonne celle-là ;)
10/04/2019, 15h18
Sodium

Non je ne comprends pas trop. Si tu sais faire du JavaScript tu sais faire du TypeScript, c'est juste du JavaScript avec des fonctionnalités en plus. Si il connaît d'autres langages, TypeScript est même beaucoup plus simple car plus proche.

Par contre effectivement je ne vois pas forcément la pertinence de TypeScript pour communiquer avec un serveur NodeJS, les deux étant totalement indépendants. TypeScript c'est juste de la quality of life du développeur.
10/04/2019, 18h24
Engiwip

Citation:

Envoyé par Sodium

Par contre effectivement je ne vois pas forcément la pertinence de TypeScript pour communiquer avec un serveur NodeJS, les deux étant totalement indépendants. TypeScript c'est juste de la quality of life du développeur.

effectivement on peut communiquer avec le language que l'on souhaite .
sans offense je pense que vb.net est en perte de vitesse et pour communiquer avec un serveur Nodejs autant le faire en Typescript.

effectivement si c'est pour integrer des appels a Nodejs dans un projet existant ma réponse n' a pas de sens. j'ai lu en travers
10/04/2019, 18h39
Engiwip

Citation:

Envoyé par Marco46

Il est bien cool ton lien, paragraphe 3 :

En d'autres termes, pour apprendre TypeScript il faut apprendre JavaScript + TypeScript.

Pour ce qui est des exemples du billet que tu as fournis, je vais me répéter parce que je le répète à chaque discussion avec des novices mais TypeScript transpile par défaut en ES3. Donc une version de JS qui a 20 ans.

Quand tu transpiles vers une version récente de JS, la transpilation consiste à tout simplement supprimer les informations de typage.

personne n'oblige a regarder le code JS transpilé en ES3 . Est ce qu'on oblige le dev java a regarder le Bytecode ? non. tout le monde s'en fout.

Citation:

Envoyé par Marco46

Le paradigme de la logique. Comme TS = JS + Types c'est quand même pas trop con d'apprendre le coeur du langage d'abord.

C'est marqué où ?

tu peux venir de PHP ou .net et faire le saut direct en Typescript sans maitriser le JS. je vois pas le pb. c'est meme mieux de pas se chopper les mauvaises habitudes de JS.

Citation:

Envoyé par Marco46

Ensuite un projet TS vient s'insérer dans un écosystème existant dont la plupart des dépendances sont écrites en JS directement avec un support TS via les typings ce qui fait que les patterns utilisés sont la plupart du temps ceux de JS et non ceux d'un TS orienté objet.

Et ? l'auteur de vient de VB.net il n' y a pas d'existant JS
on a eu une discussion l'autre jour sur JS + flow vs Typescript.
a vrai dire je me suis plongé dans le TS . je ne vois pas ou est le l'utilité de comprendre tout de JS.

Citation:

Envoyé par Marco46

TS n'est pas du C# ou du Java à la sauce JS. Il vaut mieux éviter d'utiliser les mêmes patterns que dans ces langages. C'est une des raisons de l'échec d'Angular. Ils ont essayé de faire du Java côté client. Grave erreur.

et pourtant les notions d'objet de C# et Java aideront forcément pour comprendre le TS pour Nodejs qui est le nouveau "Tomcat"
angular c'est un peu different nous sommes coté client avec la promesse difficile d'unifier et cadrer et les outils web , l'ecosysteme et les équipes travaillant de concert.

a vrai dire TS EST le Java pour nodejs

Citation:

Envoyé par Marco46

pas d'accord . il y a la possibilité de penser composant
Et pas en JS ? Elle est bien bonne celle-là ;)

oui effectivement tu as raison mais c'est moins intuitif que TS.

mince marco c'est de la balle TS.
10/04/2019, 21h26
Marco46

C'est quand même incroyable de pas comprendre, c'est pourtant d'une simplicité enfantine.

TypeScript n'est pas un langage à proprement parler, c'est une extension de JavaScript.

Donc autant apprendre d'abord JavaScript qui est déjà suffisamment touffu comme ça, et ensuite apprendre TypeScript qui étend le langage avec la notion de typage statique (structurel et pas nominal comme Java ou C#) uniquement à la phase de transpilation (il n'en reste rien à l'exécution).
10/04/2019, 21h51
Sodium

Sauf que comme le disaient les messages plus haut, le JavaScript pure oblige à prendre de très mauvaises habitudes de codage avec sa logique absurde, je ne vois donc pas l'intrérêt de se forcer à avaler ça.
Et s'il faut apprendre le JavaScript parce que TypeScript est traduit en JavaScript, alors autant apprendre directement le binaire pour avoir directement le langage machine tant qu'on y est.
10/04/2019, 21h54
Engiwip

Citation:

Envoyé par Marco46

TypeScript n'est pas un langage à proprement parler, c'est une extension de JavaScript.

.

C est valable pour ceux qui connaissent déjà JS oui on peut le voir comme une extension.
Pour les nouveaux entrants le language a apprendre est bien TS.
10/04/2019, 23h07
Marco46

Citation:

Envoyé par Engiwip

C est valable pour ceux qui connaissent déjà JS oui on peut le voir comme une extension.

TypeScript est une extension de JS. Je te demande pas ton avis je t'informe. C'est écrit texto dans le billet que tu as toi-même linké, c'est écrit dans la documentation, c'est expliqué dans les design goals.

Je peux plus rien pour toi.

JavaScript + types = TypeScript

TypeScript - types = JavaScript.

TOUT ce que tu écris en TypeScript sans utiliser de type c'est du JS pur.

Citation:

Envoyé par Engiwip

Pour les nouveaux entrants le language a apprendre est bien TS.

Non car ce n'est pas un langage c'est une extension. La documentation de TS ne suffit pas à apprendre le langage, elle n'est pas exhaustive. Il manque beaucoup de concepts, ils ne traitent que les parties du langage sur lesquelles adosser des types. L'API de base n'est même pas décrite.
11/04/2019, 08h04
Sodium

Citation:

Envoyé par Marco46

TOUT ce que tu écris en TypeScript sans utiliser de type c'est du JS pur.

C'est faux, TypeScript possède notamment des interfaces.
11/04/2019, 09h36
Marco46

Je te mets en gras puisque tu as du mal à lire :

Citation:

TOUT ce que tu écris en TypeScript sans utiliser de type c'est du JS pur.
11/04/2019, 10h41
Sodium

Une interface n'est pas un type, TypeScript permet d'ailleurs également de déplacer des types personnalisés.
Tu pourrais être un peu moins agressif, d'autant plus que tes interventions n'apportent pas grand-chose à la question posée.
11/04/2019, 12h18
Marco46

Citation:

Envoyé par Sodium

Une interface n'est pas un type, TypeScript permet d'ailleurs également de déplacer des types personnalisés.

Documentation TypeScript sur les interfaces, 1er paragraphe :

One of TypeScript’s core principles is that type checking focuses on the shape that values have. This is sometimes called “duck typing” or “structural subtyping”. In TypeScript, interfaces fill the role of naming these types, and are a powerful way of defining contracts within your code as well as contracts with code outside of your project.

Citation:

Envoyé par Sodium

Tu pourrais être un peu moins agressif

Désolé je réponds vite et je vais à l'essentiel parce que j'ai peu de temps et que je ne peux pas laisser des inepties sans réponses sur ce forum quand j'en lis parce qu'il y a des gens qui nous lisent.

Du coup c'est possible que la forme n'y soit pas je m'en excuse.

Citation:

Envoyé par Sodium

d'autant plus que tes interventions n'apportent pas grand-chose à la question posée.

A la question initiale pas littéralement ça mériterait un autre sujet mais c'est quand même très lié.

Un défaut courant des devs Java / .NET c'est d'aller vers TS en pensant se retrouver dans le même style de langage. C'est une erreur. Une vraie erreur de débutant. J'ai vu des devs Java se lancer dans Angular sans lire la doc TypeScript en partant du principe que c'était du TS donc ce qui était vrai en Java était vrai en TS. Je crains également que beaucoup de décideurs qui choisissent des stacks J2EE / Angular ou .NET / Angular aillent vers ce genre de stack avec des profils fullstack en pensant faire des économies, notamment de formation sur la partie JS / TS. C'est une erreur et ça peut couter cher en maintenance à l'arrivée.
11/04/2019, 13h16
Sodium

En pratique, je me sers effectivement principalement des interfaces généralement pour valider des structures de données JSON... ça n'empêche pas qu'elles ont les même fonctionnalités que dans d'autres langages.

Quant à confondre TypeScript et Java... ça me paraît tout de même assez évident que deux langages n'auront jamais exactement la même syntaxe et logique, je ne vois pas un développeur ayant un minimum d'expérience se dire qu'il va pouvoir installer TypeScript et coder du Java tranquillou.
11/04/2019, 14h47
Marco46

Citation:

Envoyé par Sodium

En pratique, je me sers effectivement principalement des interfaces généralement pour valider des structures de données JSON...

8O

Tu te sers des interfaces pour valider des données au runtime ?

Citation:

Envoyé par Sodium

ça n'empêche pas qu'elles ont les même fonctionnalités que dans d'autres langages.

Ben non puisqu'elles n'existent pas au runtime. Ça ne sert qu'au développeur à la phase de transpilation pour lui dire qu'il essaie de faire rentrer un rond dans un espace prévu pour un carré.

Citation:

Envoyé par Sodium

Quant à confondre TypeScript et Java... ça me paraît tout de même assez évident que deux langages n'auront jamais exactement la même syntaxe et logique, je ne vois pas un développeur ayant un minimum d'expérience se dire qu'il va pouvoir installer TypeScript et coder du Java tranquillou.

C'est pas qu'ils n'ont pas exactement la même syntaxe et logique, c'est qu'ils n'ont pas du tout la même syntaxe et logique.

Et je t'assure qu'il y a une quantité pas croyable de devs dits "fullstack" qui pensent pouvoir se passer de lire la doc TS sous prétexte qu'ils font du Java ou du .NET.
11/04/2019, 19h08
Sodium

Citation:

Envoyé par Marco46

8O
Tu te sers des interfaces pour valider des données au runtime ?

Vu que ce n'est pas moi qui gère le backend c'est bien pratique si le mec en charge oublie de me dire qu'il a changé sa structure de données en phase dev.
Puis c'est pratique aussi pour faire le mappage entre les noms de champs tout pourris de notre bdd du genre srgptg et les miens qui veulent dire des trucs :aie:
11/04/2019, 19h56
Marco46
Mais l'interface n'existe pas au runtime.

Si ton interface c'est par exemple :
Code:

1 2 3 4 5 export interface IMonInterface { prop1: string; prop2: string; }
Et que ton JSON contient uniquement prop1, tu n'auras aucune erreur sur prop2 sauf si tu testes manuellement le truc.

C'est uniquement pour déclarer explicitement les contrats de tes paramètres d'entrée et tes retours de fonctions. C'est tout.
12/04/2019, 12h37
Engiwip

Citation:

Envoyé par Marco46

C'est pas qu'ils n'ont pas exactement la même syntaxe et logique, c'est qu'ils n'ont pas du tout la même syntaxe et logique.

c'est bien beau de mettre en gras et surligner tout en essayant de convaincre mais au final on a une syntaxe proche à 80% et une logique d'abstraction equivalente.

Citation:

Envoyé par Marco46

Et je t'assure qu'il y a une quantité pas croyable de devs dits "fullstack" qui pensent pouvoir se passer de lire la doc TS sous prétexte qu'ils font du Java ou du .NET.

c'est un autre pb .
quand j'achete un aspirateur , je ne regarde pas forcément la notice. çà doit marcher comme tous les autres aspirateurs. puis au final c'est bien plus intuitif de jouer avec et regarder le manuel après.

TS fait de l'objet assez proche de Java avec les meme concepts.
On peut etre en désaccord sur les buts recherchés de chacun mais c'est un autre débat.
12/04/2019, 13h31
Marco46

Citation:

Envoyé par Engiwip

c'est bien beau de mettre en gras et surligner tout en essayant de convaincre mais au final on a une syntaxe proche à 80% et une logique d'abstraction equivalente.

[...]

TS fait de l'objet assez proche de Java avec les meme concepts.

Ah bah carrément pas. Typage structurel d'un côté, nominal de l'autre, sans aucune info de typage statique au runtime pour TS le contraire pour Java, fonctions first-class pour TS, les classes comme brique de base pour Java, ...

Ça fait déjà de très très grosses différences.

(EDIT :Et je parle même pas de la gestion de l'asynchrone qui est catastrophique avec Java, on pourrait parler aussi de l'event loop JS que l'on soit browser side ou server side contre la gestion en threads côté Java, fin bref ... Les différences sont très nombreuses et fondamentales.)

Citation:

Envoyé par Engiwip

c'est un autre pb .
quand j'achete un aspirateur , je ne regarde pas forcément la notice. çà doit marcher comme tous les autres aspirateurs. puis au final c'est bien plus intuitif de jouer avec et regarder le manuel après.

J'ai bien compris que tu voulais utiliser TypeScript sans lire la notice. C'est bien le problème ;)
12/04/2019, 14h36
Engiwip

Citation:

Envoyé par Marco46

Ah bah carrément pas. Typage structurel d'un côté, nominal de l'autre, sans aucune info de typage statique au runtime pour TS le contraire pour Java, fonctions first-class pour TS, les classes comme brique de base pour Java, ...

En pratique, le nez dedans ce n'est pas si important. vraiment. je dis pas de faire un projet opengl avec non plus hein?

Citation:

Envoyé par Marco46

(EDIT :Et je parle même pas de la gestion de l'asynchrone qui est catastrophique avec Java, on pourrait parler aussi de l'event loop JS que l'on soit browser side ou server side contre la gestion en threads côté Java, fin bref ... Les différences sont très nombreuses et fondamentales.)

on s'egare de la discussion , on ne compare pas Node avec J2ee....

Citation:

Envoyé par Marco46

J'ai bien compris que tu voulais utiliser TypeScript sans lire la notice. C'est bien le problème ;)

la notice quelle notice ? :mouarf: