Vous avez déjà voulu créer une appli desktop qui tourne sur Linux, Mac et Windows en même temps ? En Rust, c'était un peu compliqué jusqu'ici. Heureusement, Slint , créé par la société allemande SixtyFPS GmbH, propose une solution sympa !

L'idée, c'est de décrire votre interface dans des petits fichiers .slint (un genre de mini HTML/CSS pour appli native), et de brancher ça à du Rust, du C++, du JavaScript ou du Python. Comme ça, vous codez le visuel d'un côté, la logique de l'autre.

Et ce qui est encore plus cool c'est que leur runtime tient dans 300 KiB de RAM. A titre de comparaison, une appli Electron type Discord en bouffe plusieurs centaines de mégaoctets. Slint tourne donc aussi bien sur un Raspberry Pi, un microcontrôleur STM32, ou directement dans un navigateur via WebAssembly.

Par exemple, SK Signet, un fabricant sud-coréen leader sur le marché américain des bornes de recharge électrique, anime ses écrans tactiles 15 à 32 pouces avec. OTIV fait tourner ses trains autonomes dessus. WesAudio l'utilise également pour son plugin audio pro.

Donc c'est du sérieux et si vous voulez tester sans rien installer, direction SlintPad . Vous tapez du code, et le rendu apparaît dans le navigateur. Ensuite pour débuter un projet Slint en local, faudra faire un cargo install slint-lsp puis utiliser le template slint-rust-template dispo sur GitHub. 2 minutes de compilation plus tard et hop, vous avez votre première fenêtre.

Côté tarif, Slint est gratuit pour les projets open source et gratuit aussi pour les applis desktop, mobile ou web même propriétaires. Seul l'embarqué propriétaire est payant. Donc pour la majorité des gens, c'est gratos.

Le revers de la médaille c'est qu'il faudra apprendre un nouveau langage de description, et la bibliothèque de boutons et menus prêts à l'emploi est moins fournie qu'un Qt qui a 30 ans d'avance derrière lui. Mais ça vaut le coup d'essayer puis vu que tout le monde vibe code de toute façon, ça ne devrait pas vous poser trop de soucis.

Voilà, si vous bricolez vos propres outils sur Raspberry Pi ou que vous voulez juste une appli desktop ultra-légère sans embarquer un navigateur entier avec, c'est à regarder.

Merci Chrltc pour le lien !

Source : github.com/slint-ui/slint

Le scraping web, c'est un combat permanent contre les sites qui changent leur HTML toutes les deux semaines. Vous vous emmerdez à coder vos sélecteurs CSS, ça marche pendant un mois, puis le site refait son design et hop, votre script s'éteint en silence. C'est pourquoi Karim Shoair (alias D4Vinci sur GitHub) a sorti Scrapling, un framework Python qui s'adapte tout seul quand le DOM bouge.

La clé c'est adaptive=True sur n'importe quel sélecteur. Vous lui dites "je cherchais .product", Scrapling sauvegarde alors la signature de l'élément (texte, attributs, position dans l'arbre), et la prochaine fois que le site a renommé sa classe, il retrouve l'élément via similarité.

Concrètement ça donne ça :

from scrapling.fetchers import StealthyFetcher
StealthyFetcher.adaptive = True
page = StealthyFetcher.fetch('https://example.com', headless=True)
product = page.css_first('.product', adaptive=True) # Retrouve l'élément même si la classe a changé

Le truc marche grâce à un algo de similarité maison qui compare la structure DOM autour de l'élément. L'auteur lui-même a écrit un long post Medium intitulé " Creating self-healing spiders with Scrapling in Python without AI ", et ça résume bien la philosophie : pas de modèle IA mais juste des heuristiques solides !

La doc précise que adaptive=True ne sauvegarde que le premier élément de la sélection. Du coup si vous récupérez 50 produits d'un coup avec .css('.product'), seul le premier sera adapté. Faudra donc soit utiliser css_first comme dans l'exemple, soit boucler manuellement et appeler adaptive sur chaque élément. C'est bon à savoir...

Y'a également 3 fetchers selon le besoin. Fetcher pour les requêtes HTTP rapides avec spoofing TLS, StealthyFetcher qui passe Cloudflare Turnstile via un navigateur furtif (Camoufox sous le capot), et DynamicFetcher qui lance un Chromium ou un Chrome via Playwright pour les sites lourds en JS. Du coup vous pouvez démarrer léger en HTTP et basculer vers un navigateur uniquement quand un site bloque, sans réécrire votre code.

Côté perfs, le README annonce du lourd : 2 ms pour extraire 5000 éléments contre 1584 ms pour BeautifulSoup avec lxml. Sauf que Parsel et Scrapy font aussi 2 ms. Donc le gain vient du moteur lxml utilisé en direct, ce qui veut dire que si vous étiez déjà sur Scrapy, vous ne gagnerez pas en vitesse brute. Mais si vous traînez encore du BS4 partout, le saut sera énorme !

Sur le terrain anti-bot, ça se compare bien à Botasaurus dont je vous avais parlé. La différence c'est que Scrapling embarque un ProxyRotator natif et propose un blocage d'ads/trackers (~3500 domaines) activable via block_ads=True ou automatique en mode MCP, ce qui simplifie la vie quand vous tournez sur un serveur (où les IPs des datacenter se font régulièrement filtrer). Botasaurus, lui, vous laisse gérer la rotation à la main.

Détail sympa pour les bidouilleurs : y'a également un serveur MCP intégré (pip install "scrapling[ai]"). Du coup Claude ou Cursor peuvent piloter Scrapling directement pour extraire des données, en réduisant la consommation de tokens car l'IA ne voit pas tout le HTML brut, juste ce qui est extrait. Pour les agents qui scrappent en boucle, c'est cool.

