Quels sont les coûts liés à l'utilisation de frameworks JavaScript pour le développement Web ?

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.

https://www.developpez.com/public/images/news/coj01.PNG
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.

https://www.developpez.com/public/im...ews/coj02a.PNG
Quantité de JavaScript servi sur les appareils mobiles



https://www.developpez.com/public/im...ews/coj02b.PNG
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é.

https://www.developpez.com/public/im...ews/coj03a.PNG
Temps de traitement CPU (en millisecondes) des scripts pour les appareils mobiles



https://www.developpez.com/public/im...ews/coj03b.PNG

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.

https://www.developpez.com/public/im...ews/coj03c.PNG
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 ?

:fleche: Quel est votre avis sur le sujet ?
:fleche: Les frameworks JavaScript, un mal nécessaire pour le développement Web ?
:fleche: Ou le problème serait-il plutôt JavaScript lui-même ou les développeurs ?
:fleche: 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 :

:fleche: 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
:fleche: Le langage JavaScript est-il responsable de la lenteur des sites Web de nos jours ? Oui selon un expert
:fleche: Google veut financer le développement de fonctionnalités liées aux performances dans les frameworks JavaScript à hauteur de 200 000 USD

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.

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.

Citation:

---

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

Citation:

---

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.

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

@blasted

Citation:

---

React
A JavaScript library for building user interfaces

---

Source: https://reactjs.org/

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.

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. ;)

Citation:

---

Envoyé par blasted

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:

---

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>

---

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

Citation:

---

Envoyé par sboudes

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

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.

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.

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.

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.

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

Citation:

---

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

---

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.

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.

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.

Citation:

---

Envoyé par grunk

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.

Citation:

---

Envoyé par Michael Guilloux

:fleche: 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.

Citation:

---

Envoyé par Michael Guilloux

:fleche: 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. :aie:

Citation:

---

Envoyé par Michael Guilloux

:fleche: Ou le problème serait-il plutôt JavaScript lui-même ou les développeurs ?
:fleche: 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. :aie: 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.

Citation:

---

Envoyé par blasted

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.

Citation:

---

Envoyé par xhe11662

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:

---

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 ?

Citation:

---

Envoyé par Hacksterix

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.

Citation:

---

Envoyé par air-dex

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.

---

Perso, j'attends de voir pour Web Assembly...
Déjà le but premier, c'est d'avoir un bytecode portable. Les performances sont intéressantes (quand on sait s'en servir correctement) mais de ce que j'ai vu, on n'est pas non plus au niveau du natif.
Et surtout, c'est un environnement complètement différent, qui a le cul entre deux chaises : il vise à la fois les devs web frontend et les devs C/C++/rust mais dans les deux cas il demande un apprentissage assez important.

@MicroAlexx ah ok donc c'est une bibliothèque ? :ptdr: :troll:

Citation:

---

Envoyé par MicroAlexx

@blasted


Source: https://reactjs.org/

---

L'énergie déployée pour faire de malheureux boutons me semble parfois surréaliste.

A l'heure où le secteur se doit de mieux exploiter les machines pour réduire son empreinte énergénique, il convient de veiller au ratio coût / services rendus de chaque lib, framework, pseudo-framework ...

D'ailleurs très souvent les sites, services web sont difficilement exploitables sur mobile, tablettes ou petits micros : quand ce n'est pas le chargement distant de la lib qui fout la merde, c'est la sur utilisation du JS qui prend le relais.

Citation:

---

Envoyé par fodger

quand ce n'est pas le chargement distant de la lib qui fout la merde, c'est la sur utilisation du JS qui prend le relais.

---

Je charge et j'utilise des SPA correctement développés sur un tél entrée de gamme qui a 7 ans.
Ah c'est sûr faut pas faire n'importe quoi, configurer correctement son build avec webpack, faire gaffe à ne pas créer une floppée d'élements dans le dom (comme avec vanilla JS d'ailleurs). Bref, c'est un métier quoi.

Je pense qu'il y a une grosse confusion entre le dev fainéant qui utilise des libs pour faire défiler des photos ou faire un menu déroulant et celui qui utilise une librairie de rendu dynamique pour faire une application web. Utiliser des libs pour tout et n'importe quoi ça donne un rendu difficile à faire sur mesure, faire beaucoup de rendu dynamique de HTML en JS pur ça donne un code dégueulasse, impossible à maintenir et debugger quand on revient dessus par la suite. Une application Angular ça marche 1mo de JS au lancement de l'application et c'est marre, ensuite ça ne fait plus que des appels API réduits au strict minimum niveau données.

Quand on trackers publicitaires, animations, trucs qui popent etc, c'est rarement de la faute du dev. Le dev web utilise énormément Internet, il sait quels trucs sont casse-burnes et n'a pas envie de les intégrer, mais c'est rarement lui qui prend la décision finale d'intégrer ou non une fonctionnalité supposée augmenter le chiffre d'affaire ou créer un "effet whaou top super" qui rend la chose à peu près inutilisable mais qui fera plaisir au client.

