Discussion :

[Logan Mauzaize]

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.

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.

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

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.

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;
    }
}

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

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 javascript :

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

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 ?

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.

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.

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

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.

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 ?

[landry161]

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à

[SylvainPV]

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

[Logan Mauzaize]

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.

[SylvainPV]

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.

[Logan Mauzaize]

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

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.

[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/

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.

[thelvin]

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.

[Logan Mauzaize]

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)

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.

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.

[SylvainPV]

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.

[dancom5]

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.

[valencio01]

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 ?

[psychadelic]

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.