Un développeur donne des pistes pour l’exécution des pages dynamiques sans recourir à JavaScript

bah m**de, moi qui commence a peine a maitriser correctement jQuery:aie:

Effet d'annonce ou pas?, html5 forké, ... j'y crois pas, on m'a dit depuis 2004 que javascript allait mourir ... il y a eu ajax ... on m'a dit que js allait mourir ... il y a le côté obscur (nodejs) ... et encore j'entends que JS risque de mourir vous comprenez mon sentiment :( aujourd'hui lorsque j'entends cette annonce depuis 11 ans et toujours rien au contraire...

Qu'on soit pour ou contre, c'est surtout l'inverse qui se produit.

c'est une bonne idée

Si il peuvent intégrer Angular et l'accès aux fichiers... alors, les autres langages ont un sérieux soucis à se faire ! (Surtout si ils intégrent Angular !):mrgreen:

Je pense que ce qu'il veut remplacer, c'est la modification du DOM via Javascript et rajouter une couche qui permettrait de faire du databinding (suffit de regarder l'exemple posté).

C'est une très bonne chose à mon avis, effectivement on va changer un peu les fondations de l'HTML qui va devenir bien plus moderne et adapté aux compétences et usage des développeurs d'aujourd'hui. Mais ça reste pour du bon, à savoir que la manipulation du DOM via l'API JSON permettra de se placer dans la dynamique des API RESTful, et que le databinding nous permettra de nous passer de librairies telles qu'Angular qui, malgré le fait qu'elles soient bonnes, restent des librairies qui sont à charger et plutôt lourdes.

Si son idée se concrétise, ça sera une bonne chose pour le web en général à mon avis.

Citation:

---

Envoyé par yahiko

Le gars devrait d'abord réfléchir à comment nous débarrasser de CSS.

---

Enfin quelqu' un du même avis que moi :mrgreen:

Citation:

---

Envoyé par landry161

Enfin quelqu' un du même avis que moi :mrgreen:

---

Avant de cracher sur CSS, vous avez une solution de remplacement tout aussi extensible ? :zoubi:

@antoyo

Projet intéressant. Manquerait pu qu'à compiler ta bibliothèque au sein d'un navigateur.

ce qu'il manque surtout ce sont des fonctionnalités étendues dans le navigateur qui n'est pas prévu pour de l'applicatif au départ.

- fenêtre popup
- masques d'éditions
- grille de données, modifiable, triable, ...
- compression de données
- cryptologie
- etc...

tout cela se fait aujourd'hui en Javascript sur la base du DOM

En gros, il nous propose d'apprendre un nouveau mode de développement sans garantir que ça sera aussi puissant et accessible que l'est devenu JavaScript grâce à des frameworks tels que jQuery ou Angular.

Ce dernier ne cesse de s'améliorer et permet d'avoir du code bien structuré et à l'arrivée, assez simple à maintenir, ce qui était loin d'être le cas lorsqu'on travaillait en JS "tout nu".

Bref, de loin, ça ressemble à "changer pour changer".

Bien entendu, si cette solution apporte les mêmes avantages tout en améliorant les temps de chargement, on s'y intéressera fatalement mais on en est pas encore à pouvoir tirer ce genre de conclusion.

Il est donc urgent d'attendre.

Citation:

---

ce qu'il manque surtout ce sont des fonctionnalités étendues dans le navigateur qui n'est pas prévu pour de l'applicatif au départ.

- fenêtre popup
...

---

J'ai abandonné les pop-up depuis 3ans au profit des lightbox jquery.

Je n'aime pas les pop-up car sa "bloque" tous le navigateur, au lieu d'une lightbox qui bloque juste le site.

Citation:

---

Envoyé par sazearte

J'ai abandonné les pop-up depuis 3ans au profit des lightbox jquery.

Je n'aime pas les pop-up car sa "bloque" tous le navigateur, au lieu d'une lightbox qui bloque juste le site.

---

C'est très certainement ce qu'il voulait dire.

Ta lightbox tu l'as avec jQuery, c'est pas un mécanisme fourni avec HTML + court JavaScript. Au contraire des pop-ups, qui se font avec un simple window.open() mais qui emmerdent tout le monde.

Ces pop-under, c'est jamais que la fonctionnalité d'une pop-up, mais correctement limitée à la portée du tab fourni par le visiteur, pour ne pas lui pourrir la vie. Et dans ce monde où on fait de l'applicatif sur les sites webs, c'est très utilisé, normal. D'où manque d'un moyen simple, intégré, direct de le faire.

Et comment peut on imaginer un tel changement sans avoir demandé l'avis de Microsoft, Google et Mozilla ?

D'autres aussi proposent de se débarrasser de JavaScript... le 1er avril
http://ajaxian.com/archives/intent-t...ove-javascript

Le gars s'est mangé une réponse 1h25 après son troll :

https://lists.w3.org/Archives/Public...5Mar/0072.html

Du coup changement du sujet : "relayer le troll, n'est ce pas troller ?"

A la lecture des "news" de developpez, j'avoue me poser de plus en plus de questions sur la direction que prends le site. On a presque l'impression de lire des "news" yahoo ; c'est dire ...

Le language HTML étant un language de balisage, ça me paraît complètement impossible de proposer ce que fais le javascript juste avec le balisage. Ou alors ce n'est plus du HTML.

De toutes façons le job du HTML c'est le fond d'un site pas sa forme, donc à partir de là emballé c'est pesé !

L'article n'est pas assez précis pour qu'on puisse se faire une idée

Si j'ai compris l'objectif, il est de diminuer le temps d'exécution mémoire à l'intérieur du navigateur, en contre-partie, on devra charger du code JSON.
Or si l'on analyse les temps passés dans les navigateurs, ce ne sont pas les temps "CPU" les plus longs, mais les temps de chargement des données, des images ou du code.
Pour nous faire gagner des millisecondes en CPU ne risque-t-on pas de perdre des centièmes de secondes (voir plus si c'est un smartphone) dans des connexions pour charger du JSON !
Et fin du JavaScript mais début d'un nouveau langage qui ne sera pas forcement plus facile à mettre en œuvre (une structure JSON complexe n'est pas forcement facile à lire) .

Citation:

---

Envoyé par peterdan

Si j'ai compris l'objectif, il est de diminuer le temps d'exécution mémoire à l'intérieur du navigateur, en contre-partie, on devra charger du code JSON.

---

Nope.
L'objectif annoncé est d'arrêter de nécessiter JavaScript pour un usage qui est devenu basique, et qui ne demande aucune forme de programmation, donc ne justifie pas un langage de programmation. Dans le cas présenté, JavaScript est là non pas parce que c'est son rôle, mais pour implémenter une fonctionnalité qui n'est pas fournie par les navigateurs (car pas non plus par HTML lui-même). JavaScript est un polyfill pour un truc qui n'existe pas, quoi.

Tant qu'à faire, cela permettrait de se passer d'inclure des bibliothèques JavaScript lourdes juste pour faire une fonctionnalité web basique, mais c'est plus un à-côté que le véritable objectif.


Quand il parle des temps d'exécution, il parle de l'intérêt de la technique "site d'une seule page qui ne se recharge jamais," peu importe de quelle manière on implémente cette technique. Elle est appréciée parce que la navigation est plus rapide et plus agréable pour l'utilisateur.
La proposition ne change rien ou pas grand-chose à ces temps d'exécution-là. Mais elle les préserve et le fait sans JavaScript artificiel.

Voilà en gros l'idée.

Citation:

---

Envoyé par peterdan

Or si l'on analyse les temps passés dans les navigateurs, ce ne sont pas les temps "CPU" les plus longs, mais les temps de chargement des données, des images ou du code.
Pour nous faire gagner des millisecondes en CPU ne risque-t-on pas de perdre des centièmes de secondes (voir plus si c'est un smartphone) dans des connexions pour charger du JSON !
Et fin du JavaScript mais début d'un nouveau langage qui ne sera pas forcement plus facile à mettre en œuvre (une structure JSON complexe n'est pas forcement facile à lire) .

---

Les techniques actuelles ne sont pas magiques. Elles font déjà ça ou pire de toute façon.

Citation:

---

Envoyé par Olivier Famien

Que pensez-vous de cette proposition ?
Aura-t-elle du succès quand on sait que la tendance actuelle est à l’usage de JavaScript ?

---

Que cette personne ne me semble pas très réfléchi ... Pour le templating, il y a les Web Components. Et il veut créer un nouveau langage à interpréter, à quoi bon puisqu'on en a déjà un ?
Je vois rien de différent avec les techniques Ajax actuelles, récupération de données JSON ou DOM et injection dans la page ... La liberté en moins pour de la custo.

En plus cela va à l'encontre des architectures orientées service (dont RESTful) où délivre de la "donnée" et c'est au client de s'adapter. Là, il faut adapter le service au client ...

Et cela va également à l'encontre de la volonté actuelle de ne plus trop faire évoluer les standards HTML mais laisser les APIs proposés les améliorations nécessaires.

Si c'est juste la récupération et la compilation du JS qui lui pose problèmes, il existe les caches et les CDN. Il suffit alors aux navigateurs de garder également la version compilée en cache (peut-être est-ce déjà le cas ?)

Ce qui est assez marant c'est de voir que Facebook fait le constant inverse avec React.js, le JS est plus rapide que le DOM. Je n'ai pas fait le test mais je suppose que si une grosse boîte comme Facebook investit, c'est qu'il doit y avoir une bonne part de véridique.

Citation:

---

Envoyé par antoyo

J’avais déjà pensé à un truc pour faire du dynamisme dans une page web sans JavaScript.
L’idée que j’avais eu était un langage similaire à CSS, mais permettant de réagir aux événements.

---

Plutôt intéressant sur la forme mais je suppose que ca doit rester des traitements simples du genre "switch". Surement une idée à creuser pour aboutir
à quelque chose qui permette de traitements des cas plus complexes.

Citation:

---

Envoyé par antoyo

Les seules parties qui différent du CSS sont l’événement "$click" et les attributs spéciaux genre "text".
J’ai programmé un script… en JavaScript… convertissant ce langage en JavaScript, ce qui permet de l’utiliser dans une page web.
Vous pouvez trouver le code ici.

---

Tu devrais détailler ton README.md ;)

