Discussion :

[BugFactory]

Cette proposition peut simplifier l'écriture d'applications utilisant beaucoup Ajax, mais ne peut pas remplacer Javascript. L'usage du Javascript ne se limite pas à Ajax, on s'en sert aussi pour effectuer de nombreuses opérations ne nécessitant aucun rechargement de page. Sa proposition peut énormément simplifier certaines choses, mais pas remplacer le Javascript. Prenons un exemple : une page où on doit choisir un intervalle de date, avec trois champs : date de départ, date de fin, durée. On peut utiliser le Javascript pour afficher une popup calendrier quand un champ date reçoit le focus, calculer la durée quand la date de fin est modifiée, calculer la date de fin quand la durée est modifiée. C'est bien plus simple à faire avec Javascript.

Ceci dit, l'écriture d'applications WEB en une page est effectivement assez complexe, et on utilise déjà le HTML comme template. Un support natif pourrait effectivement faciliter le travail.

[Aiekick]

ca changeras rien..

quand on avait des modem 56K, les contenu étaient moins dynamique et les pages ce chargeait lentement.
A l'air de l'adsl, les pages ce chargent lentement (moins quand méme ), parce que comme les connexion sont plus véloce, bah du coup on charge beaucoup plus les pages web.
si on fait un nouveau system qui améliore le chargement, les pages vont encore plus être chargé avec tout un tas de contenu media..

C'est comme les software, a l'air des 486; les application tournait pas si mal finalement
A l'ait des Pentium, la puissance des machine a augmenté, donc on a commencé a codé dégueulasse en perf mais maintenable.
Et maintenant on se traîne des soft mal conçu, mal optimisé mais rapide a dev, qui fait que le surcroît de puissance par rapport au 486, ne nous apporte finalement que peu de plus value dans beaucoup de cas.

[Golgotha]

C'est un troll ?

Non parce-que, le mec a t'il conscience que c'est totalement le contraire qui se passe, des équipes de tout bord bosse sur des lib/framwork js, et c'est pas près de changer.

C'est juste un buzz quoi. Sinon je trouve sont idée très mauvaise, ça prouve juste qu'en tant que développeur web, il est complètement à la rue.

[Paleo]

Attention car cet article est une interprétation un peu cavalière de la proposition initiale. Tout d'abord cette proposition est un simple e-mail envoyé sur une mailing list du WHATWG (et non du W3C, même si l'archive y est hébergée).

Cela forcerait le navigateur à charger les données dans un nouveau modèle d’objets en remplacement du DOM qui permet pour l’heure d’effectuer des changements sur une page dynamique.

Cette phrase fait croire que l'auteur suggère de remplacer le DOM par autre chose. L'auteur parle d'éléments du DOM qui deviendraient remplaçables, comme c'est le cas lorsqu'on définit des éléments dans un template.

Cette proposition, si elle aboutit, permettra selon Bobby Mozumder, de réduire le temps de réponse d’une page dynamique en la faisant passer à intervalle compris entre 10 et 50 ms contre 300 à 1500 ms pour le chargement des pages actuelles

Ce n'est pas ce que dit l'auteur. Il parle des SPA actuelles, en mentionnant qu'il est plus rapide de charger des données en JSON que de recharger toute la page HTML.

[yahiko]

Je suis allé recherché les réactions anglo-saxonnes qui sont souvent préférés à certains experts francophones (allez savoir pourquoi) :
Le consensus général est globalement mauvais.

Lots of very bad ideas here -- backwards-incompatibility with previous versions of HTML is always a good litmus test that a proposal hasn't been thought through. The main thing is that this doesn't solve any problem that exists. We can already do everything his proposal would enable; all this does is make it more inflexible.

Traduction : Beaucoup de mauvaises idées ici --- l'absence de rétro-compatibilité avec les versions antérieures de HTML est toujours un bon indicateur des raisons pour lesquelles cette proposition n'a été approfondie. Le point essentiel est que ceci ne résout aucun problème qui existe actuellement. Nous pouvons déjà faire tout ce que cette proposition permettrait ; et celle-ci rendrait les choses plus rigides.

source : InfoQ

[mrqs2crbs]

