First off, it takes time to grow a design system's coverage. Design systems exist to provide common solutions that are versatile enough to be applied in multiple contexts. To do that successfully, we first need to fully understand those contexts - and that means diverging before we converge.

Ultimately, design systems are not replacing nothing. They’re replacing context-specific (if inefficiently created) solutions.

It doesn’t make sense for product teams to adopt design system components and patterns unless it matches or exceeds the quality of those that they’re already using.

"Vibe coding" is a trendy expression for "Automated coding".

Automated programming especially allows me to quickly build the tools I need so fast that every blacksmith that ever existed on this earth would envy me deeply.

With the automated coding, "we can finally get rid of all that middle work. That adapting layer of garbage we blindly accepted during these years. A huge amount of frameworks and libraries and tooling that has completely polluted software engineering, especially in web, mobile and desktop development."

The frameworks claim to solve three problems: simplification, automation and labour cost. "You unlock a feature that has nothing to do with engineering: you no longer need to hire a software engineer. You hire a React Developer.

Software engineering is back in a sense again: We have the chance again to get rid of useless complexity and keep working on the true and welcome complexity of our ideas, our features, our products. The complexity that matters. The complexity that is actually yours.

Automation and boilerplating have never been so cheap to overcome. I’ve been basically never writing twice the same line of code. I’m instantly building small tools I need, purpose built, exactly shaped around the problem at hand. I don’t need any fancy monorepo manager. A simple Makefile covers 100% of my needs for 99% of my use cases.

Bash, makefiles, ...

Think about it

The author creates a project to gather statistics about the top most starred projects on Github or the most downloaded packages on NPM.

1. 9-27% of JS/TS projects declare themselves to be ES Modules
2. Less than 6% of JS/TS files declare that they are ES Modules via the .mjs, .cjs or .mts file extensions.

Some ideas:

1. kill .mjs, .cjs and .mts should be replaced by the type="module" in package.json. Let's stick to .js, .jsx, .ts and .tsx
2. Make type="module" the default and warns when the type is not set to module.
3. We should upgrade the most common libraries used by the community to ES Modules
4. The NPM registry can require an explicit module field on new packages, making it clear when a package intentionally uses CommonJS.
5. NodeJS can officially drop support for require and module.exports in a future version, creating a bit more pressure to migrate.

relevant questions about to include anti-patterns in the documentation. Note these questions are also pertinent .

• How much is the component or pattern being used?
• How often are people looking for it in our design system?
• Is there an opportunity to make it less bad?

Including bad practice in design systems gives us an opportunity to call it out: it's the perfect place for alignment of our understanding or opinion of what constitutes bad practice.

I don’t subscribe to the idea of purely “descriptive” design systems - ones that simply systematise existing UI, regardless of its usability and quality. Design systems have a responsibility to mitigate - and certainly to not proliferate - bad practice.However, design systems must also acknowledge the reality of the context in which they sit. If problematic components and patterns are being widely used, then our design systems can play an important role in discouraging further uptake, raising awareness of their issues, and offering risk-mitigation advice and alternatives to consider. As with most design system concerns, there’s no blanket solution here. But I hope these considerations will help you the next time you’re faced with this question.

Un retour des posts publié entre 1996 et 1998. Le web a tellement évolué depuis!

Mots-clés lié à display: flex

• auto : L'ancien roi. Contextuel, imprévisible parfois, il laisse le navigateur calculer la taille selon le modèle de boîte standard (display).
• min-content : "Je veux être aussi petit que possible." Le navigateur va essayer de réduire la boîte jusqu'à ce que le mot le plus long ou l'élément le plus large force la largeur minimale. C'est le "soft wrapping" ultime.
• max-content : "Je prends toute la place dont j'ai besoin." La boîte s'élargit pour contenir tout le texte sans aucun retour à la ligne, quitte à provoquer un scroll horizontal (à utiliser avec prudence !).
• fit-content : Le compromis parfait. C'est mathématiquement équivalent à min(max-content, available-space). La boîte s'adapte au contenu, mais s'arrête poliment si elle touche le bord du conteneur parent.
• stretch : L'élément s'étire pour remplir l'axe disponible. C'est souvent le comportement par défaut des flex-items ou des grid-items.

Math functions such as clamp(), min(), max().

Le pattern Repeat Auto Minmax (RAM) est usuellement donné aux snippets qui génère une grille responsive sans aucun breakpoint grid-template-columns: minmax(300px, 1fr)

Une autre manière de refonder le village abandonné. À voir comment l'expérience se perpétuera dans quelques années.

Why don’t we approach guidance and documentation as modular parts of our systems, the way we do with everything else?

For example: “Buy this book” not “Buy This Book”.

This is important in button documentation, guidance on links, content A-Z styleguide, developer documentation in GitHub, Storybook or design libraries in Figma or Sketch. Design systems seek to increase efficiency via common solutions that can be maintained centrally and reused in multiple places. We can do that for documentation too.

We can create the guidance in one of those places and link to it. This is more maintainable, but forces people to go to another place to get all the information they need to complete their task.

Documentation has variants too: in the design libraries, we may simply tell people to write calls to action in sentence case, but in the content styleguide, we may want to explain that sentence case is proven to be more readable most of the time. So already we have 2 variants: rule and rule with rationale. As more tools are used for different purposes, the documentation get more variants.

It's common to have multiple documentation tool, so we need a way to plugin our common documentation to every one of them. So the author is working on such tool that can deliver specific documentation variants.

Publié le 17 juillet 1998.

A l'époque, la France limitait le chiffrement avec une clé de 40 bits, là où l'EFF avait cassé un chiffrement 56 bits avec une machine de 250 000$. Donc ce prototype de l'EFF cassait la clé de 40 bits en 3 secondes.

L'auteur recommandait

Bref, il est temps que les gouvernements se décident à autoriser un cryptage un rien plus costaud. Un cryptage à l’aide de clefs de 64 bits est déjà largement plus puissant. Évidement, cela ne résoudra pas le problème de l’état qui veut avoir un oeil sur tout.
Mais sérieusement, est-ce que les criminels en tout genre vont s’amuser à crypter en utilisant des outils légaux ? Non, ces mêmes criminels utilisent des clefs de 1024 bits ou même de 2048 bits (PGP est capable de coder avec une telle puissance et il est très simple à mettre en œuvre)."
Donc, le seul qui est gêné dans l’histoire c’est l’honnête citoyen qui désire simplement éviter que son patron, son provider, une tierce personne aille mettre un nez dans ses affaires

GitHub Issues as free database