I've started using the term HTML tools to refer to HTML applications that I've been building which combine HTML, JavaScript, and CSS in a single file and use them to provide useful functionality. I have built over 150 of these in the past two years, almost all of them written by LLMs. This article presents a collection of useful patterns I've discovered along the way.

First, some examples to show the kind of thing I'm talking about:

• svg-render renders SVG code to downloadable JPEGs or PNGs
• pypi-changelog lets you generate (and copy to clipboard) diffs between different PyPI package releases.
• bluesky-thread provides a nested view of a discussion thread on Bluesky.

These are some of my recent favorites. I have dozens more like this that I use on a regular basis.

You can explore my collection on tools.simonwillison.net - the by month view is useful for browsing the entire collection.

If you want to see the code and prompts, almost all of the examples in this post include a link in their footer to "view source" on GitHub. The GitHub commits usually contain either the prompt itself or a link to the transcript used to create the tool.

• The anatomy of an HTML tool
• Prototype with Artifacts or Canvas
• Switch to a coding agent for more complex projects
• Load dependencies from CDNs
• Host them somewhere else
• Take advantage of copy and paste
• Build debugging tools
• Persist state in the URL
• Use localStorage for secrets or larger state
• Collect CORS-enabled APIs
• LLMs can be called directly via CORS
• Don't be afraid of opening files
• You can offer downloadable files too
• Pyodide can run Python code in the browser
• WebAssembly opens more possibilities
• Remix your previous tools
• Record the prompt and transcript
• Go forth and build

The anatomy of an HTML tool

These are the characteristics I have found to be most productive in building tools of this nature:

1. A single file: inline JavaScript and CSS in a single HTML file means the least hassle in hosting or distributing them, and crucially means you can copy and paste them out of an LLM response.
2. Avoid React, or anything with a build step. The problem with React is that JSX requires a build step, which makes everything massively less convenient. I prompt "no react" and skip that whole rabbit hole entirely.
3. Load dependencies from a CDN. The fewer dependencies the better, but if there's a well known library that helps solve a problem I'm happy to load it from CDNjs or jsdelivr or similar.
4. Keep them small. A few hundred lines means the maintainability of the code doesn't matter too much: any good LLM can read them and understand what they're doing, and rewriting them from scratch with help from an LLM takes just a few minutes.

The end result is a few hundred lines of code that can be cleanly copied and pasted into a GitHub repository.

Prototype with Artifacts or Canvas

The easiest way to build one of these tools is to start in ChatGPT or Claude or Gemini. All three have features where they can write a simple HTML+JavaScript application and show it to you directly.

Claude calls this "Artifacts", ChatGPT and Gemini both call it "Canvas". Claude has the feature enabled by default, ChatGPT and Gemini may require you to toggle it on in their "tools" menus.

Try this prompt in Gemini or ChatGPT:

Build a canvas that lets me paste in JSON and converts it to YAML. No React.

Or this prompt in Claude:

Build an artifact that lets me paste in JSON and converts it to YAML. No React.

I always add "No React" to these prompts, because otherwise they tend to build with React, resulting in a file that is harder to copy and paste out of the LLM and use elsewhere. I find that attempts which use React take longer to display (since they need to run a build step) and are more likely to contain crashing bugs for some reason, especially in ChatGPT.

All three tools have "share" links that provide a URL to the finished application. Examples:

• ChatGPT JSON to YAML Canvas made with GPT-5.1 Thinking - here's the full ChatGPT transcript
• Claude JSON to YAML Artifact made with Claude Opus 4.5 - here's the full Claude transcript
• Gemini JSON to YAML Canvas made with Gemini 3 Pro - here's the full Gemini transcript

Switch to a coding agent for more complex projects

Coding agents such as Claude Code and Codex CLI have the advantage that they can test the code themselves while they work on it using tools like Playwright. I often upgrade to one of those when I'm working on something more complicated, like my Bluesky thread viewer tool shown above.

I also frequently use asynchronous coding agents like Claude Code for web to make changes to existing tools. I shared a video about that in Building a tool to copy-paste share terminal sessions using Claude Code for web.

