Discussion :

[cmascart]

Bonjour à tous,

Les requêtes Ajax sont géniales.

Elles permettent d'établir un véritable dialogue interactif, entre le client et le serveur, piloté par des événements côté client,
qui déclenchent une requête depuis un XMLHttpRequest

Dès réception de la réponse, son événement onload réagit, et la traite.
* Côté serveur, PHP emballe la réponse dans un tableau associatif avec json_encode($tableau).
* Côté client, l'événement onload en JavaScript déballe avec JSON.parse(e.target.responseText).
Autant dire que je n'utilise plus XML, trop lourd, auquel je préfère, de loin, json.

Au point d'être convaincu que le web serait bien plus efficace, si les pages web étaient conçues en Json, plutôt qu'en XML, dont HTML est une sous-composante.
Un tableau associatif permettrait l'économie de <BALISE>Blablabla</BALISE>.
Pour une paire de clef=>valeur de type Balise=>'Blablabla'

Au lieu de <A href="cible.php" target="_blank">Clique</A>.
On aurait
a=>[href=>'cible.php', target=>'_blank', inner=>'Clique'].
Le Inner d'une balise peut être une simple chaîne, ou un tableau associatif, contenant d'autres balises, selon une structure arborescente, comme c'est déjà le cas.

Actuellement, une page web est parsée dans un Document Object Model (DOM), qui est un arbre, dont la balise HTML est la racine.
Ce DOM peut, parfaitement, être aussi parsé dans un Json de contenu identique, mais bien plus concis et compact: gain de bande passante

Le navigateur, qui reçoit cette chaîne JSON, appelons-la JML (Json Markup Langage), la parserait dans un DOM, de rendu identique pour l'internaute, qui verrait la même page web qu'auparavant, en HTML.
Ne cherchez pas après une doc sur JML, sur le web, c'est une pure invention de ma part. Rien à voir avec le Java Modeling Langage, homonyme.

Pour ne pas trop déstabiliser les éditeurs de sites web, éventuellement, dynamiques, avec PHP, comme moi,
le serveur (apache2, iis) transformerait le HTML en JML, juste avant l'envoi, de façon totalement transparente pour l'émetteur,
qui aurait, toujours, l'impression d'envoyer de bonnes vieilles pages web classiques en HTML.
Statiques ou dynamiques, c'est pareil: aucune différence de langage, au moment de l'envoi.

Apache2 parse l'HTML, créerait un tableau associatif DOM, qu'il emballerait dans un json_encode($dom), et enverrait le JSON au navigateur.
Navigateur, qui, à son tour, déballe la chaîne Json par un JSON.parse(chaineJson) en JavaScript, reconstruit le DOM et l'affiche, comme avant.
Au niveau CSS, aucun changement.
Pour l'internaute, aucun changement non plus.

Les nouveaux navigateurs seront réceptifs aux deux: Html et Json
Le temps que les éditeurs de sites web s'adaptent, et conçoivent des sites nativement en Json, qu'Apache2 ne devra plus parser avant l'envoi.
Dans quelques années, le temps que de nouveaux outils d'édition apparaissent, et c'en sera fini d'HTML, comme d'XML.

Je pense qu'il faudrait proposer l'idée au W3C.
Qu'en pensez-vous ?

Bonne rentrée,
Christian.

[mathieu]

Autant dire que je n'utilise plus XML, trop lourd, auquel je préfère, de loin, json.

je suis complètement de votre avis et il y avait quelques années j'avais fait des comparaisons pour des données qui étaient utilisées pour la communication entre 2 sites.
et comparant la taille du contenu, j'avais trouvé que le format json faisait 20 % de taille en moins que le xml. je crois que maintenant les serveurs http gèrent de façon transparente la compression de la réponse HTTP donc cela ne change peut-être pas grand chose entre les 2 formats.
et ensuite en comparant le temps d'analyse des 2 formats, j'avais aussi trouvé un réduction de 20 % du temps de traitement du json par rapport à l'xml.
ce sont des nombres cités par une mémoire très lointaine donc ils sont peut être à plusieurs points de pourcentage de précision mais l'idée est là.

et en plus de ça, j'aime bien ressortir cet extrait d'un tutoriel qui date de aout 2009 (donc il y a 14 ans) :

