Discussion :

[Bill Fassinou]

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

Êtes-vous d’avis que les frameworks, en particulier les frameworks JavaScript, aient peu à peu détruit les performances Web ou l’expérience utilisateur ? C’est là la thèse que défend un billet de blogue d'un gamer et journaliste portant le pseudo « cheatmaster30 » travaillant sur Gaming Reinvented, une plateforme pour les nouvelles et les éditoriaux sur le jeu. Il estime que ces dernières années, les performances du Web ont baissé à cause de l’avènement des frameworks Web, comme React et Vue.js, et les applications web monopage (single-page application (SPA)) qui privilégient les développeurs à l’expérience utilisateur.

C’est peut-être un sujet qui revient plus souvent, faut-il utiliser les frameworks JS ou pas ? L’écosystème JavaScript a évolué ces dernières années plus que jamais et il existe désormais des dizaines de frameworks JS front-end comme back-end. Cependant, des voix s’élèvent pour dire que JavaScript est responsable de la lenteur des sites Web, notamment le JavaScript de tiers. Selon cheatmaster30, les frameworks JS ont rendu la page Web moyenne désormais plus grande que jamais, les pages de 2 à 3 Mo étant plus courantes que jamais.

« C'est un fléau sur Internet, et beaucoup de personnes blâment les frameworks dans leur ensemble. Après tout, beaucoup de ces sites sont construits avec des frameworks JavaScript même quand ce n'est pas vraiment nécessaire (comme avec beaucoup de sites de news). Et un bon nombre d'entre eux utilisent aussi Bootstrap pour le CSS », a-t-il dit. Toutefois, selon lui, il ne s’agit pas là du vrai problème. « Je pense plutôt que le problème est l'état d'esprit des développeurs et des concepteurs dans de nombreuses entreprises », a-t-il déclaré.

Les frameworks auraient rendu les développeurs et les ingénieurs moins soucieux de leurs utilisateurs ou de leurs clients que par le passé, plaçant leur satisfaction au-dessus des usagers de leurs applications. « Je crois fermement que beaucoup de développeurs et d'ingénieurs logiciels placent leur satisfaction professionnelle au-dessus de leurs utilisateurs ou de leurs clients », a-t-il déclaré, ajoutant que c’est ce qui a conduit les développeurs vers toutes ces pratiques douteuses, ainsi qu'à un manque d'intérêt pour ce qui compte.

Par exemple, il estime que les systèmes de construction lourds comme Webpack et des dizaines de composants NPM sont utilisés pour faire gagner du temps et de l'effort aux développeurs, sans tenir compte des kilo-octets (ou même des méga-octets) de JavaScript qui s'ajoutent au produit fini. Des composants tiers sont apportés avec des quantités importantes de CSS et de JavaScript, simplement pour éviter d'avoir à construire ces composants à partir de zéro, la taille de la page étant damnée (fonctionnalités inutiles, chargement lent, etc.).

Dans d’autres cas, cheatmaster30 allègue que les développeurs choisissent d’utiliser un langage ou une technologie pour effectuer un travail simplement parce qu’elle est “cool”, et non parce qu’elle est la mieux adaptée pour faire le travail. « Regardez tous ces sites de nouvelles reconstruits comme des SPA avec des frameworks JS très résistants. Ils n'ont pas besoin d'être faits comme ça, et ils ne devraient probablement pas l'être », a-t-il déclaré. Par ailleurs, il ajoute que ces choix ne s’observent pas uniquement chez les développeurs.

Selon lui, il n'y a pas que les développeurs qui sont ainsi. Il estime que tout le monde est comme ça dans la chaîne de commandement. Les gestionnaires, les PDG, les investisseurs, l'équipe de marketing, les ventes, etc. Tout le monde veut avoir l'air bien devant ses pairs ou devant les hauts dirigeants, et tout se termine par une surcharge de travail et une lourdeur qui en résulte, ce qu'il faut changer. Le client ou l'utilisateur doit être en priorité, et non les personnes qui travaillent sur le produit ou encore l'entreprise elle-même.

