Uther a écrit :



Certes, il y aura de la perte d’infos, ce que je voulais dire c’est que ça sera toujours mieux que du javascript brouillé.





Je ne connais pas assez les techniques d’obscurcissement mais celles que j’ai vues préservaient les informations de types, se contentant de renommer ceux-ci. Il est ainsi possible de savoir que deux variables sont deux instances du même type ou de rechercher toutes les instances de ce type. Et a priori je ne pense pas qu’il soit possible de dissimuler cela en JS sans heurter les performances.



Donc je maintiens que du JS brouillé reste un peu mieux de c côté. Mais encore une fois je ne pense pas que ce soit important : voir le code source des pages que je visite est bien moins intéressant que d’avoir un web rapide où l’on peut efficacement utiliser d’autres langages que le JS.







Je pense qu’à terme les développeur web auront des outils de type flash qui leur génèreront les wasm qu’ils ont besoin



Chacun utilisera simplement le langage correspondant à son besoin, comme aujourd’hui en-dehors du web.



Certains voudront de grosses performances (C/C++/Rust), d’autres voudront des langages pour de très gros projets et de grandes équipes avec du typage statique (Java/C#/etc), d’autres enfin adopteront des langages dynamiques adaptés à de petits projets (Python, Ruby, JS). Et beaucoup choisiront simplement ce que leur équipe connaît.

brazomyna a écrit :



Il n’y a pas de notion de type d’objet (ou de classes) en JS. Les seuls types existant sont: String, Number, Boolean, Object, Array, Null et Undefined.





Le langage lui-même ne permet pas de déclarer des types mais en pratique le programmeur en définit quand même de fait, dans son esprit et dans son code. On peut même créer une taxonomie de types dans les objets du quotidien (les types sont un concept mathématique avant d’être un concept informatique).



Ainsi on peut considérer que tous les objets créés par la fonction bidule forment un type, et c’est presque toujours pertinent.



Dès lors en partant des fonctions globales tu vas pouvoir deviner les types créés par elles, puis les types créés par leurs membres, etc. Jusqu’à pouvoir typer chaque objet (indiquer au programmeur qu’il a été produit par la fonction XYZ).



Rien de tel avec un langage du niveau assembleur. Tu pourrais être tenté d’identifier des constructeurs mais ceux-ci sotn multiples, parfois “inlinés”, et parfois non appelés car la mise à zéro suffisait. Et plus simplement il est difficile d’identifier un appel comme étant un constructeur (allocation sur la pile en particulier).







A ce titre, faire du reverse engineering sur un code obfusqué, même avec les infos de type qui perdurent (et donc juste les nomages qui dégagent), reste suffisamment consommateur en temps pour que ça ne soit plus intéressant de tenter l’opération inverse.



Je suis d’accord.

white_tentacle a écrit :



Mais je suis curieux sur les raisons du choix de C++ : un langage typé statiquement, sans GC, bref, à des années lumière de ce que connaissent les dev web. Donc pas vraiment le candidat idéal au vu de la cible finale (à moins que le but ne soit à terme d’amener ces développements vers des langages statiquement typés)





Ils ne poussent personne à opter pour le C++. Ils veillent simplement à ce que leur jeu d’instructions soit suffisamment riche pour supporter toutes les fonctionnalités du C++ car si c’est le cas il peut supporter efficacement 99% des langages de programmation.

brazomyna a écrit :



Ce n’est ni plus ni moins que ce que je disais avant: les optimisations possibles sont à regarder du côté du temps de démarrage, pas de l’exécution en soi, car le JS reste le JS.



Si on veut pouvoir faire les optimisations (donc avoir les perfs) d’un langage style Java, C++, etc… pour ce qui concerne les perfs d’exécution, il faut changer la nature même du langage (genre en rajoutant du typage fort, etc…) et donc c’est hors du cadre de ce dont on parle ici puisque le WebAssembly concerne le support de l’ECMA Script dans son ensemble.





Non, tu as compris de travers tout le projet.



Ce n’est PAS un bytecode pour Javascript. C’est un bitcode du niveau assembleur, avec des instructions du type “charger le contenu de l’adresse mémoire du registre A dans le registre B” ou “additionner le contenu des registres A et B en les considérant comme des entiers 64 bits”. C’est un assembleur pour un processeur imaginaire, conçu pour servir de source à la compilation vers n’importe quel CPU. Comme dans LLVM et PNaCl, et d’autres compilateurs.



Le seul moment où JS interviendra à terme dans tout ça ce sera parce que les API du navigateur (et seulement elles) resteront conçues pour JS. Autrement dit les objets du DOM demeureront des objets dynamiques pour JS. Et il y aura donc vraisemblablement quelques instructions du type “tenter de charger un entier 32 bits depuis la référence JS dans le registre A avec le membre nommé selon l’adresse d’une chaîne utf-8 stockée dans le registre B”. Mais ces instructions ne seront utilisées que pour interagir avec le navigateur. Et on peut même imaginer qu’à terme tout ou partie des API auront des contreparties natives.







brazomyna a écrit :



Oui, mais en général, tes 10Mo sont pas parsés en une fois ; ça se fait au fur et à mesure des besoins (genre je vais sur tel écran, on charge ce contrôleur dynamiquement à ce moment là)





Ce n’est pas possible pour une compilation statique, même en JIT : si ta méthode “abc” appelle la fonction nommée “def”, il faut que tu localises “def” avant de compiler “abc”. Tu dois donc tout parser dès le départ.



Sans cela à l’appel de “def” tu vas demander à ton compilateur de scanner toutes les sources jusqu’à ce qu’il trouve enfin une fonction appelée “def”. Autrement dit il va rapidement devoir tout parser. Autant le faire dès le départ, ça sera plus efficace.



En revanche tu peux, après avoir parser “def”, en retarder la compilation jusqu’à sa première invocation. Mais je ne suis pas sûr que ça n’aie pas d’impact sur les performances, même en supposant que tu accordes au compilateur tout le temps nécessaire pour bien optimiser.

brazomyna a écrit :



Ok, donc si on parle d’un nouveau langage qu’on compile ensuite, je comprends mieux ; mais l’article laissait justement penser que c’était censé permettre de réutiliser toutes composantes de l’ECMA Script actuel.





Ils proposeront bien sûr des instructions pour que le code natif puisse interagir avec les objets JS, notamment parce que les API du navigateur continueront à fournir des objets JS et parce qu’il faudra pouvoir dialoguer avec le code JS existant. Mais comme je le disais ce ne sera qu’accessoire, via par exemple des instructions exigeant une référence JS dans un registre et l’adresse de la chaîne d’un nom d’un membre dans un autre registre.



Mais encore une fois ce n’est pas le coeur du projet et les instructions de base seront quant à elles d’aussi bas niveau que que l’asm.







brazomyna a écrit :



Je parlais du fonctionnement actuel. Par exemple tu as une énorme appli Angular composée de 200 controlleurs avec 10Mo de code source en tout, le browser charge pas la totalité des controlleurs, seuls ceux dont il a besoin, au fur et à mesure.





Ok mais ce sont des chargements effectués à la volée par des bibliothèques modulaires, pas par le compilateur.



C’est très bien pour les bibliothèques modulaires dont une partie seulement des fonctionnalités sont utilisées par tel ou tel site. Mais ce n’est possible pour une application native compilée en un gros paquet de 100Mo d’asm.js et qui nécessite que tout ait été parsé et compilé avant de démarrer.

 





Firefly’ a écrit :



“Les développeurs Java et .NET s’écrient : « Ah ! »”

  ”« WebAssembly »[..] doit fournir en fait un bytecode aux navigateurs” 



J’allais dire que j’avais  été induit en erreur par la news, mais en pratique, c’est pas un bitcode ( pas executable directement, puisqu’il doit être traduit en code machine spécifique à la platforme, aussi simple cette conversion soit elle ), mais bien un code intermédiaire ( bytecode ), même si déjà optimisé et déjà low lvl.





Laissons tomber la distinction vaseuse “bitcode” / “bytecode” pour laquelle tout le monde n’est pas d’accord sur le sens.



Ce qui importe c’est que ces instructions sont bel et bien du niveau de l’assembleur. L’assembleur d’un processeur fictif mais permettant une traduction parfaite vers les instructions du processeur cible.









sr17 a écrit :



Non



Car les implémentations seront vraisemblablement “bound checked”.





Non elles ne le seront pas : chaque page s’exécute dans un processus distinct sans la permission d’accéder aux API du système ou à la mémoire des autres processus et c’est la seule sécurité nécessaire. Au sein de ce processus le code peut faire tout ce qu’il veut.



Donc les seuls vérifications aux frontières seront celles qui existent pour n’importe quel code en espace utilisateur : la table de mémoire virtuelle du processus, consultée par le CPU à chaque lecture.



Le seul surcoût sera le fait de devoir passer par les API du navigateur plutôt que par celles du système.



On parle de modèle “double sandbox” : une première sandbox constituée du processus isolé (isolation mémoire, permissions du système), la seconde sandbox en ce que les seules API externes autorisées sont celles du navigateur.

ILPlais a écrit :



J’espère que ça ne sera pas un remake des applets Java ou d’ActiveX " />





De nos jours tous les navigateurs s’orientent vers le modèle de Chrome, à savoir l’isolation de chaque page dans un processus distinct. Or l’isolation mémoire entre processus est mise en oeuvre par le matériel et le système d’exploitation, et elle est probablement inviolable en soi.



Dès lors un processus (une page web) ne peut dialoguer avec le reste du monde que via les API exposées via le navigateur. Autrement dit les possibles failles de sécurité sont les mêmes que pour JS, ni plus ni moins, et liées aux fonctionnalités exposées par le navigateur. A vrai dire la seule différence est dans le compilateur et celui de WebAssembly sera beaucoup plus simple.



La situation était très différente avec ActiveX, Flash ou Java : tout le navigateur s’exécutait dans un unique processus, et tous avaient accès à des fonctionnalités plus étendues que celles offertes à JS.







brazomyna a écrit :



je vois pas comment ça peut faire gagner quoi que ce soit en perfs lors de l’exécution.

Ce que cette solution semble améliorer c’est juste le temps entre le moment où le code a fini de charger et le début de son exécution.

Donc ça démarrera plus vite mais ça s’exécutera pas plus vite pour autant.









Firefly’ a écrit :



c’est juste qu’au lieux d’avoir interpreteur + jit, on as que du jit. Avec un bytecode déjà optimisé (hors optimisation de plateforme, laissé au jit )





Non, ça va au-delà.



a) C’est un bitcode, pas un bytecode : les instructions équivalent à un assembleur générique là où dans le bytecode de Java & co les instructions sont de haut niveau, décrivant directement des appels de fonction et se référant à une structure de types.



