Discussion :

[Bill Fassinou]

En 2001, Roy Fielding, un cofondateur de la fondation Apache, avait prédit que JavaScript allait réussir à s'imposer sur le Web,
voici ses raisons

Sur le Web d’aujourd’hui, le triplet HTML, CSS et JavaScript dominent largement les autres combinaisons utilisées dans le développement des applications Web, une tendance qui va sans doute continuer à progresser au cours des années à venir. Malgré le fait que Java soit jugé plus robuste que JavaScript, le langage de Sun Microsystems n’a pas su s’imposer avec la fonctionnalité des applets pour le Web. Ce qui s’est passé, Roy Fielding, un des fondateurs de la fondation Apache, l’avait prédit, citant quelques-unes des raisons pour lesquelles JavaScript allait battre Java sur le Web.

Roy Thomas Fielding est un informaticien américain né en 1965 à Laguna Beach en Californie. Il est notamment connu pour ses travaux pour le développement des premiers serveurs Web, et principalement le serveur Web Apache, le fonctionnement du Web, la spécification HTTP et est l’un des fondateurs de la fondation Apache. Dans un paragraphe d’un mémoire publié en 2001 sur la façon dont l’architecture REST a influencé le développement de l’architecture du Web moderne, Fielding comparait Java et JavaScript et trouva ce dernier plus efficace sur le Web que Java.

Roy Thomas Fielding

Selon Fielding, les deux langages ont été introduits à un moment où le paradigme du code à la demande (code-on-demande) était en plein essor sur le Web. Pour rappel, en informatique distribuée, le code à la demande est une technologie qui envoie un code logiciel exécutable d'un ordinateur serveur à un ordinateur client à la demande du logiciel du client. À ce jour, les exemples les plus connus du paradigme du code à la demande sur le Web sont les applets Java, le langage ActionScript d'Adobe pour le lecteur Flash, et le langage JavaScript.

Pour lui, si les applets Java n’ont pas pu tenir la concurrence avec la montée du JavaScript, ce n'est certainement pas pour sa qualité technique en tant que langage, puisque sa syntaxe et son environnement d'exécution sont considérés comme médiocres par rapport à Java. Ce n'est pas non plus à cause du marketing : Sun (désormais racheté par Oracle) dépasse de loin Netscape à cet égard, et continue à le faire. Ce n'est pas non plus pour les caractéristiques intrinsèques des langages, puisque Java a eu plus de succès que JavaScript dans tous les autres domaines de programmation (applications autonomes, servlets, etc.).

En outre, Roy Fielding pense que les raisons de cette divergence se trouvent dans les caractéristiques que présente le langage Java en tant que type de média de représentation au sein de REST. L’analyse de Fielding admet que le langage JavaScript est mieux adapté au modèle de déploiement de la technologie Web. Selon lui, JavaScript est beaucoup plus facile à apprendre, sans grand effort pour un débutant.

De même, il estime que JavaScript a également un impact moindre sur la visibilité des interactions. Des organisations indépendantes peuvent lire, vérifier et copier le code source écrit en JavaScript de la même façon qu'elles pourraient copier le code HTML. Java, en revanche, est téléchargé sous forme d'archives binaires, ce qui signifie que l'utilisateur doit se fier aux restrictions de sécurité dans l'environnement d'exécution Java. En plus, ce dernier posséderait de nombreuses autres fonctionnalités dont l'autorisation dans un environnement sécurisé est jugée discutable.

Il s’agit notamment de la possibilité de renvoyer les requêtes RMI (invocation de méthode distante) au serveur d'origine. Il a aussi déclaré que la distinction la plus importante entre les deux est peut-être le fait que JavaScript entraîne une latence moindre perçue par l'utilisateur. Ce dernier est généralement téléchargé dans le cadre de la représentation primaire, alors que les applets Java nécessitent une requête séparée. Le code Java, une fois converti au format de code d'octet, est beaucoup plus grand que le JavaScript typique.