De plus, dans une certaine mesure, les utilisateurs comprennent cela. Il estime qu’on le voit bien par le nombre de produits et de services “merdiques” qui finissent par l'emporter sur des rivaux plus exigeants. Toutefois, cela n'est pas le cas de tous les services. « Regardez Craig's List. C'est apparemment moche, mais la technologie utilisée n'est probablement pas un sujet de conversation très important », a-t-il déclaré.

«  Il en va de même pour Hacker News et pour l'ancienne version de Reddit ou pour de nombreux jeux populaires en général comme Minecraft ou Wii Sports ou Tetris », a-t-il ajouté. Il estime qu’aucun de ces jeux n'est particulièrement fantaisiste dans tous les sens du terme, mais ils se sont tous vendus à des millions d'exemplaires néanmoins.

« Alors, créateurs, arrêtez de vous focaliser sur votre CV ou votre convenance personnelle. Cessez de faire passer vos propres intérêts avant ceux de vos utilisateurs et de gaspiller des centaines de kilo-octets pour des choses dont personne ne se soucie. Vous n'êtes probablement pas Facebook ou Google, et vous ne devriez pas concevoir ou construire des choses comme si c'était le cas. Faites plutôt ce qui est nécessaire pour le travail et offrez une expérience que l'utilisateur aimera utiliser, avec aussi peu de ressources que nécessaire. Faites cela, et vos utilisateurs et clients vous en remercieront », a-t-il conclu.

Source : cheatmaster30

Et vous ?

Quel est votre avis sur le sujet ?
Les frameworks Web détruisent-ils vraiment les performances du Web ?
Quelles sont votre position et votre stratégie sur les frameworks ?

Voir aussi

Le langage JavaScript est-il responsable de la lenteur des sites Web de nos jours ? Oui, selon un expert

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

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

[Invité]

Quel est votre avis sur le sujet ?

Que cheatmaster30 n'a pas dû connaitre l'époque de Flash et des applets Java...

[Edrixal]

Quel est votre avis sur le sujet ?
Les frameworks Web détruisent-ils vraiment les performances du Web ?
Quel est votre position et votre stratégie sur les frameworks ?

Je vois dans la boite informatique ou je suis, ils ont décider que le site internet devait être gérer par... Le pôle commercial !
Aucune des personnes en question n'a jamais taper une ligne de code. Ils ont donc choisie de passer par un CMS... WordPress.

Bien sur ils voulais faire original. Donc ils ont choisie un thème spécial, ajouter plein de truc à droite à gauche, en ont virer la majorité, ect...
Au final, ils ont sortie un jolie bébé, beau à voir visuellement, mais qui permet de commencer à naviguer au bout de 3/4s et qui s'affiche au complet en 10/12s.

La faute aux nombreux script.
Mais bon la gestion commercial sont content, maintenant ils peuvent ajouter une page ou modifier les informations sur nos produits directement ! Au prix d'un site difficilement navigable...

