Discussion :

[Michael Guilloux]

Quels les sont coûts liés à l'utilisation de frameworks JavaScript pour le développement Web ?
Une analyse des sites utilisant React, Vue.js ou Angular

Quels sont les coûts liés à l'utilisation de frameworks JavaScript pour le développement Web ? Cette question a certainement plusieurs fois été abordée, et dans la plupart des cas, les avis les plus partagés semblent pointer du doigt les frameworks JavaScript comme étant responsables de la lenteur des sites Web. Il est en effet fréquent d'entendre que les performances du Web auraient baissé ces dernières années à cause de l’avènement des frameworks Web, comme React et Vue.js, et les applications Web monopage ou SPA (single-page application) qui privilégient les développeurs à l’expérience utilisateur.

S'invitant dans le débat, Tim Kadlec, un développeur qui aide les organisations à améliorer les performances de leurs sites, estime pour sa part qu'il n'y a « pas de moyen plus rapide de ralentir un site que d'utiliser un tas de JavaScript », et c'est justement ce que font les frameworks JavaScript : utilisez beaucoup plus de JavaScript. Mais « le truc avec JavaScript », poursuit-il, « c'est que vous finissez par payer une taxe sur les performances pas moins de quatre fois », dit-il. Les quatre taxes auxquelles il fait allusion sont :

• le coût de téléchargement du fichier sur le réseau ;
• le coût de l'analyse et de la compilation du fichier non compressé une fois téléchargé ;
• le coût d'exécution du JavaScript ; et
• le coût de la mémoire.

« La combinaison [de ces quatre taxes] est très coûteuse. Et nous utilisons de plus en plus de JavaScript sur le Net. Nous rendons les fonctionnalités de base de nos sites de plus en plus dépendantes de JavaScript à mesure que les organisations évoluent vers des sites propulsés par des frameworks tels que React, Vue.js et al », dit-il. Ce ne sont toutefois pas des propos non fondés puisqu'il le montre en se basant sur une analyse effectuée grâce aux données du site HTTP Archive.

HTTP Archive suit plus de 4 millions d'URL de bureau et plus de 5 millions d'URL mobiles. Parmi les nombreux points de données collectés par HTTP Archive, on peut citer la liste des technologies détectées pour chaque site suivi. Cela signifie que vous pouvez sélectionner des milliers de sites utilisant divers frameworks et voir la taille de code JavaScript qu'ils transmettent et ce que cela coûte au processeur ; ce à quoi Tim Kadlec s'est intéressé.

Il a décidé de comparer les données agrégées de HTTP Archive pour l'ensemble des sites Web enregistrés et les comparer aux données spécifiques aux sites utilisant React, Vue.js et Angular. Il a aussi ajouté jQuery, qui reste une bibliothèque très populaire et qui représente également une approche de développement JavaScript différente de l'approche SPA fournie par React, Vue.js et Angular.

Nombre d'URL suivies par HTTP Archive pour lesquelles les frameworks ciblés ont été détectés

Pour Tim Kadlec, dans un monde idéal, un framework ne devrait pas se concentrer sur l'expérience développeur uniquement, mais fournir une bonne expérience aux personnes utilisant leurs sites. Ils ne devraient donc pas négliger la performance qui est un élément essentiel, ce pour quoi M. Kadlec a voulu regarder le temps de démarrage/chargement des sites Web, mais aussi le temps de traitement du code JavaScript de ces sites.

Taille du code JavaScript servi sur les appareils mobiles et desktop

Pour analyser le temps de démarrage des sites Web, Tim Kadlec a trouvé logique de regarder la quantité de JavaScript transmise sur le réseau.

Quantité de JavaScript servi sur les appareils mobiles




Quantité de JavaScript servi sur les appareils desktop

Si l'un de ces frameworks est utilisé, il y a sans surprise plus de JavaScript, même dans les situations idéales. Vous ne pouvez pas en effet utiliser un framework JavaScript et vous attendre à charger moins de JavaScript dès le départ. Ce qui est remarquable cependant, c'est la différence entre les frameworks. Les sites avec jQuery sont les meilleurs du lot sur les appareils de bureau et sur mobile. Viennent ensuite les sites utilisant Vue.js et React. Les sites avec Angular sont les pires du groupe.

