En réalité, cela introduit un coût immédiat.
Chaque abstraction anticipée augmente :

• le temps de développement
• le temps de review
• la difficulté d’onboarding
• la surface de bugs potentiels
• la complexité du debugging
• la quantité de tests nécessaires
  Et surtout :
• le besoin anticipé peut ne jamais arriver.
  Mais même si ce besoin arrive un jour, un autre problème apparaît. La solution que nous avons imaginée n’est peut-être pas la bonne.

The library parses rich schemas (nested sections, $ref, arrays, key/value maps, pattern properties…) into a navigable form tree, renders it as a keyboard-first editor, and validates the result after every edit so users always see the full list of issues before saving.

It can be useful someday

• not memory safe (thread access, ...)
• error handling
• garbage collected
• used to directly call sys calls
• can trigger MTE on Android because Go reads the whole page of memory to access a string

It's not a bad language: It's often easy to write a full production ready server using only the standard library. In 2026 this is becoming more of a feature due to the ongoing supply chain attacks. Go itself also has some great technologists working on the project who are extremely responsive and care very deeply.

Les pièges a éviter:

• readme cimetière
• theator of documentation: useless comments
• outdate trap: "how" is a wrong answer
• un ROI négatif.(Lectures × Temps gagné) - (Temps d’écriture + Maintenance).

Pour maximiser ce ROI, il faut distinguer quatre types de documentation :

1. ROI Infini : La doc fonctionnelle (le problème). C’est la boussole de la feature. Elle ne décrit pas les boutons, mais la valeur.
   • Le contenu : À quel problème client répond-on ? Quelle est la vision à 6 mois ? Quelles sont les limites actuelles (ce qu’on a décidé de ne pas faire) ?
   • Pourquoi c’est crucial : Sans elle, un dev qui itère sur la feature 1 an plus tard risque de supprimer un comportement “bizarre” qui était en fait une réponse vitale à un besoin client.
   • Le public : Elle est le pont entre la Tech, le Produit et le Marketing. C’est la doc qui aligne tout le monde.
2. ROI Élevé : La Doc d’Intention (l’histoire).
   • Pourquoi ce choix ? Quelles étaient les limitations ? C’est ce qui survit aux refactos (ex: les ADR - Architecture Decision Records). N’importe quel dev peut comprendre votre code, mais personne ne peut deviner une intention métier disparue.
3. ROI Opérationnel : La Doc d’Usage (le manuel). Le strict nécessaire pour être autonome. Par exemple le guide du “Day One”. Si je ne peux pas lancer le projet à tous les coups en quelques minutes lors d’un onboarding, le README a échoué.
4. ROI Négatif : La Doc d’Implémentation. Les détails techniques changeants. C’est du “Waste”. À supprimer au profit d’un code propre, typé et bien nommé.

La documentation est écrite pour être lue, sinon elle est nulle. Une bonne documentation doit être compréhensible par la majorité de l’équipe (Tech, Produit, voire Marketing).
Le vrai danger lors d’une passation, ce n’est pas la perte du “savoir-faire” technique, c’est la disparition de la compréhension du système.

Because the problem is so low-level to solve that the Rust guarantees can not work properly at this assembly code level.

Safe wrappers can be built upon it though.

C'est ce qu'on fait: tester en tant qu'utilisateur. C'est le minimum, je dirais même avant les tests automatisés.

Les tests valident le code
l’usage valide le produit.

En comparant la réalisation du ticket avec l'essai du produit en tant qu'utilisateur:

Exécuter un ticket est simple :

• lire les requirements
• implémenter la logique
• écrire les tests
• ouvrir une pull request

Tester réellement le produit demande un effort différent.
Il faut :

• suivre le parcours complet
• imaginer les actions d’un utilisateur (se mettre à sa place)
• tester des scénarios inattendus.
  C’est plus lent, et demande de l’empathie.

About the <picture> syntax which the author finds great.

On the contrary, the srcset and sizes attributes on one image are hard to use. "So, we are left describing the all of the sizes that an element will be, across every breakpoint and container query, as a single string, in an HTML attribute. How disgusting."

A tool is neede to write media queries in the sizes attribute.

How is a tool supposed to generate (min-width: 1340px) 257px, (min-width: 1040px) calc(24.64vw - 68px), (min-width: 360px) calc(28.64vw - 17px), 80px though?

The author proposes to bury this attribute and use sizes="auto". The developer can rely on loading="lazy" to load the images after the layout is computed, thus the browser know the size in advance.
sizes values remain a must have for images displayed way up at the top of the page... well sizes="100vw" is a good fit for it, isn't it?
All other images? loading="lazy" sizes="auto"