Enfin, l’autre chose en défaveur de Java est qu’il exige que l'ensemble des fichiers de classe soit téléchargé et installé avant que l'application puisse s’exécuter. Par contre, le JavaScript peut être exécuté pendant le téléchargement du reste de la page HTML. Ces différents arguments de Fielding semblent montrer que dès le départ, Java n’avait aucune chance de s’imposer sur le Web au détriment de JavaScript. Aujourd’hui, JavaScript est allé bien au-delà de ce pour quoi il a été conçu au début. Le langage a un écosystème plus vaste que jamais et continue à se développer.

Le rapport sur l’état de JavaScript en 2019 montrait comment il a continué à prendre de l’ampleur au cours de ces dernières années. Le langage semble avoir conquis le Web pour toujours. Il est d’ailleurs actuellement le langage le plus utilisé par les contributeurs sur GitHub. Par ailleurs, d’autres facteurs ont aussi contribué à sa domination sur le Web. Les entreprises comme Microsoft ont aussi poussé quelques pions.

Une fois que l'on ne pouvait plus compter sur la présence de Java sur tous les principaux navigateurs, il ne restait plus que le JavaScript et il ne cessait de s'améliorer. Il a développé plus tard TypeScript, un surensemble de JavaScript avec des propriétés beaucoup plus strictes. Cela a pour but d'améliorer et de sécuriser l'écriture de code source JavaScript. Il a contribué à faciliter la création d’application Web plus moderne. D’autres projets comme Node.js ont apporté JavaScript du côté du serveur avec un temps d’exécution ultrarapide.

Source : Roy Thomas Fielding

Et vous ?

Quel est votre avis sur le sujet ?
Êtes-vous du même avis que Roy Thomas ?
Pour quelles autres raisons JavaScript dépasse Java sur le Web selon vous ?

Voir aussi

État de JavaScript en 2019 : les développeurs aiment un peu plus React, Angular est en déclin, un groupe de développeurs pense que JS est « trop complexe »

Python devance Java et devient le deuxième langage de programmation le plus utilisé par les contributeurs sur GitHub, après JavaScript

The State Of JavaScript 2018 : l'enquête révèle que JavaScript est en pleine évolution. Voici une vue macro des technologies JS utilisées

La version 3 de Svelte, le framework de composants graphiques, est disponible et repense la réactivité des frameworks autrement

La version stable de TypeScript 3.7.0 est disponible et apporte diverses fonctionnalités et quelques améliorations au langage

[grunk]

D'un autre coté il n'existe toujours aucune alternative à javascript si on veux interagir côté client. Difficile de ne pas s'imposer dans ces conditions

Quand on y pense c'est d'ailleurs très surprenant qu'aucun acteur majeur des navigateurs n'est voulu lancer son alternative.

[youtpout978]

D'un autre coté il n'existe toujours aucune alternative à javascript si on veux interagir côté client. Difficile de ne pas s'imposer dans ces conditions

Quand on y pense c'est d'ailleurs très surprenant qu'aucun acteur majeur des navigateurs n'est voulu lancer son alternative.

Si maintenant il y a WebAssembly, il y a blazor pour le C# mais la partie full client n'est pas encore terminé, ça devrait sortir cette année néanmoins, pour les autres langages je ne sais pas ou ça en est.

Et si Google a tenté Dart mais ça été un flop, en même temps c'est compliqué quand c'est pas une norme adopté par tous les navigateurs, surtout qu'à l'époque chrome n'avait pas les mêmes part de marché qu'aujourd'hui.

[Sodium]

JavaScript s'est imposé pour une seule et unique raison : c'est le seul langage supporté en natif par tous les navigateurs. Pas besoin d'aller chercher plus loin.

[yahiko]

JavaScript s'est imposé pour une seule et unique raison : c'est le seul langage supporté en natif par tous les navigateurs. Pas besoin d'aller chercher plus loin.

Pour compléter, et aller plus loin, on peut se demander pourquoi c'est le cas.