Il faudra quand même bien se rendre compte qu'essayer de faire une appli avec un visualiseur de document et un pauvre langage de script, c'est une gageure ! Forcément on a des montagnes de bidouilles couteuses pour arriver à quelque chose! Rappelez-vous comment on faisait une appli en 3 clicks avec Delphi il y a 25 ans, sur des PC à 300MHz. On a laissé tomber tout ça pour du HTML et du javascript ? Quelle régression, ces "appli web" sont un énorme pas en arrière et a fait perdre 20 ans à l'informatique :( Sans parler de la difficulté de développement, de formation, la productivité nullissime.

Il faut combien de centrales nucléaires ou au charbon pour faire tourner tout ce javascript, ces nodejs etc ? le gaspillage d'électricité, d'espace de stockage, l'obsolescence forcée et donc les déchets électorniques et le gaspillage de matériaux précieux qui en résulte ... quelle horreur !

Microsoft Silverlight, les Applets Java, XUL, tout le monde a essayé de pondre quelque chose de mieux mais ça a échoué par manque de standardisation et d'open source à l'époque.
Mais maintenant qu'il n'a plus en pratique que Chrome et Firefox dans la course. .NET Core est open source alors on devrait ressortir tout ça des cartons.

Un paquet d'applications natives très performantes sont écrites en technologies web dont Visual Studio Code qui est l'un des meilleurs IDE actuels.

Delphi c'est un truc d'informaticiens, ça leur permet de faire des applications rapidement, moches, désagréables à utiliser, difficiles à maintenir car il y a des incompatibilités majeures d'une version de Delphi à l'autre. Le combo HTML/CSS est probablement ce qu'on a de mieux actuellement pour avoir un contrôle total de l'apparence et des fonctionnalités, facile à décliner sur différentes tailles d'écrans et systèmes (Windows, Mac, Linux, Android, iOS...)

On utilise beaucoup Delphi chez nous, résultat on a des dizaines d'applications qui ont plus de dix ans plus vraiment maintenue et on a dû trouver un développeur spécifiquement pour faire évoluer celles importantes qui sont bloquées sur une ancienne version.

En 1990, j'attendais devant une page blanche que mon modem se connecte et qu'il charge la page HTML.
En 2000, j'attendais devant une page presque blanche que tout le tableau HTML soit chargé pour qu'il apparaisse (vous vous souvenez de cette manie de mettre toute la page dans une balise <table> pour gérer les menus latéraux ?)
En 2010, j'attendais devant une page blanche que les librairies jQuery & cie se chargent
En 2020, j'attends devant une page blanche que le framework Vue/React/Angular se charge, puis devant un joli "spinning-icon" que le backend répondent au Front-end.

:aie::ptdr:

on insiste pas assez sur la nécessité d'un backend rapide, pas un truc qui appelle une procédure stockée non optimisé via un ws qui dure 30 secondes sous prétexte que c'est couteux d'optimiser.

Vous habitez tous en Afrique sub-saharienne ou quoi ? J'attends rarement plus d'une seconde pour le chargement d'une homepage d'un site, à part sur dvp.net où chaque page met trois plombes, et j'ai pas une question de JavaScript :roll:

Citation:

---

Envoyé par Alexandre T

En 1990, j'attendais devant une page blanche que mon modem se connecte et qu'il charge la page HTML.
En 2000, j'attendais devant une page presque blanche que tout le tableau HTML soit chargé pour qu'il apparaisse (vous vous souvenez de cette manie de mettre toute la page dans une balise <table> pour gérer les menus latéraux ?)
En 2010, j'attendais devant une page blanche que les librairies jQuery & cie se chargent
En 2020, j'attends devant une page blanche que le framework Vue/React/Angular se charge, puis devant un joli "spinning-icon" que le backend répondent au Front-end.

:aie::ptdr:

---

Déjà, la première page web a été publiée le 13 novembre 1990, donc je doute que tu aies attendu beaucoup de pages web cette année là...
Et ensuite, je pense que les sites web font un peu plus de choses désormais. En 1990, tu gérais ton compte en banque tout en regardant une vidéo HD dans Netscape ?

Nan mais je comprends, faudrait des sites des années 90 sur des machines de 2020 comme ça les pages seraient chargées en 0.00000000001 secondes, les devs pourraient se gargariser de benchmarks, l'humanité en ressortirait grandie.

Citation:

---

Envoyé par Sodium

Vous habitez tous en Afrique sub-saharienne ou quoi ? J'attends rarement plus d'une seconde pour le chargement d'une homepage d'un site, à part sur dvp.net où chaque page met trois plombes, et j'ai pas une question de JavaScript :roll:

