Bonjour Nal<,
Quelques mots pour te signaler que Mozilla vient de starter une nouvelle disruption : il sera peut-être bientôt possible d’écrire un seul code (en Rust, C & C++, au hasard) qui s’exécute partout. Le même. Si si. Et là , cher Nal ton Noeil aiguisé comme ceux d’un aigle chassant sa proie tu sautes sur le trollomètre et crie « mais ça existe déjà , c’est Java !»
Non, Java a besoin d’un greffon pour être exécuté dans un navigateur. Et toc. En plus c’est tout naze. Re toc. Et on voit rarement des gens coder en C pour ensuite passer tout ça en Java. Re re toc. Et non ce n’est pas un april fool. Re re re toc.
WebAssembly c’est ce machin qui permet de faire des trucs vachement bien pour les apps dans les navigateurs. C’est Jaynial. Mais c’est quant même dommage d’avoir besoin d’un navigateur pour exécuter de telle merveille. Si wasm (webassembly) pouvait servir en dehors du navigateur nous aurions alors un seul code qui les gouverne tous qui pourrait être lancé sur MacOS, iOS, BSD/LinuxAndroid, GNU/Linux, les BSD et Windows, et dans ou en dehors de leurs brouteurs web. C’est là que wasi (WebAssembly System Interface) interviendra.
Allez plus loin :
Le ouebsite
La vidio
Un article du blog de Lin Clarke sur wasi
Un autre article (long et particulièrement bien fait, pour rappeler ce qu’est wasm) du blog de Lin.
Et y' a mĂŞme des tut_tut_oraux
Enfin la jolie Nimage :
# Rien compris
Posté par Zenitram (site web personnel) . Évalué à  5. Dernière modification le 01 avril 2019 à 19:40.
J'ai essayé de suivre, mais difficile… J'ai des logiciels codé en C++ mis en WASM donc je peux mettre dans le navigateur (avec ces limitations d'API genre impossible d'avoir l'API fichier "normale"), ça OK je comprend WASM.
J'ai sans doute rien compris sur WASI, car ce que je vois c'est un concurrent d'API de navigateurs en terme d'évolution qui pourraient être dans le navigateur aussi, avec une forme de navigateur sans interface web (node.js?), bref juste un fork de navigateur "étendu" en terme d'API et "sans GUI" saupoudré d'un peu de marketing.
J'ai loupé quoi?
[^] # Re: Rien compris
Posté par Tangi Colin . Évalué à  2.
A mon avis pas grand chose. Et faut aussi rappeller que wasm a d'énormes limitation, genre les threads etc…
[^] # Re: Rien compris
Posté par Tangi Colin . Évalué à  3.
A mon avis pas grand chose. Et faut aussi rappeller que wasm a d'énormes limitation, genre les threads etc…
[^] # Re: Rien compris
Posté par bubar🦥 (site web personnel) . Évalué à  4. Dernière modification le 01 avril 2019 à 22:37.
Le ton du journal est volontairement humoristique, mais la techno est intéressante : avoir une app qui s'exécute aussi bien dans un navigateur qu'en dehors, donc sur le bureau : qu'il soit Linux, Mac ou Windows, c'est très alléchant, non ? Même s'il s'agit d'un fork de navigateur soupoudré d'un peu de marketing comme tu le dis, ou bien si les enjeux pour le navigateur lui même peuvent être floues (?), il n'en reste pas moins cette alléchante idée : un seul code pour partout. Qui ne peut répondre à tout les besoins, certe, mais dont on peut déjà entrevoir les possibilités pour un paquet de trucs (et les impacts éventuels sur les stores pe aussi)
[^] # Re: Rien compris
Posté par redo_fr . Évalué à  5.
Hum… Si les GAFAM continuent à "pousser" toujours plus l'utilisation du navigateur, l'intérêt d'avoir une application "native" diminue en proportion… La plupart des gens se moquent de lancer une application sur leur système, eux ils vont "sur Google"…
Du coup, proposer un système qui permet à la fois de lancer sur le système et dans le navigateur va juste assurer une transition douce… vers le "tout navigateur"…
Celui qui pose une question est bĂŞte cinq minutes, celui qui n'en pose pas le reste toute sa vie.
# un libc pour webassembly en somme ?
Posté par steph1978 . Évalué à  4.
qui permettra donc des appels systèmes sur les OS qui auront un runtime.
[^] # Re: un libc pour webassembly en somme ?
Posté par cmal (site web personnel) . Évalué à  4.
Si j'ai bien suivi, l'idée est de distribuer le runtime avec ton application (linkage statique). Mais sinon c'est exactement ça oui. En gros le portage standardisé sur le desktop de WASM et du coup de tout l'écosystème web (HTML, CSS).
Alors est-ce souhaitable ? Probablement pas en théorie. Mais pratico-pratiquement c'est déjà ce que font beaucoup de gens avec Electron JS et c'est une horreur qui a besoin de disparaître du coup s'il faut WASI pour parvenir à ces fins, c'est à mon sens un compromis honorable.
[^] # Re: un libc pour webassembly en somme ?
Posté par YBoy360 (site web personnel) . Évalué à  2.
C'est un peu comme feu chrome native-client ?
Sauf que native-client gérait les dépendances…
[^] # Re: un libc pour webassembly en somme ?
Posté par steph1978 . Évalué à  3.
Déprécié au profit de webassembly, ça tombe bien ;)
[^] # Re: un libc pour webassembly en somme ?
Posté par YBoy360 (site web personnel) . Évalué à  1. Dernière modification le 04 avril 2019 à 13:43.
Oui, j'avais remarqué, après avoir bien joué avec dans le temps.
Les avantages de native client: déjà sandboxé, possibilité d'utiliser GCC, ou LLVM (portable Native Client) donc tous les langages, gestion des dépendances, presque pas de machine virtuelle, multithread. Le tout en 2013…
Bien que le projet était Open Source, il faut réinventer la roue, c'est WebAssembly qui a remporté les suffrages. Les objectifs futures de WebAssembly aujourd'hui, ressemblent vraiment à ce que faisait Native Client. Je comprends mal les raisons du détour qu'on est entrain de faire… C'est bien de faire comme la dame évangéliste de chez moz avec ces dessins Photoshop hyper hype, sans aborder le fond (les fonds, car j'ai lu les 2 articles, qui parte dans tout les sens).
Dans le genre "naufrage dommageable", j'ajouterai Dart qui c'est fait détrôné par TypeScript par paresse et Anti GG.
J'aimerai bien connaitre l'opinion qu'ont les utilisateurs de TypeScript de Dart pour voir, et les arguments (j'aime autant TypeScript que Javascript, c'est dire).
[^] # Re: un libc pour webassembly en somme ?
Posté par barmic . Évalué à  3.
Tu veux dire que quand les développeurs d'Angular ont choisi typescript c'est par anti-google primaire ? :D
[^] # Re: un libc pour webassembly en somme ?
Posté par YBoy360 (site web personnel) . Évalué à  2.
Angular, tu veux dire le machin qui bondi de 2 versions tous les 6 mois, ou 50 % du code ressemble à du Json tellement c'est structuré?
à la belle époque, celle où les développeurs développaient au lieu de faire des dessins débiles dans Photoshop, il était question de mettre une machine virtuelle Dart dans les navigateurs, chose qui ne s'est pas faite.
Avant Angular et AngularJS, il y avait les WebComponents en Dart … ça à disparu, au même moment que la promesse d'intégrer Dart dans les navigateurs…
Et oui, j'adorai les WebComponents avec Dart. J'aime vraiment pas Angular.
Regarde ce blog de 2012 pour en avoir une idée :
http://blog.sethladd.com/2012/11/your-first-web-component-with-dart.html
Ce n'est pas toujours le meilleur qui gagne.
[^] # Re: un libc pour webassembly en somme ?
Posté par barmic . Évalué à  3.
Ma remarque était surtout que les développeurs d'angular étant des employés de Google leur reprocher un comportement anti-google c'est plutôt rigolo. Je ne sais pas ce qui les a fait choisir ts face à dart, mais je doute que ce soit dû à un anti-google.
Wikipedia me dit que la première version d'AngularJS date de 2009 et la première version de dart de 2011 (avec un travaille qui aurait commencé en 2010).
Il faut savoir gérer sa frustration. Oui on a tous des préférences et elles sont pas toujours gagnantes. Les ruminer pendant des années (ça fait 4 ans qu'ils ont annoncer abandonner l'idée d'intégrer dart à chrome), ça rend aigris.
[^] # Re: un libc pour webassembly en somme ?
Posté par YBoy360 (site web personnel) . Évalué à  1.
j'avais remarqué ton smiley, j'ai pas été très courtois mais ça n'était pas contre toi. En plus t'as raison, c'est Google qui a peur de son ombre qui a fait sombrer les WebComponent et Dart et le reste..
Il existe maintenant Angular Dart, mais je sais pas. J'ai passé trop de temps à jouer avec des technos hyper prometteuses, j'en ai marre. D'autant plus que faire de l'Angular 7, 8 ou 9 TS inside quand on a fait du Dart avec les WebComponent, ça fait pas envie. On fait tout sur le serveur, et on utilise un minimum de React en Javascript (avec quelques composants en AngularJS).
Ça vaut ce que ça vaut. C'est pas l'extase, mais mon besoin est surtout que la techno soit pérenne dans le temps. Au moins, Javascript, je pense que c'est là pour un moment.
[^] # Re: un libc pour webassembly en somme ?
Posté par CrEv (site web personnel) . Évalué à  3.
Question conne, mais si c'est tant une horreur, pourquoi ça existe et ça se développe ?
Quelle alternative existe aujourd'hui pour faire des app multi-plateformes (desktop + web Ă minima)Â ?
[^] # Re: un libc pour webassembly en somme ?
Posté par barmic . Évalué à  2.
Il y a beaucoup de choses qui se développent sans que ce soit particulièrement souhaitable (extrémisme, les cyberattaques, le harcèlement, le spam, les platistes, les antivax,…). Se questionner sur le pourquoi est-ce que ça existe est tout à fait pertinent, mais ça n'est pas en soit un argument qui va dans leur sens. On peut expliquer la violence des manifestations (et donc la comprendre) sans pour autant être d'accord.
Mais pour répondre :
Parce que les navigateurs ne font pas encore un boulot suffisant, je pense. Si une application peu fonctionner sur le web, il n'y a pas de raison qu'elle en sorte. C'est en soit une méthodologie qui permet d'avoir les inconvénients des 2 mondes.
Par exemple l'un des enjeux des navigateurs c'est de mieux les ressources : pas forcément consommer moins, mais segmenter mieux chaque site et mieux isoler/montrer quel site consomme les ressources.
Il y en a probablement d'autres.
[^] # Re: un libc pour webassembly en somme ?
Posté par CrEv (site web personnel) . Évalué à  4.
Je sais bien qu'on est sur linuxfr, mais c'est sérieux comme réponse ?
Une question sur l'omniprésence d'electron et la réponse parle de "extrémisme, les cyberattaques, le harcèlement, le spam, les platistes, les antivax" ?
Surtout que la question était quand même précisée, orientée :
Parce que on peut crasher autant qu'on veut sur electron, aujourd'hui c'est tout de mĂŞme ce qui permet Ă plein d'app d'exister aussi bien sous forme d'appli desktop que de site web.
Ça a écrasé les dernières tentatives à la GTK, Qt, etc.
[^] # Re: un libc pour webassembly en somme ?
Posté par barmic . Évalué à  2. Dernière modification le 04 avril 2019 à 14:11.
C'est une méta-argumentation, les exemples ne sont pas heureux certe, mais ils ne sont pas là pour faire un parallèle. Juste pour illustrer mon argument. Je le redis de manière plus simple et sans fioriture :
Indépendamment de la qualité ou non d'electron/nodejs/js, l'argument qui dit que si ça se développe c'est que c'est souhaitable (ce que tu sous-entendais), n'est pas valide à mon humble avis.
Ça te choque moins, exprimé ainsi ?
Et j'y ai répondu, je sais bien qu'on est sur linuxfr, mais répondre à un commentaire sans lire ou chercher à comprendre le commentaire auquel on répond ?
Tu remarquera que je n'ai dis nul part que ces techno ont en soit un problème de qualité, juste que faire du desktop + web pose des soucis de gestions.
[^] # Re: un libc pour webassembly en somme ?
Posté par flan (site web personnel) . Évalué à  3.
La question amène sa réponse : sur le web il n'y a que le JS de possible.
À partir de là , ta question revient à demander pourquoi il n'y a pas de concurrence dans les domaines couverts par un monopole d'État…
[^] # Re: un libc pour webassembly en somme ?
Posté par Claude SIMON (site web personnel) . Évalué à  1.
Avant d'utiliser Electron, j'utilisais Chromium Embedded Framework, qui, comme son nom le laisse entendre, est également basé sur Chromium, et, encore avant ça, j'utilisais XULRunner, qui utilisait le moteur de rendu de Firefox, mais qui n'est plus officiellement maintenu.
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
[^] # Re: un libc pour webassembly en somme ?
Posté par Thibault (site web personnel) . Évalué à  2.
WASM n'a pas vraiment de rapport avec le HTML, CSS ou même javascript. De base un programme en Webassembly, même exécuté dans un navigateur, ne peut même pas interagir directement avec le DOM.
Le but ici est simplement de définir une sorte de sous-ensemble de POSIX ce qui permettrait de compiler un programme desktop "classique" vers un binaire multiplateforme qui s’exécuterait dans une sandbox au travers de la VM webassembly.
C'est difficile de comparer ça avec Electron car tu n'as pas besoin de déballer un navigateur au complet, la norme actuelle de webassembly est relativement simple et est prévu pour être indépendante du reste du web.
# Applet Java
Posté par barmic . Évalué à  4.
Non non ça n'existe plus depuis Java 11.
[^] # Re: Applet Java
Posté par BAud (site web personnel) . Évalué à  2.
les applets, c'était obsolète depuis openJDK 9 : https://openjdk.java.net/jeps/289
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.