• # 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://flowg.cloud - https://krouter.cloud

        • [^] # 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://flowg.cloud - https://krouter.cloud

            • [^] # 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.