Claude Code for web and Codex Cloud run directly against my simonw/tools repo, which means they can publish or upgrade tools via Pull Requests (here are dozens of examples) without me needing to copy and paste anything myself.

Load dependencies from CDNs

Any time I use an additional JavaScript library as part of my tool I like to load it from a CDN.

The three major LLM platforms support specific CDNs as part of their Artifacts or Canvas features, so often if you tell them "Use PDF.js" or similar they'll be able to compose a URL to a CDN that's on their allow-list.

Sometimes you'll need to go and look up the URL on cdnjs or jsDelivr and paste it into the chat.

CDNs like these have been around for long enough that I've grown to trust them, especially for URLs that include the package version.

The alternative to CDNs is to use npm and have a build step for your projects. I find this reduces my productivity at hacking on individual tools and makes it harder to self-host them.

Host them somewhere else

I don't like leaving my HTML tools hosted by the LLM platforms themselves for a couple of reasons. First, LLM platforms tend to run the tools inside a tight sandbox with a lot of restrictions. They're often unable to load data or images from external URLs, and sometimes even features like linking out to other sites are disabled.

The end-user experience often isn't great either. They show warning messages to new users, often take additional time to load and delight in showing promotions for the platform that was used to create the tool.

They're also not as reliable as other forms of static hosting. If ChatGPT or Claude are having an outage I'd like to still be able to access the tools I've created in the past.

Being able to easily self-host is the main reason I like insisting on "no React" and using CDNs for dependencies - the absence of a build step makes hosting tools elsewhere a simple case of copying and pasting them out to some other provider.

My preferred provider here is GitHub Pages because I can paste a block of HTML into a file on github.com and have it hosted on a permanent URL a few seconds later. Most of my tools end up in my simonw/tools repository which is configured to serve static files at tools.simonwillison.net.

Take advantage of copy and paste

One of the most useful input/output mechanisms for HTML tools comes in the form of copy and paste.

I frequently build tools that accept pasted content, transform it in some way and let the user copy it back to their clipboard to paste somewhere else.

Copy and paste on mobile phones is fiddly, so I frequently include "Copy to clipboard" buttons that populate the clipboard with a single touch.

Most operating system clipboards can carry multiple formats of the same copied data. That's why you can paste content from a word processor in a way that preserves formatting, but if you paste the same thing into a text editor you'll get the content with formatting stripped.

These rich copy operations are available in JavaScript paste events as well, which opens up all sorts of opportunities for HTML tools.

• hacker-news-thread-export lets you paste in a URL to a Hacker News thread and gives you a copyable condensed version of the entire thread, suitable for pasting into an LLM to get a useful summary.
• paste-rich-text lets you copy from a page and paste to get the HTML - particularly useful on mobile where view-source isn't available.
• alt-text-extractor lets you paste in images and then copy out their alt text.

Build debugging tools

The key to building interesting HTML tools is understanding what's possible. Building custom debugging tools is a great way to explore these options.

clipboard-viewer is one of my most useful. You can paste anything into it (text, rich text, images, files) and it will loop through and show you every type of paste data that's available on the clipboard.

This was key to building many of my other tools, because it showed me the invisible data that I could use to bootstrap other interesting pieces of functionality.

More debugging examples:

• keyboard-debug shows the keys (and KeyCode values) currently being held down.
• cors-fetch reveals if a URL can be accessed via CORS.
• exif displays EXIF data for a selected photo.

Persist state in the URL

HTML tools may not have access to server-side databases for storage but it turns out you can store a lot of state directly in the URL.

I like this for tools I may want to bookmark or share with other people.

• icon-editor is a custom 24x24 icon editor I built to help hack on icons for the GitHub Universe badge. It persists your in-progress icon design in the URL so you can easily bookmark and share it.

Use localStorage for secrets or larger state

The localStorage browser API lets HTML tools store data persistently on the user's device, without exposing that data to the server.

I use this for larger pieces of state that don't fit comfortably in a URL, or for secrets like API keys which I really don't want anywhere near my server - even static hosts might have server logs that are outside of my influence.

