La proposition m'a parrut humoristique au début, mais à la réflexion. Actuellement on utilise des minifieur pour balancer au client quelque chose le plus petit possible. Si on laisse le minimum de travail au niveau du client (il prend du code et il l'exécute dans un bac à sable), on doit nettement gagner en performance.
Je pense que les VM (JVM, parrot, .Net, etc) ont une carte à jouer dans le domain avec forte isolation entre l'espace mémoire où s'exécute le code reçu et celui des programmes natifs.
Là où il y a un vrai problème c'est pour l'adoption. Tu peut difficilement avoir d'étape transitoires pour passer de l'un à l'autre (et surtout elle reporte les possibilités d'étape transitoires sur le client et pas sur le serveur).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Puisque nous ne sommes pas vendredi...
Posté par barmic . En réponse à la dépêche Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?. Évalué à 2.
La proposition m'a parrut humoristique au début, mais à la réflexion. Actuellement on utilise des minifieur pour balancer au client quelque chose le plus petit possible. Si on laisse le minimum de travail au niveau du client (il prend du code et il l'exécute dans un bac à sable), on doit nettement gagner en performance.
Je pense que les VM (JVM, parrot, .Net, etc) ont une carte à jouer dans le domain avec forte isolation entre l'espace mémoire où s'exécute le code reçu et celui des programmes natifs.
Là où il y a un vrai problème c'est pour l'adoption. Tu peut difficilement avoir d'étape transitoires pour passer de l'un à l'autre (et surtout elle reporte les possibilités d'étape transitoires sur le client et pas sur le serveur).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)