Tout ça pour dire que c'est parfois plus compliquer que le choix d'un dev. Les CMS permettent à n'importe qui de créer un site, des personnes complétement amateur qui n'y connaissent pas grand chose et font ce qu'ils peuvent pour avoir un jolie visuel.
Et j'ai beau eu leur expliquer qu'il vaut mieux avoir un site avec un visuel moyen (mais propre !) qui est rapide, plutôt qu'un jolie site qui rame, mes arguments sont tomber dans le néants. Je ne suis donc pas étonner. Aux utilisateurs de faire savoir qu'ils préfère les sites rapide. Après tout, nous avons enregistrer une augmentation des visites sur notre site internet depuis (Ainsi qu'une durée de visite plus longue ), donc finalement mon avis de dev qui préfère un site rapide, c'est peut être pas vraiment ce que recherche le client

[thejoker31]

J'ai quelques réflexions à ce sujet:
d'une part veulent ils perdre toute la clientèle des seniors et autre GJ qui n'ont pas les moyens de changer leur PC pour des laptops?

d'autre part veulent ils faire vendre plus de harware?

au final n'y a t'il pas une perte de pouvoir d'achat pour le Ecommerce la base de leur business?

et par conséquent une migration vers des plateformes Ecommerce type Amazon?

les gagnants sont donc les mastodontes...

[darklinux]

Quel est votre avis sur le sujet ?

Que ce monsieur n ' a jamais connus les années 1990 au niveau du web avec les applets Java 1.0 /1.2 , active X etc . Javascript / Python ont permis une normalisation , Chrome , puisque c 'est le leader utilise le GPU pour accélérer , nous avons le MP4 , qui est très bien , un effort considérable par rapport au .WMV de triste mémoire , que ce monsieur , reprenne son MacBook Pro et code !

[kilroyFR]

Oui on peut toujours faire la meme chose en assembleur dans son coin et reinventer la roue carree.

Justement l'interet de ces frameworks (d'autant plus JS ou c'est assez rock n roll pour le dev), ils ont grand interet.
N'est ce pas le propre de l'informatique de faire des composants, mutualiser ? donc de creer des frameworks aboutis qui rendent les services attendus.

On en a bien dans ma boite, principalement des jeunes arrivants, qui bavent sur l'existant et veulent reinventer parce que plus malins que les autres.
Bootstrap et autres c'est de la merde ?... ben on voit comment leur projets depensent une energie folle a maintenir un code qu'ils ont ecrit et qui est une belle usine a merde dans laquelle personne ne veut mettre les doigts.
On a la chance d'avoir l'open source qu'on n'avait pas il y a 30 ans et qui permet des gains considerables en termes de recuperation de composants.
Ca c'est du concret, pas du pipeau de developpeur a l'ego surdimensionné.

Performances du WEB ? les materiels (PC, mobiles etc) n'ont jamais ete aussi surpuissants
Interactivité utilisateurs ? on n'a jamais ete aussi pres d'interface utilisateurs web proches des interfaces desktop rigides.

Non, le gars s'est trompé de siecle.

[Invité]

Je suis plutôt d'accord avec le constat mais pas vraiment avec les causes qu'il avance. Clairement aujourd'hui une grande partie des sites utilisant React/Angular/Vue ou autre framework front end n'en a au mieux strictement pas besoin et vraisemblablement ça lui fait du tord. Il ne faut pas oublier qu'a la base ces outils ont étés conçus pour gérer des applications du calibre de Facebook ou Gmail, faire son blog en React c'est un joli cas d'utilisation de bazooka pour tuer une mouche.

Aujourd'hui la plupart des personnes vivant dans les pays développés n'auront pas de problèmes à charger une application web de 2-3Mo, quitte à ce que ça prenne quelques secondes pour les mecs en bout de ligne en Lozère. Le problème c'est que dans un monde où il faudrait faire de plus en plus attention à l'utilisation des ressources, on se comporte en informatique comme les rois du pétrole des années 70 et là ou un site pourrait peser quelques kilooctets on colle un gros React de 1Mo+. Ça semble peu important au niveau individuel mais l'économie d'échelle au niveau du web pourrait être colossale.

Pour ce qui est des frameworks backend, il y en a pour tous les goûts mais là tendance est plutôt vers le micro framework depuis quelques années qui me semble être un bon compromis entre performance et maintenabilité, surtout que rien n'empêche de pré-générer ses pages et des les servir comme des fichiers statiques, et pour les contenus plus dynamiques se baser sur du JS et des API.

[tlt]

Je trouve aussi que les frameworks Web ont un peu réduit les performances du Web. C'est peut être parce qu'il y a qu'autres facteurs decisionnels à part la technique pure et donc le dev.
Par contre c'est tout le contraire au niveau expérience utilisateur. Il est plus accessible de remodeler l'experience utilisateurs en passant par des frameworks que plutôt sans. C'est plutôt difficile de recréer la roue à ce niveau là.

edit: ça se ressent beaucoup car là où je suis, je suis à 80% du temps sur de la 2G, mêm si là 4G est là mais pas partout; et la data se monnaye en Mo. Par exemple, il y a pas mal d'offre de 5Mo de data (mais je ne vais pas les citer , en tout cas pas directement ici ). Certaines pages bouffent aussi de la rame,en plus de la data, à cause de certains frameworks même si ils sont à jours et soi disant optimisés, alors que là où je suis, il y a encore beaucoup de téléphone à 1 coeur avec moins de 1Go de ram, parfois même sous android 4.1 ou moins. Et il y a encore pas mal de telephone avec des navigateurs Java (par exemple les telephones itel ).

[Sodium]

Ce discours est un peu le marronnier du développement web, et le discours ne tient pas très longtemps :

• les pages font aujourd'hui souvent plusieurs mo : et alors ? Déjà une fois que c'est chargé c'est chargé, une application one-page ne fait ensuite plus appel qu'à des api. Aujourd'hui on a la fibre optique, la 4g, bientôt la 5g, c'est pour s'en servir ou juste pour le plaisir de payer pour un service qu'on n'utilise pas ? L'auteur a-t-il seulement connu l'époque du 56k quand il fallait une éternité pour charger trois pauvres images ? Oui il y aura toujours les gens qui vivent au milieu de la brousse et ont une connexion moisie, mais si l'on se base toujours sur le maillon le plus faible d'une base d'équipements au lieu de chercher le meilleurs compromis on n'avance jamais
• la puissance pareil, n'importe quel smartphone est aujourd'hui plus puissant que les pc que la majorité des gens achètent chez Darty. C'est pour s'en servir ou pour le plaisir de faire tourner des benchmarks ?...
• ... d'autant que c'est dans l'autre sens qu'il faut voir les choses. Les applications ne sont pas plus lourdes magiquement à cause de l'utilisation de frameworks, elles sont plus lourdes parcequ'ils permettent de faire des choses plus complexes. On pourrait faire la même chose uniquement en jQuery, les manipulations du DOM seraient tout aussi lourdes
• pourquoi l'expérience du développeur ne serait-t-elle pas importante ? On est des humains, on a le droit de travailler dans des conditions correctes, ce qui jusqu'à il y a peu était pratiquement impossible en front-end. Ensuite, si l'application est buguée parce que la complexité du code le rend peu fiable, qui en paie le prix ? L'utilisateur. S'il faut trois fois plus de temps pour sortir des features parce que l'application est compliquée à maintenir et faire évoluer ? L'utilisateur

Quant à l'argument de l'économie de bande passante et donc l'écologie, il est assez ridicule, une minute de vidéo en streaming représentant probablement plus que tout le code qu'un utilisateur télécharge en un an.

[clorr]

On ne peut pas nier un effet de mode. Comme le cloud, ou l'IA, les tendances influencent beaucoup les choix des développeurs ou de leur hiérarchie. Maintenant, est-ce juste un effet de mode ?

Il y a un paramètre a ne pas oublier dans le monde du développement, qui est le travail d'équipe. Et le fait est que les frameworks permettent aussi de scinder les projets, de faire travailler les gens en parallèle d'une manière qui n'est peut être pas toujours la plus optimale, mais le framework propose un formalisme qui aide à mettre en place des process et des méthodes de travail en équipe. Et ça, ça plait aussi à la hiérarchie.

Les devs solo peuvent être aussi intéressés car cela rationnalise leurs devs, que ce soit sur un seul site ou d'un site à l'autre pour ceux qui font du freelance.

Malheureusement, cela se fait au détriment du client et de la "beauté" du code, mais ce n'est pas la première fois ni la dernière que cela arrive...

Le point positif que je relèverait néanmoins ici, est que ces pratiques amènent à une rationalisation du dev web et, derrière, amènent de l'innovation a un niveau plus global. J'ai tendance à penser que des évolutions telles que les web components sont aussi le résultat de l'adoption de ces frameworks.

Donc, même si j'ai un ordi antédiluvien et que je peste contre ces pages qui mettent une heure à charger et me ralentissent, et que j'apprécie la beauté du code, j'ai du mal à condamner ces pratiques.

[wallas00]

This is easily the biggest load of horse shit I’ve read in a very long time. It’s obviously written by someone that A) HAS ZERO EXPERIENCE IN SOFTWARE DEVELOPMENT, and B) lacks the balls to put his own name on the ‘by line’.

