Discussion :

[gallima]

https://benchmarksgame-team.pages.de...avascript.html
Je suis pas expert niveau performance, mais cela reflète bien les différences de coût entre notre existant de frontend java et nos nouveaux frontend en javascript.


Javascript n'est pas très présent dans mon domaine (https://stackoverflow.com/tags/nlp/info pas une seul référence à javascript). De même les outils en javascript existant sont généralement des API vers d'autre systèmes qui ne sont pas en javascript (deeplearn.js même pas en version 1.0). En machine learning (https://stackoverflow.com/tags/machine-learning/info) C++/Python/Java dominent. Pour les taches de raisonnement, c'est surtout du C++ et des langages un peu typé à la compilation (scala/java/ocaml/erlang ou le tout nouveau Rust qui brille bien) éventuellement du python avec un projet de réécriture en C à coté.C'est amusant car il est rare que les raisonneurs utilisent plus que des bibliothèques très généraliste, comme si le fameux écosystème ne sert à rien à coté des performances.

Si quelqu'un dispose d'un raisonneur OWL2(w3c) ou d'un solveur ce CSP (Choco/swi-prolog-cplfd) en javascript alors je suis preneur à 100%; (en Typescript si possible). J'aurais plein d'idée pour le mettre en valeur.
De même si vous avez des exemples d'utilisation des instructions SIMD en javascript je suis prenneur.


Maintenant c'est vrai que je ne fais du javascript que depuis 5-6 ans et surtout pour des ihm/web (donc je ne suis pas full time javascript) mais j'ai vraiment rien vu de javascript qui pourrait m'aider sur mon cœur de métier. à chaque fois que y a quelque chose d'un peu fun c'est pour faire des IHM avec javascript/SVG/html. Avoir le choix entre 25 lib pour des connexions réseaux, c'est cool, mais à chaque fois les 2-3 libs des langages 'old-fashion' font bien le boulo.


Je pense que réécrire un logiciel avec un cahier des charges plus précis (l'existant) donne toujours plus de performance à la fin.
Si vous êtes près a payer pour une ré-écriture complète alors l’intérêt spécifique de javascript est secondaire; regarder d'abord de quoi est composé votre équipe et le sujet auquel vous vous attaquez.

[Marco46]

Javascript ne permet pas nativement la gestion de fichiers. Il faut passer par une api non standard ou par un module node codé sans doute en c ou c++.

Si manipuler le filesystem n'est pas natif en js, manipuler le DOM ne l'est pas non plus. Et JavaScript n'est pas plus natif que du Java ou du C#, tout ça est écrit en C/C++ ...

Je vois pas trop où tu veux en venir là ...

15 ans plus tard C/C++ se portent très bien, Java est toujours pas aussi rapide mais se défend bien, l'embarqué est toujours dév en C.

Désolé mais non. Java a écrabouillé tous les autres langages dans le champ du dev de gestion et en particulier sur le dev web. Trouver du taf en C/C++ de nos jours c'est quand même pas la même tisane que trouver du dev J2EE. Ce qui se passe depuis quelques années c'est que Java est à son tour entrain de se faire écrabouiller par le JavaScript. C'est pas encore arrivé trop en France parce qu'on est systématiquement à la bourre de 5/10 ans, mais aux USA c'est flagrant. On y aura droit.

Et en embarqué tu devrais regarder de plus près ce qui se fait avec node. Là aussi c'est entrain de percer significativement. Et en desktop aussi, on a de plus en plus de clients lourds développés intégralement en js. Le plus connu pour les développeurs est probablement Visual Studio Code.

Le seul point sur lequel l'écosystème js est mauvais c'est les traitements lourds qui consomment beaucoup de CPU. C'est normal c'est designé pour avaler un très grand nombre de requêtes réseaux, pas pour faire du calcul. Or 95% du code des applis web nécessitent peu de calcul mais d'avaler un très grand nombre de requêtes très vite. L'architecture basée sur les threads ne tient pas la distance face à l'event loop mono-threadé. C'est comme ça. Ça scale pas. Node.js scale mieux. C'est plus simple à dev, plus simple à tester, plus simple à déployer, plus simple à opérer.

Les stacks modernes c'est du js à tout va back et front et pour certains traitements spécifiques du Java/C#/C/C++/whatever.

[koyosama]

"J'ai vu du code de merde fait en <tel_langage> alors <tel_langage> est pourri".

https://blog.risingstack.com/node-js...e-js-at-scale/

le rapport entre synchone et multithread? La dernière phrase ne veux rien dire.

"Je galère a faire du synchrone dans un langage asynchrone, mais dans un langage multithread je peux faire du multithread". gné?

Oui effectivement sur le plan mécanique non.

Le parallèle entre les deux sont un action et séparation de tâches de la tâche principale. Quand on veut simuler une tâche qui affecte une tâche principale, on fait de l'asyncrone, du multi-threading, du paralelisme. Le mécanisme c'est différent, mais en terme de programmation UI, tu verras peut-être peu de différence ou alors ton application à une subtitilité.

Je dis ça, car je veux faire le même mécanisme que le mutithread, c'est à dire faire 50000 appels serveurs sur un autr thread (en fait je m'en fois qu'ils bloque la thread puisqu'il n'est pas sur ma thread UI). Alors que Javascript que Javascript, imaginons j'ai 4 serveurs different à appeler, je dois faire ce qu'on appelle un callback hell juste parce que mes données serveur ce suivent et est dépendant des unes des autres. L'exemple, le plus simple serait le la récupération de l'addresse où je suis sur Google Maps.

J'ai travaillé par exemple sur une appli mobile, où je dois récupérer la position initiale (alors dèjà juste ça c'est foutu requête Promise où je dois attendre la réponse), ouis je dois le transformer, ensuite je dois appeler le putain Geocoder pour répérer l'addresse physique, ensuite attendre la réponse et le transformer. Juste ça, cela me fait un putain de code imbriqué, bien sûr j'ai écrire des module pour cacher ces transformations et tous les layers qui faut. Mais pour juste ça, j'ai dû écrire trop de code que je devrais.

Alors qu'un code C#, je dis pour tout sur cette thread, tu m'appelles quand tu as finis et ça peut me prendre que un fichier et une seul indentation pour rendre le code visible.
Au final, dans la mécanique c'est la même chose, mais l'écriture et la maintenance c'est différents, même pour les tests unitaires sont différents, y'en a un où un seul test pour une seul fonction, l'autre 3 ou 4 pour être que les transformations sont corrects. C# tu peux rendre les requête serveur synchrone, si je le met sur un thread differents, il sera pseudo-asynchrone.

Même utilisé un lambda server, je trouve moins compliqué que d'utiliser Javascript nativement pour faire la même tâche.

[grunk]

Désolé mais non. Java a écrabouillé tous les autres langages dans le champ du dev de gestion et en particulier sur le dev web. Trouver du taf en C/C++ de nos jours c'est quand même pas la même tisane que trouver du dev J2EE.

En web java est ,pour moi loin derrière, PHP voir même javascript où là effectivement il prend tout son sens.
Chez nous on embauche que du dév C++ et c'est pas forcément évident à trouver. Alors que tout le monde veuille faire du JS parce que c'est la mode je veux bien le croire , mais je peux t'assurer que C++ à encore de beau jour devant lui , y'a qu'à voir le succès de QT en ce moment.
Après je veux bien qu'on me montre comment gérer 500Mbit de flux vidéo en y appliquant divers traitement d'image avec JS , comment gérer des cartes électronique avec JS , etc ... C'est sans doute possible mais je doute que ce soit l'outil adapté.

Pour moi faire un git en javascript c'est du même acabit que faire un site web en C++ , c'est possible mais ça n'a aucun intérêt si ce n'est la branlette intellectuelle que ça représente.
Chaque langage à ses forces et ses faiblesses , croire que JS va écraser tous les autres c'est se fourrer le doigts dans l'oeil jusqu'au coude. Il a sa place comme les autres , faut juste pas essayer de le revendre à toutes les sauces.

Et en embarqué tu devrais regarder de plus près ce qui se fait avec node. Là aussi c'est entrain de percer significativement.

Y se trouve que je travail dans l'embarqué , et j'aimerais bien savoir comment tu fais tourner node sur des systèmes avec quelques Ko de ram ... Jusqu'à maintenant on à pas trouvé mieux que le C. Les raspberry et autre truc de genre c'est pas de l'embarqué , c'est juste des petits pc

[mister3957]

Quand tu as besoin de puissance, multithreading, manipuler à l'échelle du bit etc. pas de problème tu peux faire ton truc en C/C++ et tes pauvres bindings v8 / nan pour exploiter ça en JS.

Comme ça ton traitement d'image est fait là dedans, tu profites des avantages de la puissance du C/C++, et pour le déploiement, la scalabilité, la plomberie, le ZDD, le TTM, le prix et l'accès aux compétences, tu profites des avantages du JS.

C'est comme en cuisine, il faut que ça soit varié, équilibré, et surtout bien dosé. Ce serait débile de faire un oeuf au plat sur son lit d'omelette accompagné de ses oeufs brouillés parsemés aux oeufs mimosa tout ça parce que son truc au chef, c'est les oeufs et rien d'autre ;-)

