Version imprimable
Perso, j'attends de voir pour Web Assembly...Citation:
Envoyé par air-dex
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
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.
Je charge et j'utilise des SPA correctement développés sur un tél entrée de gamme qui a 7 ans.Citation:
Envoyé par fodger
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:
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à...Citation:
Envoyé par Alexandre T
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
Citation:
Envoyé par SimonDecoline
Keep calm ! Je versais dans l'humour et l'ironie. Avez-vous remarqué les smileys ?Citation:
Envoyé par 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é :aie:
Oh pardon, je n'avais pas compris.Citation:
Envoyé par Alexandre T
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)
Ça existe encore mais ça se fait désormais en CSS. On appelle ça "Grid Layout". :P :aie:Citation:
Envoyé par Alexandre T
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 .