b) Javascript a un typage dynamique, ce qui rend littéralement impossible la compilation sans surcoût de nombreux types et méthodes. Et si en théorie on pourrait optimiser davantage qu’aujourd’hui, en pratique les compilateurs sont contraints par le temps de compilation. Un langage dynamique ne pourra jamais être aussi optimisé qu’un code avec typage statique en général, point barre (même si on peut toujours écrire telle ou telle courte méthode donnant les mêmes perfs en JS qu’en C).





Grosso modo, scope du JS, avec les perfs du java/c# ( voir mieux ? (doute)  )



Les performances théoriques seront maximales, ni plus ni moins : un programme écrit en C++ pourra s’exécuter dans la navigateur a la même vitesse que sur le bureau.



Le surcoût de l’isolation est le même que celui déjà payé par les applis natives, “sur le bureau” (et équivalents smartphones). Et les défis de la compilation sont là aussi les mêmes.



La seule petite différence c’est que la compilation devra rester rapide sur le navigateur, une contrainte absente en offline. Mais il n’y a pas tant de boulot que ça à faire pour convertir du webassembly en asm. Il y a aussi le fait que les API du navigateur auront un léger surcoût par rapport aux API du système mais ça devrait être négligeable (encore qu’il y faudra offrir des API graphiques sans surcoût pour les applis en plein écran - en-dehors de ce mode il faudra conserver des garde-fous pour ne pas compromettre l’affichage).

