Next - WebAssembly : le format binaire du web a sa démo pour Chrome et Firefox

WebAssembly, qui ambitionne de devenir le code binaire du web, franchit une nouvelle étape. La technologie est en cours de test chez Apple, Google, Microsoft et Mozilla, certains proposant même des préversions aux développeurs intéressés.

WebAssembly est un projet commun des quatre entreprises pour s’occuper des problèmes de JavaScript. Comme nous l’indiquions ce matin, le langage de script est devenu omniprésent, au point d’être utilisé dans la conception de logiciels classiques. On le trouve évidemment surtout dans les pages web, où il permet de créer des services complets. Se pose alors la question des performances.

Gommer les problèmes du JavaScript

De nombreux travaux ont été menés sur les dernières années pour accélérer le traitement du JavaScript. C’est le cas des optimisations réalisées par Google sur le moteur V8, d’asm.js chez Mozilla, de Chakra chez Microsoft et ainsi de suite, chacun y allant de sa machine virtuelle ou de composants divers. Comment du coup garder les avantages de JavaScript, tout en gommant ses défauts, en particulier la sécurité et les performances ?

Apple, Google, Microsoft et Mozilla ont proposé en juin de l’année dernière leur solution : un bytecode, autrement dit un code intermédiaire, à mi-chemin entre le script et l’assembleur. Les développeurs Java et .NET notamment connaissent bien ce code, qui consiste en fait à prémâcher le travail du compilateur en lui fournissant un code précompilé. Les avantages proposés étaient multiples : performances, sécurité, une taille réduite des fichiers, un parsing très rapide du code via des types de variables très simples, etc.

Une première démonstration fonctionnelle

Lors de l’annonce cependant, l’ensemble du projet en était à un stade peu avancé, malgré les efforts manifestes des quatre entreprises. Évidemment, le travail a avancé, et ils sont prêts désormais pour une démonstration et des préversions de certains navigateurs. C’est Mozilla qui a ouvert le bal des annonces, via l’ingénieur Luke Wagner : « Je suis très heureux d’annoncer que WebAssembly a franchi une étape importante : il y a désormais de multiples implémentations expérimentales dans les navigateurs, toutes interopérables ».

Wagner indique que la route est encore longue mais que la synchronisation des éditeurs permet de présenter un résultat beaucoup plus probant au public. Même écho chez Microsoft, à travers Limin Zhu, responsable du développement du moteur Chakra : « En dépit de leur statut précoce, la démo démarre beaucoup plus rapidement qu’en utilisant uniquement asm.js, puisque les binaires WebAssembly ont une taille de fichier réduite et sont parsés plus rapidement que du JavaScript ordinaire ».

Un travail sur les performances avant tout

Du côté de chez Google, le message est peu ou prou le même : les performances sont clairement supérieures. Le responsable Seth Thompson explique par ailleurs que la prise en charge de WebAssembly se fait en aménageant une compatibilité dans la machine virtuelle V8, notamment en réutilisant le compilateur TurboFan. « Un décodeur WebAssembly spécialisé valide les modules en vérifiant les types, les indices de variables locales, les références de fonctions, les valeurs de retour et la structure du contrôle de flux en une seule passe ».

Pour autant, même si la démonstration fournie est fonctionnelle, les travaux nécessaires sont encore nombreux, sans parler des outils à fournir aux développeurs. Thomson en donne d’ailleurs une idée : « Nous prévoyons également plusieurs fonctionnalités pour le futur (notamment le multithreading, le dynamic linking et une intégration au DOM et au ramasse-miettes) et de continuer le développement des toolchains pour la compilation C, C++ et d’autres langages, via le backend WebAssembly LLVM et Emscripten ».

Chez Mozilla, les ambitions sont les mêmes. Le support de WebAssembly sera donc ajouté plus tard aux outils de développement de Firefox, notamment le débogueur et le profileur. Parmi les améliorations envisagées, l’éditeur souhaite également réduire le temps de lancement à froid et la préparation d’un lot complet d’opérateurs. Luke Wagner, qui travaille également au W3C, indique que ce dernier suit le développement de près en vue de standardiser l’ensemble.

Le succès passe par la séduction des développeurs web

Il est évident que WebAssembly pourrait jouer un grand rôle dans le développement web au cours des prochaines années. Le succès de la technologie passe cependant par une interopérabilité totale (ce qui est évidemment l’un des objectifs) et par des outils adaptés aux développeurs. La question du support par les navigateurs ne se pose évidemment pas, les sociétés travaillant sur le projet représentant tous les plus utilisés.