Citation:

---

Envoyé par antoyo

Et voici une page utilisant cela.

---

Dommage on ne voit pas le code de ton "framework" qui correspond aux exemples. Des "frames" à la JS Fiddle feraient surement le boulot.

Citation:

---

Envoyé par antoyo

Code:

---

1 2 3 4 5 6 7 8 9 10

#toggleButton $click { .red { class: -red +blue; color: blue; } .blue { class: +red -blue; color: red; } }

---

---

Je serais plus partant pour partir sur un principe de "state". D'un côté on a une partie déclarative qui permet de modifier simplement, les états qui sont gérables en tant que sélecteur CSS (classe, attribut, état) pour la gestion de l'affichage, le CSS gère déjà.

Citation:

---

Envoyé par TiranusKBX

je vois mal comment il est possible de réaliser des fonctions aussi complexe que le permette le JavaScript uniquement avec des objets JSON très formaté
si il veut éviter de charger des scripts externe il peut déjà mettre son code js dans son HTML

Pour réaliser ces ambitions il devrait alors créer quelque-chose de fondamentalement différent du html actuel

---

Mais si voyons comme les opérateurs de MongoDB, ca te donne pas envie :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

{code: [ {$for:{ $init:{var=["i"]}, $while:{i:{$lt:4}}, $inc:{i:$inc}, $block: { ...} }}, ... ] }