[Marco46]

En web java est ,pour moi loin derrière, PHP voir même javascript où là effectivement il prend tout son sens.

Bah j'ai quand même fait pas mal d'entreprises qui font du dev de gestion web, toutes ces boites ont des stacks J2EE. J'ai jamais vu du PHP.

Chez nous on embauche que du dév C++ et c'est pas forcément évident à trouver.

Ça je veux bien te croire, il y a très peu d'offres donc les gens ne se forment pas et ne sont pas formés à C/C++.

Alors que tout le monde veuille faire du JS parce que c'est la mode

Parce que c'est plus efficace. Ca fait mieux le job.

Après je veux bien qu'on me montre comment gérer 500Mbit de flux vidéo en y appliquant divers traitement d'image avec JS , comment gérer des cartes électronique avec JS , etc ... C'est sans doute possible mais je doute que ce soit l'outil adapté.

Ben écoute Netflix stream 8 tera / s avec du node. C'est bien que ça doit marcher non ?

Pour les traitements c'est justement ce que je te disais précédemment, tu délègues cette partie à quelque chose d'adapté (Java, .NET, ...). Mais tu délègues uniquement ça. Tout le reste c'est fait en node.

Pour moi faire un git en javascript c'est du même acabit que faire un site web en C++ , c'est possible mais ça n'a aucun intérêt si ce n'est la branlette intellectuelle que ça représente.