Notez que les sponsors Platinum du projet sont tous des fournisseurs de proxies (DataImpulse, BirdProxies, Evomi, etc.). C'est logique vu l'usage du framework, mais gardez en tête que pour bypasser un Cloudflare sérieux à grande échelle, vous aurez besoin de proxies résidentiels payants, donc d'eux. L'outil est gratuit, mais le contournement industriel ne l'est pas.

Pour installer, c'est pip install "scrapling[fetchers]" puis scrapling install pour récupérer les binaires navigateur. Une image Docker existe aussi (pyd4vinci/scrapling) et y'a même un shell interactif (scrapling shell) pour debugger vos sélecteurs en live.

Bref, c'est carrément pas mal pour ceux qui scrapent régulièrement. Alors si BS4 vous fait pleurer, allez voir par ici .

Et merci à Letsar pour le lien !

Ruby Central, l'association qui gère l'écosystème Ruby (RubyGems, Bundler, les conférences RubyConf et RailsConf), est en "vrai péril financier".

Le conseil d'administration l'a annoncé en se séparant de sa directrice exécutive, Shan Cureton, dans le cadre d'un plan de réduction des coûts. Les finances de l'organisation dépendaient trop "du timing optimiste de la réception des fonds par rapport aux dates fixes de nos dépenses", selon les administrateurs.

Le contexte, c'est un conflit qui dure depuis des mois. Fin 2025, Ruby Central a retiré plusieurs mainteneurs historiques de RubyGems et Bundler sans les prévenir.

Les mainteneurs concernés ont visiblement mal pris ce move, et ont lancé un fork rival appelé Gem Cooperative (gem.coop). Dans la foulée, ils ont publiquement accusé Ruby Central de prise de contrôle autoritaire. L'ancienne directrice avait en fait justifié les retraits par des demandes de sponsors et d'entreprises dépendantes de Ruby, inquiètes de problèmes de supply chain et de gestion des accès.

Le résultat, c'est un écosystème fracturé. D'un côté, Ruby Central avec le registre officiel RubyGems.org et les conférences. De l'autre, des mainteneurs expérimentés partis avec leur savoir-faire et une partie de la communauté. Et entre les deux, des sponsors qui hésitent à mettre de l'argent dans une organisation en crise de gouvernance.

Le conseil a voté en avril la transition vers un "working board" bénévole, ce qui veut dire moins de salariés et plus de travail non rémunéré. C'est le genre de restructuration qui peut effectivement sauver les finances à court terme, mais qui fatigue forcément les contributeurs au bout d'un moment.

Pour les développeurs Ruby, c'est quand même préoccupant. RubyGems est l'équivalent de npm pour JavaScript ou pip pour Python, c'est l'infra de base sur laquelle tournent des milliers de projets en production. Une association gestionnaire en péril financier et en conflit avec ses propres mainteneurs, ça fragilise clairement toute la chaîne.

Bref, Ruby Central doit trouver un modèle viable sans ses mainteneurs historiques et sans directrice. Pas simple.

Source : The Register

Wolfenstein 3D, pour ceux qui n'étaient pas nés en 1992, c'est le FPS qui a tout lancé. Le jeu de Carmack et sa bande chez id Software, qui a directement mené à DOOM l'année suivante.

Eh bien un dev Rust vient de le recréer de zéro, et c'est 100% jouable dans le navigateur.

Iron Wolf , c'est donc le projet de Michael Bohn, un allemand, qui bosse sur ce truc depuis mai 2021, soit près de cinq ans. On n'est donc pas sur un portage vibe codé à l'arrache. C'est vraiment une réécriture complète.

La version web d'Iron Wolf tournant dans le navigateur

Le bonhomme a carrément créé ses propres crates Rust pour émuler la carte VGA et la puce sonore OPL. J'ai d'abord cru qu'il réutilisait une lib existante, mais non, il a tout écrit from scratch en Rust. Bah ouais, développer ses propres librairies d'émulation hardware juste pour un side-project, what else ?? Je trouve que ça force le respect !

Le truc cool, c'est que la version shareware du jeu est incluse directement dans le dossier testdata/ du repo. Du coup sur macOS, Linux ou Windows, un git clone + just run-sdl-shareware et hop, vous voilà dans les couloirs du château. Attention sur Ubuntu 22.04, faut avoir libsdl2-dev d'installé avec apt install libsdl2-dev, sinon la compilation plante avec une erreur cryptique. Par contre, si vous êtes sur la version Ubuntu 24.04, là ça passe direct. Et si vous avez les fichiers WAD du jeu complet qui traînent sur un vieux CD-ROM quelque part, ce sera encore mieux car la version web permet de les uploader pour jouer à l'intégrale.

Ça tourne donc en WebAssembly sur wolf.ironmule.dev , sans plugin, juste Chrome ou Firefox récent. Voilà, si vous vous demandiez si on peut encore jouer au classique en 2026... la réponse est carrément oui !

Pour les curieux, le raycasting, cette technique de rendu qu'utilisait Wolfenstein 3D, est réimplémenté très fidèlement puisque le moteur de Michael dessine les murs comme le code de Carmack le faisait à l'époque... sauf que là ça tourne dans un onglet de navigateur. Vos fichiers de jeu sont également stockés localement via IndexedDB et un service worker gère le mode hors-ligne ce qui est très pratique pour jouer en avion ou quand on est chez Free (je décoooonnnne, humour humour).

Le projet en est à sa version 0.9.0, sous licence GPL-3.0 et si les classiques d'id Software recréés par des passionnés vous branchent, sachez que DOOM aussi a ses portages bien sympas.

Bref, si la nostalgie du raycasting vous titille, allez faire un tour sur wolf.ironmule.dev.