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

Le , par Michael Guilloux, Chroniqueur Actualités
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


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de grunk 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
Avatar de gstratege gstratege - Membre habitué https://www.developpez.com
le 18/05/2018 à 8:50
Citation Envoyé par grunk Voir le message

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 ?
Je pense par langage moins puissant, il veulent dire langage de plus bas niveau. Donc, tu peux faire avec tout ce que tu peux faire avec un langage de plus haut niveau mais plus difficilement. L'avantage c'est que ça t'offre plus de souplesse.

Après pourquoi écrire git en JavaScript, je ne comprend pas l'intérêt.
Avatar de Artemix Artemix - Membre actif 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
Avatar de mister3957 mister3957 - Membre expérimenté https://www.developpez.com
le 18/05/2018 à 9:21
Après avoir refait pas mal de services jusqu'alors écrits en C++ pour les passer en JS, j'y ai vu pas mal d'intérêts :
- Plus facile à maintenir
- Les artefacts sont plus rapides à construire (donc time to market plus intéressant)
- Plus facile à déboguer
- Courbe d'apprentissage largement réduite
- Portabilité (sauf dans de rares cas, quand ça utilise des modules natifs spécifiques)
- Ecosystem riche et ouvert
- Compétences accessibles sur le marché
- Asynchrone

Il y en a juste un qui est resté en C++ car demandant pas mal de puissance et de maîtrise entre la mémoire et le CPU, mais consommé au travers de JS.

Dans une archi microservices, on s'en fou un peu de la puissance du langage, on scale au niveau de l'infra. Il vaut mieux payer un peu plus côté que d'être dépendant de profiles rares et chers, maintenant qu'on le peut avec les conteneurs et leurs orchestrateurs, autant en profiter.

Un petit loup cependant, l'écosystème JS évolue très vite, donc la vieille et l'adaptation est importante pour ne pas se retrouver rapidement avec du code périmé.
Avatar de GordonFreeman GordonFreeman - Membre averti https://www.developpez.com
le 18/05/2018 à 9:47
Bonjour,

Alors perso j'ai rien compris à cette théorie ....
La moindre puissance ?! Puissance de quoi ? de calcul ?

A moment donné faut arrêter le délire.
Le choix d'une technologie pour le développement d'une application évolutive et maintenable est plutôt lié au besoin technique, aux fonctionnalités requises, aux framework/API disponible pour traiter telle ou telle problématique, etc etc.

Si on suis le raisonnement on pourrais aller plus loin hein, tout développer en C voir en assembleur ?! Ben non, allons plus loin dans la démarche; en binaire
Bon, j'arrête la mais franchement rien compris à cette théorie... Et en plus pour nous dire de redévelopper les application en javascript ?!

Bref, bien bonne journée à tous, je pars changer de métier
Avatar de tomlev tomlev - Rédacteur/Modérateur https://www.developpez.com
le 18/05/2018 à 10:23
Citation Envoyé par grunk Voir le message
alors que le dit logiciel est déjà codé en C...
Juste histoire de pinailler : git n'est pas écrit entièrement en C, il y a des parties en bash ou en perl il me semble.
Avatar de Matthieu76 Matthieu76 - Membre éclairé https://www.developpez.com
le 18/05/2018 à 10:27
Citation Envoyé par grunk Voir le message
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
Je suis tellement d'accord avec toi !
Avatar de clorr clorr - Membre du Club https://www.developpez.com
le 18/05/2018 à 10:44
Je pense pas que le gars ait passé git en JS à cause de la théorie de TBL. C'est le genre de chose qu'on fait parce qu'on est passionné d'un langage et qu'on veut l'appliquer sur une techno qui nous plait.

Dans une archi microservices, on s'en fou un peu de la puissance du langage, on scale au niveau de l'infra. Il vaut mieux payer un peu plus côté que d'être dépendant de profiles rares et chers, maintenant qu'on le peut avec les conteneurs et leurs orchestrateurs, autant en profiter.
+1, la performance pure d'un langage est moins importante que son éco-système, qui va du nombre de programmeurs capable de le lire et l'écrire aux outils de déploiement qui vont avec.

Sinon, le postulat de TBL est ce qu'on applique tous les jours quand on fait des fonctions, des classes et des librairies qu'on réutilise, on crée des implémentations bas niveau qu'on expose et qu'on réutilise sous une forme plus haut niveau. On crée une sorte de méta langage spécifique à notre champ d'application et on l'utilise ensuite pour implémenter le fonctionnel. On fait tout ça naturellement, car on a tous une limite personnelle à la complexité qu'on peut gérer et le but de tout ça et d'assurer la maintenabilité.

