[MàJ] Le protocole HTTP/2 a désormais son document RFC

[MàJ] Le protocole HTTP/2 a désormais son document RFC

Direction le RFC Editor

Avatar de l'auteur
Vincent Hermann

Publié dans

Internet

15/05/2015 3 minutes
53

[MàJ] Le protocole HTTP/2 a désormais son document RFC

Le futur standard HTTP/2 est désormais finalisé. L’annonce vient d’en être faite ce matin par le président du HTTP Working Group au sein de l’IETF, Mark Nottingham. Prochaine étape désormais, la publication sous la forme d’un standard via un document RFC.

HTTP n’a pas bénéficié de révision majeure depuis 1999, quand la version 1.1 a été publiée. Au rythme où les technologies du web progressent, un successeur était très attendu et les problématiques très nombreuses. Comme on le sait, le futur HTTP/2 est bâti sur les fondations de la technologie SPDY, et en dépit de quelques critiques, le travail réalisé a fait consensus.

Depuis ce matin, on sait que le futur standard est finalisé, ce qui se traduit par une liste précise de caractéristiques. Dans sa forme actuelle, le protocole est donc largement basé sur SPDY, tout en gommant certains de ses défauts et en ajoutant d’autres capacités. HTTP/2 a pour objectif majeur d’accélérer le chargement des pages web et de sécuriser davantage les connexions, deux problématiques qui deviennent d’autant plus importantes que les ressources web sont très largement utilisées.

Du côté des performances, la caractéristique principale du protocole est le multiplexage des requêtes, autrement dit l’envoi par lots. Le serveur les reçoit donc toutes en même temps et peut procéder à l’envoi simultané des données, contrairement à la situation actuelle où de nombreux éléments doivent attendre que d’autres soient chargés. Les connexions « live » avec les serveurs pourront en outre être maintenues plus longtemps et le chiffrement sera une part importante des nouveautés.

Avec HTTP/2 viennent donc les promesses de connexions plus rapides et mieux sécurisées, mais il faudra encore attendre. Comme indiqué par Mark Nottingham de l'Internet Engineering Task Force ce matin, le protocole est maintenant en route vers le RFC Editor et ses différents documents devraient donc recevoir des numéros officiels d’attribution très prochainement.

Précisons que même si HTTP/2 n’est pas encore à proprement parler un standard, son inclusion est actuellement en travaux dans la plupart des navigateurs. C‘est le cas notamment chez Google avec Chrome 40, la firme ayant récemment annoncé que SPDY serait abandonné dans les prochaines semaines, son existence n’ayant plus lieu d’être.

53

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Commentaires (53)


Coté serveur ça se passe comment ?


Il faudra attendre que les serveurs web le supportent ;)


Il y a d’ailleurs une extension sur Firefox qui permet de savoir si un site (ou des ressources externes de celui-ci) utilise SPDY ou HTTP/2.0.


Microsoft a officiellement annoncé son support aux Techdays (avec project spartan).


Tiens, ça sera l’occasion de rajouter des codes de réponses adaptés au chats dans un RFC du 1er avril <img data-src=" />


C’est bien de corriger les problèmes. Dommage que ca se termine toujours par faire du “en plus” au lieu de “en mieux”.



Davantage de complexité dans le protocole =&gt; Davantage de failles potentielle dans les implémentations.

Sans compter les problème d’interopérabilité au début (Chrome vs Apache, Firefox vs IIS, …).



Enfin bon, il reste du temps avant la généralisation de HTTP/2 over IPv6. <img data-src=" />


Très intéressante cette actu … <img data-src=" />



&gt;contrairement à la situation actuelle où de nombreux

&gt;éléments doivent attendre que d’autres soient chargés.



Ca me fait penser aux régies publicitaires qui lorsqu’elles ne sont pas accessibles font ramer toute la page web.



Heureusement, on a optimisé notre site web et nous n’avons plus le problème à présent !








Vekin a écrit :



Il y a d’ailleurs une extension sur Firefox qui permet de savoir si un site (ou des ressources externes de celui-ci) utilise SPDY ou HTTP/2.0.







Marchi pour le lien <img data-src=" />









FRANCKYIV a écrit :



Très intéressante cette actu … <img data-src=" />