Ça je veux bien admettre qu'une implémentation de git dans le browser sur un filesystem virtuel c'est un peu spécial ! Mais va savoir les usages auxquels pourront penser d'autres personnes ?

De but en blanc je vois assez bien les applications possibles pour gérer une appli de prise de notes collaborative par exemple. Ou pour écrire de la doc. J'ai jamais compris pourquoi les entreprises n'ont pas encore switché des dinosaures comme Word ou Writer pour du markdown. C'est tellement plus facile à gérer du markdown plutôt que ce fatras de xml dans une archive zip ! Probable que les outils n'existent pas encore, et peut être que cette implémentation de git facilitera les choses !

Bref, je crois pas que ça soit de la branlette intellectuelle, il y a probablement plein de use cases utiles auxquels on pense pas.

Chaque langage à ses forces et ses faiblesses , croire que JS va écraser tous les autres c'est se fourrer le doigts dans l'oeil jusqu'au coude. Il a sa place comme les autres , faut juste pas essayer de le revendre à toutes les sauces.

Ah mais je crois pas, je constate ! Regarde les chiffres du nombre de modules sur les différents registres, du nombre de codes sources sur github et consort, le nombre d'articles, de conférences, etc ... Et le nombre de boites qui annoncent avoir migré avec succès, c'est hallucinant !