• word-counter is a simple tool I built to help me write to specific word counts, for things like conference abstract submissions. It uses localStorage to save as you type, so your work isn't lost if you accidentally close the tab.
• render-markdown uses the same trick - I sometimes use this one to craft blog posts and I don't want to lose them.
• haiku is one of a number of LLM demos I've built that request an API key from the user (via the prompt() function) and then store that in localStorage. This one uses Claude Haiku to write haikus about what it can see through the user's webcam.

Collect CORS-enabled APIs

CORS stands for Cross-origin resource sharing. It's a relatively low-level detail which controls if JavaScript running on one site is able to fetch data from APIs hosted on other domains.

APIs that provide open CORS headers are a goldmine for HTML tools. It's worth building a collection of these over time.

Here are some I like:

• iNaturalist for fetching sightings of animals, including URLs to photos
• PyPI for fetching details of Python packages
• GitHub because anything in a public repository in GitHub has a CORS-enabled anonymous API for fetching that content from the raw.githubusercontent.com domain, which is behind a caching CDN so you don't need to worry too much about rate limits or feel guilty about adding load to their infrastructure.
• Bluesky for all sorts of operations
• Mastodon has generous CORS policies too, as used by applications like phanpy.social

GitHub Gists are a personal favorite here, because they let you build apps that can persist state to a permanent Gist through making a cross-origin API call.

• species-observation-map uses iNaturalist to show a map of recent sightings of a particular species.
• zip-wheel-explorer fetches a .whl file for a Python package from PyPI, unzips it (in browser memory) and lets you navigate the files.
• github-issue-to-markdown fetches issue details and comments from the GitHub API (including expanding any permanent code links) and turns them into copyable Markdown.
• terminal-to-html can optionally save the user's converted terminal session to a Gist.
• bluesky-quote-finder displays quotes of a specified Bluesky post, which can then be sorted by likes or by time.

LLMs can be called directly via CORS

All three of OpenAI, Anthropic and Gemini offer JSON APIs that can be accessed via CORS directly from HTML tools.

Unfortunately you still need an API key, and if you bake that key into your visible HTML anyone can steal it and use to rack up charges on your account.

I use the localStorage secrets pattern to store API keys for these services. This sucks from a user experience perspective - telling users to go and create an API key and paste it into a tool is a lot of friction - but it does work.

Some examples:

• haiku uses the Claude API to write a haiku about an image from the user's webcam.
• openai-audio-output generates audio speech using OpenAI's GPT-4o audio API.
• gemini-bbox demonstrates Gemini 2.5's ability to return complex shaped image masks for objects in images, see Image segmentation using Gemini 2.5.

Don't be afraid of opening files

You don't need to upload a file to a server in order to make use of the <input type="file"> element. JavaScript can access the content of that file directly, which opens up a wealth of opportunities for useful functionality.

Some examples:

• ocr is the first tool I built for my collection, described in Running OCR against PDFs and images directly in your browser. It uses PDF.js and Tesseract.js to allow users to open a PDF in their browser which it then converts to an image-per-page and runs through OCR.
• social-media-cropper lets you open (or paste in) an existing image and then crop it to common dimensions needed for different social media platforms - 2:1 for Twitter and LinkedIn, 1.4:1 for Substack etc.
• ffmpeg-crop lets you open and preview a video file in your browser, drag a crop box within it and then copy out the ffmpeg command needed to produce a cropped copy on your own machine.

You can offer downloadable files too

An HTML tool can generate a file for download without needing help from a server.

The JavaScript library ecosystem has a huge range of packages for generating files in all kinds of useful formats.

• svg-render lets the user download the PNG or JPEG rendered from an SVG.
• social-media-cropper does the same for cropped images.
• open-sauce-2025 is my alternative schedule for a conference that includes a downloadable ICS file for adding the schedule to your calendar. See Vibe scraping and vibe coding a schedule app for Open Sauce 2025 entirely on my phone for more on that project.

Pyodide can run Python code in the browser

Pyodide is a distribution of Python that's compiled to WebAssembly and designed to run directly in browsers. It's an engineering marvel and one of the most underrated corners of the Python world.

It also cleanly loads from a CDN, which means there's no reason not to use it in HTML tools!