Well I’ve Got almost 30 years in the business of writing applications. Almost 20 years alone in web apps. I’ve never met a developer exhibiting the behavior this guy sites. He’s just making crap up.

Having rewritten and replatformed a number of apps to some of the mentioned frameworks, I can say empirically that they are more performant and efficient than their client — server predecessors. Every time I migrate an app to, let’s say, Google’s Angular framework, I’ve consolidated 1000’s of lines of code. Production builds of these sites are fractions of the size of a once-standard web app deployment.

The article concludes with some career advice. Lol. Yeah ok. I have some of my own. Stick to what you know.

First off, the newest frameworks aren’t just dreamed up as an exercise in programming — they make something easier to do. Granted, that something might not be whatever the short-term product needs. If you’re administering a news site that hasn’t changed anything in decades, then rewriting it in React might seem more personal exercise than strict business requirement. But you do it to future-proof your product. At some point your product will want to release an app, roll out a custom comments feature, chat, analytics, or something modern. A good programmer will usually choose a framework in anticipation of those future needs.

The second part is a bit taboo to discuss, but I’ll do it anyways: economic necessity. In the good ol’ days when people worked the same job at the same company for 40 years, you might be ok with keeping simple “boring” systems in place. But these days, you don’t work at the same place for 40 years… the same companies probably won’t even exist in 40 years. You need to make sure you’re familiar with the latest technology for your own sake. Good employers understand this and will help their best programmers stay on top of their game by having them work with the latest technology. Yes, sometimes this means a slightly more involved tech solution than the most simple immediate solution, with possibly some added time as the developer learns the quirks of the framework better, but this is part of the cost of talent retention.