&gt;contrairement à la situation actuelle où de nombreux

&gt;éléments doivent attendre que d’autres soient chargés.



Ca me fait penser aux régies publicitaires qui lorsqu’elles ne sont pas accessibles font ramer toute la page web.



Heureusement, on a optimisé notre site web et nous n’avons plus le problème à présent !





Je pensais à la même chose <img data-src=" />. Une des raisons qui peuvent pousser à utiliser un bloquer de pubs …









FRANCKYIV a écrit :



Ca me fait penser aux régies publicitaires qui lorsqu’elles ne sont pas accessibles font ramer toute la page web.







Oui, mais non.



Si la page “rame” c’est que, d’une manière ou d’une autre, elle attend les données de la pub pour s’afficher. Et ca sera toujours le cas en HTTP/2.



Les pubs sont servies par un serveur différent, donc le client créera une connexion TCP/IP dédiee vers ce serveur et attendra la réponse (idem qu’en HTTP/1).



La différence c’est qu’en HTTP/2 le client crée une seule connexion par serveur (au lieu de une connexion par “objet” demandé). Donc si ta page rame a cause d’une limitation du nb de connexion gérée par le client, tu auras un gain. Mais tu peux déjà avoir ce gain en augmentant la limite de connexion de ton client web.









127.0.0.1 a écrit :



Oui, mais non.



Si la page “rame” c’est que, d’une manière ou d’une autre, elle attend les données de la pub pour s’afficher. Et ca sera toujours le cas en HTTP/2.



Les pubs sont servies par un serveur différent, donc le client créera une connexion TCP/IP dédiee vers ce serveur et attendra la réponse.







As-tu lu ma deuxième phrase ?



Oui, j’ai bien vu que le problème a été corrigé sans avoir eu besoin de HTTP/2.



Mon point c’est de préciser que HTTP/2 n’aurait de toutes façons pas réglé vraiment ce problème particulier.








127.0.0.1 a écrit :



Oui, j’ai bien vu que le problème a été corrigé sans avoir eu besoin de HTTP/2.



Mon point c’est de préciser que HTTP/2 n’aurait de toutes façons pas réglé vraiment ce problème particulier.







<img data-src=" />



Tu dois bien pourvoir les fusionner et minifier, non ?








kras a écrit :



Spéciale dédicasse aux Wordpressiens, continuez à mettre une dizaine de CSS

et de JS dans le

On vous

aime les gars ! Même le HTTP/3 ne pourra rien pour vous.





Je n’utilise pas wordpress mais … il y a un inconvénient à séparer ces CSS et JS en plusieurs fichiers ?

(une dizaine semble trop selon toi)



Cela ralentit la page puisque il faut faire 10 requêtes au lieu de 2 (un JS, un CSS).


ça se passe comment quand il y a un proxy ?








jeffk_ a écrit :



Coté serveur ça se passe comment ?







Même question



Le proxy devra savoir décompresser et lire les Headers HTTP/2. Sinon, pas de changement dans le principe: le proxy redirige les requêtes/réponses entre le client et le serveur, en servant d’intermédiaire.








127.0.0.1 a écrit :



C’est bien de corriger les problèmes. Dommage que ca se termine toujours par faire du “en plus” au lieu de “en mieux”.



Davantage de complexité dans le protocole =&gt; Davantage de failles potentielle dans les implémentations.

Sans compter les problème d’interopérabilité au début (Chrome vs Apache, Firefox vs IIS, …).



Enfin bon, il reste du temps avant la généralisation de HTTP/2 over IPv6. <img data-src=" />







C exactement mon ressenti… mais je préfère que tout le monde se mette d accord ça fera avancer beaucoup plus vite les choses… car pour les protocoles y a pas de 49-3 :o












iosys a écrit :



je préfère que tout le monde se mette d accord ça fera avancer beaucoup plus vite les choses…





C’est un peu les principes des Working Groups de l’IETF <img data-src=" />









Koxinga22 a écrit :



Je n’utilise pas wordpress mais … il y a un inconvénient à séparer ces CSS et JS en plusieurs fichiers ?

(une dizaine semble trop selon toi)





Pour le dev c’est beaucoup mieux d’avoir des fichiers bien séparés. Ça permet d’avoir une organisation claire et de faciliter le debug.