si le XML se justifiait à l'époque des premières évocations d'AJAX (la mode était au XML et les formats alternatifs comme JSON n'existaient pas), il est aujourd'hui controversé

https://dmouronval.developpez.com/tu...e-ajax/#Lno-II

malgré tout cela, je trouve encore des nouveaux projets qui se basent sur XML ou encore pire sur des formats comme SOAP (qui était une bonne idée au moment de se création mais qui est maintenant inutilement lourd par rapport à ce qui a été inventé depuis).
et tout ça ne vient pas d'un souci technique mais d'un souci humain qui est tout simplement l'habitude. l'homme s'habitue à tout, au meilleur comme au pire et cela provoque une inertie énorme.
cela me rappelle une connaissance qui faisait des études dans le domaine juridique et qui m'expliquait que quand un ministre arrivait à faire voter une réforme et qu'en plus il arrivait à mettre son nom dans le nom de la réforme, son travail n'était pas encore fini. il devait aller régulièrement voir les fonctionnaires concernés pour les supplier de changer d'habitude et de prendre en compte cette reforme.

il est probable que plusieurs personnes aient déjà proposé au W3C des améliorations dans le sens que vous proposez mais cet organisme doit géré l'inertie des développeurs de navigateurs et de tous les moteurs de rendu html. et donc ils savent qu'il ne peuvent pas aller plus vite que la musique au risque d'avoir le même résultat qu'avec XHTML par exemple : trop d'évolutions donne trop de travail pour sortir des habitudes et provoque au final un rejet.

[thelvin]

Au lieu de <A href="cible.php" target=_blank">Clique</A>.
On aurait
a=>[href=>'clible.php', target=>'_blank', inner=>'Clique'].

Bah. Ton truc proposé est illisible alors que le lien "comme d'hab" se lit bien.

C'est pas plus compliqué que ça. Il y a aussi le contenu mixte, qu'un format à balise représente bien, alors qu'un arbre genre JSON peut le faire, mais uniquement mal le faire.

En revanche, on peut remarquer que genre, les paragraphes et contenus conteneurs de texte, on besoin d'un format balisé certes, c'est aussi pour ça qu'on a le markdown et équivalents. Mais que le reste de la structure tiendrait dans un format genre JSON.

En revanche de la revanche, XML est extensible, le X n'est pas usurpé, mais ne l'est que du fait qu'il reprend la structure qu'a également HTML. JSON en comparaison n'a aucune extensibilité, ce n'est qu'un appel à une infinité de problèmes. Ça se remarque avec toutes les API JSON qui essaient d'évoluer, et en lieu et place d'essayer de faire l'impossible, à la place à chaque fois elles ont une nouvelle version qu'on ne peut pas traiter comme l'ancienne version. Le web ne s'embarrasse pas de ça et n'arriverait probablement pas à le faire. Au départ c'est pour ça que le web est ce qu'il est et n'est pas un document Word ou un truc AOL.

[cmascart]

L'inertie est un frein considérable à l'évolution. Mathieu a raison.
Il existe des milliards de pages web en HTML de par le monde.

La solution me semble de placer un parseur JSON en aval d'Apache2 (ou iis)
Actuellement, le parsing de l'HTML en arbre DOM se fait au niveau du navigateur (côté client, donc)

L'encodeur JSON, côté serveur, transformerait l'HTML en JSON... s'il y arrive.
Car il peut caler sur une structure mal faite

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
<PREMIERE><SECONDE>Contenu</PREMIERE></SECONDE>
<PREMIERE><SECONDE>Contenu</PREMIERE>

Dans la première ligne, les balises devraient avoir été fermées dans l'ordre inverse de leur ouverture, pour emballer la seconde dans la première.
Dans la seconde ligne, la seconde balise n'est pas fermée.

En HTML, aucun problème: ce code sale peut être expédié sur le web. Le navigateur n'a qu'à se débrouiller avec.
Avec un encodeur JSON: il produira une erreur. La page web ne part pas.

Ca va agacer les mauvais développeurs, priés de revoir leur copie.
Mais améliorera la qualité du code envoyé en ligne.

En cas de succès de l'encodage, la chaîne JSON obtenue sera zippée, puis, finalement expédiée sur le web.
Côté client, le navigateur dézippe, parse le JSON, puis, affiche le DOM, comme avant.
Le même DOM que celui obtenu après lecture de l'HTML actuellement.
Le parsing du JSON est garanti, puisqu'il a été correctement généré par le serveur.

En ce qui concerne l'affichage de la source (CTRL-U), ce sera beaucoup plus propre.
Le navigateur affichera une structure arborescente, avec des poignées d'ouverture (expand / collapse) à chaque nœud, plutôt qu'un texte HTML.
La plupart des navigateurs (j'utilise Firefox) le font déjà dans la console, onglet Inspecteur.

Envoyer du JSON zippé, plutôt que de l'HTML en clair, épargnera énormément de bande passante.
Les utilisateurs de smartphones, au quota mensuel limité, apprécieront.

C'est dans cet état d'esprit que j'utilise les unicodes, plutôt qu'un <IMG src="..."/>
L'unicode fait une dizaine d'octets, mais c'est un autre débat.

En résumé: pour ne pas bousculer les habitudes, les développeurs continueront à coder en HTML, comme avant.
Les sites web actuels restent fonctionnels.
Ce qui change, c'est l'encodage-zippage de l'HTML en JSON avant l'envoi.

[thelvin]

Personne ne t'a attendu pour zipper. Et à partir du moment où tu fais ça, le reste du passage au JSON que tu proposes ne sert à rien.

Si tu veux des messages d'erreur quand le document est mal formé, utilise tu vrai XHTML. Rien ne t'en empêche.

[NoSmoking]

Bonjour,
pas tout compris où serait le gain, car gain il doit y avoir.
Mais déjà entre

Code html :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
<A href="cible.php" target="_blank">
  Clique
</A>

Code json :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
const Tree = {
  "A": {
    "href": "cible.php",
    "target": "_blank",
    "text": "Clique",
  }
}

... pour moi il n'y a pas photo, et je ne te parle même pas des éléments profondément imbriqués !

L'encodeur JSON, côté serveur, transformerait l'HTML en JSON... s'il y arrive.

tu ajoutes donc une étape !

Côté client, le navigateur dézippe, parse le JSON, puis, affiche le DOM, comme avant.
Le même DOM que celui obtenu après lecture de l'HTML actuellement.

plus une autre étape côté client !!

Envoyer du JSON zippé, plutôt que de l'HTML en clair, épargnera énormément de bande passante.

une partie non négligeable de la bande passante est mangé par le chargement de bibliothèque tant JS que CSS

[Nb]

Bonjour,

je ne comprend pas non plus où serait le gain.

Si on compare des choses comparables (l'exemple donné pour décrire un lien hypertexte est bon) le gain de taille est infime ou inexistant.
Après si tu compares des données transmises en XML accompagnées de leur propre description à un json qui envoient des données brutes forcément que le json parait moins verbeux ...

De même tu compares SOAP au JSON; ca n'est pas possible car le premier est un protocole d'echange d'informations entre objets distants (qui utilise certes XML) alors que le second n'est qu'un format de données textuel.
Du coup tu sembles preferer les API REST en Json au SOAP en XML, mais en fait les API REST qui utilisent le JSON sans autre chose que les données brutes ben ca devient très vite bordélique et difficile à maintenir. Du coup des normes ont été inventées (genre Hydra) pour essayer de pallier ce soucis et ces normes permettent de décrire tous les types de données en détail et les liens entre les differents objets et les endpoints ... et du coup on revient sur un truc genre soap qui est tres verbeux mais qui permet par exemple de generer automatiquement la doc d'une api ou que des clients de l'API puissent la découvrir par eux meme sans avoir besoins d'intervention humaine.

Bref si veux envoyer exactement les mêmes données en XML et en Json tu risques effectivement de gagner un peu en volume avec le JSON, mais c'est tellement à la marge que remplacer le HTML pour ca me parait plus qu'hasardeux

[cmascart]

Bonjour à tous,

Fondamentalement, une page web est un arbre, dont la racine <HTML> contient deux descendants
<HEAD>, qu'on ne voit pas, et <BODY>, qui est visible.

En un précédent message, je proposais de remplacer l'HTML par du JSON, plus concis, pour véhiculer cet arbre.
Car JSON permet d'emboîter récursivement, des éléments, comme l'XML, dont HTML n'est, finalement, qu'une implémentation.

Perso, je ne pratique plus XML, j'utilise exclusivement JSON. Je pense que le web devrait en faire autant.
quel que soit le langage HTML ou JSON utilisé, pour construire l'arbre, il faut le parser.

Il existe, d'ailleurs, une instruction JavaScript JSON.parse(string), qui effectue un travail analogue.

Comme tout code source, HTML et JSON sont incompréhensibles par la machine.
Parser, c'est, en quelque sorte, compiler.
Entre la réception du code source, et l'affichage de la page web, le navigateur doit parser l'HTML.

Ce que je propose, ici, c'est d'effectuer ce parsing côté serveur.
Pour envoyer, ensuite, du code compilé, incompréhensible, par internet.
Non seulement compilé, mais éventuellement, crypté par la clef du certificat.

Pour l'utilisateur, aucune différence.
Le temps perdu, côté serveur, à parser et compiler, serait gagné côté client.

Quel intérêt ?
Actuellement, les pirates ont accès au code source des pages web d'accueil des sites sensibles.
HomeBanking, espace client, CPanel chez un hébergeur web, ...

Qu'il leur suffit de lire en clair, pour reproduire, avec une facilité étonnante, sur un faux site.
L'utilisateur, grugé, n'y voit que du feu, et y introduit ses codes secrets.

Internet a été créé, dans un climat de confiance, entre universités, qui ont repris Arpanet et instauré le TCP-IP.
Toute sa structure repose sur la confiance, qui fait le bonheur des escrocs.

L'HTTPS n'y change rien. Il garantit juste que le nom de domaine mène bien au bon serveur, identifié par son IP.
Il empêche l'interception, entre le serveur et le client, par l'homme du milieu, et la redirection (spoofing).

Mais le client https, éventuellement malveillant, reçoit toujours l'HTML déballé, en clair.

Par conséquent, le serveur (Apache2, IIS) aurait trois options, pour envoyer sa page web,
toujours en https, évidemment, que ma proposition n'abolit pas.

1) HTML classique, à l'ancienne et en clair (par défaut)
2) En JSON, toujours en clair (idéalement)
3) Compilé, crypté par la clef du certificat (pages sensibles)