Que ça soit pas le cas en France encore, ça c'est clair, mais ça arrive gentiment. Il y a 2 ans il n'y avait rien, aujourd'hui la plupart des startups démarrent sur du node. Il y a plein d'offres sur linkedin. Bref ...

Y se trouve que je travail dans l'embarqué , et j'aimerais bien savoir comment tu fais tourner node sur des systèmes avec quelques Ko de ram ... Jusqu'à maintenant on à pas trouvé mieux que le C. Les raspberry et autre truc de genre c'est pas de l'embarqué , c'est juste des petits pc

Alors je suis pas expert, mais pour l'IoT (si c'est ça que tu appelles embarqué), il y a plein de cartes qui embarquent un node en natif. Il y a des versions de node dédiées qui embarquent un moteur différent de V8 qui est optimisé pour tourner avec peu de ressources.

Mais honnêtement j'y connais rien je sais juste que ça existe.

[Marco46]

Alors que Javascript que Javascript, imaginons j'ai 4 serveurs different à appeler, je dois faire ce qu'on appelle un callback hell juste parce que mes données serveur ce suivent et est dépendant des unes des autres. L'exemple, le plus simple serait le la récupération de l'addresse où je suis sur Google Maps.

C'est parce que tu veux coder ton js en ES5 comme si t'étais en 2010. Entre temps on a eu Babel puis ES6/7/x en natif et plein de libs (Bluebird, rxjs, ...)

C'est pas interdit d'utiliser des promesses ou de l'async/await ...

Même utilisé un lambda server, je trouve moins compliqué que d'utiliser Javascript nativement pour faire la même tâche.

En 2010 oui c'était pas tip top. Ce n'est plus vrai aujourd'hui (et depuis quelques années déjà d'ailleurs).

[alves1993]

Ben écoute Netflix stream 8 tera / s avec du node. C'est bien que ça doit marcher non ?

Hunnn ,
Il serait aimable de ta part de donner des épreuves de ton affirmation (Lien articles ; benchmarks ; citation ; etc....).

Pour les traitements c'est justement ce que je te disais précédemment, tu délègues cette partie à quelque chose d'adapté (Java, .NET, ...). Mais tu délègues uniquement ça. Tout le reste c'est fait en node.

Insinues-tu que presque toute la Stack de Netflix est écrite en Node ?
Si oui a quel niveau ? plus de 80% de la Stack? plus de 70% de la Stack ?

[psychadelic]

Hunnn ,
Il serait aimable de ta part de donner des épreuves de ton affirmation (Lien articles ; benchmarks ; citation ; etc....).

Insinues-tu que presque toute la Stack de Netflix est écrite en Node ?
Si oui a quel niveau ? plus de 80% de la Stack? plus de 70% de la Stack ?

NetFlix à commencé sa migration depuis Java vers Javascript-NodeJS en 2012, donc ça doit faire un petit moment qu'il doivent en être à 100% JavaScript.

Visiblement t'a raté les info, parce que ça avait fait son Buzz sur les actualités numériques, mais bon, il y aura toujours des devs pour s'imaginer encore que javascript est un jouet, et que nodeJs ne fonctionne que sur des serveurs, ou encore que le nombre de packages présents sur NPM dépasse le chiffre de la population Française.

https://www.slideshare.net/micahr/go...ejs-at-netflix

[Marco46]

Hunnn ,
Il serait aimable de ta part de donner des épreuves de ton affirmation (Lien articles ; benchmarks ; citation ; etc....).

C'est les chiffres donnés par Christophe Porteneuve à la conf Web2Days l'an dernier (juin 2017, elle est sur YouTube sous le nom de "Node.js partout").

Si on cherche un peu on tombe sur un article de 2014 qui donne un chiffre de 8 millions de tera octets streamés par mois.