&nbsp;

Pour la prod il faut toutefois prévoir de les fusionner en un seul fichier et minifier le code. Sinon tu augmentes le temps de téléchargement (fichier plus gros) et pour chaque fichier ton navigateur va faire une requête : demande du fichier…attente de la réponse du serveur…téléchargement du fichier…



Pour te faire une idée, si tu utilises Firefox tu vas sur un site tu fais ctrl + shit + i et tu vas dans l’onglet “network” Tu recharge la page et il va te montrer tout les fichier télécharger et le temps de chargement. Si tu regardes le Timing pour chaque fichier tu as souvent par exemple un temps d’attente ou le navigateur attente la réponse du serveur. C’est souvent court mais si tu multiplies par 20 fichiers ça peu facilement représenter plusieurs secondes.









seb2411 a écrit :



Pour le dev c’est beaucoup mieux d’avoir des fichiers bien séparés. Ça permet d’avoir une organisation claire et de faciliter le debug.

 

Pour la prod il faut toutefois prévoir de les fusionner en un seul fichier et minifier le code. Sinon tu augmentes le temps de téléchargement (fichier plus gros) et pour chaque fichier ton navigateur va faire une requête : demande du fichier…attente de la réponse du serveur…téléchargement du fichier…



Pour te faire une idée, si tu utilises Firefox tu vas sur un site tu fais ctrl + shit + i et tu vas dans l’onglet “network” Tu recharge la page et il va te montrer tout les fichier télécharger et le temps de chargement. Si tu regardes le Timing pour chaque fichier tu as souvent par exemple un temps d’attente ou le navigateur attente la réponse du serveur. C’est souvent court mais si tu multiplies par 20 fichiers ça peu facilement représenter plusieurs secondes.





Je préfère Firebug, l’onglet network du module de debug par defaut de FF n’est ni pratique ni ergonomique.

Mais donc, c’est “juste” le temps de chargement des fichiers qui fait tiquer ? parce qu’au final, ca ne change pas grand chose d’avoir un js de 1000 lignes ou 10 js de 100 lignes, la différence se compte en millisecondes.

Et une fois les fichiers chargés en cache, il n’y a plus d’appels donc cet “inconvénient” de devoir attendre 3 ms ne se produit que lors du premier chargement.



Plutôt bénin comme problème selon moi.

Et très largement compensé par la praticité d’un code modulaire dont on ne charge que les éléments utiles.



Ce n’est pas un problème WordPressien comme tu aimes le dire, c’est une problématique générale au front-end.

Et justement HTTP/2 règlera ce problème, en un seul stream tu pourra charger 100 fichiers d’un seul trait… Enfin si j’ai bien compris.








fgirardey a écrit :



Ce n’est pas un problème WordPressien comme tu aimes le dire, c’est une problématique générale au front-end.

Et justement HTTP/2 règlera ce problème, en un seul stream tu pourra charger 100 fichiers d’un seul trait… Enfin si j’ai bien compris.





Je l’ai compris comme ca aussi….









Koxinga22 a écrit :



Je préfère Firebug, l’onglet network du module de debug par defaut de FF n’est ni pratique ni ergonomique.

Mais donc, c’est “juste” le temps de chargement des fichiers qui fait tiquer ? parce qu’au final, ca ne change pas grand chose d’avoir un js de 1000 lignes ou 10 js de 100 lignes, la différence se compte en millisecondes.

Et une fois les fichiers chargés en cache, il n’y a plus d’appels donc cet “inconvénient” de devoir attendre 3 ms ne se produit que lors du premier chargement.



Plutôt bénin comme problème selon moi.

Et très largement compensé par la praticité d’un code modulaire dont on ne charge que les éléments utiles.





C’est pas bénin car selon ou tu te trouves sur la planète le temps communication avec le serveur peu facilement exploser.

Sur des sites, si tu veux avoir des performances correcte il faut que le site soit chargé en quelques secondes. Par exemple si tu as un objectif de chargement de la page en 3s et que tu as 10 js qui mettent 200ms a charger tu te retrouves déjà a 2 secondes juste pour charger du JS. Si tu fais pareil pour le css tu passes a 4 secondes.



