C'est exactement le concept derrière
Aurora OS.js
, un projet open source complètement barré qui simule un système d'exploitation complet dans votre navigateur... avec des mécaniques de jeu de hacking intégrées.
Le truc, c'est que ce n'est pas juste une démo technique. Aurora OS.js embarque un vrai système de fichiers virtuel avec stockage persistant, un terminal avec des commandes type Linux (ls, cd, cat, mkdir...), un gestionnaire de fenêtres, un bloc-notes avec coloration syntaxique, et toute une architecture modulaire pour les applications. Bref, ça ressemble à un vrai OS, ça se comporte comme un vrai OS, mais ça tourne dans un onglet de votre navigateur.
Côté technique, les développeurs n'ont pas fait dans la demi-mesure. C'est à base de React 19, Electron 39, TypeScript 5, Tailwind CSS v4, et des animations fluides grâce à Framer Motion. Et le tout nécessite Node.js 24 minimum, ce qui montre qu'on est clairement sur des technos de pointe.
Le projet suit une roadmap en trois étapes. La version actuelle (v0.7.7) se concentre sur les fondations et l'utilisabilité. La v1.x apportera le gameplay solo de hacking. Et la v2.x ? Du multijoueur persistant où vous pourrez hacker d'autres joueurs. Ça va être trop incrrrr !
Si vous aimez
les expériences dans le navigateur
ou
les projets qui repoussent les limites du web
, Aurora OS.js mérite clairement un coup d'œil. Y'a une démo live sur GitHub Pages pour tester directement (user: guest / mdp: guest). Et comme c'est sous licence AGPL-3.0, vous pouvez fouiller le code et même contribuer si le cœur vous en dit.
Bon, faut qu'on parle un peu du moteur de recherche de mon site. Ceux qui l'ont déjà utilisé savent de quoi je parle : c'était pas terrible. Enfin, « pas terrible » j'suis gentil. C'est un espèce d'overlay avec des résultats certes fiables mais c'était vraiment pas pratique.
Et en plus de ça, comme j'ai un site statique généré avec Hugo, je passais par Algolia pour la recherche. Si vous ne connaissez pas, Algolia c'est un service cloud qui indexe votre contenu et vous fournit une API de recherche ultra-rapide. Sur le papier c'est génial et dans la pratique aussi d'ailleurs sauf que voilà, ça coûte des sous. Et mon site rencontre un franc succès ces derniers temps (merci à vous !), donc j'ai de plus en plus de visiteurs, donc de plus en plus de recherches, donc une facture Algolia qui grimpe gentiment chaque mois.
Du coup je me suis dit : « Et si je trouvais une solution de recherche pour sites statiques ? » Parce que oui, ça existe et c'est comme ça que j'ai découvert Pagefind.
Pagefind c'est donc un moteur de recherche statique open source développé par CloudCannon qui fonctionne comme ceci : Au moment du build de votre site, Pagefind parcourt tout votre HTML généré et crée un index de recherche qu'on peut interroger avec un peu de JS. Y'a donc plus d'API, et tout se fait localement sur le navigateur des internautes.
Bref, ça avait l'air très cool alors évidemment, je me suis lancé dans l'aventure et comme j'aime bien me compliquer la vie, j'ai décidé de pas juste intégrer Pagefind tel quel. Non non. J'ai voulu recréer l'interface du Google de 1998 parce que à quoi bon avoir son propre site web si on peut pas s'amuser un peu ^^.
Laissez-moi donc vous raconter cette aventure.
Le problème avec Algolia
Leur service est excellent, je dis pas le contraire, la recherche est rapide, les résultats sont pertinents, l'API est bien foutue mais voilà, y'a le modèle de pricing puisque Algolia facture au nombre de requêtes de recherche.
Plus les gens cherchent sur votre site, plus vous payez et quand vous avez un site qui fait plusieurs millions de pages vues par mois, bah... ça chiffre vite. En gros je dépasse très vite les 10 000 recherches offertes chaque semaine et ensuite ça chiffre. C'est pas la mort, mais c'est un coût récurrent débile pour un truc qui pourrait être gratuit.
En plus de ça, y'a la dépendance à un service externe. Si Algolia tombe, ma recherche tombe. Et si Algolia change ses prix, je vais devoir subir. Même chose si Algolia décide de modifier son API... il faudra que j'adapte mon code. Bref, c'est le cloud dans toute sa splendeur... C'est pratique mais on n'est jamais vraiment chez nous.
Pagefind à la rescousse
Pagefind résout donc tous ces problèmes d'un coup. C'est un outil en ligne de commande qui s'exécute après votre générateur de site statique (Hugo dans mon cas, mais ça marche avec Jekyll, Eleventy, Astro, ou n'importe quoi d'autre).
Concrètement, vous lancez :
npx pagefind --site public
Et Pagefind va :
Scanner tous vos fichiers HTML dans le dossier public/
Extraire le contenu textuel (en ignorant la nav, le footer, les pubs si vous lui dites)
Créer un index de recherche optimisé
Générer des fichiers JavaScript pour interroger cet index côté client
Et le résultat c'est un dossier pagefind/ qui contient tout ce qu'il faut. Ensuite; à vous de servir ces fichiers statiquement avec le reste de votre site, et la magie pourra opérer !
L'index pour mes 18 000 articles fait environ 1,5 Go. Ça peut paraître beaucoup, mais Pagefind est malin car il découpe l'index en fragments et ne charge que ce qui est nécessaire pour la recherche en cours. Du coup en pratique, une recherche typique télécharge quelques centaines de Ko, et pas plus.
L'intégration technique
Pour intégrer
Pagefind
dans mon workflow Hugo, j'ai donc été cherché le binaire, je l'ai mis sur mon serveur et je l'ai appelé dans un cron comme ça, je rafraichi l'index de recherche 1 fois par jour (et pas à chaque génération du site).
L'astuce ici c'est d'indexer uniquement les div ayant la class data-pagefind-body='true' et d'exclure les éléments qui ne font pas partie du contenu éditorial afin de ne pas indexer ce qui se trouve dans le header, les natives, le footer...etc.
Côté JavaScript, Pagefind utilise les imports ES6 dynamiques. Ça veut dire que le moteur de recherche n'est chargé que quand l'utilisateur lance effectivement une recherche :
C'est bien fichu parce que search.results retourne immédiatement les références des résultats, mais le contenu réel (titre, extrait, URL) n'est chargé que quand vous appelez result.data(). Du coup vous pouvez implémenter une pagination propre sans télécharger les données de milliers de résultats d'un coup.
Le délire rétro - Recréer Google 1998
Maintenant que j'avais un moteur de recherche fonctionnel, fallait l'habiller. Et c'est là que j'ai eu cette idée un peu débile : Pourquoi pas recréer l'interface du Google de 1998 ?
Pour les plus jeunes qui lisent ça, Google en 1998 c'était une page blanche avec un logo, un champ de recherche, et deux boutons : « Google Search » et « I'm Feeling Lucky« . Pas de suggestions, pas de carrousels, pas de pubs... Juste un champs de recherche. C'était la belle époque !
J'ai donc créé une page de recherche avec deux vues distinctes. La page d'accueil avec le logo centré et le champ de recherche au milieu, exactement comme le Google originel.
Et la page de résultats avec le logo en petit en haut à gauche et les résultats en dessous.
Pour le code CSS, j'ai voulu être fidèle à l'époque. Times New Roman comme police par défaut, les liens en bleu souligné qui deviennent violet une fois visités. Et surtout, les boutons avec l'effet 3D des interfaces Windows 95 :
.search-button:active { border-style: inset; }
Ce border: outset et border-style: inset au clic, c'est exactement ce qui donnait cet effet de bouton en relief qu'on avait partout dans les années 90. Pour moi, ça fait toute la différence pour l'authenticité. Même le logo, je l'ai volontairement « dégradé » pour qu'il soit de la même qualité que le logo Google d'origine.
La pagination « Koooooorben »
Vous vous souvenez de la pagination de Google avec « Goooooogle » en bas de page ? Le nombre de « o » correspondait au nombre de pages de résultats. J'ai fait pareil, mais avec « Koooooorben ».
let logo = 'K'; for (let i = 0; i < oCount; i++)
{
logo += o;
} logo += 'rben'; }
Plus il y a de résultats, plus il y a de « o ». C'est complètement inutile mais ça me fait marrer à chaque fois que je le vois.
Le bouton « J'ai de la chance »
Ah, le fameux « I'm Feeling Lucky » de Google, j'ai voulu l'implémenter comme à l'époque ! Si vous tapez une recherche et cliquez sur « J'ai de la chance », vous êtes envoyé sur le premier résultat. Classique. Mais si vous cliquez sur le bouton avec le champ vide sur la home de la recherche, vous êtes envoyé sur un article aléatoire parmi les +18 000 du site.
Pour ça, j'ai utilisé une astuce : le sitemap. Mon Hugo génère un fichier sitemap.xml qui contient toutes les URLs du site et je peux aller piocher dedans en JS :
Un seul fetch, un peu de parsing XML natif, et hop c'est le grand retour de la fonctionnalité « article aléatoire » qui vous manquait, je le sais !
Tri et nombre de résultats
Je vous ai aussi mis une listbox qui vous permet d'afficher 10, 25 ou 50 résultats ainsi qu'un tri par pertinence ou data. Et ça aussi Pagefind sait parfaitement le navigateur.
Mode sombre et accessibilité
Même si l'interface est rétro, j'ai quand même ajouté quelques fonctionnalités modernes. Le mode sombre respecte les préférences système, et j'ai intégré la police OpenDyslexic pour les personnes dyslexiques.
Le truc important c'est de charger ces préférences avant le rendu de la page pour éviter le fameux flash. J'ai donc un petit script qui lit les préférences dans le localStorage et applique les classes CSS immédiatement :
function() {
if (localStorage.getItem('theme') === 'dark') {
document.documentElement.classList.add('dark-mode');
}
if (localStorage.getItem('dyslexic-font') === 'true') {
document.documentElement.classList.add('dyslexic-mode');
}
});
Gestion de l'historique navigateur
Un détail qui peut sembler anodin mais qui est super important pour l'expérience utilisateur c'est la gestion du bouton retour du navigateur.
Quand vous faites une recherche, l'URL change selon votre requête du genre /recherche/?q=linux&p=2. Du coup si vous partagez cette URL à un collègue, la personne arrivera directement sur les résultats de recherche. Et si vous utilisez le bouton retour, vous reviendrez alors à la recherche précédente.
Et si vous ne trouvez pas votre bonheur dans mes +18 000 articles (ce qui serait quand même étonnant ^^), j'ai ajouté des liens pour relancer la même recherche sur Google, DuckDuckGo, Qwant, Brave et Ecosia. Bref, un petit service bonus pour mes visiteurs, exactement comme le proposait Google à l'époque.
Le bilan - Algolia vs Pagefind
Après 1 semaine d'utilisation, voici donc mon verdict ! Côté portefeuille d'abord, Algolia me coûtait entre 60 et +100 euros par mois et maintenant pour Pagefind, c'est zéro euros ! Et les performances sont également au rendez-vous. Algolia c'était rapide et bien là, ça l'est encore plus. Seul compromis à noter, l'index Algolia se mettait à jour en temps réel, alors que Pagefind nécessite une reconstruction au moment du build.
La conclusion
Voilà, j'ai maintenant une recherche qui marche vraiment bien, qui me coûte 0€ par mois, et qui a un look rétro qui va en surprendre plus d'un...
Alors est-ce que c'était nécessaire de passer autant de temps sur le design rétro ? Hé bien absolument pas. Mais est-ce que ça valait le coup ?
Franchement, oui !! C'est mon site, je fais ce que je veux, et si ça peut faire sourire quelques visiteurs nostalgiques des débuts du web, c'est du bonus.
D'ailleurs un grand merci aux Patreons
qui me soutiennent car sans eux, je n'aurais pas pu passer mon dimanche là dessus ^^
Et puis surtout, ça m'a permis de découvrir Pagefind qui est vraiment un excellent outil. Donc si vous avez un site statique (ou n'importe quel type de contenu textuel) et que vous cherchez une solution de recherche gratuite et performante, je vous le recommande chaudement. La documentation est claire, l'intégration est simple, et le résultat est top !
Vous avez déjà essayé de faire du traitement vidéo dans le navigateur
Bienvenue en enfer ! Et dire que pendant 20 ans, la seule solution viable c’était de compiler FFmpeg en WebAssembly, attendre 10 secondes que 40 Mo de code se chargent, puis regarder votre RAM fondre comme neige au soleil.
Heureusement,
MediaBunny
débarque et compte bien changer les choses !
En effet, cette bibliothèque TypeScript vous permet de lire, écrire et convertir des fichiers vidéo et audio directement dans le navigateur. MP4, WebM, MKV, MP3, WAV, Ogg, FLAC, vous nommez simplement le format, et MediaBunny le gère. Et la bibliothèque ne pèse que 5 Ko en version minifiée. Ça semble peu mais en fait, au lieu d’essayer de porter un outil desktop vers le web, Vanilagy (le créateur) a construit MediaBunny from scratch pour exploiter ce que le navigateur savait déjà faire.
La clé, c’est donc l’API WebCodecs qui existe depuis Chrome 94 sorti en 2021, mais que presque personne n’utilise. Cette API donne accès direct à Javascript à l’accélération matérielle de votre GPU pour encoder et décoder la vidéo que ce soit du H.264, H.265, VP8, VP9 et tout ça en temps réel. Et MediaBunny se branche dessus et vous donne une interface propre pour manipuler vos médias.
Vous voulez extraire les métadonnées d’une vidéo MP4, convertir un WebM en MP4 ou encore extraire une piste audio d’une vidéo ? En 3 lignes de code c’est plié, et tout ça en local dans votre navigateur.
MediaBunny supporte plus de 25 codecs vidéo, audio et sous-titres. H.264, H.265, VP8, VP9, AV1 pour la vidéo. AAC, Opus, Vorbis, MP3, FLAC pour l’audio. WebVTT pour les sous-titres…etc.
Et l’outil étant pensé avec un design modulaire qui permet de faire du
tree-shaking
, vous pouvez embarquer uniquement le code dont vous avez besoin, ce qui allège encore plus le bouzin. MediaBunny est d’aillerus l’évolution technique de deux projets du même auteur : mp4-muxer et webm-muxer. Ces bibliothèques faisaient déjà du bon boulot pour écrire des vidéos MP4 et WebM côté client, mais MediaBunny va beaucoup plus loin en supportant la lecture, l’écriture et la conversion pour tous les formats courants.
Si ça vous chauffe, pour installer MediaBunny, c’est du classique :
npm install mediabunny
Et voici un exemple d’utilisation basique pour lire un fichier vidéo :
Le code est dispo sur
GitHub
sous licence MPL-2.0, ce qui vous permet de l’utiliser dans des projets commerciaux sans problème et la documentation complète est sur
mediabunny.dev
avec des guides pour tous les cas d’usage.