Actuellement, si l’on souhaite tester WebAssembly, il n’existe qu’un moyen de le faire : se rendre sur la nouvelle page mise en ligne sur le dépôt GitHub officiel. De là, on pourra récupérer une préversion de Chrome ou de Firefox compatible, puis revenir sur la page afin d’y lancer la démo, Angry Bots (basé sur le moteur Unity). Cette dernière est un jeu où l’on contrôle au clavier (déplacements) et à la souris (tir et visée) un personnage dans un complexe futuriste, rempli de robots meurtriers. Notez qu’on peut la lancer également en asm.js classique pour mesurer l’écart significatif des temps de chargement.

Pour ceux qui le souhaitent d’ailleurs, la page est à garder dans les favoris pour vérifier le statut général du projet. Signalons également que Microsoft dispose également d’une version compatible de son navigateur Edge, mais uniquement en interne pour l’instant. Du côté d’Apple, pas d’annonce particulière, mais la page consacrée au statut des technologies supportées par Webkit indique bien que WebAssembly est en développement.

Commentaires (54)

picatrix

Il y a 8 ans

un format binaire ça ouvre des perspectives intéressantes pour les auteurs de virus …

OlivierJ Abonné

L’informatique, le domaine où on réinvente les trucs tous les 5 ou 10 ans, parfois plus. " />
En l’occurrence, on réinvente la compilation JIT de Java et le bytecode, à l’époque où on pensait que le Java allait être utilisé de plus en plus pour rendre le Web plus riche (client riche) via les applets Java.

Keizo Abonné

Ah oui mais la attention c’est google/MS/Mozilla qui sont derrière ! c’est beaucoup mieux " />

Dr.Wily

Bienvenu dans le Web fermé….

alex.d. Abonné

Et le bytecode Flash !
 

CryoGen Abonné

Le JAVA ce n’est pas du JIT il me semble. Par contre il me semble bien qu’il y en avait au début de C#.

marba

C’est la suite logique de la convergence full web. J’espère que ce sera en opt-out par défaut, mais bon faut pas rêver " />

 

CryoGen a écrit :

Le JAVA ce n’est pas du JIT il me semble. Par contre il me semble bien qu’il y en avait au début de C#.

Au tout début les interpréteurs Java ne faisaient pas de compilation JIT, mais ensuite c’est devenu courant au début des années 2000, cf&nbsphttps://en.wikipedia.org/wiki/Java_version_history .

Mem's Abonné

Attention, ce n’a rien à voir avec du bytecode/code intermédiaire.
Mais plutôt la possibilité d’avoir du javascript sous format binaire plutôt que text, les données d’AST sous format binaire en quelque sorte.
Donc on ne peut pas le comparer à du CIL, ABC, Java bytecode, etc.
 
Le format prévoit un format text pour pouvoir le lire en clair
 
http://www.2ality.com/2015/06/web-assembly.html

arxone Abonné

C’est ni plus ni moins dangereux que du javascript. C’est juste le format qui change.

Naneday

Si ca a la meme syntax que le JS, alors non merci, je trouve le JS degeulasse

Uther Abonné

picatrix a écrit :

un format binaire ça ouvre des perspectives intéressantes pour les auteurs de virus …

 Pas plus que le JavaScript actuel qui est déjà compilé en code machine.
 

OlivierJ a écrit :

L’informatique, le domaine où on réinvente les trucs tous les 5 ou 10 ans, parfois plus. " />
En l'occurrence, on réinvente la compilation JIT de Java et le  bytecode, à l'époque où on pensait que le Java allait être utilisé de  plus en plus pour rendre le Web plus riche (client riche) via les  applets Java.
C'est pas vraiment  comparable : le bytecode de la JVM n'avait été pensé que pour les besoin du  langage Java et il était prévu à la base pour être interprété.&nbsp; Il n'était clairement pas adapté aux performances, ni à supporter un  éventail large de langages, même si en le torturant on a réussi a en tire quelque chose.     
 Le WebAssembly a été pensé dès le début pour pouvoir être compilé en code machine en AOT et pas en JIT. Et il est prévu qu’il n’impose pas des concepts de haut niveau. Du coup il peut être la cible de langages comme le C ou le C++.
 

Dr.Wily a écrit :

Bienvenu dans le Web fermé….

   Ça n’a rien de fermé, bien au contraire la spécification est complètement ouverte.
 

CryoGen a écrit :

Le JAVA ce n’est pas du JIT il me semble. Par contre il me semble bien qu’il y en avait au début de C#.

 La compilation JIT, a au contraire été popularisée par Java (même si ce n’est pas lui qui l’a inventé). Avant son introduction les performances étaient catastrophiques.
 C’est d’ailleurs en partie pour ça que Sun a baptisé la version 1.2 de Java : “Java 2”
 

marba a écrit :