Il y a pourtant eu à une époque la tentative de Microsoft d'imposer le VBScript. Il a échoué malgré le fait qu'Internet Explorer détenait une grande partie des parts de marché des navigateurs (92% en 2004 selon Wikipédia).

JavaScript l'a emporté parce que ce fut le langage du premier navigateur grand public : Netscape. Et que de facto, tous les navigateurs suivant ont été contraint de supporter (plus ou moins) JavaScript.

C'est un cas d'école où le premier sur le marché rafle la mise.

[Sodium]

Je pense que c'est plus compliqué que ça. À l'époque on ne faisait pas grand-chose en JavaScript (voir en web tout court) car ça n'a jamais été pensé pour ça, ça servait à faire clignoter un texte, changer une couleur, de toute manière il fallait limite écrire du code séparé pour chaque navigateur. D'où l'apparition des applets Java, extensions vba, Flash, etc. Sauf que les utilisateurs ont fini par en avoir que chaque page web affiche 15 extensions inutiles, lourdes et souvent portes d'entrées aux attaques. Donc on les a peu à peu supprimées. Et il restait quoi ? Bah JavaScript, avec lequel on a pu faire de plus en plus de trucs, mais qui restent du bricolage car le langage n'est pas adapté à de la programmation complexe.

[air-dex]

D'un autre coté il n'existe toujours aucune alternative à javascript si on veux interagir côté client. Difficile de ne pas s'imposer dans ces conditions

Quand on y pense c'est d'ailleurs très surprenant qu'aucun acteur majeur des navigateurs n'est voulu lancer son alternative.

C'est ça. JavaScript s'est imposé grâce à la chasse aux sorcière des plugins sur navigateurs, menée soit-dit en passant par les créateurs du JavaScript (Mozilla) et par quelqu'un de rancunier envers Adobe (Steve Jobs parce qu'Adobe avait refusé de faire une version Mac de Photoshop à une époque où Apple était en grande difficulté). Que reste-t-il pour faire du Web côté client une fois que t'as dégagé Java, Flash et Silverlight ? On retourne tous faire du VB Script sur ce bon vieux Internet Explorer ?

JS a eu la chance d'être au bon endroit au bon moment du coup tout le monde l'utilise quand même.

Si maintenant il y a WebAssembly, il y a blazor pour le C# mais la partie full client n'est pas encore terminé, ça devrait sortir cette année néanmoins, pour les autres langages je ne sais pas ou ça en est.

Et si Google a tenté Dart mais ça été un flop, en même temps c'est compliqué quand c'est pas une norme adopté par tous les navigateurs, surtout qu'à l'époque chrome n'avait pas les mêmes part de marché qu'aujourd'hui.

WASM est difficile à lire et à écrire pour un développeur humain. Le plus simple avec WASM est d'écrire son code dans un autre langage (C++, Rust...) puis de le compiler/transpiler en WASM, pas d'écrire à la main un fichier .wat qui sera une horreur à maintenir. Mais même là ton WASM seul ne suffira pas. Il lui faudra probablement des bindings JS pour le faire interagir avec le reste de la page. Donc du JavaScript, encore et toujours.

[psychadelic]

Pour moi, il oublie de parler de jQuery.

et même des librairies JS, avec en tête YUI (Yahoo! User Interface Library)
Javascript n'était pas très utile dans les début du net, tout le monde découvraient le "truc", et le plus important était d'avoir des pages HTML pour faire des site vitrines.

Ce n'est qu'ensuite qu'on à voulu rendre les pages un peu plus attractives et la Google à bien joué le coup avec jQuery, car le principal souci de Google c'était que le web puisse être lisible en html et non en html sauce Microsoft, ou sauce Adobe/Flash, en encore en sauce applets Java.

On à besoin de standards Web indépendants pour le bénéfice de tous (et non pour le bénéfice de multinationales)

