Discussion :

[Invité]

A mon sens, le débat est le même ici (quoi que c'est pire, car on tente une espèce de fuite en arrière)

Je ne pense pas que ce soit une fuite en arrière. La POO à la java/c++ est issue de recherche des années 70/80. Les langages fonctionnels modernes comme elm/ocaml/haskell sont issus de travaux des années 90 et plus.

Le Fortran est mort principalement parce qu'il a arrêté d'évoluer, et que "politiquement" il a été décidé qu'il fallait le mettre au placard.

Fortran est encore souvent utilisé dans certains domaines et il continue d'évoluer (POO, concurrence, etc). La dernière norme date de 2018.

Microsoft a inventé le Basic à peu près à la même époque, et pourtant VB.NET est toujours très utilisé.

Basic a été inventé par 2 profs du Dartmouth College et non par Microsoft.

Et quand on y regarde bien, C++ 11 n'a plus rien à voir sur bien des points avec la première mouture, et un programme en C des années 80 ne compilera pas sur un gcc flambant neuf (alors que le *.exe généré à l'époque peut parfaitement encore tourner sous certaines conditions).

Justement si. La POO de C++ n'a quasiment pas évolué depuis les années 90. Quant aux nouvelles fonctionnalités, il y a justement compatibilité ascendante. Un code en C++98 a de grande chance de compiler sur un GCC de 2020.

Je ne dis pas tout ça pour faire une leçon d'histoire des langages mais pour illustrer qu'on pense tous connaitre des faits alors que ce sont souvent des légendes ou des impressions personnelles. Et c'est ce que relêve l'article par rapport à la POO et au fonctionnel, et donc que ça vaudrait peut-être le coup d'essayer vraiment le fonctionnel.

[Marco46]

Je ne parlais pas de ce débat, mais celui de décider d'abandonner un langage (et toute une méthodologie) au profit d'un autre sous prétexte que pour faire ça ou ça, parfois c'est plus adapté.

Si tu as des équipes de 200 personnes, tu peux te permettre d'en former 10, 15, 20% sur une dizaine de langages/technos différentes, puis "faire tes courses" en fonction d'un besoin précis (à condition que toi-même ait suffisamment de recul sur chaque langage/techno pour faire un choix qui tienne la route).
Mais la réalité est généralement autre, les équipes sont souvent bien plus réduites, et le chef de projet est mono ou bi-techno maxi. Donc habitude ou non, il n'a pas vraiment d'autre choix que d'utiliser les outils qu'il a à disposition et que son équipe sait utiliser.

Il me semble pourtant que les projets web sont assez courants ... Je parle de JavaScript là !

[Stellar7]

Il y a des discussions qui font sourire quand on regarde dans le rétroviseur.

En licence info, on n'avait toujours pas accès à l'internet, à l'époque, à moins d'avoir une connaissance qui était au moins parmi les thésards. C'était le grand développement du minitel (mais là, je commence à m'égarer). On faisait du Pascal, et la POO n'en était qu'au début de son développement (pour ceux qui avaient accès à l'internet).
Avec le binôme, ou avec l'équipe projet (on avait 1 long projet sur un semestre), on avait commencé à exploiter certaines particularité de la portée des données en Pascal, en particulier quand on utilise différents fichiers. Ce qui revient à dire que l'on s'était organisé comme si (ce qui s'appellerait plus tard) les classes étaient chacune dans son fichier. Ainsi, on contrôlait bien l'interface. Bref, on avait commencer à s'organiser façon (une vision de la) POO, avec un langage qui n'en parlait à l'époque pas.
À la fin de la licence, je (heu, "on") pestais car il manquait vraiment un truc au Pascal : pouvoir passer une fonction/procédure en paramètre, "voir" l'assigner comme une variable. (re-)Bref, on commençait à avoir une approche utilisant du fonctionnel.

Plus tard, le vocabulaire est venu : POO, classes, fonctionnel, etc. Les guerres de religion afférentes aussi : j'ai eu un méchant échange avec un responsable, en DEA, qui me disait que "la POO, c'est bon, tout le monde c'est ce que c'est, c'est pas la peine de définir les contours". Ben justement, c'est comme en modélisation : on commence par définir les contours et le vocabulaire, parce que des avis, il y en a une pelletée.

