Discussion :

[melka one]

je vois que tu est nouveau sur le site et c'est la que ça tique dans ma tête, tu parle comme un pros mais le fait que tu soit nouveau met un point d’interrogation sur tes connaissances du coup je préféré resté neutre.

[air-dex]

L'avantage de jQuery à l'époque est qu'il absorbait les différences entre les navigateurs, qui ne respectaient pas toujours bien les normes. Ça et une solution simple pour gérer les requêtes HTTP. Maintenant les navigateurs sont bien plus à cheval sur les normes. Il n'y a plus de grands écarts comme avant. Et pour les requêtes HTTP il y a Axios qui se suffit à lui-même.

Quant à JavaScript, n'oublions pas que sa chance a été d'être là au bon endroit au bon moment. Il fut un moment où c'était le seul langage encore disponible pour du Web côté client, après la chasse aux plugins dans les navigateurs qui aura notamment eu raison d'ActionScript et de Java et avant l'arrivée de Web ASseMbly qui aura ouvert la porte du Web côté client à beaucoup de langages (C++, Rust...). Certains langages comme TypeScript sont de fausses alternatives car ayant besoin de JS à un moment donné.

JS sera increvable tant qu'un autre langage simple d'utilisation ne sera pas pris en compte dans les navigateurs.

• Certes WASM rend cela possible, mais il est bien trop compliqué pour la majorité des devs.
• Google a essayé avec Dart, ce fut un échec.
• Il est étrange que Microsoft n'ait jamais tenté sa chance avec TypeScript dans Edge.

Je pense que presque personne utilise de langage sans framework aujourd'hui. C'est possible, beaucoup plus léger, mais réinventer la roue ça demande tellement de temps.

L'abondance de ressources aide aussi : qualité des connexions et puissance des machines physiques faisant tourner les navigateurs sur lesquelles le site ou l'application tourne. Aussi légère soit-elle face à ses concurrentes, je ne suis pas si sûr qu'une application Vue.js tiendrait la route sur IE6 sous Windows XP, quand bien même IE6 serait parfaitement aux normes Web. Le tout sans haut débit DSL sinon c'est pas drôle.

Quant au reste je suis totalement d'accord. De nos jours, un langage de programmation ne peut être viable sans tout son écosystème d'outils et de frameworks majeurs. C'est pourquoi chaque langage arrive désormais avec un SDK au complet, un outil de gestion des projets et un gestionnaire de paquets. Cf. Rust qui ne se contente pas de fournir qu'un compilateur (rustc), mais aussi un outil de formattage de code (rustfmt), un linter (clippy), un générateur de documentation (rustdoc) et un outil de CLI gestionnaire de paquet et de projet (Cargo) avec son repo officiel (crates.io), ainsi qu'un site centalisant toutes les documentation de ses crates (docs.rs). Il lui fallait bien tout ça pour avoir sa chance et percer. Comme c'est un jeune langage, il ne reste plus qu'aux frameworks à s'y imposer étant donné la jeunesse du langage (Diesel, SeaORM, Sycamore, Leptos, Rocket.rs, Tauri...). Pour les vieux langages c'est l'inverse, avec par exemple Composer et packagist.org qui sont arrivés après Symfony et WordPress chez PHP.

Même les frameworks proposent très souvent leurs propres outils de CLI pour les rendre plus simples à utiliser. C'est dire !

[d_d_v]

De toutes façons, ce web dynamique a cassé toutes les bases simples et ergonomiques du web initial: des popups partout, des IHM qui ne fonctionnent parfois pas si vous n'avez pas le navigateur que le concepteur du site a utilisé (!), plus moyen de revenir à la page d'avant en utilisant le cache, plus de couleur bleue des liens que vous avez visités, ...

[Madmac]

Question bête, mais on pourrait pas envisager d'utiliser un autre langage de script pour le web (côté client), par exemple du Python ou autre ?

Il faudra certainement une variante optimisé en terme de performance, et capable de manipuler le DOM et de faire de l'événementiel, mais ça réglerait ces soucis lié au JS je crois.

C'est une question ouverte, je n'ai pas assez de recul pour y répondre.

https://github.com/opal/opal

https://semaphoreci.com/blog/ruby-webassembly