Ca s’appel de l’optimisation. C’est souvent pénalisant en terme de visites que ce soit pour les visites directes ou pour les moteurs de recherches. Apres si tu as un ptit blog perso c’est pas la mort mais pour du professionnel il vaut mieux faire attention.



En gros, il faudrait qu’à la publication, le generateur aille lire tous les js des modules actifs et recopie leur contenu dans un seul js à mettre en prod (les noms de fonctions sont préfixés du nom de module donc pas de conflit à l’horizon)


En 3G ou 4G, le ping est à désiré. Il peut y avoir une latence jusqu’à 200ms avant de commencer le chargement d’un fichier à proprement dit, pour résoudre le DNS, initialiser la nouvelle connection, etc.



Depuis ce type de connection, un site pas spcécialement bien foutu, ça peut dépasser très facilement 6secondes de temps de chargement en plus sur un wordpress pas forcément bien foutu. &nbsp;Ce n’est plus bénin.

&nbsp;

Par ailleurs, (comme dis plus haut)&nbsp;sur un site héberger sur un dédié sans CDN, un visiteur venant d’un pays éloigné, aura aussi ping relativement haut. Même problème que suscité.&nbsp;

&nbsp;







&nbsp;








Koxinga22 a écrit :



En gros, il faudrait qu’à la publication, le generateur aille lire tous les js des modules actifs et recopie leur contenu dans un seul js à mettre en prod (les noms de fonctions sont préfixés du nom de module donc pas de conflit à l’horizon)





Dans ce scénario faudrait mettre le fichier obtenu en cache pour que ce soit “rentable” en terme de performance.



Le cas général aujourd’hui, c’est de “compiler” ton lot de module en un seul JS. Certaines IDE comme webstorm, ou certaines appli comme Codekit https://incident57.com/codekit/ mac only) ou Prerpos https://prepros.io/ win/mac/lin) &nbsp;le font automatiquement dès qu’un fichier du lot est sauvegardé.&nbsp;



Certains outils génère même un JS different pour chaque pages, selon les modules employé, mais demande

&nbsp; quelques pré-requis :&nbsp;browserify.org&nbsp;.









Koxinga22 a écrit :



En gros, il faudrait qu’à la publication, le generateur aille lire tous les js des modules actifs et recopie leur contenu dans un seul js à mettre en prod (les noms de fonctions sont préfixés du nom de module donc pas de conflit à l’horizon)





Oui, normalement pour les framework modernes (genre Symfony en php) ca se gère automatiquement.&nbsp; Pour Wordpress je pense qu’il doit y avoir des plugins mais c’est dommage qu’il gèrent pas ça nativement et proprement.









jun a écrit :



Dans ce scénario faudrait mettre le fichier obtenu en cache pour que ce soit “rentable” en terme de performance.



Le cas général aujourd’hui, c’est de “compiler” ton lot de module en un seul JS. Certaines IDE comme webstorm, ou certaines appli comme Codekit https://incident57.com/codekit/ mac only) ou Prerpos https://prepros.io/ win/mac/lin)  le font automatiquement dès qu’un fichier du lot est sauvegardé. 



Certains outils génère même un JS different pour chaque pages, selon les modules employé, mais demande

  quelques pré-requis : browserify.org .





Ca revient à copier les contenus des fichiers dans un seul fichier, non ? Éventuellement, virer les sauts de lignes, les espaces inutiles ce genre de truc ?







seb2411 a écrit :



Oui, normalement pour les framework modernes (genre Symfony en php) ca se gère automatiquement.  Pour Wordpress je pense qu’il doit y avoir des plugins mais c’est dommage qu’il gèrent pas ça nativement et proprement.





Ben, je tripatouille mon propre CMS depuis assez longtemps et justement la semaine dernière je me suis relancé dans un système où l’utilisateur peut créer son propre module d’affichage de contenu et l’inclure au site. Dans cette optique, il m’a semblé naturel d’avoir le js et le css spécifiques au module dans un dossier à part, et de charger toutes les ressources utiles en fonction du contenu de la page demandée (une page qui utilise les modules 1 et 3 ne chargera pas le js qui fait tourner le module 2)

Ca ne coute pas beaucoup plus cher de remplacer la recherche des ressources utiles par une copie de tous les js en un seul et de charger ce (gros) fichier tout le temps pour tout le monde.