Donc si on calcule un peu ça donne 60*60*24*30 pour 2 592 000 secondes par mois, une simple division donne environ 3 tera octets par mois en 2014. Donc pas impossible avec la hausse du trafic de netflix. En tout cas on est dans des ordres de grandeurs cohérents avec sa présentation !

Insinues-tu que presque toute la Stack de Netflix est écrite en Node ?
Si oui a quel niveau ? plus de 80% de la Stack? plus de 70% de la Stack ?

De ce que C. Porteneuve explique c'est toute la stack car le temps de boot d'une stack J2EE monolithique lors d'une nouvelle release est trop long (+ d'une heure) alors qu'en microservices + node ils sont de l'ordre de la minute. Je t'invite à faire l'expérience de start un JBoss même avec un simple hello world c'est affreusement long à démarrer. Après tu feras un npm start sur ton Node et tu verras que ça boote en quelques millisecondes.

Il y a aussi des gains de latence très significatifs.

Bref, Node est conçu spécifiquement pour être performant pour faire massivement du réseau et pour être utilisé dans un PaaS, c'est pas le cas de Java qui est plutôt conçu pour faire du développement classique en tant qu'amélioration des vieux développements C/C++. Le but initial était de s'abstraire de la gestion de la mémoire (introduction d'un garbage collector) et d'être multi-plateforme grâce à la JVM installable partout. Je simplifie mais en gros c'est ça.

Donc en bout de ligne l'écosystème node est adapté au web, Java ne l'est pas il n'a jamais été conçu pour. Donc dès que tu dev du web, même de l'appli de gestion sur de l'intranet d'entreprise c'est plus intéressant de faire du Node et de conserver Java uniquement pour des traitements spécifiques. Par exemple c'est pas un hasard si Elasticsearch ou Hadoop sont écrits en Java et pas en JavaScript ni en C/C++. Le calcul distribué en js c'est très moyen puisque le calcul CPU est un killer de perf pour node (du fait de l'event loop mono-threadée en choix de design contre les threads).

