Ce billet est la suite naturelle de mon billet précédent, ou je parle du gachis des performances sur Internet.
Ce qui est ressorti des discussions, c’est que le Web est ce qu’il est, un énorme succès, parce que les formats d’échanges sont des formats textes.
ça me semble un élément intéressant à analyser (même si ce n’est qu’un des axes d’analyse).
Donc au début du Web, notre amis Tim Berners-Lee est donc parti sur un langage texte pour décrire le contenu des pages, le HTML.
Avantage : Pas besoin d’outils pour éditer les pages.
Donc, le Web a pu se développer très vite, sans attendre d’avoir des outils d’édition HTML.
J’ai beau chercher, je ne vois pas d’autres raisons : on peut tout à fait imaginer un format « binaire » standard, ouvert.
Alors oui, à l’époque, ça c’est avéré être une très très bonne idée.
Mais aujourd’hui, rester sur des formats uniquement texte ne me semble carrément pas raisonnable.
On pourrait par exemple imaginer un double format : texte et binaire.
Ceux qui veulent peuvent envoyer un format texte, ça marcherait toujours.
Les autres pourraient utiliser un format binaire, encore une fois il faudrait un format ouvert (donc non propriétaire, non protégé par des brevets), et standardisé (ou tout au moins bien décrit).
Il y a des domaines ou les formats binaires se sont bien développer. Les images (JPG) par exemple…
Bon évidement, pour transporter des images, personne n’a imaginé un format texte…
Alors, aujourd’hui, n’avoir que du texte / xml pour envoyer des pages complexes, des styles (CSS), des programmes (javascript) ou des données structurées (xml), je trouve que c’est…. nul.
Et je suis prends le pari avec qui veut que ça ne restera pas comme ça !
Qui veut jouer ?
(par contre, ça peut prendre du temps 😉 )
Ca fait quand même quelques temps que les navigateurs supportent la compression gzip et le keep alive 😉
Bonjour,
Le format binaire n’apporte qu’une réduction du poids des flux et une interprétation plus rapide.
La réduction d’un fichier texte (html) s’effectue en GZIP au niveau du serveur.
En ce qui concerne l’interprétation, avoir du code binaire implique de ne pouvoir lire le fichier directement sans passer par un programme externe.
L’avantage du html/ccs/js est que n’importe quel éditeur de texte peut faire l’affaire.
Dans le cas contraire, il faut les sources d’un côté, un compilateur, etc …
Les languages interprétés se sont imposés face aux languages compilés pour ce qui est des sites Internet grâce à leur simplicité.
Par leur nature, ils enverront à priori toujours un flux texte.
Parallèlement, des flux type xml ou json se sont développés pour communiquer entre des applications.
Si on reste sur un web classique (site internet et non des appli flash ++), les flux en texte resteront selon moi.
DU texte pour des images ? Mais si : uuencode !
Au oui, et puis pour les architecture web, c’est un retour en arrière de 10 ans ! HTML / HTTP était prévu pour présenter des thèses et des bibliographie au CERN et on en a fait un poste client universel remplacant un desktop, alors forcement, quand on utilise un marteau pour planter une visse, c’est pas efficace, mais ca fonctionne.
Une piste : revenir au client-serveur avec echange de données JSON et utiliser un framework type qooxdoo pour les interfaces graphiques.
Encore un point a propos du format binaire : c’est aussi du texte, mais en binaire 🙂
Il ne faut pas trop idéaliser non plus ce « binaire » ou s’imaginer de strucs, c’est juste un fichier texte comme les autres, mais les mots sont des chiffres et la sémantique une convention. Est-ce vraiment plus rapide ? non.
Ne pas confondre rapide/efficace et verbeux, ce sont deux notions différentes.
HTML et XML sont verbeux et doivent être améliorer.
JSON est un format texte non verbeux par exemple.
Je me doutais bien que vous alliez me parler de gzip.
Très bien de faire du GZip, mais le gain en perf est sans commune mesure quand on dialogue directement avec un vrai format binaire.
Format binaire :
Prend l’exemple ou tu veux transmettre un nombre.
En format texte, tu as une chaîne de caractères, un caractère par chiffre.
au format binaire, tu as directement le nombre.
Le gain est très important.
Pareil pour les mots clés, les structures, …
C’est particulièrement important pour les scripts (javascript), mais aussi pour les échanges entre applications (web services), ou on serait 1000 fois plus efficace en échangeant des flux binaires.
« Bon évidement, pour transporter des images, personne n’a imaginé un format texte… »
HTTP transporte l’image, qui lui même est transporté via IP qui lui même est transporté par TCP. L’image est donc transporté mais ne transporte rien.
L’image quant à elle est une représentation (au départ) codé en hexadécimal (du texte donc) de l’état de chaque pixel en RGB.
Ensuite parlons du texte et d’HTML, il est encodé dans un jeu de caractère qui code chaque caractère dans sur un ou plusieurs octets et chacun d’entre eu représente 8bits un code… binaire….
Et en binaire tu n’as pas de chiffre tu as un code binaire. Qu’il faudra à un moment donné retranscrire.
Le binaire n’est pas un format. Il s’agit d’un système de numérotation qui est un concept fondamental de l’informatique.
Je cite wikipedia concernant ses inconvénients :
« » »
… En informatique, la représentation binaire permet de clairement manipuler des bits : chaque chiffre binaire correspond à un bit. La représentation binaire nécessitant l’usage de beaucoup de chiffres (même pour des nombres assez petits), ce qui entraînerait d’importants problèmes de lisibilité et donc de risques d’erreur de transcription pour les programmeurs … » » »
Tu préconiserais donc qu’on écrive nos sites web en Assembleur ?
Dans ta réflexion tu fais remonter à un niveau d’abstraction des problématiques que l’industrie a réussi déléguer à des couches plus basses. HTTP est au niveau le plus haut de l’abstraction.
Bien à toi.
Sur mainframe il y a le comp3 entre autre. Mais c’est effectivement avantageusement remplacé par la compression gzip et ca ne fonctionnerai bien qu’avec les chiffres, puisqu’en unicode on dispose d’une palette de caractères plus larges qu’en EBCDIC (je crois que la base d’unicode va jusqu’a U+FFFF, alors que l’EBCDIC contient une palette limitée qui tient sur 8 bits).
@Thierry> Je pense simplement qu’il y a des échanges ou le format texte est particulièrement inefficace.
Il ne s’agit pas que de la taille de ce qui est échangé (qui est effectivement corrigé avec un GZip) mais surtout du temps pour interpréter le texte, et le convertir dans un format compréhensible par la machine…
De tels formats sont nombreux : flash, java par exemple.
Donc, je confirme : le monde internet gagnerait dans son ensemble si on passait en format binaire pour certains échanges.
Et je pense évidement en particulier aux web services !
Et est-ce que tu peux m’expliquer pourquoi Adobe n’est toujours pas capable de nous fournir un player flash qui soit capable de gérer des animations et des films en plein écran sans surcharger la machine ou planter le navigateur ?
Alors qu’avec un solution basé sur JS + Canvas, c’est uniquement du texte, mais il est possible de proposer des optimisations poussés, de la compilation JIT au niveau du navigateur. Et en plus ça évite une phase de compilation.