Even better, the Pyodide project includes micropip - a mechanism that can load extra pure-Python packages from PyPI via CORS.

• pyodide-bar-chart demonstrates running Pyodide, Pandas and matplotlib to render a bar chart directly in the browser.
• numpy-pyodide-lab is an experimental interactive tutorial for Numpy.
• apsw-query demonstrates the APSW SQLite library running in a browser, using it to show EXPLAIN QUERY plans for SQLite queries.

WebAssembly opens more possibilities

Pyodide is possible thanks to WebAssembly. WebAssembly means that a vast collection of software originally written in other languages can now be loaded in HTML tools as well.

Squoosh.app was the first example I saw that convinced me of the power of this pattern - it makes several best-in-class image compression libraries available directly in the browser.

I've used WebAssembly for a few of my own tools:

• ocr uses the pre-existing Tesseract.js WebAssembly port of the Tesseract OCR engine.
• sloccount is a port of David Wheeler's Perl and C SLOCCount utility to the browser, using a big ball of WebAssembly duct tape. More details here.
• micropython is my experiment using @micropython/micropython-webassembly-pyscript from NPM to run Python code with a smaller initial download than Pyodide.

Remix your previous tools

The biggest advantage of having a single public collection of 100+ tools is that it's easy for my LLM assistants to recombine them in interesting ways.

Sometimes I'll copy and paste a previous tool into the context, but when I'm working with a coding agent I can reference them by name - or tell the agent to search for relevant examples before it starts work.

The source code of any working tool doubles as clear documentation of how something can be done, including patterns for using editing libraries. An LLM with one or two existing tools in their context is much more likely to produce working code.

I built pypi-changelog by telling Claude Code:

Look at the pypi package explorer tool

And then, after it had found and read the source code for zip-wheel-explorer:

Build a new tool pypi-changelog.html which uses the PyPI API to get the wheel URLs of all available versions of a package, then it displays them in a list where each pair has a "Show changes" clickable in between them - clicking on that fetches the full contents of the wheels and displays a nicely rendered diff representing the difference between the two, as close to a standard diff format as you can get with JS libraries from CDNs, and when that is displayed there is a "Copy" button which copies that diff to the clipboard

Here's the full transcript.

See Running OCR against PDFs and images directly in your browser for another detailed example of remixing tools to create something new.

Record the prompt and transcript

I like keeping (and publishing) records of everything I do with LLMs, to help me grow my skills at using them over time.

For HTML tools I built by chatting with an LLM platform directly I use the "share" feature for those platforms.

For Claude Code or Codex CLI or other coding agents I copy and paste the full transcript from the terminal into my terminal-to-html tool and share that using a Gist.

In either case I include links to those transcripts in the commit message when I save the finished tool to my repository. You can see those in my tools.simonwillison.net colophon.

Go forth and build

I've had so much fun exploring the capabilities of LLMs in this way over the past year and a half, and building tools in this way has been invaluable in helping me understand both the potential for building tools with HTML and the capabilities of the LLMs that I'm building them with.

If you're interested in starting your own collection I highly recommend it! All you need to get started is a free GitHub repository with GitHub Pages enabled (Settings -> Pages -> Source -> Deploy from a branch -> main) and you can start copying in .html pages generated in whatever manner you like.

Bonus transcript: Here's how I used Claude Code and shot-scraper to add the screenshots to this post.

Tags: definitions, github, html, javascript, projects, tools, ai, webassembly, generative-ai, llms, ai-assisted-programming, vibe-coding, coding-agents, claude-code

J’espère que vous êtes bien installés dans votre cockpit, parce que GitHub nous a reservé une sacrée surprise : Copilot Workspace, un environnement de développement nouvelle génération entièrement propulsé par l’IA.

Vous connaissez sûrement déjà GitHub Copilot, ce fidèle acolyte qui nous assiste depuis l’année dernière en nous soufflant des suggestions de code directement dans votre IDE, et bien avec Copilot Workspace, GitHub veut carrément révolutionner la façon de concevoir des logiciels.

L’idée est simple : vous exprimez ce que vous voulez faire en langage naturel, comme si vous discutiez avec votre pote développeur et Copilot Workspace vous aide à transformer votre concept en réalité, étape par étape.