Conclusion du laïus : certaines notions sur lesquelles on peut poser des mots aujourd'hui, existent depuis bien longtemps, et beaucoup y sont venus. Ces notions sont utiles quelque part ou par moments ? => On finit par les retrouver dans les langages, même ceux qui n'y faisaient pas référence au départ, parce qu'on s'aperçoit que finalement c'est bien utile.

Alors inutile de taper sur le côté "pur" de certaines approches, comme objet (avec Smalltalk) ou fonctionnel (avec Haskell), car elles servent de champs d'investigations.

Elles peuvent même servir de manière très pratique.
Vers 1994, parler de POO était un peu "dépassé" et "tout le monde savait" que Java allait tomber à l'eau comme toutes les modes (dixit les directeurs de recherche du cnrs que je croisais). Il ne fallait surtout pas dire que l'on faisait de l'objet "poussé", et encore moins du Smalltalk. Au boulot, j'ai été le seul à faire planter une appli très utile sur les serveurs Sun : je me suis retrouvé sur la console Smalltalk. Mais le vendeur n'en avait jamais parlé à quiconque… Smalltalk a été à l'époque le seul environnement qui permettait de proposer à l'utilisateur, sur le Sun, un look & feel unix / windows / mac à la demande, en 3 mots à la console. C'était aussi l'époque d'apparition de NeXTSTEP, coulé par la concurrence.
Côté fonctionnel, Microsoft est un contributeur pour Haskell. Première conséquence : l'existence de F#, une mise en œuvre dans l'environnement Microsoft. C'est un premier pas, car ce qui est jugé intéressant ou utile, va se retrouver dans les autres langages de Microsoft. Donc pas la peine de taper sur Haskell ni sur F#.

Il y a des manières de penser et de s'organiser qui sont utiles, mais qui ont leurs champs d'applications privilégiés. Les noms viennent après, les modes aussi. Mais si c'est utile, cela va se répandre.

Bon, tout cela est bien joli, mais l'entreprise va généralement chercher un codeur pas cher pour faire du bénéf' en le plaçant. À partir de la, les belles idées…

[Invité]

Conclusion du laïus : certaines notions sur lesquelles on peut poser des mots aujourd'hui, existent depuis bien longtemps, et beaucoup y sont venus. Ces notions sont utiles quelque part ou par moments ? => On finit par les retrouver dans les langages, même ceux qui n'y faisaient pas référence au départ, parce qu'on s'aperçoit que finalement c'est bien utile.

Je suis assez d'accord. Par contre, les "mots" du fonctionnel viennent du lambda-calcul des années 30 donc on peut dire qu'ils ont toujours exister.

Côté fonctionnel, Microsoft est un contributeur pour Haskell. Première conséquence : l'existence de F#, une mise en œuvre dans l'environnement Microsoft. C'est un premier pas, car ce qui est jugé intéressant ou utile, va se retrouver dans les autres langages de Microsoft. Donc pas la peine de taper sur Haskell ni sur F#.

F# c'est la version Microsoft du langage ocaml, pas haskell. Par contre, c'est vrai que certains gros contributeurs de haskell étaient des chercheurs employés par Microsoft. C'est même un peu étonnant car Microsoft n'a pas vraiment fait de promotion autour de ces 2 langages.

[StringBuilder]

Il me semble pourtant que les projets web sont assez courants ... Je parle de JavaScript là !

Bon, je commence à raccrocher les wagons...

J'avais pas fait attention à la ligne en tout petit mentionnant "d'après mon expérience avec Typescript".

Si je comprends bien, on parle donc en effet, en Typescript (donc JavaScript en effet) de savoir si on doit travailler avec des classes d'objet, ou avec du fonctionnel.

Et là d'un coup, au risque de troller un peu, je comprends bien mieux...

Il ne s'agit pas de jeter à la poubelle les langages objets que sont Java ou C# et les remplacer par F# ou LISP, mais de changer la façon de coder en JavaScript.

Si c'est ça, ok, je comprends mieux (ouf ! me direz-vous).