---

Ca te fait pas rêver ? :aie:

Citation:

---

Envoyé par 23JFK

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é.

---

Je vois pas de raison de mettre de telles limitations dans un standard. Si pour une page simple ca ne justifie pas, aujourd'hui le Web se compose également de véritables "applications". Avec les frameswork moderns, une page Web devient un client graphique comme un client lourd.

Si la page devient ingérable en terme d'utilisabilité, les utilisateurs s'en détourneront. Et les développeurs seront contraint à faire un régime. Et puis si les caches sont bien gérés, il n'y a aucun soucis.

Citation:

---

Envoyé par derderder

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.

---

Pourquoi un bytecode ? C'est au moteur JS de gérer l'exécution du JS. Eventuellement le couple navigateur/moteur JS peut mettre en cache une version plus ou moins compilé mais ce n'est pas du ressort d'HTML/JS/CSS.

Citation:

---

Envoyé par grunk

Plus sérieusement le développeur ne propose pas de supprimer JS mais de faire ce que font actuellement les framework du type angularjs avec leur data-binding directement dans le html. Ce qui en soit n'est pas idiot puisqu'on s’épargne le chargement d'un lib et on passe par des traitement natif dans la navigateur et plus par du js interprété.

---

Citation:

---

Envoyé par thelvin

Oui bon, le gars il veut faire les templates d'Angular mais sans JavaScript. Je dis pas que c'est stupide mais c'est pas vraiment révolutionnaire. Au bout d'un moment c'est jamais que des iframe un peu plus souples.

---

Citation:

---

Envoyé par bilgetz

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.

---

Les Web Components offrent déjà le mécanisme de template. Le seul manque c'est le data binding. Et le problème à ce niveau c'est que chacun voit midi à sa porte. Certains veulent utiliser des éléments DOM, d'autres du JSON et d'autres un scope JavaScript.