Par exemple, si vous avez une idée de fonctionnalité à ajouter à votre projet, vous ouvrez Copilot Workspace, vous saisissez une description de ce que vous voulez faire, et hop ! L’IA analyse votre requête, génère un plan d’action détaillé, et vous guide tout au long du processus de développement.

Brainstorming, planification, implémentation, tests… Chaque phase est assistée par Copilot Workspace qui vous fera des suggestions, répondra à vos questions, et automatisera un maximum de tâches fastidieuses, le tout de manière transparente et collaborative.

Le top du top, c’est que tout est « steerable » comme ils disent chez GitHub. Cela veut dire que vous gardez le contrôle à tout moment et chaque suggestion de l’IA peut être affinée, modifiée ou rejetée selon vos désirs. Bref, vous restez le pilote et Copilot n’est que votre copilote (et gardez votre culotte) !

D’ailleurs, Copilot Workspace vous permet d’orienter le système via le langage naturel à 2 endroits : en modifiant la spécification (une description de la base de code actuelle et de l’état souhaité) et en modifiant le plan (une liste d’actions à entreprendre dans chaque fichier). Cela vous permet de guider le système vers la solution que vous souhaitez mettre en œuvre. Cette capacité de pilotage est essentielle, car elle permet aux développeurs de dépasser les limites de la taille des suggestions, en imitant la façon dont ils travaillent sur des problèmes réels. Cela se traduit par un code généré plus précis et plus facile à évaluer.

Une fois votre code écrit, vous pouvez le valider et l’exécuter directement dans l’environnement, histoire de vérifier que tout roule comme sur des roulettes. Chaque Copilot Workspace permet une synchronisation en direct avec les Codespaces, ce qui vous permet d’ouvrir un terminal, d’installer des dépendances et d’exécuter votre code directement depuis l’espace de travail. Et si vous avez besoin d’outils plus avancés, hop, vous basculez dans un Codespace pour retrouver une expérience d’IDE complète dans le cloud, avec un serveur exécutant VS Code.

Côté collaboration, vous pouvez partager un instantané de votre Workspace avec vos petits camarades en un clic, pour recueillir leur feedback ou les laisser expérimenter leurs propres idées. S’ils font partie de la preview technique, ils pourront même forker votre Workspace et itérer dessus. Par contre, si vous apportez des modifications à votre Workspace après l’avoir partagé, ces changements ne seront pas reflétés dans la version partagée. Il faudra alors partager un nouveau lien pour transmettre la dernière mouture.

Et le plus chouette, c’est que Copilot Workspace est accessible de partout, même depuis votre smartphone. Comme ça, la prochaine fois que vous avez une illumination en faisant vos courses, vous pourrez directement la prototyper depuis le rayon fromages du supermarché !

Avec cette annonce, GitHub affiche clairement son ambition : démocratiser le développement logiciel en le rendant plus intuitif, plus naturel, plus humain en somme. Leur vision à long terme c’est un monde où tout le monde peut coder aussi simplement qu’on fait du vélo et je dois dire que je suis plutôt emballé par cette perspective puisque je fonctionne déjà comme ça pour mes projets de dev grâce notamment à Cursor.

Sous le capot, Copilot Workspace est propulsé par le modèle GPT-4 Turbo, que les équipes de GitHub ont jugé le plus performant pour cette tâche après avoir testé de nombreuses alternatives. D’ailleurs, c’est intéressant de comparer Copilot Workspace avec les autres fonctionnalités de la gamme Copilot.

Là où Copilot vous aide à écrire du code en faisant des suggestions au fur et à mesure que vous tapez, et où Copilot Chat permet de discuter des changements potentiels, Copilot Workspace est un véritable environnement de développement orienté tâches, qui planifie et rédige des modifications coordonnées sur plusieurs fichiers. Chacun de ces outils a son utilité, et ils se complètent à merveille.

GitHub a surtout compris l’importance d’impliquer les développeurs dans cette aventure. C’est pour ça qu’ils lancent Copilot Workspace en technical preview, histoire de recueillir un maximum de feedback et d’itérer en fonction. Si ça vous tente de jouer les beta-testeurs, c’est par ici pour vous inscrire !