JavaScript est à la base un langage pour ainsi dire non typé, et son support du modèle objet plus que limité.
Il a évolué ces dernières années avec TypeScript, mais ça reste à la fois :
- un langage peu typé
- très limité en terme de POO
=> Bref, tout sauf un langage réellement orienté objet.

Enfin, TypeScript est utilisé plutôt en frontend, donc gère la couche présentation, et très partiellement la couche métier.
=> La couche présentation n'a pour ainsi dire pas besoin d'objet (on se contente de contrôles utilisateurs et des objets déjà présents dans Angular par exemple, sans devoir en créer de nouveaux ni de les enrichir)
=> La couche métier côté front-end va se contenter de faire quelques contrôles et calculs sans pour autant implémenter les règles métiers (trop complexes et trop proches des données pour être embarquée côté utilisateur). A nouveau, pour faire quelques calculs simples sur un nombre limité de données, la POO ne sert rigoureusement à rien.

Par conséquent, ne pas faire de POO en JS, pour faire autre chose, à la limite n'importe quoi d'autre se tient, puisque de toute façon JS n'est pas fait à la base pour faire de la POO.

Voilà, désolé si certains prendront ce message pour un troll. C'est pas tout à fait vrai ni tout à fait faux cependant

[foetus]

très limité en terme de POO [...] JS n'est pas fait à la base pour faire de la POO.

tu te trompes - pour simplifier (*), il a 2 programmations objet : la programmation objet (pure (Python, Smalltalk, ...) et les autres (C++, Java, ...)) et la programmation orientée prototype (Self, JavaScript) (<- lien wiki en français)


* : Plus de détails sur le wiki en anglais, "Object-oriented programming"

[Invité]

Si je comprends bien, on parle donc en effet, en Typescript (donc JavaScript en effet) de savoir si on doit travailler avec des classes d'objet, ou avec du fonctionnel.
...
Il ne s'agit pas de jeter à la poubelle les langages objets que sont Java ou C# et les remplacer par F# ou LISP, mais de changer la façon de coder en JavaScript.

Pas uniquement. L'article parle aussi de elm, qui est un langage inspiré de haskell, pour le front.

Par conséquent, ne pas faire de POO en JS, pour faire autre chose, à la limite n'importe quoi d'autre se tient, puisque de toute façon JS n'est pas fait à la base pour faire de la POO.

Je ne suis pas expert en JS mais je pense que ta vision de JS et du front n'est pas du tout à jour. La POO JS est différente de la POO java/c++ mais largement aussi puissante. Quant à la complexité des applications front, je pense que ça a bien augmenté depuis quelques années, avec les SPA PWA et tous les frameworks qui vont avec (ou pas d'ailleurs).

[Marco46]

Il ne s'agit pas de jeter à la poubelle les langages objets que sont Java ou C# et les remplacer par F# ou LISP, mais de changer la façon de coder en JavaScript.

Ben si justement. Sais-tu que le plus clair du Fortune 500 a migré de stacks J2EE vers node ces dernières années ? Twitter, paypal, netflix, Uber, LinkedIn, Walmart, Groupon, etc ... etc ... La liste est longue !

Et même pour les clients lourds il y a de plus en plus d'applications complexes, par exemple Visual Studio Code.

Il a évolué ces dernières années avec TypeScript

TypeScript est une excellente extension mais c'est surtout le langage vanilla lui-même qui a énormément évolué en 5 ans.

Enfin, TypeScript est utilisé plutôt en frontend, donc gère la couche présentation, et très partiellement la couche métier.

Je n'en rajouterais pas sur la POO les autres ont répondu mais tu sembles totalement ignorer que JavaScript est énormément utilisé côté backend et sur des SI de très grande complexité. Après Node n'est pas conçu pour effectuer des traitements CPU lourds mais pour traiter un très grand nombre de requêtes, c'est aussi de la complexité dans un contexte asynchrone et stateless tel que le web et JS se comporte à merveille dans le contexte du web, bien mieux que Java y compris côté backend.

Bref pour traiter des I/O à la pelle, et le fonctionnel pour ça c'est bien plus efficace que la POO à classe traditionnelle.

Ce n'est pas un hasard si le FaaS (Function as a Service) c'est autant développé ces dernières années. Ça répond à un besoin concret.

[moldavi]