C’est la suite logique de la convergence full web. J’espère que ce sera en opt-out par défaut, mais bon faut pas rêver " /> 

  Vu que WebAssembly ne permet rien qui ne soit déjà possible avec JavaScript je ne vois pas ce que tu aurais à y gagner.
 

Mem’s a écrit :

Attention, ce n’a rien à voir avec du bytecode/code intermédiaire.
Mais plutôt la possibilité d'avoir du javascript sous format binaire plutôt que text, les données d'[AST](https://en.wikipedia.org/wiki/Abstract_syntax_tree) sous format binaire en quelque sorte.      

 Donc on ne peut pas le comparer à du [CIL](https://en.wikipedia.org/wiki/Common_Intermediate_Language), [ABC](https://www.adobe.com/content/dam/Adobe/en/devnet/actionscript/articles/avm2overview.pdf), Java bytecode, etc.      

&nbsp;      

Le format prévoit un [format text](https://github.com/WebAssembly/design/blob/master/TextFormat.md) pour pouvoir le lire en clair      

&nbsp;      
http://www.2ality.com/2015/06/web-assembly.html

Techniquement le WebAssembly est bien plus proche d’un bytecode que du JavaScript binaire.

Certes il se présente sous la forme d’un AST, mais cet AST ne correspond absolument pas à du code Javascript, mais bien a un pseudocode qui travaille avec des structure plus bas niveau.

Naneday a écrit :

Si ca a la meme syntax que le JS, alors non merci, je trouve le JS degeulasse

 Ça n’est pas une bonne vision du projet. Personne ne programmera directement en WebAssembly : même s’il y a une représentation textuelle, elle ne servira probablement qu’aux créateurs de compilateur et a ceux qui feraient des outils très techniques.
 Tu programeras dans le langage de ton choix qui sera compilé en WebAssembly.

hurd Abonné

Uther a écrit :

Ça n’a rien de fermé, bien au contraire la spécification est complètement ouverte.

Humm humm… déjà que l’usage de script javascript obfusqué est plus que limite…
Alors aller encore plus loin et mettre du format binaire, ça craint sérieusement.
https://www.gnu.org/philosophy/javascript-trap.html

Flykz

Je ne vois pas en quoi le WebAssembly résoudrait un “problème” du JS. Le fait que le JS soit compilé à la volée n’est pas un “problème”, c’est juste un choix qui a été fait pour ce langage, avec son lot d’avantages et d’inconvénients.

D’ailleurs, dire que le JS n’est pas performant c’est soit faire preuve de mauvaise foi (comme les gens qui ne prennent pas la peine de s’y intéresser le font bien souvent),  ou ne rien comprendre au langage (enfin vu le nombre de gens qui confondent l’API du DOM avec le JS…).

Peu importe l’avis que l’on a sur le WebAssembly, dire que c’est une solution aux problèmes du JS n’est pas vrai. Le JS a des problèmes réels qui n’ont rien à voir avec sa compilation en temps réel (puisqu’il est principalement question de ça, outre le fait que ce ne soit pas un langage de bas niveau) comme les variables globales, ou l’eval, pour les plus connus.

Donc non, le WebAssembly n’est pas là pour faire ce que fait déjà  l’ecmascript.

sr17

Flykz a écrit :

Je ne vois pas en quoi le WebAssembly résoudrait un “problème” du JS. Le fait que le JS soit compilé à la volée n’est pas un “problème”, c’est juste un choix qui a été fait pour ce langage, avec son lot d’avantages et d’inconvénients.

D’ailleurs, dire que le JS n’est pas performant c’est soit faire preuve de mauvaise foi (comme les gens qui ne prennent pas la peine de s’y intéresser le font bien souvent), ou ne rien comprendre au langage (enfin vu le nombre de gens qui confondent l’API du DOM avec le JS…).

Peu importe l’avis que l’on a sur le WebAssembly, dire que c’est une solution aux problèmes du JS n’est pas vrai. Le JS a des problèmes réels qui n’ont rien à voir avec sa compilation en temps réel (puisqu’il est principalement question de ça, outre le fait que ce ne soit pas un langage de bas niveau) comme les variables globales, ou l’eval, pour les plus connus.

Donc non, le WebAssembly n’est pas là pour faire ce que fait déjà l’ecmascript.

Désolé de vous décevoir, mais non, le javascript, ce n’est pas ce qui se fait de mieux au niveau performances.

Plusieurs caractéristiques pénalisent ce langage en terme de vitesse d’exécution.

hurd a écrit :

Humm humm… déjà que l’usage de script javascript obfusqué est plus que limite…
Alors aller encore plus loin et mettre du format binaire, ça craint sérieusement.      
https://www.gnu.org/philosophy/javascript-trap.html

  Justement, ce n’est pas un problème car le WebAssembly vise a remplacer les lourds blocs de code Jascsript compilés qui sont de toute façon déjà systématiquement obfusqués.
Le WebAssembly ne vise pas a remplacer le JavaScript en tant que script, mais en temps que bytecode.
 

Flykz a écrit :

Je ne vois pas en quoi le WebAssembly résoudrait un “problème” du JS. Le fait que le JS soit compilé à la volée n’est pas un “problème”, c’est juste un choix qui a été fait pour ce langage, avec son lot d’avantages et d’inconvénients.

   Sauf qu’il faut prendre en compte que le JavaScript est actuellement le seul langage sur le Web utilisable coté client sans plugin.
 Comme tu le dis, il a ses avantages et ses inconvénients, et si c’est langage de script qui peut avoir un certain intérêt, il n’est clairement pas optimal la plupart des usages trop lourd qu’on lui prête parfois aujourd’hui.
 

Flykz a écrit :

D’ailleurs, dire que le JS n’est pas performant c’est soit faire preuve de mauvaise foi (comme les gens qui ne prennent pas la peine de s’y intéresser le font bien souvent),  ou ne rien comprendre au langage (enfin vu le nombre de gens qui confondent l’API du DOM avec le JS…).

 Tout dépend de ce que tu appelles performant. On peut faire beaucoup de chose avec JavaScript, tout comme en Java.  Mais malgré tous les progrès du JIT, il y a des contraintes techniques qui font que Java ou JavaScript ne pourront jamais approcher les niveaux de performance de langages comme le C, à moins de sacrifier tout ce qui fait le cœur du langage comme le fait asm.js.
 Mais de toute façon cet amas de code généré n’est plus que vaguement du JavaScript, alors autant avoir un vrai bytecode qui sera encore plus propre, rapide, léger.

127.0.0.1

un problème de programmation
- des ingénieurs parmi les plus compétents
- une mutualisation des efforts des plus grandes sociétés
- 40 ans d’évolution dans le domaine de l’informatique
- des ressources hardware digne d’un super-calculateur
  
  … et au final, ils ont trouvé LA solution:
  
  l’assembleur.

127.0.0.1 a écrit :

un problème de programmation

des ingénieurs parmi les plus compétents

une mutualisation des efforts des plus grandes sociétés

40 ans d’évolution dans le domaine de l’informatique

des ressources hardware digne d’un super-calculateur

… et au final, ils ont trouvé LA solution:

l’assembleur.

Tout ça pour lancer des applications dans un navigateur web ! " />

Olipla

Mem’s a écrit :

Mais plutôt la possibilité d’avoir du javascript sous format binaire plutôt que text

C’est un peu plus que ça. Par exemple, WebAssembly a un type entier, ce dont ne dispose pas JS (qui n’a que des flottants).

flamaros

Le kiff serait un byte code qui contient le code pour toutes les archi, seules les parties spécifiques auraient besoin d’être dupliquées (SSE, NEON, ASM,…).
 Et d’avoir a cote des outils permettant de filtrer ce big binaire pour en extraire que la version demandée par l’utilisateur final.

 Ha ben en fait Apple fait déjà ca, leur byte code contient les versions 32 et 64 bits alors que le store peux n’envoyer que la bonne version au device a l’installation.

Toutes les app devraient être comme ca, c’est super pour nous les développeurs qui pourrions ainsi utiliser plusieurs languages car leur byte code seraient compatibles.
 

Ben en fait la convergence est plutôt vers les applications compilées du coup.

sephirostoy Abonné

Si ça peut ouvrir la voie à des toolchains permettant de créer des pages web avec autre chose que cette immondice de JS, sans avoir recours à des plugins, why not.

flamaros a écrit :

Le kiff serait un byte code qui contient le code pour toutes les archi, seules les parties spécifiques auraient besoin d’être dupliquées (SSE, NEON, ASM,…).  Et d’avoir a cote des outils permettant de filtrer ce big binaire pour en extraire que la version demandée par l’utilisateur final.

 Ha ben en fait Apple fait déjà ca, leur byte code contient les versions 32 et 64 bits alors que le store peux
n’envoyer que la bonne version au device a l’installation.  
 

Ce que tu décris n’a rien d’un bytecode c’est juste un exécutable qui contient du code pour plusieurs architectures.  C’est plus ou moins ce que proposait NaCl de Google. Le problèmes, c’est que ça n’est jamais sorti de Chrome car ce n’était pas acceptable comme standard Web.
Un standard du Web se doit d’être indépendant de l’architecture. Or le webmaster  ne peut pas spécialiser son code pour toute les archis actuelles existantes, alors encore moins celles à venir.

 Pour palier à ça, Google a proposé pNaCl qui utilise le LLVM-IR comme bytecode. Mais les autres navigateurs n’en voulaient pas non plus, car ça forçait toujours à intégrer dans tous les navigateur l’API de plugins de Chrome qui doublonnait la plupart des API Web déjà existantes. De plus le LLVM-IR n’était pas optimal car pas vraiment prévu pour cet usage.

WebAssembly reprend le principe de pNaCl en en corrigeant les défauts qui empêchaient son adaptation par les autre navigateurs. Il s’appuiera sur les API Web et utilise un bytecode spécialement fait pour le Web : indépendant de l’architecture, optimisé pour être léger a télécharger et assez rapide a compiler.

alexia_gossa

J’adore l’évolution actuelle : Des ordinateurs ultra-puissants dont les programmes natifs sont d’une efficacité redoutable, mais pour en faire quel usage réellement ?
Pour exécuter des web-app dont le rapport performance/consommation est encore plus mauvais qu’une alimentation no-name de mauvaise qualité…

Je ne fais rien :
0xEB, 0xFE (jmp -2)

Exception

S’ils pouvaient aussi penser à envoyer le HTML en précompilé, ça gagnerait en taille, performance, etc.
Peut-être dans 10 ans.
Le web a techniquement été très mal pensé à la base, sans utilisé l’existant, tout est à refaire. Le javascript qui cherche à devenir du java en est un exemple.

C’est pas vraiment qu’il a été mal pensé mais qu’il a été pensé pour les besoins de l’époque (il y a plus de 25 ans) : présentation de document avec beaucoup de texte, très peu de mise en forme.
 
Aujourd’hui le web ce n’est plus du texte mais de vraies application complètes. Si Tim Berners-Lee avait deviné ce que deviendrait le HTML, il l’aurait certainement fait bien différemment.

JCDentonMale

Qui compilera le wasm ? Le navigateur à la volée, ou les développeurs des sites web  ?

Obidoub

Flash est mort
Vive Flash WebAssembly !

 " />

Raynor

Le Bitcode de Apple est bien un bytecode, voir section Bitcode https://developer.apple.com/library/tvos/documentation/IDEs/Conceptual/AppDistri…

C’est obligatoire d’envoyer les app sur l’AppStore sous ce format pour TvOS, WatchOS et surement bientot iOS.

hurd a écrit :

Humm humm… déjà que l’usage de script javascript obfusqué est plus que limite…
Alors aller encore plus loin et mettre du format binaire, ça craint sérieusement.
https://www.gnu.org/philosophy/javascript-trap.html

Toujours dans l’excès ce gars là…

Obidoub a écrit :

Flash est mort
Vive Flash WebAssembly !

" />

Hein ?

DHMO Abonné

Comment du coup garder les avantages de JavaScript, tout en gommant ses
défauts, en particulier la sécurité et les performances ?

En quoi WebAssembly apporte-t-il plus de sécurité ?

psn00ps Abonné

C’est horrible comme assembleur, cpu full " />

jpaul Abonné

Les développeurs " />

Uther a écrit :

Ça n’a rien de fermé, bien au contraire la spécification est complètement ouverte.

Binaire == compilé == pas lisible directement donc fermé.

Dr.Wily a écrit :

Binaire == compilé == pas lisible directement donc fermé.

Aussi fermé que le noyau Linux alors " />

maxxyme

Après avoir essayé la version standard (asm.js standalone) du petit jeu dispo sur la page en question, franchement je vois pas où sont les problèmes de performance…

JCDentonMale a écrit :

Qui compilera le wasm ? Le navigateur à la volée, ou les développeurs des sites web  ?

 Le développeur compilera le langage de son choix en wasm. Le navigateur compilera le wasm en natif selon la méthode de son choix, mais ça probablement en AOT(dès le chargement)

DHMO a écrit :

En quoi WebAssembly apporte-t-il plus de sécurité ?

 Il n’apporte ni plus ni moins de sécurité que JavaScript, vu qu’il utilise les même API et que les deux sont compilés en code machine.

Yangzebul

C’est un problème idéologique, pas technique.
 Tu ne pourra jamais forcer les gens à adhérer à des principes via des contraintes techniques.

Merci. " /> C’est bien ce qui me semblait à première vue.

kryx Abonné

Si je comprends bien, ça pourrait permettre de créer facilement un interpréteur forth. Dès qu’il y aura une toolchain pour le C, on pourra adapter un des nombreux forth libres qui existent. On pourra alors charger un source forth et l’interpréter. et tout ça sans plugin. Un programme forth, c’est tout petit et hyper rapide. Et l’intérpréteur forth aussi c’est tout petit (et rapide bien sûr sinon le forth serait lent). Ça permettrait de coder les parties les plus lentes.

il y a aussi des forth objets mais j’ai jamais tâté de  ces trucs-là, alors je ne peux pas dire.

Mais déjà coder un jeu en forth pour un navigateur, ça ce serait un truc bien geek qui me plairait bien !!!

CryoGen a écrit :

Toujours dans l’excès ce gars là…

Yangzebul a écrit :

C’est un problème idéologique, pas technique.

Vous n’y êtes peut être pas sensibles mais il y à là une vrai problématique en terme de sécurité et de liberté. Il me semble donc pas absurde de faire remarquer ce point, d’apporter une certaine désapprobation à des solutions qui vont vers moins de contrôle pour l’utilisateur.
Après je ne dit pas que tout les usages de ce genre de technologie seront mauvais mais il y à de quoi être inquiet tout de même, entre le cloud et ça, le contrôle de l’utilisateur me paraît de plus de plus menacé.

De plus, je ne vois pas en quoi être plus sensible à le question reviendrais à de l’excès. Quand au fait qu’il s’agit d’un problème idéologique, plutôt que technique , effectivement, ce n’est pas une problématique purement technique mais ça tombe bien, on ne vit pas dans un monde purement technique, les critiques idéologique ont leurs place.

Yangzebul a écrit :

Tu ne pourra jamais forcer les gens à adhérer à des principes via des contraintes techniques.

Certes… À part m’attribuer des idées étranges (ça fait un bel homme de paille), Ou veut tu en venir ?

Pas besoin de WebAssembly pour ça, c’est déjà faisable complètement faisable avec asm.js.

hurd a écrit :

Vous n’y êtes peut être pas sensibles mais il y à là une vrai problématique en terme de sécurité et de liberté.

Sauf que justement, non. Il n’y a ni de problème de sécurité ni de liberté. Du moins pas plus qu’avec JavaScript.

 Le WebAssembly aura exactement le même niveau de sandboxing que le Javascript actuellement. Il sera compilé d’une manière assez semblable (mais plus rapide et efficace). Et il ne pourra accéder qu’aux API Web standard avec les mêmes restrictions que le JavaScript.

Pour ce qui est de la liberté, un code source consultable n’a absolument rien a voir avec la liberté.  Un code compilé peut tout a fait être libre si son source est disponible sous licence libre.  Au contraire, un code JavaScript important est généralement obfusqué pour être illisible, et même si se n’est pas le cas, il n’est pas forcément libre pour autant.
 

hurd a écrit :

Après je ne dit pas que tout les usages de ce genre de technologie seront mauvais mais il y à de quoi être inquiet tout de même, entre le cloud et ça, le contrôle de l’utilisateur me paraît de plus de plus menacé.

Tu peux en effet t’inquiéter du cloud qui gère tes données de manière absolument incontrôlable. Mais tu n’as pas de raison de t’inquiéter du WebAssembly qui ne change rien à ce niveau.

 

hurd a écrit :

De plus, je ne vois pas en quoi être plus sensible à le question reviendrais à de l’excès. Quand au fait qu’il s’agit d’un problème idéologique, plutôt que technique , effectivement, ce n’est pas une problématique purement technique mais ça tombe bien, on ne vit pas dans un monde purement technique, les critiques idéologique ont leurs place.

Le problème c’est que tu accuses la technologie sans comprendre de quoi il en retourne. Parler d’idéologie ok, mais ça ne doit pas être une excuse pour dire n’importe quoi.

Overnumerousness

Uther, seul entre tous pour relever le niveau :)

Wosgien Abonné

Enfin !  A mort Javascript! Et intégrons un nouveau bytecode qui permet de rassembler les avantages du Javascript (accès direct à la structure de la page par exemple et portabilité) et ceux de Java/Silverlight (performance correctes et conso mémoire gérable)

Du multithread! Des SIMD! Et j’espère un bytecode type de celui de Java, vérifiable au chargement pour éviter les dépassements de pile.

Je suis vraiment ravi de cette nouvelle. Presque autant que si on m’avait dit qu’un nouveau processeur permettait d’adresser le cache en indexé pour exécuter du Java quasi natif…

Merci c’était exactement le fond de ma pensée " />

@Uther oui, asm.js doit permettre ça, mais il n’est pas déployé partout et il est plus lent. Mais en effet, ça donne déjà les moyens d’essayer. Mais le travail fait coté compilation sera sans doute à refaire après pour le jour où webassembly sera prêt.

asm.js est du Javascript : il marchera donc partout avec des performances certes variables. Il faut noter que asm.js est maintenant supporté de manière optimale par 3 des 4 principaux moteurs JavaScript moderne et pas trop mal WebKit.

asm.js est déjà obtenu en compilant du code C. Vu qu’il reposent tous les deux sur les mêmes API Web la conversion de l’un à l’autre devrait être triviale. WebAssembly, c’est globalement asm.js débarrasé de la couche de compatibilité JavaScript.

Ou je veux en venir ?
Je dis simplement que le fait que ce soit un format texte ou binaire n’a aucune impact sur la question de l’open-source.

Si les gens veulent faire du fermé dans un format texte il y a et y aura toujours plein de solution, tu ne pourra jamais mettre en place un socle technique qui forcera les gens a faire du code ouvert par défaut.

C’est purement une question idéologique : si tu veux faire de l’open source en WebAssembly ou autre format binaire tu peux, de même que l’inverse.

 
Taper sur une représentation binaire en disant que c’est “limite” c’est juste passer à côté de la vrai question.

Pikrass

127.0.0.1 a écrit :

un problème de programmation

des ingénieurs parmi les plus compétents

une mutualisation des efforts des plus grandes sociétés

40 ans d’évolution dans le domaine de l’informatique

des ressources hardware digne d’un super-calculateur

… et au final, ils ont trouvé LA solution:

l’assembleur.

C’est quand même amusant de suivre l’évolution du web. Ca fait 15 ans qu’on est en train lentement de recréer un PC dans le navigateur, mais en allant dans le sens inverse : du haut niveau au plus bas " /> Ca a commencé par une simple UI, puis par du code de niveau “business logic”… Et ces dernières années on a eu du stockage mémoire, des sockets, et maintenant du code machine " />

Lorsque le navigateur web sera devenu un émulateur complet d’une machine, je me demande ce qu’ils trouveront d’autre. Des machines virtuelles ? Ou bien faudrait qu’ils recommencent, en imbriquant un début de PC dans un truc à l’intérieur du navigateur. " />

Yangzebul a écrit :

Ou je veux en venir ?
Je dis simplement que le fait que ce soit un format texte ou binaire n’a aucune impact sur la question de l’open-source.

Ça tombe bien je ne parle pas spécialement de l’opensource qui est un mouvement dont je ne me sens pas spécialement proche. Ouvrir pour l’efficacité… bof.

Yangzebul a écrit :

Si les gens veulent faire du fermé dans un format texte il y a et y aura toujours plein de solution, tu ne pourra jamais mettre en place un socle technique qui forcera les gens a faire du code ouvert par défaut.

C’est purement une question idéologique : si tu veux faire de l’open source en WebAssembly ou autre format binaire tu peux, de même que l’inverse.

Taper sur une représentation binaire en disant que c’est “limite” c’est juste passer à côté de la vrai question.

Je parle de l’usage d’une représentation binaire dans le cas très spécifique du web et du code côté client.
Je pense que le fait de perdre encore un peu plus la capacité de pouvoir savoir(pas question de licence ici) ce que notre machine fait, quand bien même la machine javascript est sandboxé (pour protéger avant tout le système, pas ta vie privée par exemple) est dangereux. D’autant plus que je ne sais trop dans quel mesure un tel code compilé est “contrable”, la solution libreJS à tel du sens face à un format binaire ? Peut on facilement “bloquer” les usages indiscrets tout en gardant le reste fonctionnel ?

Alors peut être que comme Uther le dis, je raconte “n’importe quoi” mais j’ai du mal à croire qu’un format binaire sur le web ne risque pas à un niveau ou à un autre poser de vrais problèmes de cet ordre.

damrod

+100

en meme temps quand tu vois les usines a gaz pour afficher une page web toute simple…je faisais du web en asp/php3 au debut des années 2000, y’avait des limites ok mais bon les sites étaient performants…et les pages pesaient pas 10Mo pour 3boutons !!!
maintenant avec leur framework j2ee and co, utilisés pour tout et surtout n’importe quoi, maitrisés par peu de gens et utilisés par bcp, développés sans un minimum de reflexion sur l’archi pour la partie web et le mpd de la base oracle derrière, on obtient des applis horribles a maintenir et avec des perfs a chier…quand tu vois que le serveur websphere rame a mort derriere et que tu mets 3 min a afficher ta page web avec 4 boutons et une grille de donnée…ca fait rigoler quand on te sort que c du high tech ;)

enfin bon l’avantage c que la ou il fallait un dev web debut 2000, il t’en faut 10 maintenant pour le meme genre de site :)

