Discussion :

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

[Invité]

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.

[Invité]

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.

[admadama]

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.

[Sodium]

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.

[vbarr]

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.

[Sodium]

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.

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

[dfiad77pro]

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.

[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

[Invité]

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.

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 ?

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

[Alexandre T]

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

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.

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

[Sodium]

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é

[Invité]

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.

[air-dex]

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

[Eagles]

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)

[krakatoa]

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

[Sodium]

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.

[eagle777]

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 .