Avant l'envoi de la page web, le serveur envoie un header,
pour annoncer la couleur de ce qui suit: du HTML, du JSON, ou du compilé.

Même si la compilation côté serveur alourdit la communication, elle en vaut vraiment la peine.
Vu la puissance des processeurs, ce temps de compilation serait à peine perceptible.
Tout serait compilé: HTML, CSS et JavaScript.

En Belgique, en 2022, le phishing atteint presque les 40 millions d'euros.
40 millions, dont les victimes belges ont été soulagées par des escrocs anonymes et introuvables.

Ce montant, connu et déclaré, est la somme des plaintes, mais nettement en-dessous de la réalité.
A cause du silence complice de la victime honteuse, qui préfère se taire, et vivre dans le déni.
Car le phishing n'a pas que des conséquences financières, mais psychologiques considérables.

Au final, le client (le navigateur) reçoit un charabia binaire, aussi incompréhensible qu'un .exe, ou un .class en Java

OK, vous me répondrez qu'on peut désassembler un .exe, et qu'on pourrait, aussi "désassembler" une page web compilée.
Mais l'assembleur, ce n'est pas du code source. Il faut vachement s'y connaître, pour programmer à un aussi bas niveau.

Plagier un site web bancaire compilé deviendra beaucoup plus compliqué.
Bonne chance, au pirate, pour refaire une page web identique !
Avant, il suffisait de faire CTRL-U pour voir la source.