Les grandes structures (Banques et assurances) qui drivent le marché des presta (SS2I) ont donc tout intérêt à construire leur propre PaaS et à refaire leurs applis en Node. Ils feront énormément d'économies d'exploitation. C'est un investissement lourd mais on y viendra parce que c'est rentabilisé rapidement. C'est ce qu'ils ont fait aux USA et donc ça va arriver chez nous puisque nos décideurs suivent ce qui se fait là bas, ça prend simplement 10 ans à pénétrer. C'était pareil avec J2EE et les premiers frameworks, c'était pareil avec l'agile, le software craftmanship ça fait quelques années qu'on commence à sérieusement en entendre parler alors que les interventions de Uncle Bob ça a 10 ans (Clean Code c'est 2006 ? 2009 ? Je sais plus) etc ...

Donc tu verras qu'on va voir arriver tout ça dans les années qui viennent, et ça va se coupler avec une ré-internalisation des développeurs parce que ça devient trop complexe pour faire ça avec des prestas qui ont un turnover de 1 à 3 ans. Les allemands l'ont déjà fait par exemple.

[grunk]

et que nodeJs ne fonctionne que sur des serveurs

On peut faire du node coté client ? Parce que je fait partie de ces dév qui pensent que pour avoir un js autre que la version limité des navigateurs il te faut impérativement un serveur (que ce soit un bi xeon ou un raspberry , mais ca reste un serveur)

[Marco46]

Il veut dire que c'est pas que pour faire des serveurs web. Tu peux faire du client lourd avec.

[psychadelic]

On peut faire du node coté client ?

ben oui, on peut même faire des appli "client" en NodeJS, et ça doit faire depuis un moment...

par exemple Visual Studio Code est écrit en Javascript / nodeJs (avec Electron) ça te donne une idée des performances et des possibilités...
et il y a tellement d'objets dans NpM, que c'en est presque à ce demander si les mec se font pas la course pour trouver des secteurs applicatifs encore oubliés

Parce que je fait partie de ces dév qui pensent que pour avoir un js autre que la version limité des navigateurs il te faut impérativement un serveur (que ce soit un bi xeon ou un raspberry , mais ca reste un serveur)

C'est pas tout à fait comme ça que ca se passe, en réalité sur un RaspBerry tu installe un nodeJs simple auquel on ajoute une librairie pour qu'il puisse devenir un serveur.

[Pyramidev]

Marco46, par curiosité, quelle est ton opinion sur l'avenir des langages qui compilent vers du JavaScript et qui essaient de remplacer ce dernier, par exemple CoffeeScript, Dart, Haxe et TypeScript ?

[Marco46]

Je ne connais pas du tout Haxe.

Pour Dart je constate qu'il a fait un flop.

Pour CoffeeScript il a implémenté très tôt (avant l'existence de Babel je crois) plein de super nouveautés apparues plus tard dans ES6. Mais avec le ES6 partout en natif il n'est plus tellement utile. Pour donner un exemple l'équipe de Cypress.io a développé son produit de test front entièrement en CoffeeScript. Ils sont entrain de lentement migrer vers TypeScript parce qu'ils constatent que c'est un blocker pour avoir des contributeurs. C'est assez significatif ça veut dire que la pénétration de CoffeeScript est faible.

Pour TypeScript je suis pas un grand fan parce que beaucoup trop de devs Java/C# cherchent à écrire du Java/C# au lieu de réellement apprendre le js. Et on se prend une masse de confusion entre ce qui relève de TS et de ES6/7/x.

EDIT : Et ils écrivent des classes de partout alors que les modules et les fonctions suffisent amplement dans 90% des cas.

Sinon ça compile pas ça transpile

[psychadelic]

Sinon ça compile pas ça transpile

Oui, ce sont des langages pensés pour une logique de TMA; partant de la, TypeScript est celui qui a le plus d'avenir

[blbird]

Pour TypeScript je suis pas un grand fan parce que beaucoup trop de devs Java/C# cherchent à écrire du Java/C# au lieu de réellement apprendre le js. Et on se prend une masse de confusion entre ce qui relève de TS et de ES6/7/x.

Je n'aurais pas dit mieux!

[koyosama]

C'est parce que tu veux coder ton js en ES5 comme si t'étais en 2010. Entre temps on a eu Babel puis ES6/7/x en natif et plein de libs (Bluebird, rxjs, ...)

C'est pas interdit d'utiliser des promesses ou de l'async/await ...

Cela dépend quel techno que tu utilises pour faire du mobile. Malheuresment moi c'est du legacy. Ensuite, Babel dans un projet comme le mien est compliqué à mettre en place (sans compter l'intérêt du projet). Et pour être franc, qui va être refait en native plus tard, j'ai pas envie de me ca**** le c*l. Et je suis même pas sûre que les tous les browsers mobile ont la compatiblité avec les mécanisme comme async et await. C'est déjà une avancé.

Et justement les promises sont chiants à utiliser et à tester, surtout si tu dois les enchainés. On a pas tous la meilleur stack et la choisir aussi en rien de temps.

Javascript peut être sympa mais c'est le truc le plus chiant pour gérer en terme de timing.

[blbird]

Et justement les promises sont chiants à utiliser et à tester, surtout si tu dois les enchainés. On a pas tous la meilleur stack et la choisir aussi en rien de temps.

Je ne vois pas en quoi c'est compliqué à chainer? Il existe des mécanismes très simples pour ca, nativement, pourtant.

[Invité]

La grosse force de JavaScript c'est surtout le cross platform. Si tu as une équipe de dev. qui maîtrise le langage tu peux faire web + mobile + desktop qui fera le job dans tous les cas ne nécessitant pas de calculs poussés. C'est absolument pas négligeable pour une entreprise.

Question pour les gens qui font du Node, c'est jouable d'intégrer un appel asynchrone à un module codé en C/C++ sans bloquer l'event loop ?