Finally… what the hell. Programmers should shortsightedly always prioritize load time over maintainability? Or, if we go with your premise that programmers are just doing it for ‘fun’ (they’re not, see above), programmers shouldn’t have fun or learn or feel mentally engaged or improve themselves?

While frameworks add overhead, they are hardly ever the main source of bloat. In my experience, there is always lower hanging fruit than initial page size:
Analytics and trackers
Ads
Huge third party SDKs (e.g. social login or videos with ads/DRM)
Large images
Fonts
Only the last two have to do with developers. The others are, unfortunately, the current business model of the web.

Il n'y a pas que les performances à prendre en compte lorsqu'on construit une application ou un site web.

[Invité]

Quant à l'argument de l'économie de bande passante et donc l'écologie, il est assez ridicule, une minute de vidéo en streaming représentant probablement plus que tout le code qu'un utilisateur télécharge en un an.

C'est juste faux, certes c'est le streaming vidéo qui fait péter les tuyaux aujourd'hui mais l'ordre de grandeur n'est absolument pas celui que tu avances. Le dernier rapport de Sandvine de 2019, qui est une référence dans ce domaine, nous dis que le web représente 13.1% du trafic global, auxquels tu pourrais rajouter les réseaux sociaux (6.1%) mais c'est sujet à débat donc on va garder nos 13%. Le streaming vidéo c'est 60%, donc on est bien loin du "une minute de vidéo = un an de web".

On parle bien de 13% du trafic internet mondial, c'est colossal en terme d'énergie donc oui, si on peut réduire l'impact de ces 13% avec assez peu d'efforts pourquoi ne pas le faire? Est-ce que c'est si difficile de se passer des SPA là où il n'y en a pas vraiment besoin?

Après c'est philosophique et je conçois qu'on ne soit pas tous d'accord. Si tu es de ceux qui disent de rouler en 4x4 c'est pas important parce que de toutes façons le gros des émission de CO2 n'est pas là, alors en effet on ne s'entendra pas. Personnellement j'aime l'efficience et la sobriété.

[Edrixal]

...

En fait elle n'a pas vraiment tort lorsqu'elle dit qu'une minutes de stream est égale à 1 ans de code envoyer. (Bon faut que ce soit du 4k bien lourd ou être très peut productif, mais pourquoi pas.)

Le problème dans son raisonnement c'est qu'elle oublie que ce code envoyer va être récupérer pas des dizaines/centaines/milliers/millions d'utilisateurs ce qui va donc multiplier la charge de se code. Et quant ont commence à parler de milliers d'utilisateur sur son site, on commence vite à comprendre que le moindre mo télécharger inutilement en front peut vite devenir des go ou des to qui transit inutilement.

