wterm : Le terminal web propulsé par Ghostty de Vercel

BBetter Stack
컴퓨터/소프트웨어AI/미래기술

Transcript

00:00:00Voici Wterm, un émulateur de terminal web par Vercel
00:00:03qui effectue le rendu directement dans le DOM au lieu d'un canvas.
00:00:06Ainsi, la sélection de texte, la recherche dans la page,
00:00:08et les lecteurs d'écran fonctionnent simplement avec.
00:00:10C'est écrit en Zig, compilé en un binaire WASM de 12 kilo-octets,
00:00:14et il existe aussi un backend optionnel alimenté par LibGhosty,
00:00:17le même moteur qui propulse le terminal Ghosty,
00:00:19ce qui vous donne une compatibilité terminal totale dans le navigateur.
00:00:22Mais est-ce qu'un binaire WASM de 12 kilo-octets
00:00:24suffit vraiment à remplacer un émulateur de terminal natif ?
00:00:28Probablement pas, mais abonnez-vous et découvrons-le.
00:00:33Les terminaux web sont partout.
00:00:36Dans les IDE cloud comme GitHub Codespaces,
00:00:39les outils d'infrastructure comme Portainer ou Qualify,
00:00:41et même les IDE de bureau comme VS Code ou Cursor.
00:00:44Mais ils utilisent tous Xterm.js pour le faire
00:00:47parce que c'est là depuis longtemps
00:00:49et c'est essentiellement la norme.
00:00:51Xterm a pourtant un gros problème.
00:00:52Il effectue le rendu dans un élément canvas.
00:00:54Donc pour faire des choses comme sélectionner du texte
00:00:56ou trouver des mots dans une page,
00:00:58tout doit être réimplémenté de zéro,
00:01:00ce qui ne fonctionne pas toujours très bien.
00:01:02Wterm adopte une approche complètement différente
00:01:04en rendant dans le DOM,
00:01:05ce qui signifie que la sortie du terminal est juste du HTML,
00:01:08et le navigateur gère cela pratiquement gratuitement.
00:01:10Mais Wterm peut aussi faire des choses vraiment cool
00:01:13avec ce rendu HTML,
00:01:14comme ne rendre que la ligne qui a été mise à jour,
00:01:17au lieu de rendre tout le terminal à chaque image.
00:01:20Il peut aussi être écrit dans différents frameworks
00:01:22comme React ou Vue.
00:01:23Vous pouvez changer le thème.
00:01:24Et il existe aussi un paquet Wterm Ghosty séparé,
00:01:27qui remplace l'appel Zig par LibGhosty
00:01:29et fonctionne étonnamment mieux
00:01:31que l'autre projet Web Ghosty,
00:01:33dont nous parlerons plus tard dans la vidéo.
00:01:35Mais pour l'instant, essayons Wterm
00:01:37avec un simple projet de démonstration.
00:01:38Donc après avoir installé Wterm avec React,
00:01:40j'ai importé le composant ainsi que le CSS,
00:01:43et je rends le composant ici.
00:01:45Alors maintenant, si je lance l'application et que je vais dans le navigateur,
00:01:48je peux voir qu'il y a un terminal.
00:01:49Mais si je tape une commande comme ls,
00:01:51on voit que rien ne se passe.
00:01:52Et c'est parce qu'il n'est pas connecté
00:01:53à un autre ordinateur pour lire des informations.
00:01:56Laissez-moi expliquer.
00:01:57Donc pour le moment, le client n'est pas connecté à un backend,
00:01:59donc il n'a aucun endroit d'où obtenir des informations.
00:02:01Mais ce que nous devons faire, c'est le connecter à une autre machine.
00:02:04Cela pourrait être ma machine locale
00:02:06ou une machine dans le cloud,
00:02:07et ensuite rendre un faux terminal ou un pseudo-terminal
00:02:10à l'intérieur de cette machine avec les mêmes dimensions
00:02:13que celui du client.
00:02:14Donc, si nous faisons quelques frappes au clavier,
00:02:16ces informations de frappe sont envoyées
00:02:18à l'autre machine,
00:02:20qui exécute ces commandes,
00:02:22rend les résultats,
00:02:23et renvoie toutes ces informations au client.
00:02:25Et ce va-et-vient doit se produire
00:02:26très rapidement avec un délai minimal.
00:02:28Donc le meilleur moyen de connecter le client
00:02:30et l'autre machine ensemble
00:02:31est d'utiliser des WebSockets.
00:02:32Alors allons-y et faisons ça.
00:02:34On peut utiliser un HETS sur le serveur
00:02:35avec Ubuntu que j'ai déjà configuré
00:02:37avec Node installé.
00:02:38Et j'ai aussi déjà un serveur Wterm
00:02:40avec un script serveur.
00:02:42Donc si nous regardons dedans,
00:02:43on peut voir que nous créons un serveur WebSocket
00:02:45sur le chemin slash API terminal.
00:02:48Cela aura plus de sens un peu plus tard.
00:02:49Et ici,
00:02:49nous lançons un pseudo-terminal
00:02:51avec un nom qui correspond à notre type de terminal.
00:02:53Voici comment vous pouvez trouver le vôtre si vous êtes curieux.
00:02:55Et ici,
00:02:56nous recevons toute frappe du client,
00:02:58nous la traitons sur le serveur,
00:02:59donc à l'intérieur de notre faux terminal,
00:03:01puis nous renvoyons cette information
00:03:02au client ici.
00:03:03Donc le serveur renvoie tout,
00:03:05et pas seulement la ligne spécifique qui a été mise à jour.
00:03:07Maintenant, côté client, dans le fichier app.tsx,
00:03:10nous créons une connexion WebSocket
00:03:11à notre serveur sur le port slash API slash terminal.
00:03:14Ensuite, nous utilisons la transformation WebSocket
00:03:16de Wterm pour nous connecter à cette URL
00:03:19avec des reconnexions automatiques.
00:03:21Puis, c'est ce qui envoie les informations de frappe
00:03:23d'ici vers le serveur.
00:03:24Nous gérons le redimensionnement du navigateur ici,
00:03:26et puis en bas,
00:03:27la fonction handle data
00:03:28gère toutes les informations
00:03:30qui viennent du serveur.
00:03:31Et la chose cool avec le cœur ZIG
00:03:33c'est qu'il va analyser cette information,
00:03:35comprendre ce qui a été modifié,
00:03:36et ne rendre que cette partie du HTML.
00:03:39Ici, la taille des colonnes et des lignes
00:03:41doit correspondre à ce que nous avions sur le serveur,
00:03:42et tout le reste est assez explicite.
00:03:45Alors maintenant, avec le client et le serveur en marche,
00:03:47de retour dans le navigateur, si je tape LS,
00:03:49nous pouvons voir qu'il liste les fichiers dont nous disposons.
00:03:52Donc je pourrais taper LS avec l'indicateur L
00:03:53pour voir plus d'informations sur les fichiers.
00:03:55Je peux faire un CD dans un fichier,
00:03:57jeter un œil aux informations à l'intérieur,
00:03:59et aussi faire des choses comme voir la liste
00:04:01des conteneurs que j'ai en cours d'exécution.
00:04:02Je peux même ouvrir un fichier avec Vim
00:04:03et naviguer dedans.
00:04:04Mais même si tout cela fonctionne,
00:04:06ça ne le fait pas incroyablement bien.
00:04:07Je veux dire, si on essaie de surligner du texte,
00:04:09on peut voir que certains caractères
00:04:10sont complètement illisibles.
00:04:12Donc, pour corriger ça,
00:04:13nous pouvons configurer Wterm avec Ghosty
00:04:15en chargeant le cœur Ghosty
00:04:16et en l'ajoutant en tant que prop dans React.
00:04:18Vous pouvez voir maintenant que si nous ouvrons le fichier serveur
00:04:20et surlignons du texte,
00:04:22tout est beaucoup plus lisible.
00:04:23Il peut même faire des choses comme
00:04:24rendre correctement le code ouvert,
00:04:26nous permettant de changer de modèle,
00:04:27et de lui donner une invite avec le support des emojis.
00:04:29Nous pouvons même voir que Ghosty rend les couleurs
00:04:31légèrement mieux
00:04:31qu'avec le moteur de rendu par défaut de Wterm.
00:04:34Mais le cœur Zig ne fait que 12 kilo-octets
00:04:36comparé aux 400 kilo-octets de Ghosty.
00:04:39Donc si la taille vous importe,
00:04:40alors peut-être restez-en au cœur Zig.
00:04:43Quoi qu'il en soit, c'est un aperçu rapide de Wterm par Vercel.
00:04:46Bien sûr, il y a tellement plus de fonctionnalités
00:04:48que je n'ai pas passées en revue,
00:04:49comme la possibilité de convertir du Markdown
00:04:51en une belle sortie de terminal,
00:04:52d'utiliser juste Bash pour naviguer dans des faux fichiers
00:04:55si vous n'avez pas accès à un backend.
00:04:57Et il y a même des exemples
00:04:58de la façon de configurer un client SSH
00:05:00via un terminal dans le navigateur.
00:05:02Mais je n'ai pas trouvé Wterm parfait.
00:05:05Il y avait quelques problèmes de rendu
00:05:06en utilisant la version Ghosty,
00:05:08en faisant des allers-retours entre NeoVim
00:05:10ou même OpenCode.
00:05:11Et pour faire fonctionner le moteur de rendu Ghosty
00:05:13avec mon frontend BUN,
00:05:15j'ai dû importer le fichier WASM
00:05:17parce que BUN ne copiait aucun fichier non-JS
00:05:19du dossier Node modules.
00:05:21Mais j'aime l'approche de rendu dans le DOM,
00:05:23ce qui signifie que vous obtenez l'accessibilité
00:05:25et les fonctionnalités natives du navigateur
00:05:27sans faire de travail supplémentaire,
00:05:29ce qu'Xterm a eu du mal à faire,
00:05:31même s'il existe depuis plus de 10 ans.
00:05:33Mais Xterm.js a un écosystème massif
00:05:35et est la solution éprouvée,
00:05:38donc vous ne vous tromperez pas si vous finissez par le choisir.
00:05:40Il existe aussi GhostyWeb par Coda,
00:05:42qui adopte une approche différente.
00:05:43Il utilise le même moteur LibGhosty
00:05:45utilisé par le terminal Ghosty réel,
00:05:48mais c'est un remplacement direct pour Xterm,
00:05:50donc il utilise toujours l'approche de rendu canvas
00:05:52et utilise la même API,
00:05:54mais vous obtenez un meilleur terminal.

