Oui, mais le bycode est caché. Donc des étapes fastidieuses sont répétées inlassablement (analyse syntaxique, lexicale, compilation vers le bytecode) là où du bytecode limiterai la charge au client. On a aussi des fichiers qui sont du coup plus lourd (ils gardent des identifiants ASCII).
Le petit plus c'est qu'il apporte au développeur une grande liberté dans le langage utilisé :
parro : perl et les langages parro
JVM : Java, groovy, scala
.Net : C#, VBScript, J# (c'est mort ou pas déjà ?)
C'est un peu comme le fait de prendre un langage et de lui faire cracher du HTML pour l'envoyer au client, sauf que là c'est du bytecode.
C'est aussi quelque chose qui se fait pour les CSS avec des outils comme lesscss, blueprint ou autre.
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é à 1.
Oui, mais le bycode est caché. Donc des étapes fastidieuses sont répétées inlassablement (analyse syntaxique, lexicale, compilation vers le bytecode) là où du bytecode limiterai la charge au client. On a aussi des fichiers qui sont du coup plus lourd (ils gardent des identifiants ASCII).
Le petit plus c'est qu'il apporte au développeur une grande liberté dans le langage utilisé :
C'est un peu comme le fait de prendre un langage et de lui faire cracher du HTML pour l'envoyer au client, sauf que là c'est du bytecode.
C'est aussi quelque chose qui se fait pour les CSS avec des outils comme lesscss, blueprint ou autre.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)