Reste à voir les perfs.



Après tout, ce genre de projet est plus fait pour bidouiller que pour répondre à un réel besoin. Si je peux produire du code utile, cool, je distribue. Mais sinon c’est plus pour m’auto-former et garder la main.









Koxinga22 a écrit :



Ca revient à copier les contenus des fichiers dans un seul fichier, non ? Éventuellement, virer les sauts de lignes, les espaces inutiles ce genre de truc ?





Ben, je tripatouille mon propre CMS depuis assez longtemps et justement la semaine dernière je me suis relancé dans un système où l’utilisateur peut créer son propre module d’affichage de contenu et l’inclure au site. Dans cette optique, il m’a semblé naturel d’avoir le js et le css spécifiques au module dans un dossier à part, et de charger toutes les ressources utiles en fonction du contenu de la page demandée (une page qui utilise les modules 1 et 3 ne chargera pas le js qui fait tourner le module 2)

Ca ne coute pas beaucoup plus cher de remplacer la recherche des ressources utiles par une copie de tous les js en un seul et de charger ce (gros) fichier tout le temps pour tout le monde.

Reste à voir les perfs.



Après tout, ce genre de projet est plus fait pour bidouiller que pour répondre à un réel besoin. Si je peux produire du code utile, cool, je distribue. Mais sinon c’est plus pour m’auto-former et garder la main.





Je pense que tu dois pouvoir utiliser des lib déjà existantes pour faire ça. Sauf évidement si tu veux faire ça toi même.



Pour minifier c’est pas seulement virer les commentaires et les espaces inutiles mais aussi compresser le code (un exemple avec jquery :http://code.jquery.com/jquery-1.11.2.min.js).



Au final, si je vous comprends bien, il vaut mieux mettre son JS et son CSS dans le HTML directement ?








uzak a écrit :



Au final, si je vous comprends bien, il vaut mieux mettre son JS et son CSS dans le HTML directement ?





rien que pour le référencement, ce serait catastrophique









Koxinga22 a écrit :



Ca revient à copier les contenus des fichiers dans un seul fichier, non ? Éventuellement, virer les sauts de lignes, les espaces inutiles ce genre de truc ?





Ca va un peu plus loin.

&nbsp;

La minification retire espace, retour à la ligne et commentaire inutile.

On peut aller plus loin en remplaçant les noms de variables avec quelques chose de plus court.

On peut gagner jusqu’à 30% du poids du fichier comme ça.



La concatenation des fichiers permet de gagner en temps de chargement, et pas qu’un peu, sur le nombre de requête TCP à effectuer.



En dev front, aujourd’hui, tout ça, c’est pas de l’optimisation, c’est le standard =).



Dans le cas de browserify, c’est un peu différent, il ne fait pas que concatener des fichiers, mais grâce à des outils de gestion des dépendances comme requireJS ou CommonJS, il ne concatene que les modules et dépendances utiles. C’est très pertinent aujourd’hui ou l’on peut partager du code client et du code server (avec NodeJS) par exemple.



La compression des données fait pas gagner beaucoup déjà ?








seb2411 a écrit :



Je pense que tu dois pouvoir utiliser des lib déjà existantes pour faire ça. Sauf évidement si tu veux faire ça toi même.





Bien sur, le but est d’avoir un outil dont j’ai codé chaque ligne, sinon je prendrais un CMS existant :)

Et c’est aussi d’avoir un truc perso à bidouiller pour tester ce qui me passe par la tête.







seb2411 a écrit :