Temps de travail du thread principal

Il ressort clairement des données de HTTP Archive que les sites dotés de ces frameworks ont tendance à payer une lourde pénalité en termes d'octets JavaScript transmis sur le réseau. Mais ce n'est qu'une partie de l'équation. Une fois que le code JavaScript est chargé, il doit se mettre au travail, et tout travail qui se produit sur le thread principal du navigateur est particulièrement crucial. Le thread principal est en effet responsable de la gestion des entrées utilisateur et de la mise en page, entre autres. Si nous le surchargeons avec beaucoup de travail, le thread principal n'a aucune chance de faire ces choses dans de bons délais, ce qui entraîne donc des retards.

Comme HTTP Archive enregistre le temps de travail du thread principal de V8, Tim Kadlec a pu interroger le site pour voir pendant combien de temps ce thread principal travaille sur le code JavaScript chargé.

Temps de traitement CPU (en millisecondes) des scripts pour les appareils mobiles

Temps de traitement CPU (en millisecondes) des scripts pour les appareils desktop

Le constat est que pour les sites sur lesquels jQuery a été détecté, le temps de traitement du code JavaScript est beaucoup plus court que pour les trois autres frameworks analysés. Les frameworks Angular et React sont encore à la queue. La seule différence est que même si les sites Angular ont chargé plus de JavaScript que les sites React, en termes de temps de traitement, ils utilisent beaucoup moins le processeur.

Tim Kadlec a refait son analyse en ne considérant que des URL pour lesquels un seul framework (React, jQuery, Angular ou Vue.js) était détecté. Sans surprise, quand un seul framework est utilisé, les performances s'améliorent beaucoup plus souvent. Il estime que c'est bien logique : un site bien construit avec un seul framework devrait être plus performant qu'un site bien construit avec deux frameworks ou plus.

Temps de traitement CPU des scripts (en millisecondes) pour les appareils mobiles où un seul des frameworks est détecté

Notre analyste insiste toutefois sur un fait : le fait que les sites utilisant React ou Angular enregistrent un temps de traitement CPU plus élevé que les autres ne veut pas nécessairement dire qu'ils sont plus gourmands en ressources CPU que Vue.js. Cela en dit très peu sur la performance des frameworks de base, mais beaucoup plus sur l'approche de développement encouragée par ces frameworks (intentionnellement ou non).

L'écart mobile vs bureau

Tim Kadlec voulait aussi savoir s'il y avait un grand écart entre l'expérience mobile et l'expérience de bureau. En analysant les données du point de vue des octets JavaScript transmis sur le réseau au démarrage, il n'a constaté aucune différence significative. Mais en ce qui concerne le temps de traitement, l'écart est important au détriment des appareils mobiles. « Bien qu'une certaine différence soit attendue entre mobile et desktop, le fait de constater un écart important nous indique que ces frameworks ne font pas assez pour prioriser les appareils moins puissants et aider à combler cet écart », dit-il.

Ce qu'il est important de retenir, c'est que jQuery se comporte aussi bien que l'ensemble des sites. Mais lorsqu'on passe aux frameworks JavaScript, en particulier Angular, Vue.js et React, il y a un lourd tribut à payer en termes de performance.

Source : Tim Kadlec

Et vous ?

Quel est votre avis sur le sujet ?
Les frameworks JavaScript, un mal nécessaire pour le développement Web ?
Ou le problème serait-il plutôt JavaScript lui-même ou les développeurs ?
Si le problème vient de JavaScript lui-même, par quel langage faut-il le remplacer, quand cela est possible, pour avoir des sites Web plus rapides ?

Voir aussi :

Les frameworks Web détruisent-ils vraiment les performances du Web ou l'expérience utilisateur ? Ils placeraient la satisfaction des développeurs au-dessus des utilisateurs
Le langage JavaScript est-il responsable de la lenteur des sites Web de nos jours ? Oui selon un expert
Google veut financer le développement de fonctionnalités liées aux performances dans les frameworks JavaScript à hauteur de 200 000 USD

