Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Quel est l'intérêt d'écrire ou réécrire un logiciel en JavaScript ?
Partagez votre expérience

Le , par Michael Guilloux

143PARTAGES

12  3 
Lors de la conception de systèmes informatiques, on a souvent le choix d'utiliser un langage plus ou moins puissant pour publier des informations, exprimer des contraintes ou résoudre des problèmes. Mais la « règle de la moindre puissance » ou « the Rule of Least Power » de Tim Berners-Lee suggère de choisir le langage le moins puissant approprié pour atteindre un objectif donné.

D'après le patron du W3C, il y a un compromis dans le choix entre les langages qui peuvent résoudre un large éventail de problèmes et les langages dans lesquels les programmes et les données sont facilement analysés. Dans les années 1960 à 1980, les informaticiens ont consacré beaucoup d'efforts à rendre les langages aussi puissants que possible. Mais de nos jours, il y a des raisons de choisir non pas la solution la plus puissante, mais la moins puissante, disait-il dans un document du W3C daté de 2006. « Exprimer des contraintes, des relations et des instructions de traitement dans des langages moins puissants augmente la flexibilité avec laquelle les informations peuvent être réutilisées : moins le langage est puissant, plus vous pouvez faire des choses avec les données stockées dans ce langage », expliquait Tim Berners-Lee.

En 2007, comme corollaire de la Règle de la moindre puissance de Tim Berners-Lee, Jeff Atwood - un développeur de logiciels, auteur, blogueur et entrepreneur américain - a proposé la loi d'Atwood. Et elle stipule que « toute application qui peut être écrite en JavaScript finira par être écrite en JavaScript ».


Eh bien, avec le développement de l'écosystème JavaScript, il semble que beaucoup de projets ont été écrits ou réécrits en JavaScript conformément à cette loi. Un exemple récent est le logiciel de gestion de versions décentralisé Git et sa version JavaScript isomorphic-git.

D'après son développeur, isomorphic-git est une implémentation JavaScript pure de git qui fonctionne dans les environnements Node et navigateurs (y compris les WebWorkers et ServiceWorkers). isomorphic-git vise aussi l'interopérabilité à 100 % avec l'implémentation standard de git. Tout cela sonne bien, mais qu'en est-il de son utilité réelle ? Peut-être réside-t-elle dans l'intérêt d'utiliser JavaScript ?

Rappelons en effet que les langages de programmation ne vivent pas isolés et que leur destin est lié à leur écosystème. Et sur ce point, les adeptes de JavaScript peuvent justifier l'utilisation de ce langage. JS est en effet une cible de portage populaire parce que les navigateurs Web (qui ne jurent que par lui ?) sont des plateformes largement déployées, mais également parce que des plateformes comme Node et Electron - qui reposent sur JavaScript - sont aussi largement répandues. Ainsi, cibler JavaScript vous permet de cibler certains frontends et backends avec le même code. Il y a probablement encore d'autres raisons qui pourraient justifier cela. Mais qu'en est-il des inconvénients ?

En savoir plus sur isomorphic-git

Sources : The Rule of Least Power, Atwood's Law

Trouvez-vous utile de réécrire Git en JavaScript ? Quel est l'intérêt du projet isomorphic-git ?
Quel est l'intérêt d'écrire ou réécrire un logiciel en JavaScript ?
Les avantages de JavaScript pèsent-ils plus que ses inconvénients ?
Que pensez-vous de la Règle de la moindre puissance et de la Loi d'Atwood ?
De manière générale, que recherchez-vous quand vous décidez de réécrire un logiciel donné dans un autre langage ?

Voir aussi :

Excel : Microsoft ajoute la possibilité d'écrire des fonctions personnalisées en JavaScript, mais également des fonctions d'apprentissage automatique
Oracle peut-il s'opposer à l'utilisation du terme JavaScript par des tiers ? Le créateur du langage s'exprime sur la question
JavaScript : faut-il privilégier les transformations XML à JSON et aux Frameworks ? Partagez vos avis
JavaScript : Webpack en version 4 est maintenant disponible, et focus est fait sur le zéro configuration

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de grunk
Modérateur https://www.developpez.com
Le 18/05/2018 à 8:31
C'est un trolldi qui veux pas l’admettre cet article non ?

Si je choisi le langage le moins puissant qui répond à mon problème à l'instant T , comme je fait si à T+1 je dois mettr een place une fonctionnalité que ne supporte pas le langage précédemment choisi ? Je recommence tout ? Qui paye ?