[Sodium]

Oui, je me suis plantée, je voulais dire une heure de streaming, ce qui fait à peu près 21go.

Je ne pense pas que tes chiffres soient pertinents. Déjà est-ce qu'on parle de bande passante dédiée au code ou de bande passante tout court, ou images comprises et vidéos insérées dans les pages, notamment dans un flux Facebook, qui ne sont probablement pas comptabilisées comme du streaming ?

Je ne parlais pas en terme de consommation de bande passante globale et mondiale, mais pour utilisateur qui visionne de la vidéo 4k, ce qui exclut une bonne partie de la planète. Pour ces utilisateurs, et ils seront de plus en plus nombreux, le poids du code source des pages qu'ils visitent constitue une goutte d'eau dans un océan.

[scandinave]

Mon Avis?

Le mec tape encore sur des outils alors que le fond du problème c'est ceux qui l'utilisent et les contraintes dans lesquelles ils sont utilisés.

Je vais prendre l'exemple de Angular que je connais bien. Il existe nombre de méthodes d'optimisation du temps de chargement et du poids de la page par exemple :

• Chargement à la demande (Lazy-loading) : Permet de ne charger que ce qui est nécessaire à un instant T
• Rendu Serveur (Server side rendering) : Permet de pré-calculer des pages statiques qui officieront en attendant que le JavaScript se charge
• Tree-shaking : Permet de virer le code non utile à l'application au moment de la compilation.

Combien d'applications faites avec Angular n'utilisent pas ces principes? Soit par manque de temps soit par non connaissances des développeurs. Tous les frameworks demandent de la maitrise donc du temps. C'est la même chose lorsque vous devez coder à la main. Si le développeur n'a aucune expérience, ne connais rien en architecture logiciel, les performances seront également fortement dégradées.