Key Takeaway

Wterm améliore l'accessibilité des terminaux web en utilisant le rendu DOM plutôt que canvas, tout en offrant une option de performance accrue via le moteur LibGhosty.

Highlights

  • Wterm effectue le rendu du terminal directement dans le DOM, contrairement à Xterm.js qui utilise un élément canvas.

  • Le cœur de Wterm est écrit en Zig et compilé en un binaire WASM de 12 kilo-octets.

  • L'intégration optionnelle du moteur LibGhosty améliore le rendu des couleurs et la lisibilité du texte par rapport au moteur par défaut.

  • L'approche basée sur le DOM permet une gestion native par le navigateur de la sélection de texte, de la recherche et des lecteurs d'écran.

  • L'utilisation de WebSockets assure la communication entre le client Wterm et le backend pour l'exécution des commandes.

Timeline

Avantages et fonctionnement de Wterm

  • Wterm remplace le rendu canvas par un rendu DOM pour améliorer l'accessibilité.
  • Le binaire WASM ne pèse que 12 kilo-octets.
  • Le moteur LibGhosty peut être utilisé en option pour une compatibilité terminal totale.

La majorité des terminaux web actuels comme Xterm.js reposent sur un canvas, ce qui complique la sélection de texte et l'intégration des lecteurs d'écran. Wterm propose une alternative rendant la sortie directement en HTML. Cette méthode permet au navigateur de gérer nativement ces fonctions, tout en permettant une mise à jour efficace du DOM.

