Version imprimable
Il n'y a pas de compilateur C++ intégré au navigateur. Le système de fonctionnement sera du type :Citation:
Envoyé par pol2095
Le Wasm aura accès aux même API que JavaScript, ni plus ni moins.Code:
2
3
4
5
D'accord, c'est un langage de bytecode (comme Java) donc moins rapide que du natif, mais plus facile à faire fonctionner sur des systèmes différents.
Pour info, Qt - une bibliothèque C++ très utilisée - continue d'investir dans ce genre de techno et planifie pour la version 5.10 (la version actuelle est la 5.8) de pouvoir faire tourner le rendu graphique à distance depuis un navigateur. Je vous laisse imaginer les possibilités en termes d’interaction (via wifi) avec des objets connectés... (plus besoin d'installer une application sur son smart phone !)
http://blog.qt.io/blog/2017/02/22/qt-roadmap-for-2017/Citation:
Running Qt applications in a browser via Native Client (NaCl) has been possible since 2009 and since Qt 5.8 VNC can be used for remote control of Qt applications. However these options are often not as convenient as desired. With Qt 5.10 we are planning to support streaming of Qt Quick application UIs over a network to a browser using WebGL. This streaming of OpenGL commands will allow using a common browser as a remote display of a Qt application running e.g. in a nearby embedded system or far across a network. Input from touch/mouse as well as keyboard is transmitted back to the Qt application. WebGL streaming will be implemented as a platform plugin in Qt 5.10. The streaming plugin converts all painting commands to WebGL commands and transmits the streams to clients. In turn those clients transmit user input back. Clients can be Qt applications or any web browser capable of showing WebGL 1.0.
non ce n'est pas du bytecodeCitation:
Envoyé par pol2095
le bytecode est un code pour un processeur imaginaire qui aurait un nombre illimité de registre.
WASM est un arbre syntaxique
pour simplifier à l'extrême c'est un peut comme une fonction écrite en lisp les noeud sont les opérateurs et les feuilles des opérandes.
Voici un exemple d'AST généré par ClangCeci n'a rien à voir avec un code de type bytecode.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
WASM est une représentation binaire de ce type d'objet.
Il n'est pas tout a fait vrai que le navigateur ne contient pas de compilateur.
en fait les compilateurs modernes utilise des chose comme llvm. il passe par un AST pour séparer l'analyse syntaxique de l'analyse sémantique
la première construit l'AST la seconde le parcours pour produire le code final.
C'est cette dernière partie qui est embarquée.
A+JYT
On est quand même très proche de ça : WASM définit un format binaire à destination d'une stack machine:Citation:
Envoyé par sekaijin
https://docs.google.com/document/d/1...uCZw7biII/edit
et c'est seulement sa représentation textuelle - qui par convention est en S‑expression (lisp like) - qui peut être qualifiée d'AST. Mais cette représentation textuelle n'est pas WASM (qui est binaire), et elle ne peut pas être comparée à l'AST de Clang :
Je précise pour les lecteurs qu'il s'agit là de l'AST de LLVM et pas de WASM. Et pour l'annecdote, cet AST :Citation:
Envoyé par sekaijin
- il n'est pas abstrait (A) mais concret
- il n'est pas syntactique (S) mais sémantique
- ce n'est pas un arbre (T) mais un graphe
:)
Voici un exemple "d'AST" de WASM:
http://ast.run/Code:
2
3
4
5
6
7
8
9
10
11
12
Tu peux voir qu'on est beaucoup plus proche d'un langage machine abstrait de type bytecode, CIL (.Net), ou IR de LLVM... Non?
:)
Je pense que le terme AST n'est pas vraiment bon, même si c'est celui qui est utilisé dans les documents de travail que j'avais regardé. En effet, quand on parle d'AST on s'attend a un arbre qui représente la syntaxe du langage d'origine, ce qui n'est pas le cas de WASM. Pour moi c'est plus un bytecode dans le sens ou il est une représentation intermédiaire indépendante du langage d'origine.Citation:
Envoyé par sekaijin
Pour moi, le terme le plus juste serait bytecode arborescent, alors que Java ou LLVM-IR seraient des bytecodes séquentiels.
Qu'entends-tu par bytecode sequentiel?Citation:
Envoyé par Uther
Ce sont des sujets pointus que je ne maîtrise pas, mais j'ai trouvé une différente entre WASM et ce qui se fait dans la plupart des autres langages : WASM n'est pas compatible avec la forme SSA.
Je ne sais pas bien ce que cela implique, j'aurais plutôt pensé que ça éloignait au contraire d'un design arborescent?!
Bref, je me demande... d'où vient cette histoire d'AST avec WASM?
Oui c'est toujours la difficulté de simplifier de trop pour vulgariser.
le bytecode java est une suite d'instructions pour un processeur abstrait
chose que n'est pas WASM même dans sa forme binaire.
Il se situe un cran avant la production d'une séquence d'instructions. cette dernière étant faite par le navigateur.
Difficile de causer de tels concepts tout en utilisant un langage commun.
A+JYT
Pardonnez mon ignorance mais c'est quoi l’intérêt de faire tourner gimp dans un navigateur ? sa apporte quoi de plus qu'un client lourd ?Citation:
Envoyé par Tartare2240
Je développe que des clients lourd pour ma part, il existe pleins de solution simple pour pallier aux problèmes du développement multi-plateforme, du déploiement et des mise à jours (c'est souvent les remarques que j'entends de ceux qui développe du web)
Le dernier programme que j'ai développé (en python et QT) se mets à jour en utilisant un système de maj delta (il ne télécharge que les modifications entre le version du client et la dernière du serveur) et applique les mises à jour sans redémarrer le programme, donc sans killer et redémarrer les processus de mon soft.
L'avantage du client lourd par contre il est évident, c'est fonctionnel ! pas besoin de tester son programme à chaque maj des navigateurs.
Niveau performance, je sais pas si faire tourner des programmes comme gimp dans un navigateur se soit une bonne idée, ces programmes sont censé tirer partie au mieux du matos qu'il dispose et par conséquent sa nécessite des optimisations très fines de la part des dev, je ne sais pas mais je ne pense pas que webassembly soit aussi fin que des langages comme C/C++ ?
sans même parler des perf, il y'a la latence du au réseau, utiliser google doc pour moi est un "enfer" par exemple, c'est pas fluide sa n'a rien à voir avec libre office/ms office d'installer sur mon pc.
Quand aux jeux vidéos dans le navigateur, pour remplacer les jeux flash oui mais il me semble techniquement aujourd'hui impossible d'arriver à faire un open world à la witcher 3 dans un navigateur en webGL, à un moment donné faut être réaliste.
Vous pouvez voir le jeu Bananabread, c'est du même style que Quake3 (la version d'origine et la version web), c'est une régression de 20ans techniquement, on est loin d'un Arma3 Apex.
C'est peut-être un moyen d'inverser la tendance, parce qu'aujourd'hui internet, c'est 80% pour les apps et 20% pour le navigateur. Le navigateur est en perdition.
Je pense que c'est surtout conçu pour développer des jeux, mais ce qui manque avant tout au navigateur, c'est un SDK.
L’intérêt c'est que les utilisateurs occasionnels peuvent l'utiliser directement sans installation définitive. Pour un usage régulier en effet une bonne application lourde semble préférable.Citation:
Envoyé par RyzenOC
ok merci, on est donc bien sur la même longueur d'onde.Citation:
Envoyé par Uther
J'ai creusé un peu plus le sujet et réussi à clarifier (un peu) cette histoire d'AST :)
WASM peut être vu comme une forme particulière de bytecode (de haut niveau) qui se distingue de Java/.Net par son support du modèle mémoire de C/C++. WASM dispose donc de son jeu d'instructions "virtuel" (Instruction Set Architecture) qui se distingue de LLVM par sa portabilité, sa faible taille et sa rapidité à être compilé. Cela trahit les priorités de WASM : poids faible des binaires pour un téléchargement rapide, rapidité de lancement dans le navigateur. A l'inverse LLVM a pour priorité de permettre des optimizations poussées du code par les backends. WASM s'en remet à ce dernier pour effectuer les coûteuses opérations d'optimisation et ne pas avoir à le faire lui-même.
N'ayant pas cette dernière contrainte, WASM peut se permettre de ne pas descendre au niveau du graphe de contrôle (CFG) / bytecode SSA comme les compilateurs mais rester au niveau de l'arbre syntaxique (AST) afin d'avoir une représentation plus compacte et permettre sa conversion en asm.js.
A noter que l'expérimentation PNaCl de Google a cherché à adapter le bytecode de LLVM pour satisfaire ces mêmes contraintes (le bytecode généré est livré et doit donc rester stable dans le temps là où le langage intermédiaire de LLVM est temporaire à la compilation et peut changer d'une version à l'autre). Mais les auteurs de WASM ont jugé qu'il était préférable de partir d'une page vierge plutôt que de chercher à adapter un système ayant d'autres objectifs.
https://github.com/bnjbvr/webassembl...r/Rationale.md
https://github.com/WebAssembly/desig...-binary-format
On peut aussi le voir à l'envers : pouvoir alourdir les applications web plutôt que de "webiser" les clients lourds :)Citation:
Envoyé par RyzenOC
En plus des avantages donnés par Uther, il y a aussi :
- la portabilité : au hasard, supporter les multiples distributions Linux ça consomme beaucoup de temps. Là tu cibles une seule plateforme et c'est réglé (du moins c'est la promesse)
- contrôle des licences : c'est beaucoup plus facile de t'assurer que tes utilisateurs n'ont pas une version crackée de ton soft !
- itinérance : l'utilisateur met ses données dans le cloud ($$$) et peut basculer d'un ordi à l'autre facilement
Après le client lourd natif risque de garder encore longtemps son avantage dès qu'il y a des traitements algorithmiques lourds. Au hasard, un logiciel de montage vidéo...
Arriver à tourner à 150% des performances d'un code natif de base, c'est super. Mais un code natif optimisé peut tourner 3, 4, 10 fois plus vite que sa version de base, sans parler de la consommation mémoire et encore moins du multicoeur car WASM ne supporte pas le multi-threading (pour l'instant) !
Oui je pense que c'est ce qu'il faut y voir et pas vouloir remplacer ce qui se fait aujourd'hui en client lourd.Citation:
Envoyé par Aurelien.Regat-Barrel
Par exemple les démos graphiques sont pour moi totalement stupides, on s'extasie devant des trucs qui se faisait il y a 10 ans sur du client lourd. Sans parler que les jeux aujourd'hui c'est les dizaines de Go des ressources qui sont longues à télécharger, franchement le joueur n'y gagnera rien à jouer sur le navigateur.
Là par contre je suis pas vraiment d'accord. La portabilité j'y crois pas, il n'y a qu'a voir sur des pages web relativement simple il arrive souvent qu'il y ait des incompatibilités, alors sur du complexe je ne vois pas par quel miracle les problemes ne vont pas se mutliplier.Citation:
Envoyé par Aurelien.Regat-Barrel
-Le controle des licences je ne vois pas ce que ca change? Le control ne peut se faire que si c'est le serveur qui possede l'intelligence, si c'est le client qui travail quelque soit la technologie ca sera toujours crackable.
-Pour les données je ne comprends pas où est la difference avec un client lourd? C'est comme si tu confondais client lourd et déconnexion. Un client lourd il peut aller autant sur internet qu'un navigateur, si ce n'est encore plus parceque non limité par http!
Parce que - de ce que j'en ai compris - c'est du rendu OpenGL, pas du DOM/HTML/CSS. Exemple d'application C++/Qt qui tourne dans le navigateur (grâce à Emscripten) :Citation:
Envoyé par micka132
http://vps2.etotheipiplusone.com:301...es/tetrix.html
On est d'accord que y'aura des problèmes d'incompatibilités entres navigateurs. Mais malgré tout, je pense qu'assurer la portabilité de cette façon est (beaucoup) moins coûteux que pour une application native portée sur plusieurs (déclinaisons d') OS. Et au pire des cas, si ça ne marche que sur Chrome par exemple, bon ben voilà, les principaux OS sont tous supportés moyennant l'utilisation de Chrome.
C'est vrai. Dans mon esprit ce genre de techno (WASM) est une techno hybride - dans le sens de non destinée à être utilisée de façon isolée - qui sert à déporter (soulager) une partie de l'intelligence du serveur vers le client là où le client lourd va plutôt chercher à faire l'inverse. Donc pour moi avec WASM on a un modèle intrinsèquement connecté au Cloud (c'est un serveur web qui délivre l'application) là où pour le client lourd c'est quelque chose de plus qu'il faut mettre en place (et c'est assez complexe d'ailleurs).Citation:
Envoyé par micka132
Je n'avais pas imaginé qu'une application WASM puisse être lancée de manière locale comme une appli classique qu'on aurait préalablement téléchargé. Et je ne sais pas trop quoi penser de ce fonctionnement là !
Nous avons eu tout un tas de tentatives pour faire des applications desktop à partir des technos web app
Et effectivement WASM ouvre une voie dans ce sens.
Mais pour le moment le but c'est le navigateur.
Il est un point qui est important dans cette affaire c'est que WASM dans le Navigateur prévoit l'interaction entre WASM et JS.
Ce faisant nombre de fonctions que font tous les frameworks JS peuvent être mises à disposition sous la forme d'un Modules WASM.
Si on prend des librairies JS qui fournissent des widgets complexes un des problèmes est que cela est lourd et coûteux en code JS. non pas de coder avec mais de les avoir à dispo.
La même API JS ou presque en WASM sera plus compacte, plus efficace, plus rapide.
Cela permettra de bénéficier de toute la puissance de WASM dans les applications JS telles que nous les développons aujourd'hui.
Je ne veux pas dire par là qu'il faut reproduire les Lib JS que nous connaissons à l'identique. Mais qu’il faut repenser des frameworks JS en WASM pour qu'un site Web puisse en utiliser les fonctionnalités!
Pour moi il ne faut pas voir WASM comme un remplaçant de quoi que ce soit. il faut le voir comme un outils complémentaire à d'autres solutions.
il ne remplacera pas les compilateurs natifs, il ne remplacera pas la JVM ou .NET il ne remplacera pas JS
S'il réussit (est adopté) il se fera une petite place quelque part entre tout ça. Débordant sur le périmètre de certaines de ces technologies sans prendre toutes la placent. Se faisant il va nous forcer à revoir certains choix, non parce qu'il remplace mais parce qu'il apporte une autre perspective sur le sujet.
Comme chaque fois qu'une nouvelle technologie arrive on va découvrir d'autres façons d'appréhender les problèmes.
A+JYT
PS Il ne faut pas oublier les plug-ins qui sont des cibles potentielles.
j'ai testé la démo sur mon ultrabook, ça saccade par rapport à la vidéo, avec en plus un beau plantage de Firefox. Sur mobile, il ne faut même pas y penser pour le moment.
De plus le temps de chargement...
Je vais sans doute dire une énormité.Citation:
Envoyé par Aurelien.Regat-Barrel
Imaginons une application utilisant de l'IA. A l'heure actuelle, cette appli va demander du HPC et donc une station qui ne servira "que" de client pour traiter cette partie. Ou toute autre partie gourmande en puissance de calcul.
Avec du WASM, nous aurons l'avantage de ne disposer que de la partie UI sur le client à travers le navigateur transmettant uniquement les informations de l'utilisateur et tout le traitement lourd se fera en déporté dans le cloud en s'affranchissant d'énormément de contraintes techniques liées aux technologies. Et miracle, WASM peut être implémenté avec C# simplifiant la tâche du concepteur au développeur.
Pour la partie exécution en locale, avec l'hétérogénéité des plateformes, utiliser le navigateur comme environnement final d'exécution devient une solution ébauchée avec asm.js, et à mon sens bon nombres d'applis demandant d'être codées pour iOS, Android, Windows, Linux vont être simplifiées dans leur conception grâce à WASM. Reste à voir en production l'optimisation dépendante du navigateur d'un client de messagerie par exemple. J'espère que le W3C continuera à maintenir sa main mise sur le standard afin que cela ne parte pas dans tous les sens sinon la technologie perdrait son principal avantage : la portabilité alliée à des perfs respectables et suffisantes pour la satisfaction de l'utilisateur. Et dans un monde progressant vers le cloud, la 5G arrivant à grands pas, l'IA prenant de plus en plus place, je pense qu'il faut réfléchir mobilité donc hétérogénéité et de moins en moins poste de travail-clavier-souris.
Evidemment, CATIA sur smartphone ou hybride, ce n'est pas demain la veille :mrgreen:
Le support de WebAssembly est désormais disponible dans tous les principaux navigateurs
Safari et Microsoft Edge emboîtent le pas à Firefox et Chrome
WebAssembly, ou wasm, est un nouveau type de code qui peut être exécuté dans un navigateur web moderne. C'est un langage bas niveau semblable à l'assembleur, permettant d'atteindre des performances proches des applications natives (par exemple écrites en C/C++) tout en fonctionnant sur le Web. WebAssembly est conçu pour fonctionner en lien avec JavaScript et, en passe de devenir une norme dans l'industrie, il donne aux développeurs web un certain nombre d'options qu'ils n'avaient pas auparavant. Il leur permet par exemple de :
- profiter du format compact wasm pour transmettre des fichiers rapidement sur le réseau et les charger en tant que modules JavaScript ;
- obtenir des performances quasi natives sans utiliser de plug-in ;
- écrire un code à la fois performant et sécurisé, car il s'exécute dans le sandbox de sécurité du navigateur ;
- avoir un choix de langages en dehors de JavaScript. Il permet par exemple aux développeurs d'écrire du code en C ou C++, puis de compiler directement en wasm, sans devoir compiler le code en JavaScript d'abord. En dehors de C/C++, des langages supplémentaires seront supportés à l'avenir.
Avec les avantages qu’il présente, il n’a fallu que deux ans à tous les principaux fournisseurs de navigateurs pour prendre en charge le nouveau standard. Hier, dans un billet de blog, Mozilla a en effet annoncé que le support WebAssembly est désormais disponible dans tous les principaux navigateurs. Au cours des dernières semaines, Apple et Microsoft ont fourni de nouvelles versions de Safari et Edge, avec le support de WebAssembly. Étant donné que Mozilla Firefox et Google Chrome prenaient déjà en charge WebAssembly, cela veut dire que les quatre principaux navigateurs sont désormais capables de générer du code compilé dans le format wasm sur le Web.
« Google, Apple et Microsoft s'étaient tous engagés à prendre en charge WebAssembly dans leurs navigateurs. Avoir ce support sur le marché aujourd'hui est un développement vraiment passionnant », a déclaré Luke Wagner, l'ingénieur de Mozilla qui a créé le précurseur de WebAssembly, asm.js, et qui a dirigé le travail sur la spécification WebAssembly.
Pour les développeurs, la prise en charge du nouveau standard par les principaux navigateurs signifie qu'ils peuvent tirer parti de WebAssembly avec l'assurance que la plupart des utilisateurs seront en mesure d'exécuter des modules wasm par défaut.
WebAssembly apporte des performances sur le Web qu'il est extrêmement difficile d'atteindre avec JavaScript seul, notamment pour l'industrie du jeu. « Asm.js et WebAssembly étaient sans l'ombre d'un doute pour les entreprises de l'industrie du jeu, car elles avaient d'énormes investissements dans des programmes en C ++ qu'elles ne voulaient pas réécrire pour le Web », a déclaré Wagner. Raison pour laquelle cette industrie a été la première à adopter WebAssembly et asm.js. D’après l’ingénieur de Mozilla, Epic et Unity ont devancé les autres en étant les premiers à mettre en ligne leurs moteurs de jeu à l'échelle industrielle sans réécrire les bases de code C++ en JavaScript.
Mais aujourd'hui, les cas d'utilisation de WebAssembly et asm.js se sont développés au-delà des jeux en ligne. À mesure que les utilisateurs expérimentent le processus d'utilisation du format WebAssembly, et du compilateur Emscripten, ils trouvent des moyens de transférer des applications de plus en plus sophistiquées vers le Web. D'après Luke Wagner, les applications portées sur le Web grâce à WebAssembly couvrent divers domaines, y compris la vision par ordinateur, la cartographie 3D, le traitement des signaux numériques, l'imagerie médicale, la simulation physique, le chiffrement, la compression, etc. « Nous voyons maintenant des gens utiliser WebAssembly pour toutes sortes de nouveaux projets », dit-il. Pour lui, cela promet que nous serons un jour capables de faire tourner n'importe quelle application sur le Web et de la faire fonctionner comme si elle fonctionnait localement sur un PC.
Source : Blog Mozilla
Et vous ?
:fleche: Qu’en pensez-vous ?
D'un cote, c'est la mort lente du client léger qui est à l'origine du web...
De l'autre cote, ca ouvre la porte du navigateur à d'autres langages, et du coup, ça signe peut etre une periode où on pourra réduire la fragmentation de nos stacks entre back et front autrement qu'en faisant du js cote serveur...