Pour minifier c’est pas seulement virer les commentaires et les espaces inutiles mais aussi compresser le code (un exemple avec jquery :http://code.jquery.com/jquery-1.11.2.min.js).









jun a écrit :



Ca va un peu plus loin.

 …





OK. Je verrais pour des méthodes de minification. J’ai l’impression que, comme souvent, on peut faire 80% du boulot avec 20% d’effort. C’est ma devise ^_^’







jun a écrit :



Dans le cas de browserify, c’est un peu différent, il ne fait pas que concatener des fichiers, mais grâce à des outils de gestion des dépendances comme requireJS ou CommonJS, il ne concatene que les modules et dépendances utiles. C’est très pertinent aujourd’hui ou l’on peut partager du code client et du code server (avec NodeJS) par exemple.





Du coup, il créé un fichier js par combinaison de modules utilisés ? Genre la page X utilise module 1 et 3, il créé un fichier “module-1-3.js”, le remplit avec le code fournit par les modules 1 & 3 et le charge pour toutes les pages qui ont cette combinaison de module ?

C’est une bonne solution si l’on a pas beaucoup de modules et donc peu de combinaisons. Si au bout d’un moment, il n’y a jamais 2 pages qui utilisent les mêmes combinaisons de modules, ca devient moins intéressant (s’il n’y a pas de réutilisation possible du code, inutile de faire des choses qui factorisent le code).



Tu parles de compression GZip par exemple ?



Sur les fichiers css/javascript, la minification et la compression sont complémentaire. La minification réduit la taille du “de base” avant la compression. Bien sur, le pourcentage de compression est moins impressionnant, mais le résultat obtenu est bien plus léger.&nbsp;



Par ailleurs, réduire le nombre de fichier réduit le nombre d’information pas forcément utile, en évitant de multiplier le nombre de header de fichier. Supprimer ce genre de donnée sera toujours plus efficace que de les compresser =).








Koxinga22 a écrit :



OK. Je verrais pour des méthodes de minification. J’ai l’impression que, comme souvent, on peut faire 80% du boulot avec 20% d’effort. C’est ma devise ^_^’





Question d’outil =)



Y’a des gens qui préfère des outils comme prepros car c’est simple à mettre en oeuvre.

D’autre préfère des outils comme gulp, plus proche d’un maven dans l’esprit, mais qui demande un sérieux apprentissage, mais indépendant de tout IDE.







Koxinga22 a écrit :



Du coup, il créé un fichier js par combinaison de modules utilisés ? Genre la page X utilise module 1 et 3, il créé un fichier “module-1-3.js”, le remplit avec le code fournit par les modules 1 & 3 et le charge pour toutes les pages qui ont cette combinaison de module ?

C’est une bonne solution si l’on a pas beaucoup de modules et donc peu de combinaisons. Si au bout d’un moment, il n’y a jamais 2 pages qui utilisent les mêmes combinaisons de modules, ca devient moins intéressant (s’il n’y a pas de réutilisation possible du code, inutile de faire des choses qui factorisent le code).





T’as compris le truc, c’est bien la réutilisation le truc.



Aujourd’hui NodeJS (JS côté serveur) est une techno qui monte : paypal a lâché java pour NodeJS, résultat +20% de perf sur le même hardware, -30% de temps de dev. La BBC vient d’y passer aussi :&nbsphttp://www.bbc.co.uk/blogs/internet/entries/47a96d23-ae04-444e-808f-678e6809765d



Dans ce contexte, il est pas rare de vouloir mutualisé du code côté client et serveur. Mais là ou un module de logging, pour l’exemple, &nbsp;est pertinent côté serveur, il ne l’est pas côté client. Une solution comme browserify permet de générer des fichier réellement utile.&nbsp;



Le seul truc ou je rejoint pas browserify, c’est le côté “une page = un fichier”, &nbsp;qui ne permet pas de jouer sur le cache navigateur de manière optimal…



Tu dois acheter un certificat SSL, configurer ton frontal pour faire du https&nbsp; et activer le module/option HTTP2 (s’il est disponible ;)&nbsp; ) sur ton frontal

&nbsp;

Le frontal continuera a travailler en HTTP 1 / 1.1&nbsp; avec les serveurs en interne



&nbsp;facile… a dire… avec plein d’emmerde potentiel. Ex: Spdy ne supportait pas les redirections lors de l’initialisation de la connexion j’espère que cela a été corrigé.








jun a écrit :



Question d’outil =)



Y’a des gens qui préfère des outils comme prepros car c’est simple à mettre en oeuvre.

D’autre préfère des outils comme gulp, plus proche d’un maven dans l’esprit, mais qui demande un sérieux apprentissage, mais indépendant de tout IDE.





Oui mais non. Je n’ai aucun objectif à atteindre hormis apprendre. Donc aucun outil, je veux avoir tapoté chaque ligne de code avec mes petits doigts à moi.







jun a écrit :



T’as compris le truc, c’est bien la réutilisation le truc.



