Discussion :

[Michael Guilloux]

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

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

[grunk]

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

[gstratege]

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.

[Invité]

• 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

[mister3957]

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é.

[GordonFreeman]

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

[tomlev]

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.

[Matthieu76]

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 !

[clorr]

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.

[onilink_]

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.

[Pyramidev]

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.

[blbird]

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

Ce n'est pas le langage JS qui est mauvais, en tout cas ce n'est plus le cas avec du JS moderne, c'est bien la manière dont on l'utilise qui fait défaut.

[koyosama]

Ce n'est pas le langage JS qui est mauvais, en tout cas ce n'est plus le cas avec du JS moderne, c'est bien la manière dont on l'utilise qui fait défaut.

Ben moi des callbacks j'en ai juste que là. Je trouve plus simple de faire du multi-threading ou du parralelism dans un langage compilé que de simulaler du callback car t'as besoin de certaines données.
Et j'en ai fait du parallélisme et du multi-threading.

J'ai même vu des projets ignobles ou le gars a tenté de faire du settimeout pour simuler le synchrone. C'est gérable mais je suis en train me faire chier avec une imbrication de callback et de promise juste pour faire du synchrone pour des tâches spécial qui le demande. Alors que dans une langage comme C# ça prendre deux lignes de codes pour dire que cette fonction là doit tourner sur 4 processeurs différents.

[blbird]

Ben moi des callbacks j'en ai juste que là. Je trouve plus simple de faire du multi-threading ou du parralelism dans un langage compilé que de simulaler du callback car t'as besoin de certaines données.
Et j'en ai fait du parallélisme et du multi-threading.

Si tu as besoin de faire du mutli-thread ou multi-processeur, je ne vois même pas pourquoi on parle de Javascript (en tout cas pas encore, mais ca va venir assez vite).

J'ai même vu des projets ignobles ou le gars a tenté de faire du settimeout pour simuler le synchrone. C'est gérable mais je suis en train me faire chier avec une imbrication de callback et de promise juste pour faire du synchrone pour des tâches spécial qui le demande. Alors que dans une langage comme C# ça prendre deux lignes de codes pour dire que cette fonction là doit tourner sur 4 processeurs différents.

Quel est le rapport entre un besoin de synchrone sur des callbacks, et le multiprocesseur?

[Asdra]

Bonjour,

J'aimerais que tous les pseudos expert qui viennent nous bassiner avec Javascript pas performant, pas beau, pas bien... m'expliquent pourquoi énormément d'entreprises, d'acteurs et de développeurs, comme moi, l'apprécient, pourquoi il est en top sur github etc... On est surement des gros débiles, et eux sont très intelligents, je n'en doute pas.

https://www.netguru.co/blog/top-comp...ejs-production
http://githut.info/

Comme ces gens ont la science infuse, si ils peuvent me faire un topo, avec des faits et des sources, plutôt que "Language mal conçu, lent...".

Je peux aussi le faire hein, "ah oui, tu fais du <votre_language_prefere_ici>, dommage, il est mal conçu, lent, et pourri..".

Voila, merci aux experts pédants type bfmtv d'argumenter, on leur en voudra pas et on se concentrera très fort pour essayer de comprendre.

Corridalement,

Olé!

[blbird]

J'aimerais que tous les pseudos expert qui viennent nous bassiner avec Javascript pas performant, pas beau, pas bien... m'expliquent pourquoi énormément d'entreprises, d'acteurs et de développeurs, comme moi, l'apprécient, pourquoi il est en top sur github etc... On est surement des gros débiles, et eux sont très intelligents, je n'en doute pas.

Ce qui est amusant surtout, c'est qu'après, on constate que ces même experts développent avec Visual Code, et utilisent aussi Discord (>100 millions d'utilisateurs actuellement). Tout ca en JS, multiplateforme, rapide, efficace, bien foutu, ergonomique. Incroyable non?

[Asdra]

Ben moi des callbacks j'en ai juste que là. Je trouve plus simple de faire du multi-threading ou du parralelism dans un langage compilé que de simulaler du callback car t'as besoin de certaines données.
Et j'en ai fait du parallélisme et du multi-threading.

J'ai même vu des projets ignobles ou le gars a tenté de faire du settimeout pour simuler le synchrone. C'est gérable mais je suis en train me faire chier avec une imbrication de callback et de promise juste pour faire du synchrone pour des tâches spécial qui le demande. Alors que dans une langage comme C# ça prendre deux lignes de codes pour dire que cette fonction là doit tourner sur 4 processeurs différents.

"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é?

[4sStylZ]

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

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

[Marco46]

J'aimerais que tous les pseudos expert qui viennent nous bassiner avec Javascript pas performant, pas beau, pas bien... m'expliquent pourquoi énormément d'entreprises, d'acteurs et de développeurs, comme moi, l'apprécient, pourquoi il est en top sur github etc... On est surement des gros débiles, et eux sont très intelligents, je n'en doute pas.

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 !

[grunk]

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.