Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
La nouvelle norme pourrait déjà commencer par interdire la possibilité d'import de code javascript et/ou de limiter le nombre de lignes ou le poids total en kilo-octets des scripts associés à une page. Le problème de javascript c'est l'usage abusif qui en est fait. Certains sites envoient presque un méga-octets de fichiers js pour "dynamiser" une page, c'est insensé.
Pour réduire le temps de chargement des pages utilisant js, on pourrai tout simplement le compiler en bytecode pour améliorer les performances. En plus les entreprises seront contente elle pourront encore plus proteger leur code source.
En gros il voudrai inclue dans les navigateurs les templates comme dans emberJS/Handlebars ou Angular.
Il est vrai que çà éviterai que le javascript "compile" les templates.
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.
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.
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.
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).
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.Envoyé par Olivier Famien
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.
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.
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.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.
source : InfoQ
réactif .... poil au ...
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.
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 !
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 ?
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.
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
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é.
Je veux bien, mais il y a aucune raison que ce truc-là fasse mieux qu'Angular et similaires.
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.
Disons qu'on les comprend mieux si on lit l'explication originale.
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.
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.
Répondre avec citation
Partager