Le must serait un moyen d'attacher des données à un template comme on peut le faire avec les Composite components de JSF2. Une évolution dans ce sens de la spécification des Web Components me parait une bien meilleure proposition.

Sinon pourquoi pas passer par du XSLT ?

Citation:

---

Envoyé par headmax

Effet d'annonce ou pas?, html5 forké, ... j'y crois pas, on m'a dit depuis 2004 que javascript allait mourir ... il y a eu ajax ... on m'a dit que js allait mourir ... il y a le côté obscur (nodejs) ... et encore j'entends que JS risque de mourir vous comprenez mon sentiment :( aujourd'hui lorsque j'entends cette annonce depuis 11 ans et toujours rien au contraire...

---

Ouais AngularJS,Ember.Js et d'autres. malheureusement il est toujours là
:mouarf::mouarf::mouarf::mouarf:

Citation:

---

Envoyé par Logan Mauzaize

Les Web Components offrent déjà le mécanisme de template

---

Négatif, ne te laisse pas avoir par le nom de la spécification. La balise <template> ne fait pratiquement rien, même pas de la simple interpolation de données. Une bibli de templating sera donc toujours nécessaire.
voir : http://sylvainpv.developpez.com/publ...nts-debat/#LIV

Citation:

---

Envoyé par SylvainPV

Négatif, ne te laisse pas avoir par le nom de la spécification. La balise <template> ne fait pratiquement rien, même pas de la simple interpolation de données. Une bibli de templating sera donc toujours nécessaire.
voir : http://sylvainpv.developpez.com/publ...nts-debat/#LIV

---

Je préfère faire la distinction entre template (qui par définition est une coquille vide) à binding (qui sert à dynamiser un contenu). On peut faire du binding sans template et du template sans binding.