bon site performant : google/amazon, chartre graphique bien penséé, site réactif et fonctionnel
site a chier : sncf ? transilien.com nouvelle mouture ?

c dommage que les gens se posent plus la question dans le bon ordre : “quels sont les technos et outils les mieux adaptés pour répondre au besoin de mon client” alors que la c plutot “j’adore asp.net et j2ee donc on va utiliser ca :)”
je dis asp.net car c’est juste une partie de ce que peut faire la plateforme .net meme si les “décideurs” et meme certains devs ont réduits ca au c# et asp.net :/
 

hurd a écrit :

 Je parle de l’usage d’une représentation binaire dans le cas très spécifique du web et du code côté client.
Je pense que le fait de perdre encore un peu plus la capacité de pouvoir savoir(pas question de licence ici) ce que notre machine fait

Sauf que la vision “binaire = protégé” / “code source = savoir” est fausse. Certain codes sources contiennent des blob binaires, ou sont obfusqués. Et le binaire ne protège absolument pas contre la rétro-ingénierie, s’il n’est pas  prévu des solutions techniques très lourdes, qui finissent généralement par tomber.
 
 En l’occurrence le WebAssembly peut se désassembler en une représentation textuelle (standardisée par la norme) qui sera probablement bien plus lisible que du JavaScript volontairement obfusqué.