Uther a écrit :



Ca n’a rien d’impossible, ca sera au pire plus complexe.





Ce serait surtout plus lent, donc je considère que ça ne sera pas viable.



Ça reste marginal cela dit : leur modèle conviendra à plus de 99% des applications existantes, écrites dans des langages avec pile d’appels et sans fibres ou autres fioritures.







marba a écrit :



Cette nouvelle m’inquiète pour les mêmes raisons. Aujourd’hui il est possible d’obscurcir le code js, cependant une analyse du comportement et un dé-obscurcissement est toujours possible. Avec le bytecodes c’est casser un peu ce qui à fait que le web est le web. L’ouverture, un langage universel, chacun peu faire du web, héberger son site, tout le monde au meme niveau.





Rien ne changera côté hébergement et le gain en performances et fonctionnalités vaut très largement le sacrifice d’une plus grande difficulté à désobscurcir.



On ne peut pas tout avoir et ils font inconstestablement le bon choix. Il est temps que le web offre enfin des performances natives et que le navigateur devienne un OS.

 



Pourquoi ne pas parler des alternatives au JS ?

 http://www.brython.info/   je préfère ce genre d’alternative



Le but même du projet est que chacun puisse utiliser le langage de son choix mais sans être limité par les possibilités de JS, que ce soit en termes de performances et de fonctionnalités.



La moitié des gros sites sont déjà écrits dans autre chose que du JS, puis compilés en JS sur serveur (ou plus rarement à l’exécution comme dans ton exemple). Mais JS limite cette approche.



Ta suggestion était tout simplement à côté de la plaque : ce n’est pas un nouveau langage, c’est un outil pour te rendre libre d’utiliser le langage de ton choix.

js2082 a écrit :



Tu likeras moins le jour où tu t’apercevras que ce nouveau langage est aussi un afficheur de pub intégré que tu ne pourras pas contourner malgré les adblocks et consorts.





C’est faux : cette techno ne change strictement rien pour la publicité par rapport à JS.







Kulvar a écrit :



Vu qu’adBlock & cie bloquent les REQUÊTES vers les pubs, tu t’en balance complètement du JS/WA…





C’est effectivement le cas sur Firefox.



Mais Chrome, lui, n’interdit que les modifications de l’affichage. ^^

Tu penses bien que Google n’allait pas t’autoriser à échapper à leur surveillance.