Comme je le disais le support du binding (quelque soit l'approche) est surement une intéressante évolution des web components. Parmis les formes possibles j'aime bien ce qu'il est possible de faire avec les "interfaces" des Composite de JSF.

Du template sans binding ? Du HTML statique en somme ? Pas sûr de saisir tes définitions... Mais je ne vois toujours pas le rapport avec les Web Components, on faisait déjà du templating des années avant les premières ébauches de cette spec.

Citation:

---

Envoyé par SylvainPV

Du template sans binding ? Du HTML statique en somme ? Pas sûr de saisir tes définitions...

---

Pour moi un template est un morceau réutilisable, éventuellement à customiser. Et rien n'empêche de modifier le template instancié.

Le binding c'est pour moi la capacité de lier (bind) des données avec un contenu : il peut s'agir d'un template ou d'une page "brute".

Citation:

---

Envoyé par SylvainPV

Mais je ne vois toujours pas le rapport avec les Web Components, on faisait déjà du templating des années avant les premières ébauches de cette spec.

---

Surement mais pas en standard. En plus, tu peux instancier le template directement dans la page, pas besoin de JS pour ça.
On faisait aussi des "applications Web" avant HTML5 ...

Après je veux bien admettre que la spec est incomplète. Mais je pense qu'il vaut mieux repartir sur cette base plutôt que de réinventer la roue ... Après ce n'est que mon avis, il vaut ce qu'il vaut.

La spec des WebComponents est plus qu'incomplète en matière de templating: elle est inexistante. Les spécifications de l'élément <template> ne font plus parties de l'ensemble WebComponents au W3C :
http://www.w3.org/wiki/WebComponents/
http://www.w3.org/TR/2014/NOTE-html-templates-20140318/

Les Web Components ne sont pas une solution de templating, et ils n'ont pas vocation à le devenir. Il n'existe aucun standard en cours d'élaboration susceptible de remplacer le templating JavaScript. Et d'après moi, il vaut mieux ne jamais essayer de standardiser cet aspect. React est l'illustration parfaite que même après dix ans de solutions diverses et variées de templating / data-binding, on arrive encore à trouver de nouvelles approches innovantes et performantes.

Citation:

---

Envoyé par Logan Mauzaize

Sinon pourquoi pas passer par du XSLT ?

---

XSLT en soi n'est carrément pas fait pour du dynamique, essayer de le plier là-dedans ça ferait de la merde.
Maintenant si l'idée c'est d'en reprendre des portions, celles où ça n'a pas d'importance si c'est statique ou dynamique, là il y a de l'idée.

Citation:

---

Envoyé par SylvainPV

La spec des WebComponents est plus qu'incomplète en matière de templating: elle est inexistante. Les spécifications de l'élément <template> ne font plus parties de l'ensemble WebComponents au W3C :
http://www.w3.org/wiki/WebComponents/
http://www.w3.org/TR/2014/NOTE-html-templates-20140318/

---

Non, puisque <template> fait partie de la norme HTML5 : http://www.w3.org/TR/html5/scripting...mplate-element
(trouvé sur le 2e lien)

Citation:

---

Envoyé par SylvainPV

Les Web Components ne sont pas une solution de templating, et ils n'ont pas vocation à le devenir. Il n'existe aucun standard en cours d'élaboration susceptible de remplacer le templating JavaScript. Et d'après moi, il vaut mieux ne jamais essayer de standardiser cet aspect. React est l'illustration parfaite que même après dix ans de solutions diverses et variées de templating / data-binding, on arrive encore à trouver de nouvelles approches innovantes et performantes.

---

Avec ce genre de raisonnement, on peut tout aussi bien abandonné la standardisation HTML. Les outils (ex. : React) se chargent déjà de proposer de nouvelles approches. Sans proposer quelque chose allant aussi loin que certains frameworks, on aurait pu ajouté un peu de dynamisme de manière simple. Après perso, le JS ne me choque pas mais c'est juste chiant de devoir manipuler le DOM manuellement pour injecter des valeurs (ex: attributs, élément) fournis lors de l'utilisation de la nouvelle balise.

Citation:

---

Envoyé par thelvin

XSLT en soi n'est carrément pas fait pour du dynamique, essayer de le plier là-dedans ça ferait de la merde.
Maintenant si l'idée c'est d'en reprendre des portions, celles où ça n'a pas d'importance si c'est statique ou dynamique, là il y a de l'idée.

---

Bah une des utilisations de XSLT c'est justement de renvoyer des données + la feuille de style appropriée à la demande (content-type), pour générer le contenu approprié.
Par exemple avec les navigateurs tu peux leur envoyer un XML + une feuille XSL et ils t'afficheront une page si cela génère du HTML. Alors pourquoi pas l'utiliser pour des fragments ?

De toutes façons, la proposition consitait à manipuler un XML pour en faire du (X)HTML alors autant partir sur un standard (qui plus est déjà géré par les navigateurs). Ou au minimum utilisé XQuery ou les selecteurs CSS.

Je n'ai jamais dit que <template> ne faisait pas partie de la spec HTML5, j'ai dit que ça ne faisait plus partie des Web Components. C'est de là que mon vient mon commentaire initialement, pour bien faire comprendre que les Web Components et le templating sont deux choses très distinctes. Pourquoi la spec HTML templates a-t-elle été retirée de la section Web Components d'après toi ? Il faut arrêter de laisser croire que les Web Components vont apporter une solution à tout.

Quand il existe des dizaines d'approches possibles et valables pour un même besoin, un standard est purement réducteur. Les auteurs de la spécification HTML Templates en ont clairement conscience: si tu regardes les archives de mails échangés du W3C en 2012 sur le sujet, tu verras qu'ils se sont triturés le cerveau pendant des mois sans parvenir à trouver un compromis sur l'approche à utiliser. A un moment ça parlait de <template> imbriqués les uns dans les autres avec des <script> à côté pour gérer les règles logiques, ça devenait n'importe quoi et je suis bien content qu'ils aient laissé tombé l'idée.

Pourquoi la vitesse plutôt que de simplifier le langage.
Avec des ordinateurs qui sont de plus en plus puissant
et un internet plus rapide. Toujours changer pour du
plus compliqué au final. Un génocide d'un langage pour
quelques secondes de moins.

Je loue vraiment le courage de Mr Bobby d'avoir eu une idée aussi géniale mais la vrai question que je me pose c'est, est-ce-qu'évitant le javascript nous ne limitons pas certaines fonctionnalités d'une page dynamique ?

Le sujet date de mars 2015 et heureusement il est enterré.
Mr Bobby à eu une idée débile qui fut rejetée 1/2heure après avoir été émise sur le site du W3C, c'est sans doute un record !

D'ailleurs, ce topic lui-même devrait être clos.

Qu'on aime ou non le JavaScript, ou le CSS, n'y changera rien.
1 ) Tout système de présentation à besoin d'une logique indépendante pour regrouper les notions de présentation, ici c'est le CSS.
2) Tout système interactif à besoin d'un langage, ici c'est le JavaScript.

Alors sans doute que le JavaScript ou le CSS ne sont pas parfaits; c'est pour cette raison que le W3C existe.