---

Citation:

---

Envoyé par SimonDecoline

Déjà, la première page web a été publiée le 13 novembre 1990, donc je doute que tu aies attendu beaucoup de pages web cette année là...
Et ensuite, je pense que les sites web font un peu plus de choses désormais. En 1990, tu gérais ton compte en banque tout en regardant une vidéo HD dans Netscape ?

---

Citation:

---

Envoyé par Sodium

Nan mais je comprends, faudrait des sites des années 90 sur des machines de 2020 comme ça les pages seraient chargées en 0.00000000001 secondes, les devs pourraient se gargariser de benchmarks, l'humanité en ressortirait grandie.

---

Keep calm ! Je versais dans l'humour et l'ironie. Avez-vous remarqué les smileys ?

Désolée, vu le nombre de conneries qui sont débitées sérieusement régulièrement sur ce type de sujet il n'est pas toujours facile de détecter l'ironie ;)

C'est un peu comme aller à une convention de médecines alternatives, qu'un mec te dise "je sens une perturbation d'énergie quantique dans vos chakras" puis "non mais c'était de l'ironie !"... euh mais c'est exactement ce que disent les 300 stands à côté au premier degré :aie:

Citation:

---

Envoyé par Alexandre T

Keep calm ! Je versais dans l'humour et l'ironie. Avez-vous remarqué les smileys ?

---

Oh pardon, je n'avais pas compris.
Dans ce cas : hahaha c'était vraiment très drôle.
:aie::ptdr:

Pour moi le coût n'est pas forcément à la consommation CPU/mémoire ou temps de chargement mais plus au niveau pérennité et maintenance du code.

Pour un si web standard qui nécessite peu/pas de maintenance/évolution à long terme prendre un framework/lib du moment semble la meilleure solution, trouvé un dev dispo sur le marché se fera facilement et la création du site se fera rapidement.

Pour un site qui a besoin de pérennité du code et de la maintenance/évolution sur le long voir très long terme (IHM embarquée par exemple) même jQuery est à éliminer les blagues du genre "on n'est plus rétrocompatible", "on abandonne le projet" ne sont pas permises.

Ce que je trouve plus inquiétant c'est que beaucoup de dev ne savent même pas pourquoi ils utilisent un framework ni ses avantages/inconvénients par rapport aux autres framework ou au vanilla voir ne savent pas coder que ça se code en vanilla (ex: data-binding vs proxy)

Citation:

---

Envoyé par Alexandre T

vous vous souvenez de cette manie de mettre toute la page dans une balise <table> pour gérer les menus latéraux ?

---

Ça existe encore mais ça se fait désormais en CSS. On appelle ça "Grid Layout". :P :aie:

jQuery est pratique pour faire des petits trucs mais l'enfer pour un projet alors on ne peut pas comparer avec angular, vue, react
Angular dispose du lazy loading pour charger les pages à la demande (surement aussi sur vuejs, react)
et puis si la première fois on a une insoutenable attente de quelques centaines de ms, les fois suivantes c'est le cache qui s'en charge

Nan mais de toute façon faut arrêter de se leurrer, JavaScript n'a jamais été pensé pour faire des applications, le minimum pour ça c'est de pouvoir générer des vues proprement, et pour ça du data-binding est indispensable. Ca serait bien que les systèmes de template PHP adoptent ça pour arrêter de faire des foreach dégueulasses partout.

La machine est un outils , son objectif est de permettre à l'homme d'augmenter son confort ou sa commodité de vie .
Ici nous avons trois acteurs le client , le développeur et la machine. Moi en tant que développeur je n'accepterais jamais de diminuer mon confort de développement
pour que la machine soit alaise désolé .
On ne développe par pour des machines mais pour des hommes , l'informatique c'est pas pour les machines c'est pour les hommes.
Donc si mon application ou mon site est facile à manipuler par l'utilisateur et que j'ai pris moins de temps et plus de plaisir à développer grâce à vuejs/Angular/React,
je ne vois pas où est le problème ?
Si le serveur dois travailler plus et bien qu'il travaille plus, de toute façon c'est lui l' outils et un serveur c'est fait pour ça :chauffer.
Nous ne sommes plus en 80-90 ou les ressources était insuffisantes donc il fallait les gérer. Maintenant la ressource ce n'est plus le problème.
En réalité la plupart des critiqueurs des framework java-script sont les développeur séniors qui n'ont pas effectués correctement leur transitions technologiques .
Beaucoup ont du mal a accepter que ce qui était si difficile et fastidieux à leur temps est aussi facile et accessible avec les nouveaux paradigmes aujourd'hui.
Alors pour se consoler il cherchent la petite bête dans toutes les nouvelles technos avec des argument qui ne sont pas concrets.
LA MACHINE RESTE LA MACHINE .