Dans le cadre des propositions pour le prochain standard du web (HTML6), Bobby Mozumder, éditeur en chef du magazine de mode FutureClaw et développeur Web, vient de proposer une nouvelle piste pour l’exécution dynamique des pages HTML sans recourir à JavaScript afin de réduire le temps de chargement des pages web.

Pour lui, le fait de charger et compiler JavaScript à chaque appel constitue une perte de temps dont on peut s’en passer.

Salut à tous,

bon, ben j'ai été jeter un oeil sur le site futureclaw.com, j'ai pris une page au pif :
http://www.futureclaw.com/fashion/ca...015.html#look1

le résultat est assez édifiant (sur Firefox; j'ai l'adsl, mais pas la fibre):
avec/sans mise en cache:
taille : 469.46ko / 58782.25 ko
durée : 9.49 sec / 1026 sec (là, je dis chapeau l'artiste)
réponse mise en cache : 485 / 0
nombre de requêtes : 493 / 493

le type il est quand même capable de balancer environ 500 images (soit presque la totalité du poids de la page) d'un coup sur une page.

alors, c'est vrai y pas un pet de js sur ces pages,
mais avant d'imaginer une solution de remplacement, il devrait mettre un peu d'ajax ça allégerait un chouïa la navigation.

cordialement.

[xurei]

En fait il veut juste intégrer un moteur de template dans la norme HTML. J'ai envie de dire pourquoi pas... C'est pas si con de permettre au browser de fabriquer un template directement en natif.

Mais de là à dire qu'on va pouvoir se passer de JS, je me marre !

[Sodium]

Pense-t-il sérieusement que le temps de chargement des script sera encore un problème pour les terminaux grand public d'ici à ce que son idée soit éventuellement mise en place et adoptée par un nombre suffisant d'utilisateurs ?

[Greg-dev]

C'est drôle parce que perso pour un chargement de page sans tenir compte du JS j'utilise quelque chose qui existe déjà. Les attributs async et defer de la balise script.

Et puis HTML6 pour un truc qui n'a plus rien à voir avec du HTML, plutôt choisir un autre nom.

[yahiko]

La balise script, c'est du JavaScript.

Edit : Ne tiens pas compte de ma remarque, j'ai mal compris ce que tu voulais dire.

[SylvainPV]

Ces dernières années, on s'est focalisé sur la performance des scripts. Aujourd'hui on a des moteurs JS à compileur JIT ultra-optimisé, le multiplexage de HTTP/2, les subsets comme asm.js et plein de nouvelles API dédiées perf comme les Web Workers, le SIMD ou encore les Array typées. JavaScript n'a jamais été aussi rapide ! Les chiffres donnés par Bobby sur le temps de réponse des pages dynamiques sont sortis du chapeau, tout comme les gains supposés de sa proposition.

[macslan]

Ces dernières années, on s'est focalisé sur la performance des scripts. Aujourd'hui on a des moteurs JS à compileur JIT ultra-optimisé, le multiplexage de HTTP/2, les subsets comme asm.js et plein de nouvelles API dédiées perf comme les Web Workers, le SIMD ou encore les Array typées. JavaScript n'a jamais été aussi rapide ! Les chiffres donnés par Bobby sur le temps de réponse des pages dynamiques sont sortis du chapeau, tout comme les gains supposés de sa proposition.

Il faudrait pas non plus oublié l’accessibilité du site

[thelvin]

Après moi, je parlerais pas tant de questions de performances, je demanderais pourquoi j'ai besoin d'un langage de script et de construire un objet XMLHttpRequest et des appels asynchones sans queue ni tête, pour que mon bouton +1 ne recharge pas ma page HTML.

On en voit tout le temps en section HTML, qui demandent en gros "comment je fais <truc clairement AJAX>" sans avoir la moindre idée de ce qu'est AJAX, que tout ce qu'ils connaissent marche avec ça, et en soupçonnant à peine qu'il faudra peut-être du JavaScript.
... Et bon, je suis désolé, mais d'un point de vue bon sens et ingénierie, je les comprends un peu. À la rigueur on peut considérer que pour faire ça il faut une "extension HTML" et que ça s'installe avec des polyfills, mais c'est pas vraiment comme ça que c'est présenté.

Il faudrait pas non plus oublié l’accessibilité du site

Je veux bien, mais il y a aucune raison que ce truc-là fasse mieux qu'Angular et similaires.

[SylvainPV]

L'accessibilité n'est pas vraiment un problème, on a des enjeux accessibilité forts sur certains de nos projets grand public faits en Backbone et Angular et on s'en sort très bien. Le templating et routage côté client ne viennent pas "casser" les outillages existants, que ce soit des screen readers, des user stylesheets pour déficients visuels ou des contrôles alternatifs pour déficients moteurs. C'est plus pour la SEO que ça pose un souci, on est obligé de détecter les robots indexeurs et leur fournir des versions adaptées des pages. Mais je pense que c'est aux outils d'indexation d'évoluer, pas aux développeurs web d'être retenu en arrière à cause d'eux.

[macslan]

L'accessibilité n'est pas vraiment un problème, on a des enjeux accessibilité forts sur certains de nos projets grand public faits en Backbone et Angular et on s'en sort très bien. Le templating et routage côté client ne viennent pas "casser" les outillages existants, que ce soit des screen readers, des user stylesheets pour déficients visuels ou des contrôles alternatifs pour déficients moteurs. C'est plus pour la SEO que ça pose un souci, on est obligé de détecter les robots indexeurs et leur fournir des versions adaptées des pages. Mais je pense que c'est aux outils d'indexation d'évoluer, pas aux développeurs web d'être retenu en arrière à cause d'eux.

Enfin je parle pas des robots je parle de personnes ayant un déficit visuel ou autre problème

[Paleo]

Les chiffres donnés par Bobby sur le temps de réponse des pages dynamiques sont sortis du chapeau, tout comme les gains supposés de sa proposition.

Disons qu'on les comprend mieux si on lit l'explication originale.

[antoyo]

(…) Comment faire du conditionnel sans code, il faudra bien y mettre de la logique à un moment ou l'autre ?

Dans mon projet ces.js, j’ai pensé à ce problème et voici un exemple qui montre la solution à laquelle j’avais pensé :

Code css :

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

1
2
3
4
5
6
7
8
9
10
#toggleButton $click {
    .red {
        class: -red +blue;
        color: blue;
    }
    .blue {
        class: +red -blue;
        color: red;
    }
}