Maintenant c'est une bonne pratique qui s'applique a tous les langages, mais si un langage nous permet d'en faire plus pour un effort moindre, on ne devrait pas s'en priver... sauf si ça vient perturber notre écosystème et que les développeurs ne suivent pas.
Avatar de onilink_ onilink_ - Membre éprouvé https://www.developpez.com
le 18/05/2018 à 11:28
Juste pour infos, ça fait déjà un moment qu'avec Emscripten on peut transpiler tous les langages avec un backend llvm en javascript, et désormais encore mieux, en webassembly (bien plus léger).
J'ai déjà compilé un jeu en C++ vers javascript pour pouvoir le publier sur le web lors d'un ludumdare (les gens préférant les jeux qui se lancent via le navigateur).
Unity utilise Emscripten pour l'export web. Unreal fonctionne aussi exporté sur le web (et ça date, je me souviens que la démo de la citadelle est sorti il y a plusieurs années).

Aucun intérêt de faire une réécriture donc, il va plutôt s'agir de faire une API haut niveau par dessus notre code bas niveau.
Mais encore une fois Emscripten a tout prévus pour faire ça de manière pratique. Le gain de temps est considérable, et les performances sont très bonnes.
Avatar de Pyramidev Pyramidev - Membre expert https://www.developpez.com
le 18/05/2018 à 12:17
Ce que Tim Berners-Lee a écrit, c'est que, dans le développement Web, quand on la le choix entre plusieurs langages, il faut privilégier celui dont on peut le plus facilement extraire les données par une analyse du code :
Many Web technologies are designed to exploit the Rule of Least Power. HTML is intentionally designed not to be a full programming language, so that many different things can be done with an HTML document: software can present the document in various styles, extract tables of contents, index it, and so on. Similarly, CSS is a declarative styling language that is easily analyzed. The Semantic Web is an attempt, largely, to map large quantities of existing data onto a common language so that the data can be analyzed in ways never dreamed of by its creators. If, for example, some weather data is published as a Web resource using RDF, a user can retrieve it as a table, perhaps average it, plot it, or deduce things from it in combination with other information. At the other end of the scale is the weather information conveyed by an ingeniously written Java applet. While the applet might provide a very cool user interface or other sophisticated features, the results of the program will not usually be predictable in advance. A search engine finding the resource will have no idea of what the weather data is or even, in the absence of other information, that it is a weather-related resource The only way to find out what a Java applet means is generally to set it running, and see what it does. Thus, HTML, CSS and the Semantic Web are examples of Web technologies designed with "least power" in mind. Web resources that use these technologies are more likely to be reused in flexible ways than those expressed in more powerful languages.
En outre, Tim Berners-Lee conseille de privilégier les langages déclaratifs (dont les langages fonctionnels comme Haskell) aux langages impératifs :
A different sort of scalability can be found when comparing Turing-complete languages. Although all have equivalent expressive power, functional languages such as Haskell and XSLT facilitate the creation of programs that may be easier to analyze than their imperative equivalents. Particularly when such languages are further subset to eliminate complex features (to eliminate recursion, perhaps, or to focus on template forms in XSLT), the resulting variants may be quite powerful yet easy to analyze. When publishing on the Web, you should usually choose the least powerful or most easily analyzed language variant that's suitable for the purpose.
Étant donné que JavaScript est un langage impératif Turing-complet, croire que la règle de la moindre puissance a pour corolaire de tout coder en JavaScript, c'est n'avoir rien compris à la règle de la moindre puissance énoncée par Tim Berners-Lee. Il classe explicitement JavaScript dans les langages les plus « puissants » :
Computer languages range from the plainly descriptive (such as Dublin Core metadata, or the content of most databases, or HTML), through logical languages with limited propositional logic (such as access control lists, conneg content negotiation or regular expressions), to the nearly Turing-complete (PDF or some versions of SQL), through those that are in fact Turing-complete though one is led not to use them that way (XSLT, more powerful versions of SQL), through those that are functional and Turing-complete (Haskell), to those that are unashamedly imperative and Turing-complete (Java, Javascript/ECMAScript or C).
Cela dit, il soutient la standardisation de sous-ensembles de langages « puissants », par exemple JSON, un sous-ensemble déclaratif de JavaScript :
JavaScript Object Notation [JSON] is another example of a scalable language. Specifically, JSON provides for standalone use of a declarative subset of the literal declaration syntax from the JavaScript language. Standardization of language subsets can facilitate simple models for Web publishing, while providing for integration with more powerful language variants when necessary.
Contacter le responsable de la rubrique Accueil