L'aventure web de Ruby : des salles serveurs à votre navigateur

En une phrase

Un playground Ruby exécute du code Ruby instantanément dans votre navigateur web, sans aucune installation, en faisant tourner l'interpréteur Ruby au complet sur une technologie hallucinante appelée WebAssembly.

Le problème que ça résout

Ruby, né au milieu des années 90 grâce à Yukihiro « Matz » Matsumoto, a été conçu avec une philosophie centrale : le bonheur du développeur. Sa syntaxe élégante et lisible par un humain en a fait un plaisir à écrire, et pendant des décennies, son terrain de jeu a été le serveur. Propulsant des géants comme GitHub, Shopify et Airbnb (à ses débuts), Ruby est devenu une superstar du backend, surtout avec le framework Rails.

Mais cette popularité venait avec son lot de contraintes. Pour exécuter une seule ligne de Ruby, il fallait configurer tout un environnement sur votre machine. Ça signifiait :

Installer l'interpréteur Ruby lui-même.
Jongler avec les différentes versions de projets à l'aide d'outils comme RVM ou rbenv (l'expression « enfer des dépendances » ou « dependency hell » vous dit quelque chose ?).
Installer des bibliothèques, appelées « gems », qui pouvaient avoir leurs propres dépendances complexes.

Cette configuration crée une barrière importante. Pour un développeur qui veut juste tester un petit algorithme, un étudiant qui apprend les ficelles du métier, ou un dev frontend curieux des fameuses méthodes de tableau de Ruby, installer un environnement local complet, c'est comme avoir besoin d'une licence de pilote juste pour s'asseoir dans le cockpit.

Un playground Ruby fait disparaître cette friction. Il offre un bac à sable (sandbox) immédiat et sans engagement. C'est le nec plus ultra du « tester avant d'acheter », permettant à n'importe qui, n'importe où, de goûter à la joie de Ruby avec rien de plus qu'un navigateur web. C'est fait pour les tests rapides, les démos partageables et l'apprentissage sans prise de tête logistique.

Comment ça marche sous le capot

Alors, comment fait-on pour fourrer un langage côté serveur, qui s'attend à pouvoir discuter avec un système de fichiers et un système d'exploitation, dans le bac à sable ultra-sécurisé d'un navigateur web ? L'ingrédient secret est une technologie qui révolutionne discrètement le web : WebAssembly.

### Qu'est-ce que le WebAssembly (Wasm) ?

Imaginez WebAssembly (Wasm pour les intimes) comme un nouveau langage pour le web, mais pas un que vous êtes censé écrire à la main. C'est un format d'instructions binaires de bas niveau qui s'exécute dans le navigateur aux côtés de JavaScript. Voyez-le comme un minuscule processeur virtuel hyper-efficace qui vit à l'intérieur de l'onglet de votre navigateur.

Des langages comme le C, le C++ et le Rust peuvent être compilés en Wasm. Au lieu de créer un .exe pour Windows ou un binaire pour Linux, le compilateur crache un fichier .wasm. Le navigateur peut alors charger ce fichier et l'exécuter à une vitesse quasi native, bien plus rapidement que le JavaScript traditionnel. C'est la clé qui permet de faire tourner du code haute performance non-JavaScript sur le web.

  Votre code C/C++/Rust
          |
          v
[ Compilateur Wasm (ex: Emscripten) ]
          |
          v
  votre_programme.wasm  <-- S'exécute dans la VM Wasm du navigateur

### Compiler CRuby en Wasm

C'est là que la magie opère. La version standard et officielle de Ruby s'appelle CRuby parce qu'elle est écrite en langage C. Et comme le C peut être compilé en WebAssembly... vous voyez où je veux en venir.

En utilisant une chaîne d'outils de compilation spéciale (comme Emscripten), les développeurs peuvent prendre l'intégralité du code source de l'interpréteur CRuby et le compiler en un fichier ruby.wasm. Ce fichier, c'est l'interpréteur Ruby, simplement traduit dans un langage que le moteur Wasm du navigateur peut comprendre.

Quand un playground Ruby se charge, il télécharge ce fichier ruby.wasm. Vous avez alors toute la puissance du moteur du langage Ruby dans la mémoire de votre navigateur, prête à l'emploi.

### La colle JavaScript

Le fichier .wasm est puissant, mais il est aussi isolé. Il ne peut pas toucher directement à la page web, afficher du texte à l'écran, ou lire le code que vous avez tapé dans une zone de texte. Il a besoin d'un gestionnaire, et ce gestionnaire, c'est JavaScript.

Une fine couche de code de « colle » (glue code) écrite en JavaScript est responsable de la gestion du module Wasm. Voici le déroulement, action par action :

Chargement : JavaScript récupère le fichier ruby.wasm et initialise le module Wasm. C'est comme allumer la machine virtuelle Ruby.
Entrée : Quand vous tapez du code comme puts "Hello, Matz!", le code de colle JavaScript prend cette chaîne de texte.
Exécution : Le code JS appelle une fonction spécifique qui a été exportée depuis le module Wasm, un truc comme run_ruby_code(), et lui passe votre chaîne de code.
Traitement : À l'intérieur de la machine virtuelle Wasm, l'interpréteur CRuby démarre, analyse votre code et l'exécute. Quand votre code appelle puts, l'interpréteur écrit « Hello, Matz! » sur sa sortie standard (stdout).
Sortie : Le module Wasm est configuré pour rediriger son stdout vers l'environnement JavaScript. Le code de colle JS capture cette sortie.
Affichage : Finalement, le code JavaScript prend la chaîne de caractères capturée et l'affiche dans la zone de sortie sur la page web.

// Une vue simplifiée de la logique de colle JS
import initRuby from './ruby.wasm';

async function runPlayground() {
  // 1. Charger le module Wasm et ses fonctions exportées
  const ruby = await initRuby({
    // 5. Capturer tout ce que le module Wasm essaie d'afficher
    print: (text) => {
      document.getElementById('output').textContent += text + '\n';
    }
  });

  // 2. Récupérer l'entrée utilisateur
  const userInput = '3.times { |i| puts "Loop ##{i + 1}" }';

  // 3 & 4. Exécuter le code Ruby dans la VM Wasm
  ruby.eval(userInput);
}

Tout cela se produit en une fraction de seconde, créant l'illusion que vous exécutez Ruby nativement alors qu'en réalité, vous orchestrez une danse complexe entre JavaScript et un programme C compilé en WebAssembly.

Histoires vécues

### La candidate à l'entretien impatiente

Sara était au dernier tour d'un entretien technique. La consigne : « Écrivez une fonction Ruby pour trouver le caractère le plus fréquent dans une chaîne de caractères. » Son ordinateur portable était un bazar de projets. L'un utilisait Ruby 2.7, un autre Ruby 3.1. Elle redoutait la minute qu'elle passerait à se battre avec rbenv pour changer de version, en priant pour qu'une dépendance ne soit pas cassée. Au lieu de ça, elle a annoncé : « Ça vous dérange si j'utilise un playground web ? » Elle a ouvert un onglet de navigateur, a tapé son élégante solution en utilisant les méthodes group_by et max_by de Ruby, et l'a testée avec trois entrées différentes en moins de deux minutes. Les recruteurs ont été impressionnés non seulement par le code, mais aussi par son efficacité.

La morale : Un playground est un environnement instantané et impeccable. Il élimine le chaos de la configuration locale, vous permettant de vous concentrer uniquement sur le code, ce qui est inestimable sous pression.

### Le dev frontend curieux

Alex, un développeur React, lisait un article de blog qui vantait la « magnifique » syntaxe de Ruby pour la manipulation de données. L'article montrait un exemple de transformation d'un tableau d'objets en une seule ligne. Alex n'avait pas envie de se taper toute la procédure d'installation de Ruby juste pour essayer. Il a ouvert un playground Ruby, a collé le tableau, et a écrit lui-même l'enchaînement de map et select. Il l'a peaufiné, a joué avec, et en cinq minutes, il a « pigé » le truc. Le lendemain, il a utilisé un pattern de chaînage fonctionnel similaire dans son code JavaScript, inspiré par sa brève escapade au pays de Ruby.

La morale : Les playgrounds sont des bacs à sable sans friction pour l'exploration. Ils vous permettent de tremper un orteil dans d'autres écosystèmes de programmation, d'apprendre de nouveaux patterns et de ramener ces idées dans votre langage principal.

### Le rapport de bug qui a vraiment aidé

Un développeur se débattait avec un cas limite étrange dans une gem Ruby open-source. Il a ouvert un rapport de bug disant : « La méthode process échoue quand la chaîne d'entrée contient des emojis. » Le mainteneur n'arrivait pas à le reproduire. La discussion a tourné en rond pendant des jours. Finalement, un autre contributeur est intervenu, a créé un exemple minimal du bug dans un playground Ruby, et a partagé l'URL. Le mainteneur a cliqué sur le lien, a exécuté le code et a vu l'erreur instantanément. Le bug a été corrigé dans l'heure.

La morale : Un playground fournit un « exemple minimal, complet et vérifiable » sur un plateau d'argent. Il rend les rapports de bug incontestables et la collaboration incroyablement efficace.

Erreurs et pièges courants

Penser que c'est un vrai serveur. Vous êtes dans le bac à sable de sécurité d'un navigateur. Vous ne pouvez pas accéder au système de fichiers local (File.open ne fonctionnera pas sur /etc/hosts), ouvrir des connexions réseau arbitraires, ou vous connecter directement à une base de données. L'environnement est fortement restreint pour des raisons de sécurité.
Compter sur les gems externes. Votre playground dispose de la bibliothèque standard de Ruby, mais c'est généralement tout. Vous ne pouvez pas simplement faire require 'rails' ou require 'nokogiri'. L'installation de gems nécessite souvent un système de fichiers et parfois la compilation d'extensions C natives, deux choses qui ne sont pas disponibles dans ce contexte simple et isolé.
Ignorer les limites de performance du navigateur. WebAssembly est rapide, mais ce n'est pas de la magie. Une boucle infinie (loop { puts 'oops' }) ou la factorielle d'un nombre gigantesque gèlera toujours l'onglet du navigateur, car elle s'exécute probablement sur le même thread principal que l'interface utilisateur. Utilisez-le pour des scripts rapides, pas pour du calcul scientifique lourd.
Oublier l'état (state). Chaque fois que vous cliquez sur « Exécuter », vous repartez de zéro. L'interpréteur est réinitialisé, et toutes les variables de l'exécution précédente ont disparu. C'est une fonctionnalité (la reproductibilité !), pas un bug, mais cela peut vous piéger si vous vous attendez à de la persistance.

Pourquoi vous devriez garder ça à l'œil

Vous devriez penser à utiliser un playground Ruby chaque fois que vous avez besoin de faire un « coup rapide » en Ruby.

Prototypage : Tester rapidement une idée d'algorithme ou de transformation de données.
Apprentissage : Expérimenter avec la syntaxe de Ruby ou une fonctionnalité de la bibliothèque standard sans aucune configuration.
Partage : Créer un extrait de code dynamique et exécutable à inclure dans une documentation, un article de blog, une réponse sur Stack Overflow ou un rapport de bug.
Entretiens : L'utiliser comme un terrain neutre et propre pour les défis de code.
Comprendre Wasm : Jouer avec est tout simplement un moyen fantastique d'apprécier la puissance de WebAssembly et l'avenir du développement web, où le navigateur devient un environnement d'exécution universel pour de nombreux langages.

Pour aller plus loin

The Official Ruby Language Website: La source de vérité pour tout ce qui concerne Ruby.
WebAssembly.org: Le site officiel de WebAssembly, avec les spécifications, la documentation et les actualités.
MDN Web Docs: WebAssembly: La référence incontournable pour les développeurs sur le fonctionnement de Wasm dans les navigateurs, par les maîtres de Mozilla.
ruby.wasm GitHub Repository: Le projet officiel pour compiler CRuby en WebAssembly. Découvrez les coulisses de la fabrication.
Ruby on Wikipedia: Un excellent aperçu de l'histoire, de la philosophie et de l'impact du langage.

Comment un éditeur comprend le code

Les couleurs viennent d’un analyseur de langage, pas de l’exécution du programme. CodeMirror et Lezer reconnaissent les symboles et la structure dans le navigateur. Les suggestions combinent mots-clés, noms locaux lorsque disponibles, extraits et une petite référence intégrée ; survoler un symbole documenté révèle sa signature. Une suggestion ne garantit pas que cette API existe dans le moteur. Les diagnostics repèrent la syntaxe incorrecte lorsque l’analyseur le permet, sans remplacer le contrôle des types ni l’exécution : une syntaxe valide peut encore échouer. Ruby et Lua utilisent des modes fondés sur les tokens, aux diagnostics plus limités. Aucun serveur de langage distant : le code reste sur l’appareil.

CodeMirror & Lezer: MIT.