Combien de fois ai-je vu dans du code ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
List<Bar> bars = new ArrayList<Bar>

Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("SELECT * FROM Foo);
while (rs.next()) {
  String id= rs.getString("id");
  Statement stmt = conn.createStatement();
  ResultSet rs = stmt.executeQuery("SELECT * FROM Bar WHERE id = "+ id);
  bars.add(rs.getXXXX, rs.getXXXX, ...);
}

Si vous avez 100.000 entrés dans la table Foo, bonjour les dégâts. Pas besoin de framework pour faire du caca.

Autre exemple, j'ai récemment eu à faire une interface web sans framework css ou JS pour justement gagner en poids de page. Le résultat c'est que je suis tombé sur des bugs d'implémentation de navigateur qui m'ont fait perdre un temps certain. Et je ne parle pas que de IE. Que ce soit Edge, Chrome ou même Firefox, aucun ne respecte entièrement la norme. Un framework comme Bootstrap permet de palier ces déconvenues. Avec Sass, on peut n'inclure que les fonctionnalités voulues. Pour cela il faut bien sûr creuser un peu plus le sujet.

Pour moi le principal problème vient du fait qu'il y a trop de demande et pas assez de développeurs qualifiés pour faire de la qualité. Les entreprises en sont réduites à recruter n'importe qui. Les jeunes n'ont pas le temps de se former auprès des plus anciens et prennent de mauvaises habitudes. Sauf les quelques motivés qui travail sur leur temps perso pour apprendre et corriger leurs défauts. Je vois des développeurs s’intituler Full Stack Senior développeur avec 3 ans d'expériences . Impossible de maitriser en 3 ans les concepts permettant de

1. monter une bonne architecture logiciel modulaire et de la respecter
2. de maitriser Html/CSS/JS pour une bonne conception d'interface optimisée, ergonomique et adaptative
3. de maitriser les aspects fondamentals d'un backend end comme la sécurité, la mise en cache, les web services ...
4. d'optimiser des ORM ou des requêtes SQL/NOSQL
5. de correctement configurer des outils comme Maven/Gradle/Webpack
6. d'industrialiser avec le déploiement continue via Ansible, Docker/LXC, Jenkins/Travis ...

Bref, Soit vous êtes une grosse boite qui a les moyens de payer plein de gros barbu spécialisés dans des domaines spécifiques, soit vous n'avez pas les moyens et vous avez des devs qui vont devoir être polyvalents et n'auront pas d'autre choix que d'utiliser des frameworks pour juste arriver à faire en sorte que cela marche. Mais dans ce cas, l'optimisation n'arrivera jamais.

[Edrixal]

Bref, Soit vous êtes une grosse boite qui a les moyens de payer plein de gros barbu spécialisés dans des domaines spécifiques, soit vous n'avez pas les moyens et vous avez des devs qui vont devoir être polyvalents et n'auront pas d'autre choix que d'utiliser des frameworks pour juste arriver à faire en sorte que cela marche. Mais dans ce cas, l'optimisation n'arrivera jamais.

J'ai bosser sur un projet en parallèle avec une grosse boite. Honnêtement du haut de mes quelques années d'expérience dans l'informatique pro, c'était soit de gros branquignol, soit des feignants... Par exemple champ Code Postal à 255 caractères en saisie libre... Et moi coter WS j'ai du surblinder mes vérifications parce qu'aucune données envoyée n'était vérifier ou correctement calibrée. Et ça malgré de multiple réunion... En même temps ils avait dans les 2 ans de retard
Le client à fini par les dégager et engager un autre prestataire pour finir le travail et qu'est ce que ça fait du bien de travailler avec quelqu'un qui sais ce qu'il fait...

Bref, j'suis pas certain que ce soit qu'une question de moyen. C'est une question de volontés.

[Sodium]

Apparemment le nouveau moteur Ivy en test dans Angular 8 et standard dans Angular 9 réduit considérablement le poids du JS. Je n'ai pas encore pu tester personnellement, j'ai voulu l'activer dans mon projet tout à l'heure et j'ai eu une erreur npm.

[scandinave]

Bref, j'suis pas certain que ce soit qu'une question de moyen. C'est une question de volontés.

L'inverse n'est évidement pas vrai. Ce n'est pas parce qu'une boite à plein de pognon qu'elle fera des logiciels optimisés

[herr_wann]

C'est moins les frameworks que les nombreux appels externes aux régies publicitaires et autres trackers qui ralentissent l'affichage et la navigation.

[23JFK]

Je vois dans la boite informatique ou je suis, ils ont décider que le site internet devait être gérer par... Le pôle commercial !
Aucune des personnes en question n'a jamais taper une ligne de code. Ils ont donc choisie de passer par un CMS... WordPress.

Bien sur ils voulais faire original. Donc ils ont choisie un thème spécial, ajouter plein de truc à droite à gauche, en ont virer la majorité, ect...
Au final, ils ont sortie un jolie bébé, beau à voir visuellement, mais qui permet de commencer à naviguer au bout de 3/4s et qui s'affiche au complet en 10/12s.

La faute aux nombreux script.
Mais bon la gestion commercial sont content, maintenant ils peuvent ajouter une page ou modifier les informations sur nos produits directement ! Au prix d'un site difficilement navigable...

Tout ça pour dire que c'est parfois plus compliquer que le choix d'un dev. Les CMS permettent à n'importe qui de créer un site, des personnes complétement amateur qui n'y connaissent pas grand chose et font ce qu'ils peuvent pour avoir un jolie visuel.
Et j'ai beau eu leur expliquer qu'il vaut mieux avoir un site avec un visuel moyen (mais propre !) qui est rapide, plutôt qu'un jolie site qui rame, mes arguments sont tomber dans le néants. Je ne suis donc pas étonner. Aux utilisateurs de faire savoir qu'ils préfère les sites rapide. Après tout, nous avons enregistrer une augmentation des visites sur notre site internet depuis (Ainsi qu'une durée de visite plus longue ), donc finalement mon avis de dev qui préfère un site rapide, c'est peut être pas vraiment ce que recherche le client

Connaissant ce genre de spécimens, ils travaillent sur des machines surpuissantes par rapport à la moyenne des utilisateurs et forcément siglées Apple, pour être bien, ils font les tests en offline. Bref, tout pour ne pas se rendre compte du problème inhérent à la surcharge inutile des pages web en scripts voire images en ultra-HD redimensionnées en icônes sur le navigateur du client.