hurd a écrit :

D’autant plus que je ne sais trop dans quel mesure un tel code compilé est “contrable”, la solution libreJS à tel du sens face à un format binaire ? Peut on facilement “bloquer” les usages indiscrets tout en gardant le reste fonctionnel ? 

 Je ne connaissais pas LibreJS , j’ai regardé son fonctionnement. Elle ne sera certes pas utilisable en l’état, mais techniquement un binaire de bas niveau est tout aussi inspectable que du code source, donc il devrait pouvoir être adapté. Ça devrait même être plus efficace, vu qu’il n’y aura pas les structure complexes que LibreJS ne peut analyser et qu’il bloque donc par défaut.
  Reste a savoir comment connaître la licence d’un fichier wasm, je ne sais pas si la spécification prévoit quelque chose sur ce point.

WebAssembly : le format binaire du web a sa démo pour Chrome et Firefox

Un bond important, mais il en faudra d'autres

Gommer les problèmes du JavaScript

Une première démonstration fonctionnelle

Un travail sur les performances avant tout

Le succès passe par la séduction des développeurs web

Tiens, en parlant de ça :

Des chercheurs ont élaboré une technique d’extraction des données d’entrainement de ChatGPT

Toxique de répétition

Devenir expert en sécurité informatique en 3 clics