[walfrat]

Le jour ou je travail sur un logiciel ou la seul cause de lenteur est la pile de framework et non pas la façon dont ils ont été utilisé ou simplement la mauvaise gestion du projet amenant donc à un résultat de piètre qualité sera le plus beau jour de tout ma vie. En attendant le choix entre le framework ou le vanilla relève de la question existentielle pour moi.

[grunk]

C'est délicat de comparer des applicatifs utilisant jquery à des applicatifs utilisant angular/react (vue ca peut encore passer). Ce n'est en général pas la même chose.

Concernant angular les résultats sont sans doute un peu biaisés puisque les dernières versions ont apporté beaucoup d'améliorations sur la taille des applicatifs. Pas certains qu'un majorité des url testées soient en version 9.

Et oui effectivement quand on utilise un framework on rajoute de la complexité et donc du poids à une application , mais c'est vrai dans tous les langages.

[xhe11662]

à cause de l’avènement des frameworks Web, comme React et Vue.js

Dommage, react et vue ne sont pas de framework mais des lib ...
Au même titre que jquery d’ailleurs : ce sont juste des boites a outils qui ne cadre en rien la structurations du projet.

[blasted]

Dommage, react et vue ne sont pas de framework mais des lib ...

React et Vue sont bien des frameworks.
Ils ont une approche particulière (ie DOM dynamique, template, etc.) et propose chacun une architecture spécifique structurante.
Il est impossible d'utiliser ces frameworks correctement sans un EDI (ie Visual Studio Code + npm) correctement configuré (tout du moins sur un vrai projet).
Je vous laisse vous faire votre propre opinion il suffit d'aller sur les sites officiels de leurs éditeurs respectifs.

[sboudes]

Je trouve le contenu du billet de Tim Kadlec bien trop réducteur. Il est donné ici l'impression que seul le premier chargement de page compte sur l'expérience client. Même si cela compte, c'est clairement pas suffisant.

Je suis assez vieux dans le métier pour avoir vécu la bascule de beaucoup de sites d'un mode server side vers un mode client side. Certes le premier chargement est long car lié à la récupération de ressources statiques et l'exécution des JS. Mais le reste de la navigation est bien plus fluide. C'était un objectif majeur de cette bascule :
* éviter l'effet page blanche lorsqu'une page devait récupérer dans le SI des données qui mettaient du temps à venir.
* Paralléliser le chargement des différents blocs HTML pour éviter que la page n'attendent que toutes les données du SI soient récupérer avant d'afficher quelque chose, ...

Au final, pas sur que les SPA consomment plus que des applis server side. entre chaque page, seules les éléments qui ont changés sont récupérer alors que sur du server side, on récupère le contenu entier.

Est ce qu'il ne faudrait pas plutot chercher le coupable sur l'ergonomie des sites. SPA a justement fait apparaitre de nouvelles façons de naviguer plus rapidement et d'afficher du contenu au fil de l'eau (voir à quoi sert le page speed index). Cette facilité a entrainé, je crois, une augmentation terrible du nombre d'infos qu'on cherche à afficher au sein d'une page dont notamment plein de jolies images bien lourdes qui ralentissent automatiquement le chargement

[MicroAlexx]

@blasted

React
A JavaScript library for building user interfaces

Source: https://reactjs.org/

[erwan21a]

Il est improbable de comparer des sites utilisant React/Vue/Angular avec ceux utilisant JQuery sans prendre en compte leurs contextes ?
C'est comme comparer un camion et une moto, aucun n'est intrinsèquement mieux que l'autre, ce n'est juste pas du tout le même usage.

On peut aujourd'hui supposer qu'un site utilisant uniquement JQuery/Vanilla a un cœur de métier privilégiant le back-office. Donc forcément l'investissement n'est pas placé au même endroit que pour une site nécessitant un socle front solide en terme d'UX/UI.