Aujourd’hui NodeJS (JS côté serveur) est une techno qui monte : paypal a lâché java pour NodeJS, résultat +20% de perf sur le même hardware, -30% de temps de dev. La BBC vient d’y passer aussi :&#160http://www.bbc.co.uk/blogs/internet/entries/47a96d23-ae04-444e-808f-678e6809765d



Dans ce contexte, il est pas rare de vouloir mutualisé du code côté client et serveur. Mais là ou un module de logging, pour l’exemple,  est pertinent côté serveur, il ne l’est pas côté client. Une solution comme browserify permet de générer des fichier réellement utile. 



Le seul truc ou je rejoint pas browserify, c’est le côté “une page = un fichier”,  qui ne permet pas de jouer sur le cache navigateur de manière optimal…





Voir au dessus, s’il suffit de lire un fichier pour en copier le contenu, je n’ai pas besoin d’une librairie externe, je peux le faire moi-même. Avec moins de vérification, moins d’optimisation, en 1 ligne bien bourrine. Je ne cherche pas à concurrencer des solutions pro donc les perfs m’importent peu, c’est surtout avoir l’occasion de réfléchir à tout ça par moi-même.

Le seul truc externe que j’utilise, c’est la librairie jquery.









Koxinga22 a écrit :



Voir au dessus, s’il suffit de lire un fichier pour en copier le contenu, je n’ai pas besoin d’une librairie externe, je peux le faire moi-même. Avec moins de vérification, moins d’optimisation, en 1 ligne bien bourrine. Je ne cherche pas à concurrencer des solutions pro donc les perfs m’importent peu, c’est surtout avoir l’occasion de réfléchir à tout ça par moi-même.&nbsp;





T’y es pas. Ce type d’outils est là pour imposer une forme de rigueur dans le travail &nbsp;et surtout de s’éviter la partie pénible du boulot pour se concentrer sur la partie plus intellectuel.&nbsp;

&nbsp;





Koxinga22 a écrit :



Le seul truc externe que j’utilise, c’est la librairie jquery.



C’est con =) car si tu veux vraiment apprendre, c’est bien LA librairie à squizzer.









seb2411 a écrit :



Pour la prod il faut toutefois prévoir de les fusionner en un seul fichier et minifier le code.



&nbsp;

Precision : il faut faire ca de facon intelligente. Si t’as 2Mo de JS, fusionner tout le code en un seul fichier ne serait pas optimale. Il vaut mieux alors fusionner le code par module (par exemple 5 fichiers .js x 400Ko).









Koxinga22 a écrit :



En

gros, il faudrait qu’à la publication, le generateur aille lire tous

les js des modules actifs et recopie leur contenu dans un seul js à

mettre en prod (les noms de fonctions sont préfixés du nom de module

donc pas de conflit à l’horizon)





Il y a des frameworks qui font tout ça dynamiquement et automatiquement, et pour certain, en runtime.



Le framework MediaWiki et son ResourceLoader par exemple est capable de prendre une liste de dizaines de fichiers JS / CSS, gérer les dépendances, aggréger le code, le minifier, stocker une version du résultat qui servira de cache pour les prochaines visites, en fonction des types de profils des visiteurs, etc… le tout de façon totalement transparente pour le développeur comme pour l’utilisateur.



comment savoir si l’on utilise http 1.1 ou http 2 sur son navigateur ???








jun a écrit :



T’y es pas. Ce type d’outils est là pour imposer une forme de rigueur dans le travail  et surtout de s’éviter la partie pénible du boulot pour se concentrer sur la partie plus intellectuel.





Ca c’est la description des framework/librairies en général. Donc c’est valable pour tous les projets, donc aucun en particulier.

Là, c’est un projet en particulier et il a pas vocation à être vendu ou promu, c’est un passe temps. Et je préfère me faire ma librairie imparfaite que de me forcer à piger celle d’un autre. Je vois pas l’obstacle.







jun a écrit :



C’est con =) car si tu veux vraiment apprendre, c’est bien LA librairie à squizzer.





C’est un peu gratuit de s’arrêter à une affirmation …

Je peux aussi bien dire que pour bien faire, c’est LA librairie à avoir.

Et on est pas plus avancés.