Bonjour.

Justement : l'article essaie de voir s'il ne vaudrait pas mieux faire du fonctionnel plutôt que de faire tout le temps de l'objet.

Dans une publication parue il y a peu, Andy Peterson de l'entreprise Atomic Object explique pourquoi il ne fait pas un usage systématique des classes et s’appuie autant que possible sur une approche fonctionnelle.

Je vois 2 choses ici :

- pas un usage systématique des classes
- approche fonctionnelle

C'est clair ici, il fait de l'objet, même si ce n'est pas systématique. Pour le fonctionnel, il parle d'approche, mais ajouté à de l'objet ou pas... J'avoue, j'extrapole ici, mais sans exemple de la part de cet auteur, je peux extrapoler. JackIsJack résume le tout selon moi :

Un exemple vaudrait mieux qu'un long discours.

Désolé l'argument des balles de jonglages ne me séduit pas : du concret !

J'attends aussi du concret.

on note que de plus en plus de livres orientés programmation fonctionnelle paraissent

Donc c'est l'avenir... Peut-être, qui sait. A l'heure actuelle, le fonctionnel répond à des problématiques, mais pas à toutes.

Que vient faire le javascript ici ? Il apparait dans quelques commentaires mais il n'est mentionné nul part dans l'article dvp. L'article parle plutôt de elm ou des fonctionnalités de fonctionnel qui apparaissent dans beaucoup de langages.

Que vient faire javascript, je me le demande ;

Basé sur son expérience en entreprise avec Typescript

Typescript, javascript, c'est vrai aucun lien...

En fait, il s’agit d’une posture globale de l’équipe de développeurs de l’entreprise spécialisée en développement web

C'est vrai, ils sont spécialisés en développement web, mais aucun lien avec javascript...

Je ne vais pas répondre à cette question, je suis blasé là.

Sinon, vous en pensez quoi de l'évolution javascript -> typescript -> fonctionnel, vous pensez que cela va résoudre le problème de la gestion des états des objets ?

[moldavi]

Bonjour.

...

J'aime beaucoup toutes tes questions qui font réfléchir. Et aussi l'armada de réponses qui ne se remettra jamais en question, et qui a réponse à tout.

[moldavi]

Bonjour.

JavaScript est typé. Il n'a pas de typage statique ni la possibilité de définir ses propres types complexes mais il est typé.

Oui. Nous ne serons jamais d'accord.

Un langage typé qui peut ajouter des choux avec des carottes, ne sera jamais typé dans ma compréhension des choses de l'informatique.

Et quand tu as un bug, parce que tu as ajouté un chou et une carotte, dans 100000 lignes de code, oui tu t'arraches les cheveux. Un compilo C/C++ t'aurait prévenu...

Quand à l'asynchrone c'est le contexte par défaut que tu sois en browser ou en backend, le web est asynchrone et stateless. Et JS est extrêmement bien équipé pour gérer l'asynchrone du coup je ne comprends pas.

JS gère-t-il aussi l'asynchronicité de tes variables globales, ou l'état de tes objets membre ? Ils sont forts chez javascript. Je comprends le problème de l'auteur, et je ne dis pas que JS est bien équipé.

Les bugs et la maintenabilité d'un code n'ont pas de rapport avec le langage (ya plus de liens avec le paradigme du langage en revanche). Ça dépend d'abord et avant tout de l'auteur du code source.

Cela mérite un débat.

Il y a une multitude d'outils pour écrire des tests de tout type donc pas de raison de s'arracher les cheveux comme tu dis.

Outils payants ou gratuits, c'est important de savoir pour des langages tout public ?

La situation que tu décris n'existe plus depuis pratiquement 10 ans. Node a tout changé.

Oui Node a tout changé. Les développeurs Front-End font des doubles appels à la même ressource statique, et ils ne savent même pas pourquoi. Ils comprennent rien à tous ces frameworks, tellement c'est simple et tout public.

Il faut simplement apprendre le langage et les outils les plus courants. Rien de surnaturel là dedans Cela dit l'évolution de son écosystème a été tellement rapide ces dernières années qu'il est possible de l'avoir manqué complètement si on est habitué aux rythmes des langages historiques (Java, C# et pire C++).