Configuration client-serveur via WebSockets

  • La connexion nécessite un backend pour l'exécution des commandes via WebSockets.
  • Le serveur doit lancer un pseudo-terminal synchronisé avec les dimensions du client.
  • Le client envoie les frappes clavier et reçoit les résultats traités par le serveur.

Le terminal web nécessite une machine distante pour traiter les commandes. Un serveur Node configuré avec un point de terminaison WebSocket écoute les entrées du client, exécute les commandes dans un pseudo-terminal et renvoie le flux de données. Le client traite ensuite ces informations pour ne mettre à jour que les sections modifiées du DOM.

Comparaison et limites

  • Le rendu par défaut de Wterm présente des défauts de lisibilité lors de la sélection de texte.
  • Le moteur LibGhosty de 400 kilo-octets offre un meilleur rendu que le cœur Zig initial.
  • Xterm.js reste la norme établie grâce à son écosystème massif malgré ses limites en accessibilité.

Bien que l'intégration de Ghosty améliore l'affichage, des problèmes persistent avec certains outils comme NeoVim. Wterm offre une approche moderne axée sur le DOM, mais Xterm.js bénéficie d'une maturité de dix ans. Une autre alternative, GhostyWeb, conserve l'approche canvas pour remplacer directement Xterm tout en utilisant le moteur LibGhosty.

Community Posts

No posts yet. Be the first to write about this video!

Write about this video