Source

Si vous vous intéressez un peu aux outils IA, vous connaissez sûrement Claude, l’assistant IA dernière génération d’Anthropic. Depuis la sortie de sa version 3, c’est d’ailleurs devenu mon meilleur pote pour coder à la vitesse de l’éclair. j’ai même pris un abonnement payant en rusant un peu.

Toutefois, le seul truc qui me ralentissait dans mes grandes ambitions, c’était de devoir copier-coller à la main tous mes fichiers de code dans la fenêtre de contexte de Claude pour ensuite lui demander d’analyser ça, et me proposer des corrections ou une nouvelle fonction. Mais ça, c’était avant car je suis tombé sur un petit bijou opensource qui va vous changer la vie : AiFormat.

Ce petit outil en ligne de commande vous permet de sélectionner des fichiers et dossiers, et de les convertir automatiquement dans un format optimisé pour Claude. En deux clics, tout est dans le presse-papier, prêt à être envoyé à votre IA préférée.

Sous le capot, AiFormat utilise Ink, une chouette librairie pour créer des CLI avec une belle interface utilisateur. Ça vous permet de filtrer et naviguer dans vos fichiers, de les sélectionner avec les flèches, et tout ça de façon super intuitive.

Pour l’installer et le prendre en main, c’est hyper simple, tout est expliqué sur la page Github du projet. Ça commence par un simple :

npm install --global aiformat

Ensuite, pour utiliser aiformat, accédez au répertoire contenant les fichiers et dossiers que vous souhaitez partager avec Claude puis lancez la commande suivante :

aiformat

Le créateur a eu la bonne idée de mettre le projet en opensource (MIT license), du coup n’hésitez pas à y jeter un œil et même contribuer si le cœur vous en dit. La communauté vous dira merci !

Franchement, si vous utilisez souvent Claude pour coder ou analyser des projets, c’est un indispensable à avoir dans sa boîte à outils. Ça vous fera gagner un temps fou au quotidien.

Envie d’un terminal nouvelle génération qui allie performance et flexibilité ? Ne cherchez plus, Alacritty est fait pour votre bonheur !

Disponible sur toutes les plateformes qui comptent (Linux, macOS, Windows, BSD ^^), ce terminal au look sobre et épuré cache sous son capot une configuration ultra complète. Pas besoin de réinventer la roue, Alacritty s’intègre avec vos applications préférées pour vous offrir une expérience sur-mesure sans compromis sur la vitesse. Bon OK, c’est encore un peu jeune, il est un peu long à configurer et il reste quelques fonctionnalités à ajouter et bugs à corriger, mais ça n’empêche pas de nombreux baroudeurs du shell de l’utiliser quotidiennement. YOLO comme on dit.

Mais Alacritty, c’est pas qu’un simple émulateur de terminal de base. Il embarque des features bien pratiques pour améliorer la vie des accros de la ligne de commande :

• Vous aimez vim ? Ça tombe bien, avec le mode Vi vous pouvez retrouver vos réflexes pour vous déplacer et sélectionner du texte.
• Vous avez la flemme de scroller manuellement pour retrouver une commande ou une erreur ? Utilisez la recherche intégrée pour localiser ce que vous voulez en un clin d’œil.
• Vous en avez marre de jongler entre votre souris et votre clavier ? Avec les hints façon regex, plus besoin de quitter le clavier, interagissez avec n’importe quel texte à l’écran.
• Votre PC rame quand vous ouvrez 10 terminaux en même temps ? Pas de problème, avec le mode multi-fenêtres , un seul process Alacritty est partagé intelligemment.

Et je vous ai parlé que de quelques fonctionnalités, y’en a bien d’autres à découvrir dans la doc.

Après la théorie, passons à la pratique. Pour l’installer, c’est ultra simple. Si vous êtes sur macOS ou Windows, direction la page des releases GitHub pour chopper le binaire. Sous Linux ou BSD, il est sûrement déjà dans le gestionnaire de paquets de votre distrib. Sinon, les instructions détaillées vous expliqueront comment compiler depuis les sources.

