Discussion :

[Invité]

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

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

[yahiko]

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

[jfiloubarberousse]

c'est une bonne idée

[Invité]

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 !)

[N4gashi]

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.

[landry161]

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

Enfin quelqu' un du même avis que moi

[N4gashi]

Enfin quelqu' un du même avis que moi

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

[4sStylZ]

@antoyo

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

[Paul TOTH]

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

[Arno_94]

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.

[RyzenOC]

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.

[thelvin]

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.

[Darkaurora]

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

[SylvainPV]

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

[Thorien]

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

[Spartacusply]

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

[tralloc]

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

[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.
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) .

[thelvin]

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.

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.