La deuxième ligne est une condition. Elle se lit : « si l’élément contient la classe "red", applique les transformations entre les accolades ».
(pour information, le "class: -red" permet d’enlever la class "red" de l’élément tandis que "class: +red" permet de l’ajouter)

Bien sûr, avec une solution comme ces.js, nous avons toujours besoin de JavaScript (c’est un mal nécessaire), mais on peut s’en passer de temps à autre pour ajouter du dynamisme à la page web.

[MikeRowSoft]

Dans un environnement impartial pour la mesure de performance... Pourvu que sa résolution n'entraine pas à réduire les libertés des designers par la suite.

[pprem]

Si le problème n'est en réalité que le temps de chargement et d'exécution, que les navigateurs nous permettent d'embarquer du JS déjà compilé et on n'en parlera plus.

mais l'idée de gérer le HTML comme des morceaux de page qui s'autochargent "automatiquement" selon les actions de l'utilisateur, j'ai rien contre, sauf que ça veut dire qu'il faut un serveur qui gère les interactions, ce qui n'est pas obligatoire pour une application onpage n'ayant pas de nécessité d'éléments extérieurs. et puis JS, c'est quand même le top pour les jeux sur navigateur. vouloir s'en passer est à mon avis une belle connerie, même si l'intérêt d'aller plus loin dans l'intégration d'automatismes est grand.

[SylvainPV]

Inutile de se faire du mourron: c'est juste un message relativement quelconque, d'une personne relativement quelconque, dans un topic de réflexion relativement quelconque. J'imagine que le mot-clé HTML6 (malgré qu'on s'était mis d'accord pour ne plus versionner HTML après HTML5) et l'idée directrice assez originale ont suffit à faire le buzz. On peut discuter de l'idée, mais ça n'ira pas beaucoup plus loin que ça. Sauf si le monde entier trouve ça génial et buzze sur twitter. S'il vous plaît, ne buzzez pas ça.