Aujourd'hui JS est un langage pleinement standardisé sur toutes les plateformes (jQuery devient inutile), On peut lui reprocher des tas de trucs, mais c'est le seul(?) dans ce cas la, et s'il y a un vrai reproche à faire sur les autres langages, il faut s'adresser au multinationnales qui n'ont jamais été fichus de faire de leurs langages interprétés de vrais standards universels.

[youtpout978]

WASM est difficile à lire et à écrire pour un développeur humain. Le plus simple avec WASM est d'écrire son code dans un autre langage (C++, Rust...) puis de le compiler/transpiler en WASM, pas d'écrire à la main un fichier .wat qui sera une horreur à maintenir. Mais même là ton WASM seul ne suffira pas. Il lui faudra probablement des bindings JS pour le faire interagir avec le reste de la page. Donc du JavaScript, encore et toujours.

Bein c'est le framework qui s'occupe de ça, toi tu code dans ton langage préféré, c'est tout, j'ai jamais dis qu'il faut créer le Wasm à la main,je parle justement du c# dans mon cas ...

[grunk]

Quand on y pense on est quand même passer par loin de s'affranchir de JS. Quand les langages serveur comme PHP sont arrivés , JS était complètement hasbeen et c'était limite la honte de l'utilisé , c'était même courant d'avoir des navigateur avec le support JS désactivé.
Puis est arrivé le web 2.0 et les XMLHTTPRequest et là ... c'est le drame Retour en fanfare de JS avec la progression qu'on lui connait maintenant.

[air-dex]

Bein c'est le framework qui s'occupe de ça, toi tu code dans ton langage préféré, c'est tout, j'ai jamais dis qu'il faut créer le Wasm à la main,je parle justement du c# dans mon cas ...

Justement non. Tu ne coderas jamais 100% du truc dans ton langage compilable en WASM préféré.

Le gros du projet se fera comme ça. Je n'ai jamais dit le contraire. Emscripten, Blazor, Rust-WASM... compileront ton code en WASM et te créeront les bindings JavaScript dans le style de ton choix (vieux JS pré-2015, JS moderne tirant puissance d'ES6 et au delà, avec les spécificités de Node.js...), ainsi que les bindings TypeScript si tu en as besoin. Fort bien. Mais une fois tout ça inclus dans ta page Web, il faudra bien que tu tapes quelques lignes du code allant taper le WASM. Qu'écriras-tu pour cela ? Un fichier .wat ou bien du code JS qui passera par les bindings générés pour atteindre ton WASM ?

Quand on y pense on est quand même passer par loin de s'affranchir de JS. Quand les langages serveur comme PHP sont arrivés , JS était complètement hasbeen et c'était limite la honte de l'utilisé , c'était même courant d'avoir des navigateur avec le support JS désactivé.
Puis est arrivé le web 2.0 et les XMLHTTPRequest et là ... c'est le drame Retour en fanfare de JS avec la progression qu'on lui connait maintenant.

C'est par étapes. D'abord ça, puis la chasse aux sorcières contre les plugins où c'est devenu du "JS ou crève", puis la "révolution Node.js" qui a sorti JavaScript des navigateurs Web et des WebViews.

[youtpout978]

Justement non. Tu ne coderas jamais 100% du truc dans ton langage compilable en WASM préféré.

Le gros du projet se fera comme ça. Je n'ai jamais dit le contraire. Emscripten, Blazor, Rust-WASM... compileront ton code en WASM et te créeront les bindings JavaScript dans le style de ton choix (vieux JS pré-2015, JS moderne tirant puissance d'ES6 et au delà, avec les spécificités de Node.js...), ainsi que les bindings TypeScript si tu en as besoin. Fort bien. Mais une fois tout ça inclus dans ta page Web, il faudra bien que tu tapes quelques lignes du code allant taper le WASM. Qu'écriras-tu pour cela ? Un fichier .wat ou bien du code JS qui passera par les bindings générés pour atteindre ton WASM ?

Dans les exemples blazor j'ai jamais vu de procédure où tu t'amuses à ajouter des bindings js ou alors on s'est mal compris et tu me parles d'applis mélangeant wasm et js ?