🍪🌐 Pourquoi vous allez enfin commencer à utiliser WebAssembly.

Temps de lecture : 5 minutes

mai 02, 2024

WebAssembly est officiellement supporté par tous les navigateurs depuis 2017. L'avez-vous déjà utilisé ? Moi, jamais.

Aujourd’hui, je vais vous expliquer pourquoi vous non plus vous ne l’avez jamais utilisé et nous parlerons d’une nouveauté qu’ils ont sorti en janvier 2024. Je vous expliquerai pourquoi vous allez peut-être enfin décider de l’utiliser. Surtout maintenant que Ruby (3.2) le supporte.

Au programme aujourd’hui :

Pourquoi vous allez enfin commencer à utiliser WebAssembly par Tim
L’agence de recrutement pour les leads dévs RoR !

Temps de lecture : 5 minutes

Hello les petits Biscuits !

Bienvenue sur la 21ème édition de Ruby Biscuit.
Vous êtes maintenant 478 abonnés 🥳

Avant de vous laisser entre les mains de Tim pour l’article du mois, je tenais à vous rappeler que vous êtes tous les bienvenus pour donner votre avis en commentaire et partager vos expériences sur les sujets que nous abordons. Vous pouvez aussi mettre un petit like ❤️ et/ou partager la newsletter à un copain ou une copine ! 😉

Bonne lecture.

Pourquoi vous allez enfin commencer à utiliser WebAssembly

Commençons par les présentations.
Webassembly (WASM) est le quatrième standard du web, après HTML, CSS et JavaScript.

C'est un format binaire, proche du langage machine, conçu pour s'exécuter dans le navigateur. Quelle que soit la plateforme, ce code s'exécute de la même façon et à une vitesse quasi-native, c'est-à-dire aussi performante que celle obtenue avec le langage de prédilection de la machine sur laquelle ce code tourne.

Ce code est exécuté dans une sandbox, un environnement isolé qui ne peut pas interagir directement avec le système hôte. Ceci est crucial pour des questions de sécurité, afin d'éviter que du code malicieux ne puisse déclencher une catastrophe sur l'appareil de l'utilisateur, comme manipuler ses fichiers à son insu.

Pour générer du code dans ce format (.wasm), il faut le compiler, ce que l'on peut faire à partir de nombreux langages, dont Ruby.

Mais comment on l’utilise ?

L'implémentation dans les navigateurs (via l'objet WebAssembly) nous permet de compiler du code wasm en module instanciable et utilisable en Javascript. Vous pourrez trouver plus de détails sur cette API ici.

La gem ruby.wasm nous simplifie la tâche en faisant ça pour nous, via un script qu'elle fournit. On peut alors écrire du code Ruby dans le navigateur ainsi :

On remarque le require 'js' : les navigateurs n'autorisant pas l'accès direct au DOM par le code WASM, c'est une implémentation offerte par la gem déléguant au Javascript ces opérations. C'est ce qu'on appelle des bindgen : on y déclare les fonctions Javascript que l'on souhaite importer de l'hôte (le navigateur), et ce qu'on veut exporter de l'invité (le module WASM).

Qu'est-ce qu'on peut en faire ?

"But can it run Doom?" Je ne serais pas contre une petite partie avec ceux qui le veulent 😁. Pour ceux qui ne connaissent pas ce meme, c'est un jeu de 1993 qui était une grosse révolution à l'époque et maintenant les internets se défient à le porter sur toutes les machines possibles (calculatrices, oscilloscopes, brosses à dents, ...). Mais bon on est en 2024 quand même, on peut jouer à Doom 3.

Plus sérieusement, si vous avez déjà utilisé Photoshop ou Figma, ces applications web tournent en WebAssembly. Figma a utilisé cette technologie pour y porter sa base de code en C++.

