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.
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.
Tu devrais détailler ton README.md
Dommage on ne voit pas le code de ton "framework" qui correspond aux exemples. Des "frames" à la JS Fiddle feraient surement le boulot.
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à.
Mais si voyons comme les opérateurs de MongoDB, ca te donne pas envie :
Ca te fait pas rêver ?
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: { ...} }}, ... ] }
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.
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.
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 ?
Partager