De plus, le ressentie de vélocité pour l'utilisateur final n'est peut-être pas du tout corrélé avec la technologie Javascript utilisé.
Un site React/Vue/Angular peut être lourd au premier chargement et consommateur de CPU par la suite mais proposer une UX bien orchestrée et s'appuyer sur un back-office simplement efficace.
A contrario un site JQuery/Vanilla peut avoir chargement de ressources front léger tout en semblant lourd en raison d'une UX succincte et de requêtes longues en raison d'un back-office trop complexe.

Bref, sans contexte, les statistiques citées sont tout simplement aberrantes.

[Lcf.vs]

Pour ceux qui voudraient essayer des alternatives, j'ai publié, il y a peu, la version 4 d'anticore et retravaillé son readme afin de le rendre plus pédagogique, plus step-by-step.

Orienté SSR, vous serez vite étonnés de la simplicité d'utilisation, la rapidité/fluidité et la légèreté du système.

Démo live

Repository/documentation

En cas de questions, n'hésitez pas.

[xhe11662]

React et Vue sont bien des frameworks.

Bon, je viens de voir que le site de Vue.js ce declare etre un "progressiv framework" ... donc ca va etre difficile de défendre mon point de vue ^^'

Selon moi JQuery à permis d'accélérer dans manquements au standard et de mettre a plat les disparités entre browser :
- la standardisation des selector standardisé en querySelector,
- la notion de promesse avec leurs .done()/.fail() standardisé en .then()/.catch() de Promise
- le $.ajax standardisé en fetch()
et j'en oublie.

