• # Le rapport?

    Posté par  (site web personnel) . Évalué à 3. Dernière modification le 30 mai 2022 à 15:37.

    ça parle de JS en mal, mais tout ce qui est écrit marche aussi pour des images (vous avez pensé au format utilisé? le nouveau format ne passe pas sur les anciens navigateurs, et les aveugles…).
    Perso le JS est sur le même serveur et tout en HTTPS donc (quasi?) rien de ce qui est décrit n'est valide, ça tape plutôt sur HTTP, les CDN et le JS non accessible (et on peut faire du JS accessible).
    Bof, soit j'ai loupé un épisode soit ça ne convaincra que les convaincus.

    • [^] # Re: Le rapport?

      Posté par  . Évalué à 2.

      Non, ça plaide pour prévoir le cas où le JS n'est pas accessible, parce que ça arrivera et ne consernera pas que les 5 pelos qui désactivent le JS.

      • [^] # Re: Le rapport?

        Posté par  (site web personnel) . Évalué à 6.

        Faut apprendre Ă  lire.

        ça plaide pour prévoir le cas où le JS n'est pas accessible

        vs

        ça tape plutôt sur HTTP, les CDN et le JS non accessible

        Vous dites la mĂŞme chose.

        parce que ça arrivera et ne consernera pas que les 5 pelos qui désactivent le JS

        Oui l'article parle cependant de bien d'autres choses que l'accessibilité du JS, donc :

        Perso le JS est sur le même serveur et tout en HTTPS donc (quasi?) rien de ce qui est décrit n'est valide

        Cette proposition est toujours valable, surtout lorsqu'elle commence par "Perso" qui démontre une expérience personnelle (certes anecdotique, mais néanmoins existante)

        Et tu oublis l'essence mĂŞme du commentaire Ă  la base :

        tout ce qui est Ă©crit marche aussi pour des images

        Ce qui est 200% vrai.


        Ah c'est facile de commencer un commentaire par "Non" et ensuite de montrer qu'on a rien compris :)

        https://link-society.com - https://kubirds.com

        • [^] # Re: Le rapport?

          Posté par  (site web personnel) . Évalué à 1.

          Je n'avais pas osé lui rentrer dedans, un autre s'en ai chargé, ça fait plaisir.

        • [^] # Re: Le rapport?

          Posté par  . Évalué à 2. Dernière modification le 01 juin 2022 à 03:14.

          ça plaide pour prévoir le cas où le JS n'est pas accessible

          vs

          ça tape plutôt sur HTTP, les CDN et le JS non accessible

          Vous dites la mĂŞme chose.

          Ben, plus ou moins quand même. Ou alors je n'ai pas compris ce que Z. voulait dire… Pour moi, Z. critique le schéma en disant que l'auteur tape sur l'ecosystème en voulant critiquer le JS… moi j'y lis un plaidoyer pour concevoir les pages pour les cas où ça foire…

          Je pense que l'article est mieux mis en perspective en le reliant à cette page (citée en fin d'article) :
          https://kryogenix.org/code/browser/why-availability/

          Perso le JS est sur le même serveur et tout en HTTPS donc (quasi?) rien de ce qui est décrit n'est valide

          Cette proposition est toujours valable, surtout lorsqu'elle commence par "Perso" qui démontre une expérience personnelle (certes anecdotique, mais néanmoins existante)

          Ben non, justement, cette phrase en particulier me semble fausse… Parce que ta page avec son JS, elle va être chargée en 2 requêtes, que la connexion, elle peut couper entre les 2, que ton utilisateur peut toujours être derrière un firewall foireux, avoir une extension merdique, etc. En fait, le seul truc que ça enlève dans la liste, c'est le CDN qui tombe.

          Et tu oublis l'essence mĂŞme du commentaire Ă  la base :

          tout ce qui est Ă©crit marche aussi pour des images

          Ce qui est 200% vrai.

          Je ne vois pas en quoi le fait que ce soit valide aussi pour les images enlève de la pertinence au propos sur le JS… voir même au contraire : il y a une quinzaine d'années, il y avait eu un mouvement pour généraliser l'utilisation de l'attribut "alt" pour rendre les pages plus accessibles… Et les pages composées uniquement d'images sont considérées comme une mauvaise pratique alors qu'elles étaient monaie courante dans les années 2000.

          Enfin, je ne suis pas sûr qu'il n'y a pas besoin de me "rentrer dedans", on pourrait envisager de débattre avec moins de violence…

          • [^] # Re: Le rapport?

            Posté par  (site web personnel) . Évalué à 2. Dernière modification le 01 juin 2022 à 04:15.

            Parce que ta page avec son JS, elle va être chargée en 2 requêtes, que la connexion, elle peut couper entre les 2

            Pareil que pour le CSS, les images, et autres resources donc. Bienvenue dans l'hypermedia, ça existe depuis les années 1990.

            que ton utilisateur peut toujours être derrière un firewall foireux

            Si toutes les ressources sont sur le même domaine, comme le décrit la phrase de Zenitram qui tu critiques, le firewall ne bloquera pas les resources si il autorise le site internet.

            avoir une extension merdique, etc.

            Shit in, shit out.

            Je ne vois pas en quoi le fait que ce soit valide aussi pour les images enlève de la pertinence au propos sur le JS…

            Si le but de l'article n'est pas de râler pour râler, mais de sensibiliser à l'accessibilité d'un site web. TOUTES les resources chargées de façon asynchrone risque d'impacter cette accessibilité. Se concentrer sur le JS c'est donc du troll histoire de.

            Quote du site :

            “All your users are non-JS while they're downloading your JS” — Jake Archibald

            Je rajouterai donc :

            • All your users are not users while they're downloading your HTML
            • All your users are CLI while they're downloading your CSS
            • All your users are Text Mode while they're downloading your images

            Et je conclurai par quelques notions :

            • l'en-tĂŞte Keep-Alive permet de rĂ©utiliser la mĂŞme connexion au lieu d'en recrĂ©er une nouvelle Ă  chaque fois, c'est très utilisĂ© par les navigateurs web
            • la mise en cache des resources annexes d'un document hypermĂ©dia est aussi une pratique courante rĂ©duisant l'impact des 3/4 des problèmes mentionnĂ©s par l'article
            • HTTP 2 et le futur HTTP 3 vont aussi rĂ©gler pas mal de ces problèmes
            • …

            Enfin, je ne suis pas sûr qu'il n'y a pas besoin de me "rentrer dedans", on pourrait envisager de
            débattre avec moins de violence…

            Quoi ? De la communication non-violente sur LinuxFR ? Mais ou vas le monde…

            Plus sérieusement, si tu veux de la communication non violente, évite de commencer tes commentaires par un "Non" catégorique qui ne signifie que "Tu as tort, j'ai raison, je n'ai même pas besoin de développer, mais je vais le faire quand même".

            Aller je termine avec un trait d'humour. On design comment un site pour les utilisateurs qui ont cassé leur écran ?

            https://link-society.com - https://kubirds.com

            • [^] # Re: Le rapport?

              Posté par  . Évalué à 6.

              Aller je termine avec un trait d'humour. On design comment un site pour les utilisateurs qui ont cassé leur écran ?

              <audio autoplay src="/media/change-d-ecran.mp3"></audio>
              

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: Le rapport?

              Posté par  (site web personnel) . Évalué à 6. Dernière modification le 01 juin 2022 à 09:32.

              Enfin, je ne suis pas sûr qu'il n'y a pas besoin de me "rentrer dedans", on pourrait envisager de débattre avec moins de violence…

              Aller je termine avec un trait d'humour.

              Notez qu'on peut « lui rentrer dedans » avec amour et sans violence, hein.

              Adhérer à l'April, ça vous tente ?

              • [^] # Re: Le rapport?

                Posté par  . Évalué à 9.

                Seulement si les deux partis sont consentants.

                La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.

                • [^] # Re: Le rapport?

                  Posté par  . Évalué à 3.

                  Je ne peut te pertiner qu'une seule fois, mais j'adore cette blague

                  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

            • [^] # Re: Le rapport?

              Posté par  . Évalué à 3. Dernière modification le 06 juin 2022 à 17:30.

              Si le but de l'article n'est pas de râler pour râler, mais de sensibiliser à l'accessibilité d'un site web. TOUTES les resources chargées de façon asynchrone risque d'impacter cette accessibilité. Se concentrer sur le JS c'est donc du troll histoire de.

              Se concentrer sur le JS c'est surtout un moyen de dénoncer les abus en cours. Oui il y a eu des abus d'images et on en est revenu (enfin je crois). Maintenant c'est FrameworkJS partout, tout le temps, et site qui va totalement planter si le téléchargement du JS n'aboutit pas. À côté, on a les CSS qui font généralement moins de la moitié du poids du JS d'une page. Et des images indépendantes dont le non-affichage va rarement remettre en cause le fonctionnement du site. Un exemple au hasard, trouvé sur MadeWithVueJS.com : https://restaurantcolibri.ca/fr Je tire 291ko de JS pour 45ko de CSS. En désactivant les CSS et l'affichage des images j'arrive à comprendre l'objet du site, sans le JS je n'ai plus rien.
              Ce qui n'empĂŞche pas de parler des autres ressources, oui. Mais celle qui pose le plus gros soucis en ce moment c'est bien le JS indispensable.

          • [^] # Re: Le rapport?

            Posté par  (site web personnel) . Évalué à 3. Dernière modification le 01 juin 2022 à 08:14.

            Parce que ta page avec son JS, elle va être chargée en 2 requêtes,

            Pour info, tu peux mettre le JS dans la page HTML. Comme le CSS aussi.
            Bon, en vrai on a HTTP Keep-alive et HTTP2.

            elle peut couper entre les 2

            Pense aussi au cas où ton .html n'est pas chargé en entier alors. Ca commence à devenir compliqué…

            que ton utilisateur peut toujours être derrière un firewall foireux,

            Le firewall ne peut pas voir ça, c'est en HTTPS et la même connexion. Si CDN, c'est pas un problème de JS mais de CDN.
            Mais en fait en vrai la dispo des CDN est très bonne, perso je n'aime pas cette dépendance et fait tout sur le même serveur par principe (plus sur la vie privée et le contrôle) mais je comprend pourquoi les CDN plaisent (du coup je fais un entre deux : mon HTML est aussi sur un mini CDN que j'ai grace à des VPS pas chers pour profiter de la réactivité proche des gens).

            avoir une extension merdique, etc.

            Pense aussi aux extensions merdiques qui virent du HTML alors. Ca commence à devenir compliqué…

            Je pense que l'article est mieux mis en perspective en le reliant à cette page (citée en fin d'article) :

            Je l'avais vu aussi. Et déjà répondu (indice : images, CSS… ça parle de CDN, pas de JS).
            Et en pratique les gens sont assez intéressés pour quand ça arrive rechargent la page.
            Ca me rappelle la gueguerre des "téléphonistes" dans les années 2000 qui hurlaient à la qualité pourrie des "Internetistes", les premiers cherchant 99.99% de qualité même si prix élevé alors que les seconds acceptaient 99% pour 10x moins cher, spoileur les premiers ont perdu cette guerre (et j'étais aux premières loges dans mon travail la dessus).
            Voir aussi ATM contre Ethernet (spoileur : ATM qui cherchait la qualité a disparu quand Ethernet "pourri" a gagné; j'ai étudié ATM à l'école, c'était le futur… Ils ont juste oublié le prix et du coup Ethernet "de mauvaise qualité qui fait fuir les utilisateurs" a pris le dessus partout; ATM reste à peine sur la couche basse ADSL… remplacé par Ethernet en fibre optique).
            Des exemple comme ça on peut en citer des centaines dans la vie réelle aussi, combien de boites ont coulé pour ne pas avoir compris que ton lien est théorique mais que la pratique est très différente.
            Ca marche aussi dans le logiciel, où des gens essayent de corriger un bug qui touche 0.01% des gens qui râlent mais du coup laisse la concurrence garder des bugs mais offrir plus aux gens, et les gens se barrent car le logiciel sans bug est juste pas assez intéressant en réalité.

            Dans la réalité il y a une limite "oubliée" dans le lien que tu recopies, le coût et la praticité : la disponibilité à 100% et la qualité parfaite ont un coût. Il faut donc trouver le juste milieu entre coût et départ des gens supérieur à l'arrivée des gens plutôt que de chercher à retenir tout le monde.

            Enfin, je ne suis pas sûr qu'il n'y a pas besoin de me "rentrer dedans", on pourrait envisager de débattre avec moins de violence…

            OK. Commence donc à lire et répondre avec des arguments (et pas juste "non") à la personne à laquelle tu réponds plutôt que taper à côté. Tes exemples sont rigolos, ils partent du principe que la code HTML sera chargé en entier. Sérieux, à partir du moment où tu n'arrives pas à charger un .js sur ton serveur, tu peux te dire que le problème n'est pas du tout le JS mais ton serveur en entier, si le .js merde alors le .html pourra aussi et te focaliser sur le cas où le .js merde ne changera absolument rien à 99.99% de tes utilisateurs (et le 0.01% restant, celui qui bloque JS, restera le même, on s'en fout complet).

            Et zut, je suis rentré dedans. Bon, je pense qu'on a fait le tour (et je ne suis pas le seul à t'avoir répondu sur là où ça coince dans ton raisonnement, mais tu n'as pas voulu essayer de comprendre), je te laisse à chercher la qualité à tout prix et gérer des "fallback" de cas théoriques… Je parie que tu n'auras pas beaucoup de visiteurs, faute de temps à consacrer au contenu donc personne qui s’intéresse.

      • [^] # Re: Le rapport?

        Posté par  (site web personnel, Mastodon) . Évalué à 1.

        Toute façon, un site qui ne peut pas s'afficher sans JS est conceptuellement foireux de base car comparable aux trucs flash… Mas bon tant qu'il ya des conssomateurs

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.