Re: Le rapport?

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.