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.
Version imprimable
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.
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.
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.Citation:
Envoyé par Zefling
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 !
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, ...
https://github.com/opal/opalCitation:
Envoyé par Daïmanu
https://semaphoreci.com/blog/ruby-webassembly