Voir rikiki
rikiki.tordu-jardin.fr · slides en Web Components, zéro build
Le talk que je vais (très bientôt) préparer
On me demande un talk technique, un peu plus d’une heure. La veille de m’y mettre, j’ouvre mes options pour les slides, et elles me hérissent toutes.
Les bibliothèques en JS sont poussives : lentes à charger, lourdes à trimballer, pénibles à partager. Pour montrer trois slides à quelqu’un, il me faut un serveur, une build, un node_modules à ressusciter. Et dans cinq ans, plus rien ne s’ouvre. Quant aux outils clés en main, ils crachent des présentations qui sentent le cours magistral, exactement ce qu’on me reproche déjà.
La conclusion raisonnable, c’était de faire mes slides.
La conclusion que j’ai retenue, c’était d’écrire mon propre framework de slides.
Le 19 mai, premier commit. Le talk, lui, pouvait attendre.
Le cahier des charges
Je me suis donné trois règles, et je m’y suis tenu.
Léger. Le framework entier pèse une poignée de kilo-octets, gzip compris. Pas un mégaoctet de runtime avant la première slide.
Embarquable. Une slide est un Web Component. Du HTML nu, des éléments custom, rien d’autre. Vous copiez un fichier, vous l’ouvrez dans un navigateur, vous parlez.
cp starter.html mon-talk.htmlLisible par une machine. Comme je rédige de plus en plus mes decks avec un agent, la doc est pensée pour être avalée par un LLM, et une skill Claude (rikiki-deck) sait composer un deck valide sans inventer de balises.
La preuve, ici même
Le plus simple, c’est de vous le mettre sous le nez. Le cadre ci-dessous fait défiler un vrai deck rikiki, le bundle publié sur npm, monté dans la page que vous lisez. Pas une capture, pas une vidéo : ça tourne tout seul. Survolez, et vous reprenez la main (flèches pour naviguer, O pour la vue d’ensemble).
« Embarquable » n’est plus un argument de vente. C’est sous vos yeux, en train de défiler.
(Petit aveu en passant : cette page sert le bundle depuis le jardin, pas depuis un CDN tiers. J’y reviens plus bas, parce que c’est tout sauf un détail.)
Trois jours de frénésie
Une fois le premier jet debout, je n’ai plus lâché.
Jour deux, je réécris chaque composant en TypeScript propre, je passe au crible la build, je benchmarke rollup et terser contre esbuild pour finir par garder esbuild (les autres rendaient un bundle plus gros), je découpe la vue d’ensemble et l’aide en modules chargés à la demande pour gratter douze pour cent du poids initial.
Je passe donc une nuit à raboter des kilo-octets sur un projet dont le nom veut dire « tout petit ». La cohérence, au moins.
Jour trois, je le déploie. Landing Astro, status, et rikiki.tordu-jardin.fr en ligne, avec les empoignades de rigueur (un healthcheck qui se vexe parce qu’Alpine résout localhost en IPv6 avant IPv4, l’éternelle joie).
Le jouet qui se prenait pour une usine
Vous vous souvenez de Granit Golem, ce projet « rikiki » censé rester minuscule, qui a viré en plateforme industrielle ? Rikiki, le vrai, a attrapé la même maladie. En accéléré.
À peine déployé, je lui empile une CI de grande personne : scan de vulnérabilités, SBOM, métriques DORA, commits signés, procédure de rollback. Pour un outil à slides. Trois lots d’industrialisation d’affilée, avant de me regarder faire et de tout dégonfler d’un commit lapidaire : « ne garder que ce qui mérite sa place ».
J’ai un faible pour les projets minuscules. Je n’arrive juste pas à les laisser le rester.
Ce que ça sait faire
Des layouts, pas une page blanche
Le socle, ce sont des layouts prêts à l’emploi : une couverture, un séparateur de chapitre, un bloc focal, des colonnes, une punchline. Par-dessus, deck-md pour le markdown, deck-code pour un extrait coloré, deck-mermaid pour un schéma.
Un thème = un fichier de tokens
Côté thème, tout passe par des tokens CSS. Pour repeindre un deck de fond en comble, je copie un fichier de variables, je change les valeurs, et chaque composant suit, jusqu’aux callouts.
La 0.2.0, pour les vrais talks
La dernière version, la 0.2.0, a ajouté la couche qui manquait aux vrais talks. Les révélations progressives, un élément qui apparaît après l’autre (le plugin click-stages, à l’œuvre dans le deck plus haut). Le multi-deck, pour assembler une présentation depuis des fichiers séparés et l’exporter en un seul. Un livereload pour éditer une slide et la voir se rafraîchir en direct. Et un mode présentateur, avec les notes sur un second écran.
Et la boucle se referme joliment : la landing de rikiki présente rikiki en se servant de rikiki, et mes decks, je les dicte désormais à un agent à qui j’ai laissé la notice.
Les cailloux du terreau
Rien de tout ça n’est tombé droit du premier coup.
Le nom déjà pris
rikiki était déjà pris sur npm, alors le paquet s’appelle rikiki-deck. Un comble, pour un projet qui tient à rester discret.
La CSP, ou pourquoi cette page s’auto-héberge
Le dist/ qui refuse mon rangement
J’avais classé mes sources en jolis sous-dossiers. Les imports dynamiques de deck-root ont refusé de suivre, et j’ai dû tout aplatir dans un dist/ à plat. Les imports dynamiques imposent leur structure, pas la mienne.
Le présentateur fantôme
Le mode présentateur s’ouvrait sur une fenêtre vide : le moteur se redéfinissait deux fois et se marchait dessus. Je l’ai recâblé pour qu’il calcule l’URL du bundle localement et recopie les slides proprement, sans se cloner.
Le livereload qui faisait « plop »
Au début, il rechargeait toute la page à chaque frappe : un « plop » désagréable, l’écran qui clignote, la slide perdue. Je l’ai repris pour qu’il échange l’aperçu sur place, en gardant la slide active sous les yeux.
Et la suite
rikiki est sur npm, déployé, documenté, et je m’en sers déjà pour mes propres talks. Les prochains chantiers : des transitions dignes de ce nom (aujourd’hui, une slide en remplace une autre, sans façon), une vraie coloration syntaxique branchée sur shiki partout, et davantage de recettes dans la doc.
Si vous voulez fouiller : le site et sa démo, la documentation, et le paquet sur npm.
Et le talk, au fait, je l’ai donné. Avec rikiki.