Je t'ai traduit un extrait d'interview dans le commentaire au-dessus, mais je peux juste te resituer un contexte, c'est ça l'histoire, une question de perspectives, personne ne détient la vérité ultime et il faut souvent savoir lire entre les lignes.
Comme c'était précieux, on allait sûrement pas faire exprès de bouffer de la ressource…
non, l'idée était de ne pas te laisser la possibilité de bouffer de la ressource, parce que ce serait tellement peu pratique que le faire serait absurde. J'ai fait une analogie avec la petite cuiller qu'on laisse aux prisonniers : ils peuvent parfaitement s'en servir pour manger, mais s'ils veulent s'évader, ça va les faire chier, c'est fait exprès !
Donc si tu veux juste brider les possibilités, tu vas les faire chier, et peut-être nous faire chier en faisant des pages moins réactives avec les limitations que tu veux mettre.
Elles ne seraient pas moins réactives. L'idée (JavaScript == vitesse du web) est une construction marketing des années 2006 par Google qui voulait ses applications lourdes : il faut savoir que tout n'est pas accélérable dans la pile de standards constituée par les navigateurs. Depuis bien longtemps, aux environs de 2006 d'ailleurs, ce n'est pas JavaScript qui est le facteur limitant, mais l'arborescence DOM, qui n'est pas parallélisable, et qu'il faut bien parcourir, et l'arbre de rendu du document avec son arbre de styles CSS associé. Tout cela est au maximum de vitesse depuis des années, et ne peut évoluer que si de nouveaux standards émergent.
99% de tout ce qui se fait sur le web en dehors des applis lourdes (pour lesquelles l'utisateur pourrait faire des exceptions à la manière de NoScript) peut se faire avec 1% de la vitesse JS, sans différence de vitesse effective puisque tout ce qui est vraiment interactif visuellement est bridé par le DOM. Cela éviterait les spoliations de CPU qui sont le fait de programmeurs incompétents ou de l'accumulation de strates de frameworks.
Cela rétabirait 'équilibre entre les différents standards, et entre client et serveurs : on éviterait de faire en JS ce qu'on peut parfaitement construire côté serveur mais qu'il est simplement devenu plus rentable de faire sur le client, ou ce qu'on peut carrément implémenter statiquement en CSS 3.
En gros, il me semble qu'il est urgent de recentrer le Web sur le statique, et de refaire de l'applicatif une exception.
Mais ça n'est que mon avis (j'avoue, je suis biaisé, j'ai bossé 8 ans sur le moteur de rendu de Konqueror - j'exècre ce que Google a fait du Web)
[^] # Re: soit dit en passant
Posté par spart . En réponse au journal Réflexion sur ASM.js ou quand le javascript deviens enfin performant :. Évalué à 1.
Je t'ai traduit un extrait d'interview dans le commentaire au-dessus, mais je peux juste te resituer un contexte, c'est ça l'histoire, une question de perspectives, personne ne détient la vérité ultime et il faut souvent savoir lire entre les lignes.
Comme c'était précieux, on allait sûrement pas faire exprès de bouffer de la ressource…
non, l'idée était de ne pas te laisser la possibilité de bouffer de la ressource, parce que ce serait tellement peu pratique que le faire serait absurde. J'ai fait une analogie avec la petite cuiller qu'on laisse aux prisonniers : ils peuvent parfaitement s'en servir pour manger, mais s'ils veulent s'évader, ça va les faire chier, c'est fait exprès !
Donc si tu veux juste brider les possibilités, tu vas les faire chier, et peut-être nous faire chier en faisant des pages moins réactives avec les limitations que tu veux mettre.
Elles ne seraient pas moins réactives. L'idée (JavaScript == vitesse du web) est une construction marketing des années 2006 par Google qui voulait ses applications lourdes : il faut savoir que tout n'est pas accélérable dans la pile de standards constituée par les navigateurs. Depuis bien longtemps, aux environs de 2006 d'ailleurs, ce n'est pas JavaScript qui est le facteur limitant, mais l'arborescence DOM, qui n'est pas parallélisable, et qu'il faut bien parcourir, et l'arbre de rendu du document avec son arbre de styles CSS associé. Tout cela est au maximum de vitesse depuis des années, et ne peut évoluer que si de nouveaux standards émergent.
99% de tout ce qui se fait sur le web en dehors des applis lourdes (pour lesquelles l'utisateur pourrait faire des exceptions à la manière de NoScript) peut se faire avec 1% de la vitesse JS, sans différence de vitesse effective puisque tout ce qui est vraiment interactif visuellement est bridé par le DOM. Cela éviterait les spoliations de CPU qui sont le fait de programmeurs incompétents ou de l'accumulation de strates de frameworks.
Cela rétabirait 'équilibre entre les différents standards, et entre client et serveurs : on éviterait de faire en JS ce qu'on peut parfaitement construire côté serveur mais qu'il est simplement devenu plus rentable de faire sur le client, ou ce qu'on peut carrément implémenter statiquement en CSS 3.
En gros, il me semble qu'il est urgent de recentrer le Web sur le statique, et de refaire de l'applicatif une exception.
Mais ça n'est que mon avis (j'avoue, je suis biaisé, j'ai bossé 8 ans sur le moteur de rendu de Konqueror - j'exècre ce que Google a fait du Web)