Une fois installé, pas besoin de vous embêter à configurer, les options par défaut sont déjà pas mal. Mais si vous voulez quand même mettre votre patte, le fichier de config en TOML se trouve, en fonction de votre OS, dans $XDG_CONFIG_HOME/alacritty, $HOME/.config/alacritty ou %APPDATA%\alacritty.

Par exemple, pour l’installer sous macOS, vous pouvez faire également :

brew install --cask alacritty

Puis créer un fichier de config comme ceci :

mkdir -p ~/.config/alacritty && touch ~/.config/alacritty/alacritty.toml

Voici un exemple de config à mettre dedans pour obtenir un truc comme ça :

# Configuration du shell et des variables d'environnement
shell = { program = "/bin/zsh", args = ["-l"] }

[env]
TERM = "xterm-256color"

# Activation du rechargement dynamique de la configuration
#live_config_reload = true

# Configuration de la fenêtre pour un look minimaliste et semi-transparent
[window]
decorations = "buttonless"
dynamic_padding = false
opacity = 0.9
padding = { x = 25, y = 20 }

# Configuration de la police personnalisée avec styles spécifiques pour différents états du texte
[font]
size = 20.0
[font.normal]
family = "JetBrains Mono"
style = "Medium"
[font.bold]
family = "JetBrains Mono"
style = "Heavy"
[font.italic]
family = "JetBrains Mono"
style = "Medium Italic"
[font.bold_italic]
family = "JetBrains Mono"
style = "Heavy Italic"

# Configuration des couleurs
[colors]
[colors.primary]
background = '#282a36' # Arrière-plan foncé
foreground = '#f8f8f2' # Texte clair
[colors.cursor]
text = 'CellBackground'
cursor = '#ff79c6' # Couleur du curseur
[colors.selection]
text = 'CellBackground'
background = '#44475a'

# Configuration du curseur
[cursor]
style = { shape = "Block", blinking = "On" }
thickness = 0.25

# Ajout de raccourcis clavier pour améliorer l'efficacité
[keyboard]
bindings = [
  { key = 'N', mods = 'Control|Shift', action = 'CreateNewWindow' },
  { key = 'C', mods = 'Control|Shift', action = 'Copy' },
  { key = 'V', mods = 'Control|Shift', action = 'Paste' },
  { key = '+', mods = 'Control', action = 'IncreaseFontSize' },
  { key = '-', mods = 'Control', action = 'DecreaseFontSize' },
  { key = '0', mods = 'Control', action = 'ResetFontSize' }
]

Mais du coup, c’est vraiment le terminal le plus rapide ?

Difficile à dire… Mesurer les perfs d’un terminal, c’est compliqué. Sur les benchmarks, en tout cas, Alacritty s’en sort bien, surtout grâce à l’accélération GPU. Après, sur des critères plus subjectifs comme la latence ou la fluidité de l’affichage, difficile de départager les challengers. Le mieux est de l’essayer et de voir s’il convient à VOS usages.

Par contre, ne vous attendez pas à retrouver toutes les fonctionnalités de terminaux plus anciens. Pas de tabs, pas de splits, Alacritty se concentre sur son cœur de métier. Pour ces features, votre gestionnaire de fenêtres ou un multiplexeur comme tmux feront très bien l’affaire. Et si vous voulez faire un peu de customisation, il faudra vous plonger dans la doc.

Après, si jamais il vous manque un truc indispensable, le projet est ouvert aux contributions. Alacritty est d’ailleurs distribué sous licence Apache 2.0. Donc si vous vous sentez de rajouter ce p’tit truc manquant, la communauté vous accueillera à bras ouverts. Comme quoi, y’a pas que Microsoft qui sait faire dans l’open source ! mdr.

En attendant de voir vos pull requests pleuvoir sur ce projet, je ne peux que vous conseiller de tester Alacritty. Vous verrez, c’est le genre d’outil auquel on s’habitue vite et qui change la vie. Bon OK, ça reste un terminal, faut pas exagérer non plus. N’empêche que depuis que j’ai goûté à la fluidité de son rendu, j’avoue que j’aurais du mal à revenir en arrière !

Merci à Lorenper