"et pire C++"... C'est-à-dire ?

[moldavi]

Bonjour.

mais tu sembles totalement ignorer que JavaScript est énormément utilisé côté backend et sur des SI de très grande complexité.

Vous croyez vraiment à ce que vous racontez ? Quelques sont ces statistiques sur ces fameux SI d'une très grande complexité...

Les SI utilisent ce truc par phénomène de mode, par lobbying et par facilité, pas par efficacité.

Cela me rappelle des discussions en 2003 avec les soit-disant puristes Linux. Ils ont d'ailleurs disparu au fur et à mesure que les subventions Google ont disparu.

Aujourd'hui nous avons les puristes javascript, enfin les vendeurs de Framework javascript.

Bientôt, ils vont vous faire croire que l'on peut faire des jeux vidéos en node.js...

L'histoire se répète.

[Neckara]

Les SI utilisent ce truc par phénomène de mode, par lobbying et par facilité, pas par efficacité.

Personnellement, j'utilise JS en backend parce que cela m'évite de passer constamment du JS au PHP, et que cela me permet de transférer facilement du code du front-end au back-end, et inversement. De plus, JS est pas mal pour manipuler du DOM.

[StringBuilder]

J'ai quand même une question par rapport à ce que vous appelez le "backend".

Qu'est-ce donc ?