À plus petite échelle, on pourrait avoir sur un champ d'upload de fichiers, un module Python en front à qui on déléguerait une fonction de reconnaissance de signature ; on éviterait ainsi un aller-retour avec le serveur back. Le YouTubeur Fireship a monté un exemple où il a implémenté un convertisseur vidéo entièrement géré dans le navigateur. La communauté Rust est d'ailleurs très active, et a créé plusieurs frameworks front en Rust ; on peut donc coder une appli web 100% Rust, du back au front.

Il suffit de compiler ce qu'on veut vers le format WASM alors ? Oui, et non...

Limitations

On va calmer la hype :

pas de networking (sockets, ...)
pas de Threads
pas d'import de gems
le bundle Javascript pour l'implémentation Ruby du WASM est énorme (35 Mb)
pas de système de fichiers (donc pas de require './mon_script.rb' dans un module WASM)
c'est pas beaucoup plus rapide que le Javascript actuel
- les frameworks Rust et Javascript ont des performances similaires
- une start-up qui avait comme pitch d'accélérer les apps web actuelles en les portant en WASM, a fermé ses portes car les gains de performances étaient trop marginaux.

Bah c'est nul alors ? Attendez, laisser moi vous présenter WASI !

Le WASM a des avantages indéniables, en particulier le fait d'être du code isolé appelable de n'importe où et qu'on peut écrire dans une grande variété de langages. Le WASI (WebAssembly System Interface) a donc été développé pour pouvoir utiliser cette technologie en dehors du navigateur, en y ajoutant une API et une ABI (Application Binary Interface). Grossièrement, une ABI est comme une API, mais à un niveau plus bas, au niveau du code machine. On va par exemple y définir comment un module doit faire sa gestion de mémoire.

En particulier, en Janvier 2024, la version 0.2 est sortie, et offre entre autres ces améliorations majeures :

la possibilité de faire du networking, avec des sockets et des requêtes HTTP.
un système de fichier virtuel.
et surtout le component model, permettant d'importer des packages à partir de son module.

