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.

[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

[felicityjohns]

Réécrire un logiciel en JavaScript offre de nombreux avantages. JavaScript est largement utilisé à la fois pour le front-end et le back-end, ce qui permet une meilleure portabilité et des performances optimales sur différentes plateformes. De plus, il est idéal pour les applications web interactives grâce à ses frameworks populaires comme React et Node.js.

[moustic98]

Et encore là c'est rien parce qu'ils ne sont même pas sur la défensive. Mais attends un peu qu'ils commencent à se rendre compte que leur langage préféré est entrain de se faire balayer comme un fétu de paille par l'écosystème JS et là tu verras une phase de déni particulièrement violente.

J'ai vraiment de la peine pour tous ces devs Java/.NET qui vont générer des montagnes de sels dans quelques années quand toute leur expérience et expertise accumulée ne servira plus qu'à travailler sur du vieux legacy pourri et que tout le monde aura migré sur node.

C'est là qu'on va vraiment se marrer !

Pour ta culture personnelle : COBOL existe toujours !

Sun (java) à initié la Logic de composants : awt, swt, swing

Java a implémenter le model MVC, la démocratisation du client léger, et à ouvert les portes à l'existence même de JS.

Le jours ou le JS pourras couvrir un socle de fonctionnalités de base tel un grand language du calibre du c/c++, java, .NET même si j'aime pas, il aura la vie belle.

En attendant, aucune DSI n'est assez connue et buter pour recorder 30 ans d'application en JS alors qu'elle se porte bien et marche, à moins que tu casses les prix du marché et que tu recode tous en 6 mois, le risque est juste trop gros, en attendant, JavaScript est bien côté front, excellent même pour concevoir un client léger riches, mais loin, très loin de pouvoir réaliser un batch performant avec une fonctionnalité basic, même si tu exposé tous en REST.

COURAGE l'ami.

[4sStylZ]

Ah lala, Javascript continuera de faire couler de l’encre.

Un petit talk humoristique sympa : https://www.destroyallsoftware.com/t...-of-javascript

[sekaijin]

Je ne suis pas tout à fait d'accord avec l'analyse qui est faite.

Je ne sais pas comment on peut dire qu'un langage est plus "puissant" qu'un autre. pour moi il n'ont pas la même couverture expressive.

JavaScript a dans cette affaire une caractéristique qui est particulièrement utile. le fait de gérer nativement la programmation événementielle (réagir à des événements peut importe les noms qu'on donne à la chose).

on peut très bien implémenter une telle programmation en C et même en assembleur. Alors Passer de C/C++ à Javascript pour une application essentiellement événementielle
c'est juste choisir un langage qui porte nativement cette fonctionnalité à la place de l'implémentater.
dans ce sens c'est passer à un langage plus "puissant".

ReactiveC++ aurait été n choix tout aussi pertinent. et bien d'autre aussi.

Il y a aussi dans cette affaire le passage du compilé statique au compilé à la volée. (Aujourd'hui tous les langages interprétés ou presque utilisent un compilateur à la volé et une machine virtuelle). qu'on soit d'accord où pas il est une chose qui est certaine c'est que les deux ont des avantages et des inconvénients.

La question à se poser dans le choix est "quelle utilité ?" Si c'est utile pour l'application dans quelle mesure. (il est bien plus facile de faire de l'auto-programmation avec un langage interprété) pour répondre il suffit de mettre les avantages et les inconvénients de tous les langages candidats de pondérer le critère en fonction de absolument nécéssaire, nécessaire, un plus, pas nécessaire. et ça aide à y voir clair.

le dernier point est la nature des objets (en tant que structure) manipulés. Si on manipule des objets à la définition stricte peu ou pas évolutive les langages fortement structurés ont été pensé pour ça. Si on manipule des structures au contours vague et changeant les langages portant nativement de telles définitions de structures seront mieux adapté. là encore les deux ont des avantages et des inconvénients et il convient de les évaluer pour faire un choix pertinent.


Et pour finir il y a un facteur que je pense on oubli un peu trop. Les compétences. Mieux vaut utiliser un langage maitrisé et moins bien adapté qu'un langage parfaitement adapté mais inconnu. La disponibilité des compétences sur le marché sont aussi un facteur qui doit entrer dans le choix. aujourd'hui où tout va très vite on oublie un peut trop que certaines applications fonctionnent depuis 40 ans. et je sais par expérience que ce qu'on pensait pérenne sont porte depuis longtemps et d'autre qu'on disait provisoire sont là depuis des décennies. Alors choisir un langages ésotériques connu d'une poignée d'aficionados, c'est prendre le risque de devoir dépenser des sommes astronomique pour maintenir la chose. Même en choisissant des langages répandus, le temps fait que les compétences disparaissent. (on cherche des développeur COBOL aujourd'hui).

Alors plus que le fait d'avoir réécrit git ce qui serait intéressant c'est d'avoir l'analyse qui a mené à ce choix.
A+JYT

[Shepard]

Selon les stats Github, l'intérêt porté dans les projets javascript est fortement à la baisse ces 5 dernières années (bien qu'il reste le plus "tendance"):



https://madnight.github.io/githut/#/stars/2018/1

[blbird]

Une "tendance"? Il fait plus que tous les autres cumulés. Sacré tendance tu me diras dit-donc!

[Shepard]

Je trouvais ce graphique pas mal par rapport au sujet ^^

En 2012 JS avait plus de 50% de l'attention sur github, c'est vrai que c'est impressionnant !

[Invité]

S'il vous plait arrêtez de citer nodejs et electron pour "prouver" les qualités de javascript. Nodejs c'est essentiellement v8 (60% en C++) + libuv (95% en C). Pareil pour electron (70% en C++).

Quant aux nombreux packages JS sur github ce n'est pas du tout un avantage mais une conséquence de l'absence de lib standard.

[Jitou]

Tant qu'on fera du soft jetable, du front pour l'essentiel en Javascript le principe de Tim Berners Lee sera appliqué à bon escient car plus personne ne fait évoluer un soft écrit en JS, le plus souvent après quelques années on jette et on recommence, éventuellement avec le nouveau framework js tendance du moment !

[Marco46]

Encore un commentaire qui n'a aucun rapport avec le js. On peut faire n'importe quoi n'importe comment avec n'importe quel langage ou outil. Si des gens ont le pognon pour coder n'importe comment, ne pas investir dans leurs tests et réécrire tout à chaque changement de techno majeure ou évol fonctionnelle majeure c'est leur problème mais je ne pense pas que ça soit la majorité des cas, il y a globalement peu d'entreprises qui ont ce genre de moyens.

[sekaijin]

Je crois qu'il faut relativiser tous les chiffres qu'on vois.

si tu vas sur une forge né à l'époque où il n'y avait que pascal cobol et C puis C++ tu vas aujourd'hui trouver que 80% des projets sont en C++

ça ne fait pas de C++ le langage hyper dominant.

Git est né en même temps que l'émergence des des frontend Js puis de js en backend les projets C++, java etc était sur d'autre forges c'est donc normal que git se retrouve avec 50% de projet git.
cela ne signifie pas que 50% des projet sont en js.

Donc le graphique de git ne donne d'info que sur git. et rien de plus. si js est populaire et s'il est Le langage à la mode dans les écoles tous les langages ont des avantages et des inconvénients.
et non js ne remplacera pas tout pas plus que les autres langages.

A+JYT

[blbird]

Tant qu'on fera du soft jetable, du front pour l'essentiel en Javascript le principe de Tim Berners Lee sera appliqué à bon escient car plus personne ne fait évoluer un soft écrit en JS, le plus souvent après quelques années on jette et on recommence, éventuellement avec le nouveau framework js tendance du moment !

Je ne vois pas pourquoi on ne ferait pas évoluer un soft écrit en JS, pas plus qu'avec d'autres langages. Passer d'un framework à un autre (quelque soit le niveau du framework ou de la lib), c'est aussi une évolution.

Certaines grosses application JS évoluent déjà depuis de nombreuses années sans problème. Ce n'est pas une question de langage, mais de choix techniques des informaticiens.

[alves1993]

Je ne vois pas pourquoi on ne ferait pas évoluer un soft écrit en JS, pas plus qu'avec d'autres langages. Passer d'un framework à un autre (quelque soit le niveau du framework ou de la lib), c'est aussi une évolution.

Je ne suis pas d'accord avec ce que tu énonces, passer d'un Framework à un autre n'est pas une évolution mais plutôt une réécriture.
Les développeurs qui ont effectué la transition de projets AngularJs à Angular 2/4/5 peuvent en témoigner.

[blbird]

Je ne suis d'accord avec ce que tu énonces, passer d'un Framework à un autre n'est pas une évolution mais plutôt une réécriture.
Les développeurs qui ont effectué la transition de projets AngularJs à Angular 2/4/5 peuvent en témoigner.

Je comprends, mais là le problème vient plutôt :

• Du fait qu'Angular est un Framework tout inclus
• et qu'ils ont changé énormément de choses

Le problème ne vient pas de JS en lui-même, quelque soit le langage, tu aurais gagné plus de temps à réécrire une bonne partie du code existant à migrer, que de tenter de l'adapter.

La plupart du temps, un changement de version d'un framework ou d'un ensemble de librairies d'un projet donné n'implique pas une réécriture complète, juste une adaptation. Car on est souvent dans un changement de version mineure (voir majeur sans trop d'impact), et aussi souvent sur seulement une partie du code (et pas la totalité).

Pas de bol pour Angular, je compatis.

[Marco46]

Je ne suis pas d'accord avec ce que tu énonces, passer d'un Framework à un autre n'est pas une évolution mais plutôt une réécriture.
Les développeurs qui ont effectué la transition de projets AngularJs à Angular 2/4/5 peuvent en témoigner.

C'est vrai que c'est pas une évolution au sens de monter de version une lib. Ça c'est clair. En revanche si tu dois TOUT réécrire pour passer ton app de AngularJS a Angular il faut vraiment faire une pause et se poser des questions. Normalement tu as 90% de ton js qui est dans des services, et transformer tes services en classes je suis désolé mais ça impose pas de réécrire tout. Tu peux même le faire en restant en AngularJS, tu n'as plus que l'injecteur à transposer (et je me demande même qu'elle est l'utilité de cette usine à gaz dès lors que tu es en ES6 mais c'est un autre sujet).

Le vrai sujet sur une migration c'est à quel point ton appli est écrite en respectant les good practices et à quel point le test de ton appli est automatisé pour savoir pendant que tu effectues la transition si tu pètes un truc.

[nirgal76]

Bon ben, à lire ce fil, j'suis bien content de faire et maintenir des projets C++ depuis 20 ans (et ils sont partis pour durer encore un bout).
Au moins, je n'ai pas à suivre la mode du moment.
comme disait ce bon vieux Oscar, “Fashion is a form of ugliness so intolerable that we have to alter it every six months.”

[mister3957]

Il y a Git et Github, mais on aura compris.

Dans les commentaires on a pas bien vu les "pour" dire "JS ça doit être la suprématie, le langage unique, le reste c'est de la merde".

On a surtout vu les "contres" inventer des trucs faux, frustrés de devoir apprendre un truc de plus en lien avec leur métier. Sûrement ont-ils capitalisé sur une tech qui se voit de plus en plus dépréciée, menacée.

Mais c'est pas nous qui décidons, c'est le marché, la tune.

Etant expert C/C++, j'ai eu du mal à trouver un job autre chose que de la pauvre TMA sur des systèmes anciens en mode pompier et ma précédente expérience c'était en mode gourou, c'est un signe qu'il faille se renouveler pour se sentir "comme les autres". Parfois je participe à des trucs open source, mais c'est pas ça qui va me donner à bouffer.

Il est vrai que c'est chiant de devoir apprendre un truc à 40 piges et de se retrouver à demander des conseils au stagiaire du coin alors qu'on a passé des décennies pour devenir experts sur autre chose, surtout quand ça nous fait changer de paradigme, c'est frustrant et on en vient à avoir du mal à justifier son salaire alors qu'on est rendu à l'état de bleuzaille côté productivité. Je me vois mal dire en daily "ben moi (qui coûte 670 balles la journée) je suis occupé à apprendre à utiliser des promesses mais le petit kevin (23 ans) va m'aider aujourd'hui".

Pourtant il faut l'accepter et c'est pas parce qu'on est une pipe dans une techno que le bagage pro général que l'on a acquis ne vaut plus rien, y'a pas que le code dans notre métier.

Ou sinon autre solution, on fait caissier à la supérette du coin, il y a déjà plus de chance que son quotidien pro ne change pas trop trop d'une année à l'autre.