Posté par Stinouff .
Évalué à 4.
Dernière modification le 03 février 2021 à 06:24.
Je ne suis pas vraiment d'accord ;
Je trouve les usages tout aussi frustrants aujourd'hui qu'avant. Il m'arrive d'être bloqué par un script, d'être bloqué parce que je bloque un script (!), il m'arrive de devoir changer de navigateur (notamment sur smartphone mais pas que), il m'arrive souvent d'être paumé sur une page avec le nombre d'informations dont elle regorge, je me perds aussi dans les dates (le nombre d'informations obsolètes est dingue), il m'arrive toujours de changer de moteur de recherche et forcément, mon temps de patience s'est drastiquement réduit…
Bref, je trouve que tout ça, ça a changé, mais qu'au fond, je suis la même personne devant. :p
Je développe une application Web, dont une partie du backend est en Javascript, sur Node.js. Je veux déployer ça avec des RPMs, parce que je suis un vieux croûtons, et parce que mes machines n'ont pas accès à Internet. Elles sont 200 et plus, parfois sur des lignes ADSL.
Voilà la recommendation qu'on m'a faite : https://github.com/kelektiv/node.bcrypt.js/issues/573#issuecomment-771660008
@Glandos If your deployment is an RPM, just copy the node_modules folder verbatim.
Pour tous ceux qui ont déjà fait ça, un node_modules/, c'est 500Mo. On me demande explicitement de faire un transfert de 500Mo (en xz, 30Mo) juste parce que tout le monde a une bande passante grosse comme… comme… enfin, très grosse ?
Allons bon.
(Au final, j'ai fait du webpack, mon RPM fait 2Mo, il est autonome ;) )
Ce n'est pas si surprenant… personnellement, je ne pense pas que «les développeurs web» en aient quoique ce soit à cirer du côté système ou de la maintenance. On parle du web la, la pile de technologies qui:
est si mouvante que même Debian met à jour Firefox tous les 3 mois (ou un truc du genre) rompant de ce fait la promesse d'un système stable.
est si complexe que seuls 3 groupes, dont 2 ont une base de code ayant la même origine, sont encore capables de développer un moteur de rendu «standard»
pour être moderne se doit d'utiliser JS pour un stupide lien de type ancre (dans la même page). En fait, pour n'importe quel type de lien… exécuter du script au lieu d'utiliser le mécanisme standard, parce que seul le web mérite d'utiliser les ressources systèmes!
Quand on bosse pas à plein temps dedans c'est vrai que ça à tendance à bouger un peu trop. Quand je déploie une application web et que j'y reviens 6 mois après, tout à changé. Tu as désormais 4/5 versions de retard sur le framework sur lequel tu te base. Tout fonctionne encore mais bon tu te dis qu'il faudrait mieux upgrader aujourd'hui que d'attente encore. Et forcément il y a pas mal de choses à adapter pour éviter tout ces warnings de dépréciation dans tout les sens…. Et ça te prends au moins 3 jours….
Au moins 3 jours tous les 6 mois, juste pour monter la version… je t'avoues que la, ça semble raisonnable… tant qu'il n'y a qu'un seul projet, du moins.
J'ose espérer que cette maintenance corrige plus de bugs qu'elle n'en ajoute?
Ah, désolé, je suis en retard, c'était hier vendredi :)
En fait, la vraie question, c'est pas "combien de jours de maintenance tous les combien de mois", parce que ça, ça ne parle pas tant que ça.
Il faudrait en fait ajouter le temps nécessaire pour accomplir la tâche initiale, parce que ça permettrait d'avoir une estimation du coût de maintenance du projet, sur le long terme.
Si le coût de maintenance est trop élevé, ce qui ne me surprendrai vraiment pas, il est alors logique de jeter à la poubelle son site tous les 2 ans.
Quand un logiciel plus «traditionnel» fait ça, le comportement des utilisateurs est tout sauf tendre: gnome a reçu pas mal de reproches à cause de ça, il me semble.
Disons que tu ne mets pas à jour pour mettre à jour. Ça fonctionne bien, il n'y a pas de problème particulier, tu retournes sur le projet pour ajouter une fonctionnalité et tu te dis qu'il vaut mieux mettre à jour tant que ça doit bien se passer plutôt que lorsque tu as plusieurs versions majeures de retard. Mais les 3 jours pour la mise à niveau c'est en plus du travail initialement prévu. Sur d'autres types de projets il n'y a rien à faire, juste upgrader les dépendances et tout roule.
Ok on a des sites plein de JS qui mettent plusieurs secondes à charger mais c’est à comparer à avant où la moindre page quasi vide se chargeait en plus de temps que ça.
Avant, le délai était énormément lié au temps de transfert. Forcément, avec une liaison 56K… mais ça, c'est lié au réseau.
De nos jours, les sites sont lents, mais il arrive souvent que le problème soit le CPU, et ça, ben, c'est lié au site.
C’est la même chose côté compatibilité.
Ok aujourd’hui on a parfois des choses qui ne passent qu’avec Chrome mais avant c’était tout le web qui était dans une guerre de tranchée.
Ouai. Aujourd'hui, c'est apple vs google vs mozilla, principalement.
Avant, c'était microsoft vs netscape (mozilla).
Ah… oups en fait?
Aujourd’hui je ne me pose quasiment plus la question du navigateur. Je sais que ça va fonctionner.
Chez moi ça marche (tm). Ben chez moi ça marche pas, marque de merde! Certains sites marchent sous FF, d'autres sous chrome, la plupart sur les deux.
Ce n’était pas non plus plus utilisable.
Les exemples mis en avant sont valides, pour le coup. Mais j'ai quand même un contre-exemple: ouvrir un lien dans un nouvel onglet. Plus possible: le lien, c'est du JS.
On s’est amélioré sur tous les points, sans exception. Le pire d’aujourd’hui est objectivement souvent meilleur que le meilleur de l’époque.
hum… pour de simples sites web, sans vidéo, on est obligés de migrer l'infra vers la fibre ou la 5g, a cause de l'abus d'images (bien souvent qui n'apportent strictement rien).
Ce n'est pas un progrès. Ce n'est, certes, pas lié au web en soit, mais à son usage par les développeurs…
En fait une partie des applications web
Je crois que le problème, il est la. Ici. Sur le mot applications. On a voulu faire du web un système d'exploitation, littéralement. Je doute fort que ça soit adapté par exemple aux blogs.
L'accumulation de technos et autres hacks fait qu'il est impossible d'écrire un client propre et 100% fonctionnel (dillo, netsurf essaient, mais rien que les CSS cassent de partout, JS n'est pas supporté) alors que le web se voulait décentralisé (hyper-liens) on se retrouve avec une poignée de moteurs de rendu développés de façon hyper centralisée.
Les développeurs de site, eux, utilisent la plupart du temps des frameworks pour masquer le bordel et les problèmes de compat, ce qui ne risque pas de rendre la chose plus légère…
C’est juste que les compromis et les équilibres ne pointent pas si souvent que ça dans cette direction.
Bien d'accord. Et c'est peut-être un des problèmes, justement.
Prétendre faire un nouveau web qui forcerait ce choix ne serait pas une avancée, ce serait une forte régression.
Non. Ce serait une avancée.
Parce que le «nouveau web» serait spécialisé et meilleur dans son domaine. Tout comme le web actuel est spécialisé dans les applications interactives, rendant la création d'un blog sous-optimale. Le web d'avant permettait à un ado de faire son propre site web en 3 coups de cuillères à pot.
Aujourd'hui, c'est difficilement faisable sans utiliser une pile logicielle extrêmement lourde, pour un rendu final potentiellement identique (parce que bon, le classique titre+menu-a-gauche+contenu, ça reste plutôt efficace).
Aujourd'hui, c'est difficilement faisable sans utiliser une pile logicielle extrêmement lourde, pour un rendu final potentiellement identique (parce que bon, le classique titre+menu-a-gauche+contenu, ça reste plutôt efficace).
Firefox, Chrome et consorts ne t'empêchent absolument pas de faire un site avec zero div, img et script.
Et faire un site e-commerce avec gemini, bonne chance.
Ah mais tu es minimaliste, décroissant, tu n'achètes plus rien.
Retourne à l'épistolaire alors. Parce que ton flux TLS (sic!) Gemini de 34ko passe au travers d'une chier de matériels énergivores redondants et ça, c'est pas bon pour les ours polaires.
Est-ce que je suis pro-JS pour autant, certainement pas mais il reste possible de faire les choses biens.
D'accord, donc tu mets des mots ensemble sans comprendre que le rendu final peut être insultant? Mince, je t'avais surestimé. Désolé. Je recommencerais pas.
# En tant qu'utilisateur, je dirais "bof".
Posté par Stinouff . Évalué à 4. Dernière modification le 03 février 2021 à 06:24.
Je ne suis pas vraiment d'accord ;
Je trouve les usages tout aussi frustrants aujourd'hui qu'avant. Il m'arrive d'être bloqué par un script, d'être bloqué parce que je bloque un script (!), il m'arrive de devoir changer de navigateur (notamment sur smartphone mais pas que), il m'arrive souvent d'être paumé sur une page avec le nombre d'informations dont elle regorge, je me perds aussi dans les dates (le nombre d'informations obsolètes est dingue), il m'arrive toujours de changer de moteur de recherche et forcément, mon temps de patience s'est drastiquement réduit…
Bref, je trouve que tout ça, ça a changé, mais qu'au fond, je suis la même personne devant. :p
# L'écosystème n'est pas du tout économe.
Posté par Glandos . Évalué à 7.
Je développe une application Web, dont une partie du backend est en Javascript, sur Node.js. Je veux déployer ça avec des RPMs, parce que je suis un vieux croûtons, et parce que mes machines n'ont pas accès à Internet. Elles sont 200 et plus, parfois sur des lignes ADSL.
Voilà la recommendation qu'on m'a faite : https://github.com/kelektiv/node.bcrypt.js/issues/573#issuecomment-771660008
Pour tous ceux qui ont déjà fait ça, un
node_modules/, c'est 500Mo. On me demande explicitement de faire un transfert de 500Mo (en xz, 30Mo) juste parce que tout le monde a une bande passante grosse comme… comme… enfin, très grosse ?Allons bon.
(Au final, j'ai fait du webpack, mon RPM fait 2Mo, il est autonome ;) )
[^] # Re: L'écosystème n'est pas du tout économe.
Posté par freem . Évalué à 8.
Ce n'est pas si surprenant… personnellement, je ne pense pas que «les développeurs web» en aient quoique ce soit à cirer du côté système ou de la maintenance. On parle du web la, la pile de technologies qui:
[^] # Re: L'écosystème n'est pas du tout économe.
Posté par ff9097 . Évalué à 3.
Quand on bosse pas à plein temps dedans c'est vrai que ça à tendance à bouger un peu trop. Quand je déploie une application web et que j'y reviens 6 mois après, tout à changé. Tu as désormais 4/5 versions de retard sur le framework sur lequel tu te base. Tout fonctionne encore mais bon tu te dis qu'il faudrait mieux upgrader aujourd'hui que d'attente encore. Et forcément il y a pas mal de choses à adapter pour éviter tout ces warnings de dépréciation dans tout les sens…. Et ça te prends au moins 3 jours….
[^] # Re: L'écosystème n'est pas du tout économe.
Posté par freem . Évalué à 2.
Au moins 3 jours tous les 6 mois, juste pour monter la version… je t'avoues que la, ça semble raisonnable… tant qu'il n'y a qu'un seul projet, du moins.
J'ose espérer que cette maintenance corrige plus de bugs qu'elle n'en ajoute?
Ah, désolé, je suis en retard, c'était hier vendredi :)
En fait, la vraie question, c'est pas "combien de jours de maintenance tous les combien de mois", parce que ça, ça ne parle pas tant que ça.
Il faudrait en fait ajouter le temps nécessaire pour accomplir la tâche initiale, parce que ça permettrait d'avoir une estimation du coût de maintenance du projet, sur le long terme.
Si le coût de maintenance est trop élevé, ce qui ne me surprendrai vraiment pas, il est alors logique de jeter à la poubelle son site tous les 2 ans.
Quand un logiciel plus «traditionnel» fait ça, le comportement des utilisateurs est tout sauf tendre: gnome a reçu pas mal de reproches à cause de ça, il me semble.
[^] # Re: L'écosystème n'est pas du tout économe.
Posté par ff9097 . Évalué à 1.
Disons que tu ne mets pas à jour pour mettre à jour. Ça fonctionne bien, il n'y a pas de problème particulier, tu retournes sur le projet pour ajouter une fonctionnalité et tu te dis qu'il vaut mieux mettre à jour tant que ça doit bien se passer plutôt que lorsque tu as plusieurs versions majeures de retard. Mais les 3 jours pour la mise à niveau c'est en plus du travail initialement prévu. Sur d'autres types de projets il n'y a rien à faire, juste upgrader les dépendances et tout roule.
# Quand on confond problèmes du web et problèmes du net...
Posté par freem . Évalué à 9.
Je cite:
Avant, le délai était énormément lié au temps de transfert. Forcément, avec une liaison 56K… mais ça, c'est lié au réseau.
De nos jours, les sites sont lents, mais il arrive souvent que le problème soit le CPU, et ça, ben, c'est lié au site.
Ouai. Aujourd'hui, c'est apple vs google vs mozilla, principalement.
Avant, c'était microsoft vs netscape (mozilla).
Ah… oups en fait?
Chez moi ça marche (tm). Ben chez moi ça marche pas, marque de merde! Certains sites marchent sous FF, d'autres sous chrome, la plupart sur les deux.
Les exemples mis en avant sont valides, pour le coup. Mais j'ai quand même un contre-exemple: ouvrir un lien dans un nouvel onglet. Plus possible: le lien, c'est du JS.
hum… pour de simples sites web, sans vidéo, on est obligés de migrer l'infra vers la fibre ou la 5g, a cause de l'abus d'images (bien souvent qui n'apportent strictement rien).
Ce n'est pas un progrès. Ce n'est, certes, pas lié au web en soit, mais à son usage par les développeurs…
Je crois que le problème, il est la. Ici. Sur le mot applications. On a voulu faire du web un système d'exploitation, littéralement. Je doute fort que ça soit adapté par exemple aux blogs.
L'accumulation de technos et autres hacks fait qu'il est impossible d'écrire un client propre et 100% fonctionnel (dillo, netsurf essaient, mais rien que les CSS cassent de partout, JS n'est pas supporté) alors que le web se voulait décentralisé (hyper-liens) on se retrouve avec une poignée de moteurs de rendu développés de façon hyper centralisée.
Les développeurs de site, eux, utilisent la plupart du temps des frameworks pour masquer le bordel et les problèmes de compat, ce qui ne risque pas de rendre la chose plus légère…
Bien d'accord. Et c'est peut-être un des problèmes, justement.
Non. Ce serait une avancée.
Parce que le «nouveau web» serait spécialisé et meilleur dans son domaine. Tout comme le web actuel est spécialisé dans les applications interactives, rendant la création d'un blog sous-optimale. Le web d'avant permettait à un ado de faire son propre site web en 3 coups de cuillères à pot.
Aujourd'hui, c'est difficilement faisable sans utiliser une pile logicielle extrêmement lourde, pour un rendu final potentiellement identique (parce que bon, le classique titre+menu-a-gauche+contenu, ça reste plutôt efficace).
[^] # Re: Quand on confond problèmes du web et problèmes du net...
Posté par Gilet_sans_manches . Évalué à -10.
Firefox, Chrome et consorts ne t'empêchent absolument pas de faire un site avec zero div, img et script.
Et faire un site e-commerce avec gemini, bonne chance.
Ah mais tu es minimaliste, décroissant, tu n'achètes plus rien.
Retourne à l'épistolaire alors. Parce que ton flux TLS (sic!) Gemini de 34ko passe au travers d'une chier de matériels énergivores redondants et ça, c'est pas bon pour les ours polaires.
Est-ce que je suis pro-JS pour autant, certainement pas mais il reste possible de faire les choses biens.
[^] # Re: Quand on confond problèmes du web et problèmes du net...
Posté par freem . Évalué à 4.
Tu devrais apprendre à lire, et à réfléchir avant d'essayer d'insulter.
[^] # Re: Quand on confond problèmes du web et problèmes du net...
Posté par Gilet_sans_manches . Évalué à -10.
Alors je suis curieux, où est l'insulte ?
[^] # Re: Quand on confond problèmes du web et problèmes du net...
Posté par freem . Évalué à 3.
D'accord, donc tu mets des mots ensemble sans comprendre que le rendu final peut être insultant? Mince, je t'avais surestimé. Désolé. Je recommencerais pas.
# Pas mon web
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Les bons sites sont toujours bons, les mauvais sites sont de plus en plus mauvais.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.