Ou comment briller en société (de service)

ownCloud : faille béante dans les déploiements conteneurisés utilisant graphapi

Dangereuse, mais spécifique ?

Sommaire de l'article

Introduction

Gommer les problèmes du JavaScript

Une première démonstration fonctionnelle

Un travail sur les performances avant tout

Le succès passe par la séduction des développeurs web

#LeBrief : logiciels libres scientifiques, fermeture de compte Google, « fabriquer » des femmes pour l’inclusion

Des chercheurs ont élaboré une technique d’extraction des données d’entrainement de ChatGPT

Devenir expert en sécurité informatique en 3 clics

ownCloud : faille béante dans les déploiements conteneurisés utilisant graphapi

Amazon re:invent : SoC Graviton4 (Arm), instance R8g et Trainium2 pour l’IA

Guéguerre des polices dans le cyber (OFAC et ComCyberMi)

#LeBrief : faille 0-day dans Chrome, smartphones à Hong Kong, 25 ans de la Dreamcast

OVHcloud Summit 2023 : SecNumCloud, IA et Local Zones

Transparence, discriminations : les questions soulevées par l’algorithme de la CAF

Plainte contre l’alternative paiement ou publicité comportementale de Meta

Économie de la donnée et services de cloud : l’Arcep renforce ses troupes

