Alors voilà j'aime beaucoup cette idée - qui se fait généralement cracher à la gueule par la vaste majorité des développeurs - qu'un logiciel puisse être "terminé".
On voit souvent des gens dire "Ce logiciel semble parfaitement répondre à mes besoins, mais ça fait un an qu'il n'y a pas eu de commit, ça fait peur."  Pourquoi ?

Si je prends l'exemple de Shaarli : Certes on pourrait ajouter des fonctionnalités, mais il fait ce qu'il est censé faire. Il est "feature complete". Je n'éprouve aucun besoin de modifier.

Extrait de l'article :
" - It is feature complete. New things can be added, but do not need to be added. It “works”. It does something useful as it is.
- It is secure – We understand enough about it to be able to say that it will not need to be updated in the future to patch security vulnerabilities.
- It is standalone. My meaning of this is quite specific, it means that it has no runtime dependencies except for an interpreter if required."

C'est très exactement la situation de Shaarli. En ce qui me concerne, il est terminé.

Il n'y a pas de mal à ce qu'un logiciel soit terminé.
Accepter le fait qu'il le soit, c'est aussi un moyen d'éviter le "feature creep" et le "bloat". (Combien d'excellents logiciels ont fini par pourrir à force d'ajout de fonctionnalités ?)
(via https://shaarli.zoemp.be/shaare/wNwJHw)
(Permalink)

Un logiciel qui créé des motifs intéressants, presque "naturels".
https://github.com/Bleuje/interactive-physarum?tab=readme-ov-file
(Permalink)

Attendez... Python a complètement explosé Java en tant que langage populaire ?
Je présume que c'est grâce/à cause de l'IA ?
(Permalink)

Visiblement parser du Yaml c'est pas trivial, et un fichier peut être interprété différemment selon la version du parseur.
(via https://shaarli.zoemp.be/shaare/mQBe7g)
(Permalink)

Sous le coude : Un framework javascript *léger* (~10 ko) qui s'accomode de divers backends (Python, php, GO...). Et ça supporte même SSE (Server-Side Events) et donc permet de faire des pages très dynamiques sans se coltiner des usines à gaz en Javascript. Le but, c'est vraiment de faire des applications très dynamiques, mais de faire le gros du boulot côté serveur.

Je me garde ici quelques liens en rapport :
https://archive.fosdem.org/2025/schedule/event/fosdem-2025-6316-push-based-hypermedia-with-datastar/
Comparé à htmx : https://chrismalek.me/posts/data-star-first-impressions/
https://medium.com/@ianster/using-datastar-da1984a6cc77
(Permalink)

En 20 ans le web a formidablement évolué : CSS plus puissants et globalement standardisé entre navigateur, javascript, html incroyablement plus puissant (sélecteur de dates, etc.). On a des outils de base incroyablement plus puissants qu'en 2000, et on peut faire des tonnes de choses avec juste html+css+vanilla javascript, et avec une puissance CPU bien plus grande. Donc tout devrait être très rapide.

Sauf que non. Le web de 2025 est lourdingue. On construit des usines à gaz monstrueuses avec des pages de 25 Mo avec des méga-octets de javascript.
Pourquoi ? Peut-être parce qu'en tant que développeur on arrive pas à accepter le fait que développer une appli web, c'est juste faire du CRUD (Create-Read-Update-Delete) amélioré et qu'inconsciemment on en a honte. Donc on invente des cathédrales à la complexité démente pour se justifier.

Traduction de la citation au début de l'article :
« Les pages web ne sont pas si différentes de ce qu'elles étaient à la fin des années 90 et au début des années 2000. Ce ne sont toujours que des formulaires. Elles écrivent toujours simplement dans des bases de données. Beaucoup de gens, je pense, sont très mal à l'aise avec le fait qu'ils sont essentiellement des singes savants qui font du CRUD. Ils créent juste des systèmes qui créent, lisent, mettent à jour ou suppriment des lignes dans une base de données, et ils doivent compenser ce malaise existentiel en compliquant les choses. »

(via https://shaarli.zoemp.be/shaare/h-wHoQ)

Sur le même sujet :
"JavaScript broke the web (and called it progress)" - https://sebsauvage.net/links/?3j-1qA
"Why do software developers love complexity?" - https://sebsauvage.net/links/?KDWHXQ
"The Cult of Hard Mode" - https://www.joanwestenberg.com/p/the-cult-of-hard-mode-why-simplicity-offends-tech-elites
(Permalink)

Les développeurs aiment construire des choses complexes (même quand il existe des solutions plus simples) car cela est plaisant intellectuellement, mais ça se paie sur le long terme.
(Permalink)

Comment les développeurs du logiciel Obsidian réduisent les risques malgré les dépendances du logiciel. Et ce sont de très bonnes pratiques.
- petite fonctions : incluses directement dans le code de l'appli.
- modules moyens : inclus dans la base de code d'Obsidian si la licence le permet.
- gros modules : mis à jour moins souvent, uniquement lors des mises à jour de sécurité, et les changeslogs sont examinés en détail.

Les versions sont verrouillées (pas de montée automatique de versions des dépendances), ce qui leur permet d'avoir des compilation reproductibles. Les montées en version des dépendances se font après examen détaillé des changelog et des changements de sous-dépendances.
(Permalink)

Comme dit le développeur curl : « Who could have figured out that automatically downloading half the internet and ten thousand always-changing dependencies every time you build could actually be a weakness? »
(https://mastodon.social/@bagder/115218787867536141)
(Permalink)

La difficulté de ne pas écrire de données sensibles dans les logs, et différentes pistes pour y parvenir.
(Permalink)

Part de marché de php côté serveur en 2025 : 73,6%.
Voilà.
Le second, c'est (surprise !) Ruby avec... seulement 6,3%.

php est mort, vraiment ?
(Permalink)

C'est ouf comment les développeurs arrivent à transcender le matériel, comme ici avec un jeu développé pour le ZX Spectrum qui l'air en 3D sur une machine qui en théorie n'est pas assez puissante pour faire ce genre de chose !
(Voir à partir de 4 minutes 10 dans cette vidéo : https://www.youtube.com/watch?v=fg1WNO29Zh4)
(Permalink)

Message aux développeurs: N'ESSAYEZ PAS DE VALIDER LE FORMAT DES ADRESSES EMAIL. Vous le faites mal, c'est absolument certain. N'essayez pas.
Faites ce quizz pour vous en convaincre.
(Permalink)