https://kirou.wordpress.com/2014/06/09/why-we-should-stop-using-jquery/

http://samsaffron.com/archive/2012/02/17/stop-paying-your-jquery-tax

http://www.raymondcamden.com/2012/10/23/Stop-using-jQuery-all-the-time

http://modernweb.com/2013/05/06/5-things-you-should-stop-doing-with-jquery/

http://www.sitepoint.com/do-you-really-need-jquery/

http://blog.garstasio.com/you-dont-need-jquery/why-not/



Pour faire cour deux raisons reviennent souvent :




  • Le poids de la librairie est injustifié aujourd’hui alors que le support de JS est à peu prêt consistant dans tout les navigateurs.

  • C’est une librairie d’abstraction, qui nuit à l’apprentissage de JS et des WEB API.


Mouais, chacun ses choix. Si tu estimes que le poids de jquery est trop important pour ce que tu en fait, ne l’utilise pas. Mais c’est outrepasser que d’affirmer que je dois m’en passer …



Aucun des 6 liens ne donne de réelle raison de se passer de jquery (oui c’est juste du link bait) ils expliquent tous que jquery c’est trop cool et que ca rend d’énormes services. Après ils font le breakdown des temps de chargements en expliquant qu’il y a telle ou telle façon de “bien” utiliser jquery sur son site. Ils disent surtout que c’est un mauvais rapport d’utiliser jquery dans un POC de 1Ko, et là c’est sûr je suis d’accord avec eux. Mais pour un projet web complet, l’inconvénient disparait dans la masse et le service rendu est réel.

(Juste un exemple idiot : on charge des images plus grosses que jquery dans n’importe quel composant de galerie, il faut interdire les galeries d’image aussi, à cause de leur taille qui ralentit l’affichage de tes magnifiques pages codées avec amour ?)



Les syntaxes de remplacement proposées ne sont pas compatibles avec tous les navigateurs.

Comment convaincre que

var myElement = Document.getElementByID(“mon_id”);

c’est mieux que

$(“#mon_id”);

? Vraiment je ne vois pas.



Quant à l’argument que c’est un framework donc faut pas s’en servir, c’est juste idiot. Le mec qui dit ca, il boycott aussi le PHP ? le .Net ? Il code directement en binaire en induisant des impulsions électromagnétique au disque dur avec une aiguille magnétisée ?

Entre utiliser des “outils” comme tu dis pour tout et n’importe quoi genre copier une string et dire ensuite que jquery c’est trop hardcore ca t’empêche de faire le code toi-même, ca ne tient pas debout. Du javascript, j’en ai assez bouffé pour zapper toutes les syntaxes chiantes en un appel de fonction.



J’aime jquery parce qu’il me fournit des briques élémentaires rapidement, je ne me sert pas de 99% de ce qu’il propose mais les sélecteurs et les fonctions associées ca change vraiment la taille des fichiers. write less, do more, je le constate dans mes sources.



Enfin, pour la 5e fois, je ne produit pas une solution pro avec des grosses perfs turgescentes. Je fais un bac à sable versatile et évolutif pour moi-même, comme un passe-temps. Donc je n’ai pas besoin d’une librairie externe qui ne fait qu’optimiser des perfs sur des détails pointus, j’ai besoin d’une boite à outils polyvalente pour créer du gros œuvre from scratch.

Et puis même, c’est un état d’esprit général, toi tu codes uniquement des killer-app en cousant des morceaux de code récupérés sur le web ? Tu ne fais jamais de POC ou de projet perso où tu reprend tout depuis les bases pour voir ce que tu peux produire par toi-même ? Si tu as bien intégré un concept, voire juste pour le plaisir de le faire.


Yeah !


Qu’est-ce que tu veux dire par “une page = un fichier” ?


SI tu utilise jQuery uniquement pour les sélecteurs, l’intérêt est nul, et beaucoup de gens se méprennent la dessus.


en gros tu fais plus appel à des fichiers de scripts externe. les fonctions utiles sont inscrite dans le fichier. ça limite les requêtes consécutives (qui ne sont plus un problème avec cette norme) mais oblige à augmenter un peu la taille de chaque page.

alors que si plusieurs pages utilisent le même script, le navigateur reprendra la version en cache sans avoir à la re-télécharger. 2 écoles.