Plus de 60 % des demandes de suppression reçues par Google émanent de Russie

La Commission européenne et Google proposent deux bases de données de fact-checks

#LeBrief : des fichiers Google Drive disparaissent, FreeBSD 14, caméras camouflées, OnePlus 12

Le poing Dev – round 6

Produits dangereux sur le web : nouvelles obligations en vue pour les marketplaces

Usages et frugalité : quelle place pour les IA dans la société de demain ?

La NASA établit une liaison laser à 16 millions de km, les essais continuent

Semi-conducteurs : un important accord entre l’Europe et l’Inde

#LeBrief : PS5 Slim en France, Valeo porte plainte contre NVIDIA, pertes publicitaires X/Twitter

651e édition des LIDD : Liens Intelligents Du Dimanche

#Flock, le grand remplacement par les intelligences artificielles

Quoi de neuf à la rédac’ #9 : LeBrief 2.0, ligne édito, dossiers de fond

Encapsulation de clés et chiffrement d’enveloppes

Empreintes digitales : les capteurs Windows Hello loin d’être exemplaires

#LeBrief : succès du test d’Ariane 6, réparer plutôt que remplacer, Broadcom finalise le rachat de VMware

Apple ne paierait que peu de royalties à Arm pour ses puces

Des logiciels libres scientifiques français à l’honneur

Pourquoi inclure des femmes si on peut les fabriquer ?

Google commencera son ménage dans les comptes non utilisés le 1er décembre

Commentaires (54)