Trouvez-vous utile de réécrire Git en JavaScript ? Quel est l'intérêt du projet isomorphic-git ?
C'est clairement indispensable de réecrire un logiciel en javascript pour qu'il utilise un langage haut niveau, non typé qui repose lui même sur un interpréteur en C ou C++ alors que le dit logiciel est déjà codé en C...

A part essayé de donner de l'intérêt à javascript en nous montrant qu'il peut tout faire (généralement mal) je vois pas bien l'intérêt
16  0 
Avatar de Artemix
Membre habitué https://www.developpez.com
Le 18/05/2018 à 9:19
  • Suivre la mode
  • Écrire un logiciel dans un langage mal conçu et particulièrement lent
  • Remplir son disque dur à coup de plusieurs Gb de node modules
11  1 
Avatar de grunk
Modérateur https://www.developpez.com
Le 18/05/2018 à 19:43
Citation Envoyé par Marco46 Voir le message
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 !
Javascript n'est pas mauvais, faut juste l'utiliser dans des cas ou ca fait sens.
git est un outil de gestion de fichiers. 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++. A partir de là c'est pour moi pas le bon langage pour le job.

Le problème de javascript c'est que le langage est très limité en fonctionnalité de base (pas de filesystem , pas de socket, pas de thread, etc ...) puisqu'il n'en avait pas besoin dans son utilisation originale. Aujourd'hui on le "détourne" de son utilisation originelle pour en faire un langage à tout faire à grand coup de node machin et node truc.

Tout ça conduit pour moi au plus gros problème de JS : son écosystème. C'est trop compliqué ! Pour le moindre projet faut s'enfiler des dizaines de dépendances qui , on l'espère , ne disparaîtrons pas ou ne seront pas mise à jour trop vite. Du coup c'est très simple (donc pas cher) d'ajouter une fonctionnalité à un projet mais c'est aussi la catastrophe quand une de ces dépendances disparaît ou ne marche plus comme elle devrait ( cf le bordel monumental qu'avait foutu la disparition de je sais plus qu'elle ensemble de paquets).

Alors peut être que dans quelques années tout ce sera tassé , que les gros fw en présence auront fini de release tous les 15j pour ne pas se faire bouffer par le dernier truc à la mode , mais en attendent quand on développe des projets qu'on doit maintenir sur 5 ou 10 ans (voir plus) et qu'on à le choix entre un langage qui se suffit à lui même et javascript + node + x modules ... ba le choix est vite fait.

Pour conclure , y'a 15 ans les dév JAVA disait :
J'ai vraiment de la peine pour tous ces devs C/C++ 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 les dév C++ disait que JAVA était lent.

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. Et avec un peu de chance dans 15 ans JS aura un super écosystème stable , on aura plus besoin d'utiliser de transpiler et aura des alternative dans le navigateur pour ceux qui ne pourrons toujours pas le voir en peinture.
10  0 
Avatar de Jitou
Membre averti https://www.developpez.com
Le 23/05/2018 à 11:56
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 !
10  2 
Avatar de grunk
Modérateur https://www.developpez.com
Le 19/05/2018 à 8:27
Citation Envoyé par Marco46 Voir le message
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.

Citation Envoyé par Marco46 Voir le message

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
6  0 
Avatar de sekaijin
Expert éminent https://www.developpez.com
Le 21/05/2018 à 14:26
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
6  0 
Avatar de Shepard
Membre éprouvé https://www.developpez.com
Le 21/05/2018 à 19:58
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
6  0 
Avatar de SimonDecoline
Membre expert https://www.developpez.com
Le 21/05/2018 à 21:35
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.
7  1 
Avatar de sekaijin
Expert éminent https://www.developpez.com
Le 23/05/2018 à 20:43
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
6  0 
Avatar de Pyramidev
Expert confirmé https://www.developpez.com
Le 22/05/2018 à 1:48
Citation Envoyé par blbird Voir le message
C++ doit être écrit en grande partie en C et en assembleur, et le C lui-même doit bien être écrit en assembleur.
C et C++ ne sont ni des logiciels, ni des bibliothèques, mais des normes écrites en anglais.
Les trois compilateurs C++ les plus connus sont GCC, MSVC et Clang. Ils sont tous les trois codés en C++ et savent compiler à la fois du C et du C++.
6  1