Chez moi, le backend, c'est ce qui est exécuté côté serveur. A l'heure des applications web riches et des clients légers, la partie backend se résume, pour grande partie, à de la manipulation de données (CRUD en base, quelques calculs et vérification ce règles, point).
C'est d'autant plus vrai que la grande mode du backend c'est d'être stateless (monte mieux la charge, notamment permet de faire de l'asynchrone sans devoir synchroniser le contexte).

Je n'ai pas trouvé avec TypeScript comment se connecter à une base de données, écrire dans un fichier, etc. Du coup je m'interroge clairement sur l'intérêt de coder un backend en TS :
- le code exécuté en TS sur le serveur aurait à priori parfaitement pu être exécuté sur le client
- le code TS exécuté sur le serveur va reposer sur des "API" au même titre que le code exécuté sur le client

Si de toute façon je dois reposer sur des API en PHP, C# ou Java, je ne vois pas pourquoi mettre en place deux programmes, avec un échange REST au milieu, pas plus que je ne vois comment on peut se vanter d'avoir de meilleures performances avec une telle architecture !

J'ai raté un truc je pense...

[Neckara]

Chez moi, le backend, c'est ce qui est exécuté côté serveur. A l'heure des applications web riches et des clients légers, la partie backend se résume, pour grande partie, à de la manipulation de données (CRUD en base, quelques calculs et vérification ce règles, point).
C'est d'autant plus vrai que la grande mode du backend c'est d'être stateless (monte mieux la charge, notamment permet de faire de l'asynchrone sans devoir synchroniser le contexte).

Cela dépend de ce que tu développes.

Si c'est un site bête et méchant, tu vas utiliser p-e un CMS bête et méchant.
Si c'est une application, tu peux te retrouver avec beaucoup de choses en backend avec éventuellement un serveur socket.io.

Je n'ai pas trouvé avec TypeScript comment se connecter à une base de données, écrire dans un fichier, etc.

T'as pas bien cherché alors :
https://typescript.developpez.com/ac...pt-par-Yahiko/

- le code exécuté en TS sur le serveur aurait à priori parfaitement pu être exécuté sur le client

Sauf dans les cas où tu veux protéger ta propriété intellectuelle, ou si tu veux que l'utilisateur n'interfère pas avec les calculs, ou si c'est des calculs intensif et/ou que tu veux conserver un cache des choses déjà calculée pour tous les clients.

pas plus que je ne vois comment on peut se vanter d'avoir de meilleures performances avec une telle architecture !

Ce n'est pas uniquement une question de performances d'exécution, mais tout simplement de vitesse/confort de développement.

Pour la vitesse d'exécution, tu as tellement de choses qui viennent avant le langage, et au pire, tu peux toujours te démerder pour réimplémenter les goulots d'étranglements.

[StringBuilder]

Cela dépend de ce que tu développes.

Si c'est un site bête et méchant, tu vas utiliser p-e un CMS bête et méchant.
Si c'est une application, tu peux te retrouver avec beaucoup de choses en backend avec éventuellement un serveur socket.io.

Là tu me parles d'outils, pas de ce que fait le site si comment l'implémenter.

T'as pas bien cherché alors :
https://typescript.developpez.com/ac...pt-par-Yahiko/

Je dois vraiment avoir de la merde dans les yeux...
Tout ce que fait ton exemple, c'est de lire un fichier index.html et renvoyer le résultat à l'appelant.
Je ne vois pas d'accès à des données...

Sauf dans les cas où tu veux protéger ta propriété intellectuelle,

Pipo, plage, ski, toussa...

ou si tu veux que l'utilisateur n'interfère pas avec les calculs, ou si c'est des calculs intensif et/ou que tu veux conserver un cache des choses déjà calculée pour tous les clients.

Intèrférer : ok pourun site bancaire public. Pour une application d'entreprise, OSEF. Et pour choisir de surcharger un serveur de calculs pour pouvoir garder les résultats en cache, ou plutôt déporter les calculs au client... perso mon choix est vite fait !

Ce n'est pas uniquement une question de performances d'exécution, mais tout simplement de vitesse/confort de développement.

Belle façon de voir les choses. La RATP va acheter des Ferrari, et les passagers s'entasserons dans l'emplacement de la roue de secours, car les conducteurs préfèrent conduire une Ferrari plutôt que leurs bus pourraves.
Le confort du développeur doit venir dans les dernières positions quand il s'agit de choisir une techno, clairement pas l'inverse !

Pour la vitesse d'exécution, tu as tellement de choses qui viennent avant le langage, et au pire, tu peux toujours te démerder pour réimplémenter les goulots d'étranglements.

Hmmmm...
Temps d'accès en mémoire, on est de l'ordre de la µs.
Temps d'accès disque, on est de l'ordre de la ms.
Temps d'accès REST (serveur socket + encapsulation HTTP + ...) on est de l'ordre du centième ou dixième de seconde à condition d'être sur un réseau local fibré.

Bref, le goulot d'étranglement, il commence déjà par choisir la techno qui correspond au besoin : si j'ai pas besoin de faire du REST entre mon backend et ma couche d'accès aux données, je fait pas de REST en me disant que je verrai plus tard si ça rame !

[Marco46]

Et quand tu as un bug, parce que tu as ajouté un chou et une carotte, dans 100000 lignes de code, oui tu t'arraches les cheveux. Un compilo C/C++ t'aurait prévenu...

Je n'ai plus rencontré ce type de bug en JavaScript, ni même en Java d'ailleurs, depuis que j'ai pris l'habitude d'écrire systématiquement des TU.

En fait je peux éventuellement le rencontrer mais au moment de l'exécution du test, c'est à dire quelques secondes après avoir écrit mon code.

En revanche résoudre un ticket de bug dont la cause est d'avoir ajouté un chou à une carotte ça je n'ai plus rencontré depuis que j'écris des TU parce que je les détecte en amont, en fait immédiatement.

JS gère-t-il aussi l'asynchronicité de tes variables globales, ou l'état de tes objets membre ? Ils sont forts chez javascript. Je comprends le problème de l'auteur, et je ne dis pas que JS est bien équipé.

Tu confondrais pas asynchrone et mutation par hasard ?

Outils payants ou gratuits, c'est important de savoir pour des langages tout public ?

99,99999% des outils JS sont opensource et gratuits.

Oui Node a tout changé. Les développeurs Front-End font des doubles appels à la même ressource statique, et ils ne savent même pas pourquoi. Ils comprennent rien à tous ces frameworks, tellement c'est simple et tout public.

La population de dev JS est surtout très jeune et manque d'expérience, mais c'était pareil avec Java il y a 10 ans. Il ne faut pas oublier que la croissance de la population de dev est énorme, ça double tous les 5 ans donc l'expérience moyenne du dev lambda que tu rencontres dans le monde pro est mécaniquement faible sauf politique RH bien particulière.

"et pire C++"... C'est-à-dire ?

Que l'évolution de JS en 5 ans a été extrêmement rapide. "Pire" n'était pas le bon mot à employer ce n'est pas péjoratif d'avoir un écosystème stable.

Vous croyez vraiment à ce que vous racontez ? Quelques sont ces statistiques sur ces fameux SI d'une très grande complexité...

Les SI utilisent ce truc par phénomène de mode, par lobbying et par facilité, pas par efficacité.

Non c'est juste plus efficace et moins cher à exploiter pour les besoins de ces grands groupes. Ça ne veut pas dire que c'est pertinent pour tous les SI ça dépend du contexte.

Bientôt, ils vont vous faire croire que l'on peut faire des jeux vidéos en node.js...

Pour écrire un moteur graphique c'est peu probable. En revanche pour gérer la couche réseau d'un jeu en ligne c'est très probable !

Je n'ai pas trouvé avec TypeScript comment se connecter à une base de données, écrire dans un fichier, etc.

Si tu ne sais pas comment faire des I/O avec node, que ce soit en JS ou en TS ça n'a juste rien à voir TS étant une extension de JS apportant du typage statique et seulement du typage statique, c'est simplement que tu ne t'es pas formé dessus.

Les API d'I/O dépendent de la plateforme (node ou browser), pas du tout du langage.

pas plus que je ne vois comment on peut se vanter d'avoir de meilleures performances avec une telle architecture !

On a de meilleures performances si l'outil correspond au besoin.

Si le besoin est d'effectuer du calcul alors Node sera horrible en terme de performances.

Si le besoin est de traiter un grand nombre de requêtes réseau (http ou autre d'ailleurs) avec peu de traitement et d'aboutir à des I/O (fichiers, réseau, bases de données, ...) alors node est conçu pour être performant. Et il l'est vraiment beaucoup ! (débat event loop vs multi-threading)

J'ai raté un truc je pense...

Oui tu as oublié de te former c'est gênant xD

Commence donc par le point de départ :

[Neckara]

Tout ce que fait ton exemple, c'est de lire un fichier index.html et renvoyer le résultat à l'appelant.
Je ne vois pas d'accès à des données...

Si tu peux lire un fichier, tu peux aussi écrire. Et si tu recherche fs, tu trouveras toute une API de manipulation de données. Je t'ai juste donné le premier lien.

Tiens pour un accès à une base de donnée (idem premier lien) : https://www.w3schools.com/nodejs/nodejs_mysql.asp

Pipo, plage, ski, toussa...

Heu… ???

Intèrférer : ok pourun site bancaire public. Pour une application d'entreprise, OSEF.

Heu… tu es sérieux ?

Et pour choisir de surcharger un serveur de calculs pour pouvoir garder les résultats en cache, ou plutôt déporter les calculs au client... perso mon choix est vite fait !

Cela dépend encore une fois des calculs… j'en ai qui demandent ~64 cœurs, et quelques To de ram. Non, je ne vais pas les faire côté client.

Le confort du développeur doit venir dans les dernières positions quand il s'agit de choisir une techno, clairement pas l'inverse !

L'optimisation prématurée est diabolique.

Déjà un code qui fonctionne, développé dans des temps raisonnables, c'est suffisant dans 99% des cas. Et pour les 1% restant, tu peux faire évoluer ton code en réimplémentant certaines sections critiques.

Hmmmm...
Temps d'accès en mémoire, on est de l'ordre de la µs.
Temps d'accès disque, on est de l'ordre de la ms.
Temps d'accès REST (serveur socket + encapsulation HTTP + ...) on est de l'ordre du centième ou dixième de seconde à condition d'être sur un réseau local fibré.

Bref, le goulot d'étranglement, il commence déjà par choisir la techno qui correspond au besoin : si j'ai pas besoin de faire du REST entre mon backend et ma couche d'accès aux données, je fait pas de REST en me disant que je verrai plus tard si ça rame !

Pourquoi tu veux faire du REST aussi…

[Pyramidev]

Marco46 et StringBuilder, vous ne parlez pas de la même chose.

StringBuilder pense à des exemples d'applications internes en entreprise où il n'y a pas besoin de séparer le client et le serveur et où on peut directement coder des applications Desktop.
Alors, les performances des applications Desktop sont meilleures, car on ne s'encombre pas des échanges HTTP entre la partie graphique et la partie métier/calculs. EDIT après lecture du message de Neckara : mais il y a toujours des cas particuliers, comme l'exemple de Neckara où le PC du client n'est pas assez puissant.

Marco46 parle du cas où on sépare le client et le serveur. Dans le cas où le serveur reçoit un très grand nombre de requêtes, mais que chaque requête est rapide à traiter, Node se débrouille bien par rapport à la concurrence.

Mais, là, on est partis dans le hors-sujet.

[StringBuilder]

Pour rappel : je demande en quoi TS peut remplacer Java ou C# côté backend (donc pour coder les API qui fournissent et traitent les données pour le compte de la partie client).
Car autant je suis convaincu pour faire du web riche, bah de toute façon c'est JS et rien d'autre (donc TS ou alternatives), autant côté serveur, j'ai toujours pas pigé ce que TS peut apporter, et comment il peut être plus performant.

Je n'ai plus rencontré ce type de bug en JavaScript, ni même en Java d'ailleurs, depuis que j'ai pris l'habitude d'écrire systématiquement des TU.

Moralité, JS oblige a écrire 10 fois plus de TU pour compenser les lacunes (laxitudes ?) du compilateur.

En fait je peux éventuellement le rencontrer mais au moment de l'exécution du test, c'est à dire quelques secondes après avoir écrit mon code.

Ok, donc t'as une interface ITruc.
Tu as un objet Machin qui n'hérite pas de ITruc, puisque ça sert à rien d'indiquer explicitement l'héritage quand on souhaite implémenter une interface : le faire d'implémenter les méthodes suffit (en gros, du moment que mon objet implémente certaines méthodes il hérite automatiquement de toutes les interfaces qui déclarent ces interfaces).
TU ou pas, le jour où tu passes dans ton code et que tu dégages une méthode car tu penses qu'elle ne sert à rien, ce n'est qu'en rejouant tous tes TU (si tu as bien pensé à tous les écrire) que tu te rendra compte que t'as fait pété un module qui appelle ton objet dans un coin totalement hors de ton contexte.

99,99999% des outils JS sont opensource et gratuits.

Je prend le premier tuto sur DVP et bam ! Premier IDE proposé est un truc payant :
https://tarh.developpez.com/articles...er-typescript/

Si tu ne sais pas comment faire des I/O avec node, que ce soit en JS ou en TS ça n'a juste rien à voir TS étant une extension de JS apportant du typage statique et seulement du typage statique, c'est simplement que tu ne t'es pas formé dessus.

Les API d'I/O dépendent de la plateforme (node ou browser), pas du tout du langage.

Ok, donc un backend, j'ai pas de navigateur. Je suis libre, je souhaite écrire un ERP en TS, j'ai une base de données Oracle (histoire d'avoir un truc aussi bien présent sur Linux que Microsoft), je souhaite donc exécuter des requêtes SQL dedans.
File-moi des liens, car jusqu'à présent, j'ai toujours pas vu la moindre doc me parler de connexion ODBC ou autre à une base de données depuis JavaScript !

Ensuite, si les I/O sont dépendants de l'OS, de l'environement d'exécution (browser, serveur web, script, je ne sais quoi) alors :
- Vas-y la merde pour se former
- Vas-y la pérennité des outils

Si le besoin est de traiter un grand nombre de requêtes réseau (http ou autre d'ailleurs) avec peu de traitement et d'aboutir à des I/O (fichiers, réseau, bases de données, ...) alors node est conçu pour être performant. Et il l'est vraiment beaucoup ! (débat event loop vs multi-threading)

Non, ça c'est pas un besoin, c'est une conséquence de l'architecture web riche : quand t'as un écran qui fait 200 appels à des API serveur par seconde afin d'avoir un chargement asynchrone, c'est la conséquence des choix effectués (application web, asynchrone, etc.)

Oui tu as oublié de te former c'est gênant xD

Commence donc par le point de départ :

Je suis de la vieille école, j'ai pas sous la main un casque pour regarder des vidéos.
Si tu as des liens avec de la LECTURE et des exemples (si possible complets) alors je suis preneur, je veux bien me former pour aller plus loin dans ce débat.