Pour le web master, rien ne change:
Il conçoit toujours son site en HTML. C'est le serveur qui compile.

Finalement, la modification que je propose est minime:
Déplacer le parseur HTML-CSS, et le moteur JavaScript (SpiderMonkey chez FireFox) du navigateur vers le serveur.

Tant que le web véhiculera du code en clair (html, css et JavaScript) ça fera le bonheur des escrocs.

Je ne comprend pas comment le W3C n'a pas encore pensé à la compilation (parsing),
qu'il faut, de toutes façons, faire avant d'afficher la page.

Pour moi, ça saute aux yeux.
Et vous, qu'en pensez-vous ?

Bien à vous,
Christian.

[mathieu]

j'ai du mal à vous suivre là, vous êtes parti de la 1re idée d'utiliser du json pour économiser de la bande passante et des ressources processeurs.
et là vous parlez d'arnaques qui pourrait être évitées en cachant le code source. mais même sans le code source, je pense qu'il est toujours possible de recopier l'apparence d'un site. donc même si ce n'est pas au pixel près, les personnes qui ne sont pas sensibilisées se feront quand même avoir.

[thelvin]

C'est surtout que si ça ne fait aucune différence pour l'utilisateur, alors ça ne fait aucune différence pour le navigateur, qui donc peut simplement logger le code source d'origine, ou au moins un autre code source dont la seule différence c'est les espaces, sauts de lignes et autres trucs qui n'ont pas d'effet. Reproduire le site web à l'identique reste donc aussi trivialement facile que ça l'est aujourd'hui, tout comme étudier le fonctionnement de son côté client.

Ceci sans tenir compte du fait que cacher le code source est largement démontré comme inefficace pour prévenir l'exploitation indésirable, sauf dans le cas d'amateurisme exagéré dans lequel la présence de code source fait gagner trois ou quatre semaines aux abuseurs.

Bref cette proposition :

- ne semble pas apporter de bénéfice quel qu'il soit. Toutes les thèses de bénéfice que cela rapporterait, on été invalidées. Et rapidement et facilement.
- apporte de nombreux niveaux de complexité dans la technologie, ce qui est au strict minimum un ajout de dette technique très important ainsi qu'une nécessité de monter en technologies d'analyses. On pourra comparer HTTP/2 et HTTP/3 par rapport à HTTP/1.1, qui complexifient énormément les choses, mais le font en proposant des gains très concrets et en apportant des fonctionnalités favorisant la performance des échanges, et possiblement de nouvelles innovations. Et pourtant presque personne ne s'en sert et personne ne se plaint.
- est faite par quelqu'un qui ne comprend pas ces choses-là
- semble motivée par la confession même du proposant, que c'est parce qu'il aime bien JSON et que depuis il n'aime plus XML (on remarquera l'absence de compréhension de la différence)