Journal hey wasm : wasi ! wazaaaaaaa

Posté par bubar🦥 le 01 avril 2019 à 19:00. Licence CC By‐SA.

Étiquettes :

avr.

2019

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/Linux (削除ここまで)~~Android, 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 :
vieux logo de mozilla qu'il ne faut plus montrer

# Rien compris

Posté par Zenitram (site web personnel) le 01 avril 2019 à 19:40. É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 le 01 avril 2019 à 22:32. É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 le 01 avril 2019 à 22:32. É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🦥 le 01 avril 2019 à 22:36. É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 le 02 avril 2019 à 08:21. É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 le 01 avril 2019 à 23:54. É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 le 02 avril 2019 à 14:57. É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) le 02 avril 2019 à 18:23. É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 le 03 avril 2019 à 22:14. É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) le 04 avril 2019 à 13:42. É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 le 04 avril 2019 à 14:13. Évalué à 3.
        
        Dans le genre "naufrage dommageable", j'ajouterai Dart qui c'est fait détrôné par TypeScript par paresse et Anti GG.
        
        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) le 04 avril 2019 à 14:31. É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 le 04 avril 2019 à 16:19. É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.
        
        Avant Angular et AngularJS, il y avait les WebComponents en Dart ...
        
        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) le 04 avril 2019 à 18:51. É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) le 03 avril 2019 à 16:06. Évalué à 3.
    
    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
    
    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 le 03 avril 2019 à 16:59. Évalué à 2.
      
      Question conne, mais si c'est tant une horreur, pourquoi ça existe et ça se développe ?
      
      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 :
      
      [...] pourquoi ça existe et ça se développe ?
      
      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) le 04 avril 2019 à 12:58. Évalué à 4.
        
        Question conne, mais si c'est tant une horreur, pourquoi ça existe et ça se développe ?
        
        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,...)
        
        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 :
        
        Quelle alternative existe aujourd'hui pour faire des app multi-plateformes (desktop + web à minima) ?
        
        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 le 04 avril 2019 à 14:11. Évalué à 2. Dernière modification le 04 avril 2019 à 14:11.
        
        Je sais bien qu'on est sur linuxfr, mais c'est sérieux comme réponse ?
        
        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 ?
        
        Surtout que la question était quand même précisée, orientée :
        
        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) le 03 avril 2019 à 18:53. É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) le 04 avril 2019 à 14:00. Évalué à 1.
      
      Quelle alternative existe aujourd'hui pour faire des app multi-plateformes (desktop + web à minima) ?
      
      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.
      
      Zelbinium: pour la génération qui crée, pas celle qui scrolle...
  - [^] # Re: un libc pour webassembly en somme ?
    
    Posté par Thibault le 04 avril 2019 à 06:58. É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 le 02 avril 2019 à 08:34. Évalué à 4.

Non, Java a besoin d’un greffon pour être exécuté dans un navigateur.

Non non ça n'existe plus depuis Java 11.
- [^] # Re: Applet Java
  
  Posté par BAud (site web personnel) le 02 avril 2019 à 14:25. É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.