Pour exécuter du WASI, il suffit d'utiliser un runtime. Il y en a plusieurs de disponibles, qui sont spécialisés en fonction de l'environnement ciblé par votre code. Le plus généraliste (en tout cas celui que j'ai vu remonter le plus souvent) semble être Wasmtime.

Quel que soit le langage que vous utilisiez, ce runtime l'exécutera. On peut donc écrire du code Ruby qui tournera sur un frigo « connecté ». Autrement dit, Ruby peut maintenant distribuer des applications facilement, sans que son utilisateur soit obligé d'installer Ruby sur son terminal.

Pour ceux qui connaissent Docker, un cofondateur (Solomon Hykes) a affirmé que « Si WASM+WASI existait en 2008, nous n'aurions pas eu besoin de créer Docker : c'est aussi important que ça. »

Où est-ce qu'on peut utiliser le WASI ?

On peut également l'utiliser dans le browser, grâce à des polyfill. Wasmtime en fournit un ici par exemple. Ce qui nous libère de certaines limitations citées plus haut.

Mais on peut aussi l'utiliser dans le Cloud, dans des fonctions serverless, ce qui permet d'avoir des « cold start » (démarrage d'un module) très rapide, tout en n'utilisant pas de technologie propriétaire (le vendor lock). Ou dans les systèmes embarqués, ou en tant que plugins pour d'autres logiciels, et aussi dans le serveur back d'une appli web.

Autrement dit, quel que soit votre environnement ou votre langage (si ce langage le supporte), vous pouvez compiler et importer des modules WASM.

C'est ici que le component model introduit avec la version 0.2 est particulièrement intéressant, voir assez révolutionnaire. Ce modèle apporte une canonical ABI, qui permet à des modules différents de pouvoir communiquer entre eux. Par exemple, un module en C pourrait représenter une chaîne de caractères d'une autre manière qu'un module Rust ; cette canonical ABI leur fournit un format leur permettant de s'échanger correctement ces chaînes malgré les « frontières » binaires de ces modules. Je vous recommande cette conférence pour en savoir plus.

Ce modèle permet également d'avoir une interopérabilité des langages dans leurs dépendances. Concrètement, on peut avoir un module WASM écrit en Python, qui appelle un autre module en Elixir, qui lui-même appelle un autre module en C. Si ça attise votre curiosité, voici une autre conférence qui vous montre ça en direct. Cela veut dire en théorie que l'on peut appeler une librairie d'un langage supportant le WASI à partir de n'importe quel autre langage supportant le WASI. Donc par exemple importer des librairies Javascript dans Ruby, ou des librairies Ruby dans Javascript. Il n'y aurait en théorie plus besoin de dupliquer les mêmes outils à travers tous les différents langages.

Ce qu'on peut retenir

Si une librairie a déjà été compilée en WASM, vous n'avez pas à le refaire. Par exemple ce package npm vous donne accès à SQlite à partir de Javascript. Il est possible que l'on voit de plus en plus de packages de ce genre à l'avenir, donc restez à l'affût des gems.

Une conférence de la rubykaigi 2024 de Yuta Saito en mai devrait être particulièrement intéressante à suivre : il y montrera comment packager une application Ruby et ses dépendances de gems dans un programme WebAssembly.

Il semblerait que l'on soit dans l'étape de la « Pente de l'illumination » du cycle du hype. Si c'est le cas, gardez cette technologie en tête lors de vos recherches, on pourrait y voir apparaître des outils très intéressants. Par exemple warg, qui sera un package manager WASM, développé par les créateurs du component model.

— Tim

L’agence de recrutement pour les leads dévs RoR !

Comme vous le savez, derrière Ruby Biscuit, il y a Capsens 👋 , nous sommes une agence web qui fait du Ruby on Rails depuis 10 ans.

Avec le temps on s'est rendu compte que beaucoup de dévs choisissent leur entreprise un peu par hasard alors qu'ils pourraient davantage s'épanouir et se valoriser dans des structures qui leur correspondent mieux. De plus on sait à quel point les process de recrutement peuvent ne pas être adaptés à notre métier et nos profils.

Ce qui tombe super bien c'est que chez Capsens nous avons une excellente connaissance de l'écosystème RoR en France, avec un réseau d'entreprises considérable. La plupart étant des boites bien installées (+ de 5 ans), avec des équipes tech déjà présentes et qui recherchent avant tout des leads dévs et dévs séniors.

C'est pourquoi nous avons décidé de mettre à profit nos ressources pour vous aider à trouver le poste de vos rêves !

Alors tu as plusieurs années d’expériences ? Tu souhaites trouver le prochain poste de lead dév de tes rêves ?

Concrètement voilà ce qui va se passer :

Réponds à cette newsletter en te présentant en deux lignes !
Je t’envoie aussitôt notre test technique pour évaluer ta séniorité
Je te propose des créneaux pour un appel afin de faire ta connaissance et que tu me dises ce que tu cherches pour t’épanouir dans une entreprise.
Je te propose 3 entreprises qui correspondent à ton profil et tes aspirations. Pour chacune de ces entreprises :
1. Je me charge de te donner un max d’infos et répondre à toutes tes questions par message (horaires, ambiance, taille et séniorité de l’équipe, responsabilités, marge de manœuvre pour la négociation du salaire, localisation des bureaux, politique de télétravail, etc). Pas d’appels inutiles.
2. Avant de rencontrer le recruteur lui-même, je te mets en relation avec un développeur de leur équipe. Tu pourras alors te faire une idée de comment ça se passe de l’intérieur.
3. Enfin, le recruteur te recevra ! Il aura déjà eu toutes les informations que je lui aurai transmises sur toi ce qui vous permettra d’aller à l’essentiel !

Lance-toi, on attend ton e-mail ! Et si tu aimes déjà ton travail, ne nous contacte surtout pas ! Ou alors fais-le pour nous recommander ta boîte 😉

Mélanie