Et je vois chez Vue une démarche similaire qui est:
- Unifier la création d'un composant (car l'API CustomElement n'est hélas pas encore 100% supportée)
- Rendre ce composant réactif (c'est a dire, en gros, garder le JS(model) et le HTML(vue) synchrone)
Et c'est tout... pas de validation de formulaire, pas de fetch, pas de routage, pas de TS forcé, pas de syntaxe JSX/TSX a apprendre.

J'ai déjà fait dans plusieurs sites pro sans buildflow en Vue (pas de TS / NPM / Sass / Node / Cancer.js ...)
Et ca a tres bien marché et ca marchera dans 15 ans (on ne peu pas en dire autant des projets angular impossible a recompiler du premier coup 2 ans plus tard).

Bref tout ca pour dire que les 2 jouent dans la catégorie "boites a outils" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
<script src="https://unpkg.com/vue@2"></script>
Vue:<button id=a @click=i++>{{i}}</button>
<script>new Vue({el:'#a',data:{i:0}})</script>
 
<script src="https://unpkg.com/jquery"></script>
Jquery:<button id=b>0</button>
<script>$('#b').click(ev => $(ev.target).text(++j));j=0</script>

[Hacksterix]

Article basé uniquement sur une comparaison de perf.
On ne parle ni du coût de l'hebergement ni de la consommation de data.
Angular comme react et vue permettent de créer des pwa et donc pour un même contexte applicatif, un fonctionnement sur de multiples device.
Ngrx Data permet de stocker les datas nécessaires au fonctionnement dans des stores et donc d'éviter de solliciter en permanence la DB et donc de la bp... Ne circule que de l'octet de contenu.
Rxjs permet une meilleure intégration UX grace a une orchestration des requêtes asynchrones idem ngrx pour la manipulation des données en mode optimistic.
Le travail sur les composants harmonise l'ux avec un temps.d'integration inférieur en terme de masse salariale.
L'utilisation de nodejs express ou nestjs en backend permet de séparer des tâches coûteuses en microservice en améliorant en même temps la performance d'un thread qui n'est dès lors plus occuper a faire autre chose que sa tâche...
Alors oui, ça mange un peu de ram de CPU au chargement mais ce n'est rien comparé à tout ce que cela apporte. D'autre part, je tiens à ajouter qu'à chaque projets il convient de choisir la bonne techno. Angular pour blog n'est pas forcement le plus adapté en revanche pour du frontal applicatif...

[marc.collin]

Au final, pas sur que les SPA consomment plus que des applis server side. entre chaque page, seules les éléments qui ont changés sont récupérer alors que sur du server side, on récupère le contenu entier.

tu peux très bien avec par exemple thymeleaf découpé tes pages en fragment... et faire un appel serveur pour en chercher un...

[admadama]

Faudrait aussi qu'il fasse un benchmark des système de templating server side.

La compilation des templates twig par exemple, pour un peu qu'on utilise ses features (include, macros, blocks, extensions) couplé à un ORM (coucou doctrine) est aussi assez violent, cette fois pour le système de fichier et le CPU du serveur.

L'argument développé plus haut est vrai, l'approche stateless a elle aussi un coût: booter un kernel de framework backend avec sa flopée de composant à chaque requête n'est pas gratuit.

Je veux bien me passer de React mais il va falloir me donner une alternative qui me permette de proposer aux utilisateurs une UX décente avec un code aussi clean. Vanilla JS c'est bien joli mais ça peut vite devenir une galère à maintenir.

[Invité]

C'est comme d'habitude : le bon outil pour le bon problème.

React, Angular & co. ont été crées pour des applications qui ont des tonnes de parties mouvantes, comme Facebook ou Gmail. Dans le cadre d'une appli ou tu as par page de nombreux appels à des jeux de données dynamiques ça a beaucoup de sens. Si ce n'est pas le cas et/ou que ces données sont statiques alors le bénéfice apporté par ces outils est nettement moins évident.

Par exemple si vous ouvrez une appli type réseau social, regardez les appels réseau vous allez vite comprendre ce que je veux dire. A l'inverse, un site comme dvp.com hors forum est très statique et les vues peuvent être générées et mises en cache facilement côté serveur, du coup un simple Varnish offrira une expérience utilisateur bien meilleure que si le tout était sous React.

Un autre problème de ces frameworks/libs JS c'est que la navigation par onglet contrecarre une grande partie de leur utilité puisque qu'il faut se taper tout le chargement initial de la page à chaque fois, même si les fichiers sont dans le cache du navigateur.

[defacta]

Alala toutes ces technos qui font perdre du temps, de l’argent et en plus sont lourdes à charger !
Mais la mode est de faire du Javascript qui ressemble à du C++, tout comme le PHP, on doit pouvoir le confondre avec du C++ !
La simplicité et la vitesse d’exécution ne sont que secondaires, ce qui compte c’est l’esthétique avec pour modèle la syntaxe du C++ ...
C’est pas demain la veille que je changerais jQuery pour autre chose, d’autant que les autres technos appartiennent aux GAFA pour qui ont est juste des gueux ! Le choix d’une techno est aussi un choix politique.

[Benbout]

Ma boite veut essayer svelte sur un de leurs projets, et en attendant que ca prenne forme, j'en fais depuis le debut du confinement sur un projet personnel ou je dois livrer sur un chromium embarqué pour un moteur de jeu. Je ne vais pas dresser un portrait detaillé de svelte, les curieux qui ne connaissent pas iront se renseigner. Je peux juste donner mon ressenti sur ce compilateur, et c'est plutot positif pour le moment. Je n'utilise ni jquery ni preprocesseur css. Ma bilbliotheque de composants s'etoffe de jour en jour et je la trouve plutot saine. J'ai créé un configurateur de themes uniquement base sur des variables css et il s'integre parfaitement a mes sous projets dependants de ma bibliotheque. J'ecris beaucoup moins de code qu'en react, la reutilisation de la logique des composants ne pose aucun soucis, et les declarations reactives le sont vraiment. Svelte propose une gestion des contextes et des stores qui est tres epuree et qui va droit au but. D'ailleurs, c'est ce que je retiens pour le moment sur mon projet en terme de developpement de composants, je vais droit au but et c'est un plaisir d'alleger l'utilisation de ses neuronnes en evitant de se bourrer le cerveau d'abstractions inutiles. La gestion des animations, des transitions et autres motion effects est aussi bien pensée, je n'ai pas eu a installer des libs, on se rend compte qu'on a pas besoin de tout cela de toute facon. Dernier point, le compilateur a pas mal d'options et le code généré est facilement interpretable. Voila pour le moment. Cote SSR, je ne peux rien dire, Sapper a l'air de faire le boulot mais je ne me suis pas encore interessé en profondeur a l'outils et aux performances.

[Haseo86]

Ça me fait quand même rire de voir que la justification pour l'utilisation de React serait le confort des développeurs. Perso plus je l'utilise et plus je le hais, je trouve ça imbitable, c'est une prise de tête permanente à développer.

[admadama]

Ça me fait quand même rire de voir que la justification pour l'utilisation de React serait le confort des développeurs. Perso plus je l'utilise et plus je le hais, je trouve ça imbitable, c'est une prise de tête permanente à développer.

La courbe d'apprentissage a été un peu rude, surtout pour penser correctement en terme de composants.
Mais maintenant, couplé à typescript, c'est un confort dont j'ai du mal à me passer. Les erreurs remontent avant la compilation, le code est facile à organiser, les tests faciles à implémenter.
Quand je dois reprendre le JS vanilla ou jQuery de quelqu'un d'autre en général je sais que je vais passer un sale quart d'heure dans un bordel total.

[Sodium]

Une fois pour toutes, oui les sites web sont plus gourmands qu'il y a dix ans, parce qu'on ne leur demande pas de faire la même chose qu'il y a dix ans, et surtout on n'a plus le même matos qu'il y a dix ans. On n'utilise pas ce genre de framework pour faire un simple site web, on s'en sert pour faire une application web. Auparavant, on se plaignait que les sites soient blindés de Flash, maintenant on se plaint qu'on ait trouvé une alternative à Flash ?

Quant à "améliorer l'expérience développeur uniquement", laissez moi rire. Une application PHP très rapide, c'est une demi-seconde entre chaque page, sur certains site comme celui-ci c'est plutôt 3-4 secondes. Sur une application JavaScript, c'est instantané et surtout on ne passe pas son temps à recharger du code qui a 95% n'a pas changé.

Après JavaScript est un très mauvais langage et il est très dommage qu'il soit devenu celui de référence dans le scripting web, mais c'est un autre problème.

Moi je dirais plutôt qu'ici on pense surtout à la satisfaction du développeur d'avoir les meilleurs benchmarks possible, le genre de mecs qui repasse sur du code pour le réécrire de manière à ce qu'il soit illisible mais gagne quelques millièmes de temps d'exécution par-ci par-là, ce qui ne correspond à aucun gain réel pour l'utilisateur.

[air-dex]

Et ça c'est avant l'émergence de Flutter Web. Les réseaux et les navigateurs vont chialer quand il va falloir télécharger le verbeux JS issu du code Dart.

Concernant angular les résultats sont sans doute un peu biaisés puisque les dernières versions ont apporté beaucoup d'améliorations sur la taille des applicatifs. Pas certains qu'un majorité des url testées soient en version 9.

De même quid d'Angular ? Est-ce bien toujours "la version avec TypeScript", par opposition avec AngularDart ? Parce que bon si beaucoup de sites et aplis Web de l'étude sont réalisées avec AngularDart, il ne faudrait alors pas s'étonner de voir autant de JS issu de Dart saturer les réseaux.

Quel est votre avis sur le sujet ?

L'inflation s'est faite sur nos connexions toujours meilleures et nos appareils toujours plus puissants. jQuery venant d'une époque où les ressources étaient plus limitées, je ne suis pas surpris de le voir plus économe.

Les frameworks JavaScript, un mal nécessaire pour le développement Web ?

Le problème c'est quon a tendance à utiliser trop de frameworks et de librairies. Je me souviens d'un site un peu pataud pour lequel j'avais regardé ce qu'il utilisait comme librairies JS. Il y en avait une dizaine pour tout et n'importe quoi. Et comme cerise sur le gâteau, il y en avait une ultime pour optimiser les performances du site, comme si les performances moyennes du site n'avaient aucun rapport avec le trop-plein de librairies JS qu'il utilisait.

Ou le problème serait-il plutôt JavaScript lui-même ou les développeurs ?
Si le problème vient de JavaScript lui-même, par quel langage faut-il le remplacer, quand cela est possible, pour avoir des sites Web plus rapides ?

À terme (si ce n'est pas déjà le cas), le goulot d'étranglement sera le navigateur. Quoiqu'on veuille faire, il faut que le projet Web (site ou application) finisse côté client en un mélange de ces 4 langages parce que ce sont les seuls que les navigateurs soient fichus de lire : HTML, CSS, JavaScript et WebAssembly. Et donc en quelque chose avec les défauts de ces 4 technologies incontournables.

Si on veut aller vers plus de performances alors je pense qu'il faudra tendre vers du WASM renforcé, càd plus qu'une solution de performance pour le backend de la page. On pourrait alors écrire le côté client dans le langage de notre choix (C/C++, Rust, C#...), avec les technologies de ce langage de notre choix (dont les frameworks de GUI), pour ensuite compiler le tout en WASM et ne distribuer que le WASM aux navigateurs. Bien sûr les ressources multimédia (images, sons, vidéos) pourraient continuer à être distribuées séparément sinon je n'ose imaginer la taille des fichiers WASM distribués, surtout ceux avec un film en UHD complet dedans. En bref cela passera par la "desktopisation du Web" et aller jusqu'au bout de WASM, à savoir être une sorte d'assembleur comme on a notre bon vieux ASM pour les applis de bureau. Côté utilisateur on aura l'avantage des performances et côté développeur on pourra développer avec la technologie qui nous semble la plus adaptée à ce que l'on veut faire, sans que cela ne déteigne sur les performances, ni devoir passer par la case JS si JS n'est pas adapté à ce que l'on veut faire.

Il est impossible d'utiliser ces frameworks correctement sans un EDI (ie Visual Studio Code + npm) correctement configuré (tout du moins sur un vrai projet).

Le problème des librairies JS est qu'elles prennent plaisir à se rendre interdépendantes et NPM "350 Mo de téléchargements dans node_modules plus tard" n'aide pas.

Bon, je viens de voir que le site de Vue.js ce declare etre un "progressiv framework" ... donc ca va etre difficile de défendre mon point de vue ^^'

Selon moi JQuery à permis d'accélérer dans manquements au standard et de mettre a plat les disparités entre browser :
- la standardisation des selector standardisé en querySelector,
- la notion de promesse avec leurs .done()/.fail() standardisé en .then()/.catch() de Promise
- le $.ajax standardisé en fetch()
et j'en oublie.

Et je vois chez Vue une démarche similaire qui est:
- Unifier la création d'un composant (car l'API CustomElement n'est hélas pas encore 100% supportée)
- Rendre ce composant réactif (c'est a dire, en gros, garder le JS(model) et le HTML(vue) synchrone)
Et c'est tout... pas de validation de formulaire, pas de fetch, pas de routage, pas de TS forcé, pas de syntaxe JSX/TSX a apprendre.

J'ai déjà fait dans plusieurs sites pro sans buildflow en Vue (pas de TS / NPM / Sass / Node / Cancer.js ...)
Et ca a tres bien marché et ca marchera dans 15 ans (on ne peu pas en dire autant des projets angular impossible a recompiler du premier coup 2 ans plus tard).

Bref tout ca pour dire que les 2 jouent dans la catégorie "boites a outils" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
<script src="https://unpkg.com/vue@2"></script>
Vue:<button id=a @click=i++>{{i}}</button>
<script>new Vue({el:'#a',data:{i:0}})</script>
 
<script src="https://unpkg.com/jquery"></script>
Jquery:<button id=b>0</button>
<script>$('#b').click(ev => $(ev.target).text(++j));j=0</script>

La seule chose qui me chagrine avec Vue semble que le framework semble se torcher avec la validation W3C. M'est avis que si le client l'exige (parce que pourquoi pas) alors t'es mal barré si tu te bases sur Vue. Comment faire par exemple pour maquiller un v-if en data-v-if pour que ça passe à la validation sans tout péter dans Vue ?

D'autre part, je tiens à ajouter qu'à chaque projets il convient de choisir la bonne techno.

C'est possible dans un monde parfait ou dans tes projets personnels. Moins dans une entreprise qui n'a qu'une techno sous la main et qui va forcer sur celle-ci pour décrocher le projet (et surtout le fric qui va avec), indépendamment de sa capacité de la techno à convenir pour le projet lui-même.