DEV Community: Ali

The gap

Ali — Sun, 05 Jul 2026 12:00:00 +0000

There's a shape I keep sketching on whiteboards when this comes up, and it's three curves. AI adoption, going up and to the right. Hands-on coding ability in people who started after 2023, going down. And a third curve almost nobody puts on the chart: what the AI actually costs to run, versus what you pay for it. Those two lines are not the same line, and the space between them is borrowed money.

Play the three curves forward and you get a period — I don't know if it's five years or fifteen — where the people who could build software from their own heads are retiring, the people who should have replaced them never learned, and the tool that was supposed to make the difference irrelevant has been repriced out of casual reach. I call that period the gap. This post is me trying to argue myself out of it, and mostly failing.

The first curve: prompting is not authoring

Let me be precise about what juniors are and aren't learning, because "kids these days can't code" is a complaint as old as COBOL and usually wrong. Today's juniors are not lazy and not stupid — many of them ship more in their first year than I did in my first three. What they're not doing is authoring: staring at a blank function, holding the problem in their head with no autocomplete to lean on, being wrong alone, and debugging their way out. They review, they steer, they prompt again. The output is real. The formation isn't happening.

I've watched it up close. A junior on a recent project produced a clean, working feature in an afternoon — and couldn't answer why one of the two API calls in it needed a retry and the other one must never have one. Not because they hadn't read the code. Because that distinction lives in a layer of understanding you only build by having been the author when it went wrong. Skill isn't downloaded from output. It's deposited by struggle, in small amounts, over years. Remove the struggle and the deposits stop, even while the output keeps flowing. That's the trap: the metrics all look fine.

The second curve: you are not paying the real price

Here's the part of my argument people push back on hardest, so let me make it carefully. The twenty dollars a month you pay for an AI assistant is not a price. It's a bet — someone else's bet, placed with venture and cloud-provider capital, that subsidizing your dependency today buys them your budget tomorrow. The major labs lose money serving you. The GPUs are scarce, the energy is real, the datacenters are being financed like railroads. We have seen this movie: rides across Paris for six euros until the day Uber needed to become a business, then the same ride for fourteen. WeWork desks, meal delivery, scooters — every VC-funded convenience of the 2010s followed the same arc. Cheap while they're buying the habit, repriced once the habit is bought.

The honest counterargument is that inference cost per token has been falling fast, and that's true — models get distilled, hardware improves, yesterday's frontier becomes today's commodity. But three things eat that gain. Usage explodes faster than unit cost falls: agents that run for hours, codebases fed whole into context windows, one prompt fanning out into a thousand calls. The capability you actually depend on for real work stays at the frontier, and the frontier stays premium — nobody bets their production system on the free tier. And once an industry has burned hundreds of billions, the money wants to come back; it comes back through the price, the usage caps, the enterprise tier, the "your plan has changed" email. Cheap tokens for toy tasks, expensive tokens for the work that matters. The subsidy doesn't end with a bang. It ends with a pricing page that gets one row longer every quarter.

Where the curves cross

Neither curve is a catastrophe alone. A generation that codes less but has cheap abundant AI forever? Fine — that's just a new abstraction layer, and we've absorbed those before; nobody mourns hand-rolled assembly. Expensive AI in a world full of people who can code without it? Also fine — annoying, but the skill is there to fall back on. The gap is what happens when both arrive at once: the crutch gets expensive at the exact moment an entire cohort needs it to walk.

Picture a mid-size company in that world. Its senior engineers — the ones formed before the shift — are in their fifties, expensive, and leaving. Its ten-year veterans came up prompting; they're excellent orchestrators of a tool the CFO now rations, because the AI line item has quietly become the third biggest cost after salaries and cloud. There's a production incident in a system that was 80% generated three years ago, the agent budget for the month is spent, and the person on call has never once debugged something this deep by hand. That's not science fiction. That's just the three curves, extended, meeting in one on-call rotation.

The uncomfortable historical rhyme: we've lost operational knowledge this way before. Ask anyone who maintains mainframe COBOL what it costs to hire for a skill the industry stopped teaching forty years ago — the code outlived the people, and the people who remained could name their price. The gap is that dynamic, but not for one legacy niche. For the general ability to write software unassisted.

What the gap is not

I want to be fair to the future, because doom-scented essays are cheap. The gap, if it comes, is a transition, not an end state. Markets route around scarcity: if frontier AI gets rationed by price, open-weight models running on owned hardware become the diesel generator of software teams — worse, but yours. Salaries for humans who can author unassisted would spike, and spiking salaries are the best recruitment poster ever printed; the skill would get relearned, the way it always does when it pays again. And it's possible the cost curve genuinely wins — that inference becomes too cheap to meter and this whole essay ages like predictions of peak oil. I'd take that outcome happily.

But notice that every one of those escape routes takes years to travel, and none of them helps the person who is on call the night the curves cross. The gap isn't "software ends." It's a decade where the muscle is gone, the prosthetic is expensive, and everything built during the cheap era still needs an adult. Transitions are where the damage happens. Nobody drowned in the sea level; they drowned in the flood.

Positioning for it

If you buy even half of this, the hedges are cheap and mostly unfashionable. If you're junior: use the tools — refusing them is career malpractice — but ring-fence real authoring time the way athletes lift weights they'll never lift in a match. Build something with the AI turned off, regularly, and let it hurt. You're not doing it for the output; you're doing it because in a market where nobody can do it by hand, being the person who can is the trade of the decade. Scarcity is a career strategy, and hand-authoring is on sale right now precisely because everyone thinks it's obsolete.

If you run a team: treat AI spend like debt, not income — it compounds, and the rate can change. Keep an exit ramp: know today which open-weight model plus which hardware covers 70% of your usage if the invoice doubles, because negotiating that migration during a price shock is how you end up paying anything. And keep giving humans work the machine could do — on purpose, as a training budget, not a productivity failure. The companies that cross the gap intact will be the ones that kept the skill alive in humans while it was economically irrational to do so.

I might be wrong about the prices. I hope I am. But between "the subsidy lasts forever" and "keep the muscle," only one of those is a bet I have to win.

Freelance ou CDI : ce que coder le simulateur m'a appris

Ali — Fri, 03 Jul 2026 12:00:00 +0000

Il y a une phrase que tout développeur salarié a entendue au moins une fois, souvent d'un ami qui vient de se lancer : « Tu passerais freelance, tu gagnerais le double. » Le calcul derrière est toujours le même — on prend un TJM, on le multiplie par le nombre de jours ouvrés dans l'année, et on compare le résultat à un salaire net. J'ai reçu la question assez de fois pour finir par coder freelance-ou-cdi.fr, un simulateur open-source qui fait le calcul pour de vrai. Voici ce que construire cet outil — et faire tourner mes propres chiffres dedans — m'a appris.

Le calcul naïf est faux dès la première ligne

« TJM × jours ouvrés » se trompe deux fois. D'abord parce qu'un TJM n'est pas un salaire : c'est un chiffre d'affaires. Entre les deux, il y a les cotisations sociales, et selon le statut — micro-entreprise, EI, EURL, SASU, portage — elles ne se calculent ni au même taux ni sur la même assiette. Ensuite parce que l'impôt sur le revenu s'applique par-dessus, et là encore le statut change tout : une SASU qui arbitre entre salaire et dividendes ne sera pas imposée comme un micro-entrepreneur au versement libératoire. Comparer un CA freelance à un salaire net, c'est comparer un prix hors taxes à un prix payé en caisse.

C'est la première chose que le simulateur impose : il ne s'arrête pas au brut. Il descend jusqu'au net réellement disponible, après cotisations et après impôt , pour chaque statut, et il affiche le TJM d'équilibre — le tarif journalier qu'il faut atteindre pour, une fois tout payé, égaler un salaire net donné. Pour être sûr que ces chiffres ne sortent pas de nulle part, les calculs sont validés par des tests automatisés contre modele-social, le moteur open-source publié par l'URSSAF elle-même. Quand mon résultat diverge du leur, c'est mon code qui a tort.

Vous ne facturez pas 218 jours

L'erreur la plus coûteuse n'est pas dans les charges, elle est dans le dénominateur. Une année compte environ 218 jours ouvrés, et l'intuition pousse à tous les facturer. Sauf que le freelance ne vend pas des jours ouvrés, il vend des jours facturés. Enlevez cinq semaines qui ressemblent à des congés payés — sauf qu'ici personne ne vous les paie. Enlevez l'intercontrat, ces creux entre deux missions où le compteur tourne à zéro. Enlevez la prospection, la comptabilité, les devis, la veille, la formation que plus aucun employeur ne finance à votre place.

En pratique, un freelance qui tourne bien facture autour de 200 jours, et beaucoup tournent plus bas la première année. Ça n'a l'air de rien, mais c'est une bascule : à 200 jours au lieu de 218, votre TJM doit déjà monter de près de 10 % rien que pour compenser le calendrier, avant même d'avoir parlé de cotisations. Le simulateur laisse régler ce nombre précisément, parce que c'est le paramètre qui déplace le plus la ligne d'équilibre — et c'est aussi celui que les comparaisons de comptoir oublient systématiquement.

Ce que le CDI donne sans le dire

Un salaire net, ce n'est pas qu'un montant sur une fiche de paie. C'est un revenu lissé — vous touchez la même somme le mois où vous êtes malade, celui où le projet est en pause, celui où vous partez trois semaines. C'est une assurance chômage si le poste s'arrête. C'est des congés payés, une part de mutuelle, une cotisation retraite prise à la source, un budget formation, parfois une participation ou un treizième mois. Et c'est zéro administratif : pas d'URSSAF à déclarer, pas de TVA à suivre, pas de relance d'un client qui paie à 60 jours.

Rien de tout ça n'est gratuit côté freelance : ça se rachète, en prévoyance, en mutuelle privée, en épargne de précaution pour tenir les creux, et en temps passé à gérer une micro-entreprise qui est aussi une vraie entreprise. Le simulateur ne chiffre pas votre tranquillité d'esprit, mais il rend visible la partie monétisable de cet écart — et elle est plus grande qu'on ne l'imagine tant qu'on ne l'a pas alignée en colonnes.

Le résultat qui m'a surpris

Une fois le calendrier réaliste et toutes les charges en place, le constat revient presque à chaque simulation : à séniorité équivalente, l'écart de net entre un bon CDI et un freelance correctement facturé est beaucoup plus faible que le « tu gagnerais le double » du départ. Pour égaler — pas dépasser, égaler — un CDI confortable de développeur à Paris, il faut un TJM nettement au-dessus de la simple division du salaire par les jours ouvrés, souvent de l'ordre d'un tiers de plus une fois les jours non facturés et les charges digérés. Le surplus tant vanté du freelance n'apparaît qu'au-dessus de ce seuil, et il paie d'abord le risque avant d'être du pouvoir d'achat.

Donc, freelance ou CDI ?

Le simulateur donne un chiffre, mais il ne donne pas la réponse, parce que la réponse n'est pas financière. Une fois l'écart d'argent ramené à sa vraie taille — modeste, à séniorité égale — la décision se joue ailleurs : votre tolérance au risque et aux mois sans revenu, votre appétence pour l'autonomie, et surtout votre capacité à trouver des missions , qui est le vrai métier caché du freelance. Quelqu'un qui déteste vendre et dort mal quand le compte baisse sera plus riche et plus heureux en CDI, même si la ligne « freelance » du tableau est un peu plus haute. L'inverse est vrai aussi.

C'est pour ça que l'outil est public et open-source : l'intérêt n'est pas que je vous donne ma réponse, c'est que vous fassiez tourner vos chiffres, avec votre salaire, votre TJM cible et votre nombre de jours honnête. Faites le calcul sur freelance-ou-cdi.fr ; et si vous voulez juste convertir vite un TJM en salaire équivalent dans un sens ou dans l'autre, le calculateur TJM ↔ salaire fait ça sans inscription. La bonne décision, c'est celle que vous prenez avec les vrais nombres sous les yeux — pas avec ceux du comptoir.

Crèche ou nounou : le vrai coût commence après les aides

Ali — Wed, 01 Jul 2026 12:00:00 +0000

Quand est venue la question du mode de garde, j'ai fait ce que je fais devant n'importe quelle décision à plusieurs milliers d'euros : j'ai ouvert un tableur. Le même réflexe que pour comparer un TJM freelance à un salaire — parce qu'en France, sur ce genre de sujet, le prix affiché ne veut presque rien dire. Entre le tarif que vous lisez et l'argent qui sort réellement de votre compte à la fin de l'année, il y a trois couches d'aides qui rebattent complètement les cartes. Voici le calcul honnête, et ce qu'il ne dit pas.

Trois options, trois logiques de coût

Les trois modes de garde classiques ne se comparent pas sur la même grille :

La crèche (collective, municipale ou associative) facture à un tarif indexé sur vos revenus, via le barème national de la CNAF (participation familiale). Deux familles n'y paient pas le même prix pour la même place.
L'assistante maternelle agréée (la « nounou » qui garde chez elle) est votre salariée : vous la payez au tarif horaire convenu, déclaré via Pajemploi, et vous ouvrez droit à une aide de la CAF.
La garde à domicile (chez vous) suit la même logique d'emploi direct, mais coûte plus cher — sauf en _garde partagée_entre deux familles, qui divise la facture.

Comparer leurs tarifs bruts, c'est comme comparer des TJM sans regarder les statuts : on additionne des choses qui ne se déduisent pas de la même manière.

La première couche : le CMG

Pour l'assistante maternelle et la garde à domicile, la CAF verse le Complément de libre choix du mode de garde (CMG), qui prend en charge une partie de la rémunération. Son montant dépend de vos revenus, de l'âge de l'enfant et du mode de garde. Point important : le CMG a été réformé pour être linéarisé — au lieu de trois tranches qui créaient des effets de seuil brutaux, l'aide décroît plus progressivement avec le revenu, ce qui a rapproché le reste à charge de l'assistante maternelle de celui de la crèche pour beaucoup de familles. La crèche, elle, ne touche pas de CMG : son « aide » est déjà intégrée dans le tarif indexé que vous payez.

La deuxième couche : le crédit d'impôt

Par-dessus le CMG s'ajoute le crédit d'impôt pour frais de garde : 50 % des dépenses restant à votre charge, dans la limite d'un plafond annuel par enfant. « Crédit » et non « réduction », la nuance compte — il vous est remboursé même si vous n'êtes pas imposable. Ce crédit s'applique au reste à charge après CMG pour l'emploi d'une assistante maternelle, et aux frais de crèche pour la crèche. C'est la couche que les comparaisons oublient le plus souvent, et c'est celle qui divise par deux le chiffre final.

L'ordre est donc toujours le même : prix affiché → moins le CMG (le cas échéant) → moins 50 % de crédit d'impôt sur ce qui reste. Le nombre auquel vous devez comparer les options, c'est le tout en bas de cette cascade, pas le tarif du haut.

Ce que le tableau a fini par montrer

Trois constats reviennent, une fois la cascade appliquée avec de vrais revenus :

La crèche est souvent la moins chère pour les revenus modestes , précisément parce que son tarif est indexé : plus le revenu est bas, plus la participation est faible.
L'assistante maternelle se rapproche de la crèche une fois le CMG et le crédit d'impôt déduits — l'écart réel est bien plus serré que les tarifs horaires bruts ne le laissent croire, surtout depuis la linéarisation du CMG.
La garde à domicile reste la plus coûteuse en solo ; en partagée, elle redevient compétitive, au prix d'une organisation à deux familles.

Autrement dit : le classement par prix affiché et le classement par reste à charge réel ne sont pas le même classement. C'est exactement le piège que j'avais déjà vu en comparant des statuts freelance — le brut ment, le net décide.

Ce que le tableau ne chiffre pas

Et c'est là que, comme pour le freelance, l'argent cesse d'être le critère décisif. Plusieurs choses ne rentrent dans aucune cellule :

Les horaires. Une crèche ferme à heure fixe et vous attend rarement ; une assistante maternelle offre une souplesse que les parents aux journées imprévisibles paient volontiers.
Les maladies. La collectivité, c'est des microbes à répétition les premiers mois, donc des absences — les vôtres, au travail. À l'inverse, une nounou est un point de défaillance unique : le jour où elle est malade, vous n'avez pas de solution de repli.
La socialisation en collectivité contre le cocon d'un petit effectif : ni l'un ni l'autre n'est « mieux » dans l'absolu, ça dépend de l'enfant et de ce que vous cherchez.
La disponibilité. Le plus beau tableau ne sert à rien si les crèches de votre secteur affichent complet — la place réelle, souvent, décide à votre place.

La méthode, plus que la réponse

Je ne vais pas vous dire quel mode de garde choisir : comme pour freelance ou CDI, la réponse dépend de vos revenus, de vos horaires et de votre tolérance à l'imprévu. Ce qui se transpose, c'est la méthode. Calculez votre reste à charge net après aides pour chaque option — prix affiché, moins CMG, moins crédit d'impôt — avec vos propres chiffres et les barèmes en vigueur. Puis, une fois l'écart d'argent réduit à sa vraie taille, tranchez sur le non-financier : horaires, robustesse, place disponible. En France, sur presque toutes ces décisions, le prix affiché n'est jamais le vrai nombre. Le vrai nombre est plus bas, plus intéressant, et il ne se révèle qu'à celui qui prend la peine de dérouler la cascade.

One builder line and my rebuilds stopped being coffee breaks

Ali — Tue, 30 Jun 2026 12:00:00 +0000

There's a category of performance work where you profile, hypothesize, measure, and claw back milliseconds. And then there's the other kind: someone else rewrote the engine, and you just have to move over. The esbuild-based application builder is the second kind. New Angular apps have used it by default since v17; the interesting story is migrating an old app that grew up on webpack.

The headline from the app I migrated — five years old, thick with legacy — is blunt: cold production builds went from "start it and go do something else" to under a minute, and the dev server's incremental rebuilds dropped from double-digit seconds to fast enough that I stopped alt-tabbing. I did not optimize anything. I changed which tool builds the app.

The migration is one command

ng update @angular/cli --name=use-application-builder

The schematic rewrites angular.json from browser to application, flips main to browser, adjusts output paths, and leaves the rest of your configuration alone. Most of what you already declare transfers untouched: fileReplacements, the styles and scripts arrays, assets, size budgets. If your app is plain — no custom builders, no webpack fiddling — there's a decent chance you run the schematic, run ng serve, and you're done. Mine was not plain.

Casualty #1: the custom webpack config

If you're on ngx-build-plus or @angular-builders/custom-webpack, this is the part that stings: there is no "custom esbuild config" escape hatch of the same shape. Each thing your webpack config did needs its own esbuild-era answer. Going through mine turned out to be an archaeology dig — and most of the artifacts deserved burial:

A DefinePlugin injecting build-time constants — replaced by the builder's define option. One-to-one.
A loader shim for a library that assumed Node globals — the library had shipped a browser build two majors ago. Deleted the shim, updated the import.
A bundle-analyzer hook — ng build --stats-json plus esbuild-visualizer covers it.

The lesson generalizes: a years-old webpack config is mostly fossilized workarounds. Treat the migration as a chance to re-justify each line, not to port it.

Casualty #2: CommonJS gets loud

The new builder outputs ESM and is much less patient with CommonJS dependencies. Every CJS import now triggers a warning, and the old reflex — add it to allowedCommonJsDependencies and move on — costs you real money here, because CJS modules defeat tree-shaking. The warnings are a to-do list, and working through it is where the bundle wins hide: swapping one dinosaur date library for its ESM successor cut more from my main bundle than any lazy-loading work I'd done that quarter. Relatedly: if any app code still calls require() directly, it's over — output is ESM, imports only.

What you get beyond speed

The builder isn't just esbuild bolted on. Dev serve runs through Vite, which is where the instant rebuilds come from. SSR stopped being a parallel universe: the same application builder handles the server bundle and prerendering via the server and prerender options, instead of the old Universal two-builder contraption. And build output is properly hashed and code-split without the tuning folklore webpack accumulated.

The order of operations that worked

One process note, learned the annoying way: don't migrate the builder and update Angular majors in the same branch. First get the app green on a current Angular with the old builder — that isolates framework breakage from build breakage. Then flip the builder, with zero other changes, so every new error is unambiguously the builder's. Then burn down the CommonJS warnings at leisure. Three boring PRs beat one heroic one.

Verdict: this is the rare migration with an asymmetric payoff — a day or two of tooling archaeology, repaid every single time anyone on the team saves the file. If the only thing holding you back is a custom webpack config, that config is probably the strongest argument for going.

My route changes crossfade now, and I wrote zero animation code

Ali — Sun, 28 Jun 2026 12:00:00 +0000

Page-transition animations in Angular used to mean the full @angular/animations liturgy: a trigger on the router outlet, query(':enter') and query(':leave') incantations, absolute-positioning both pages during the overlap so the layout doesn't jump, and a prayer. I shipped exactly one of those in my career, and I remember the CSS more than the feature.

The browser can just do this now. The View Transitions API snapshots the old DOM, swaps in the new one, and animates between the two snapshots on the compositor. Angular's router plugs into it with one flag:

provideRouter(
  routes,
  withViewTransitions(),
)

That's the whole baseline. Every navigation is now wrapped in document.startViewTransition(), and you get a quick crossfade between routes without touching a single component. In a browser without the API, the call is skipped and navigation behaves exactly as before — no fallback branch to write, no feature detection. It is progressive enhancement in the original sense of the term.

The shared-element trick

The crossfade is nice; the morph is the party piece. Give an element on the outgoing page and an element on the incoming page the same view-transition-name, and the browser animates one into the other — position, size, the lot:

/* list page */
.product-card__image { view-transition-name: product-hero; }

/* detail page */
.product-detail__hero { view-transition-name: product-hero; }

Click a card, and its thumbnail glides into place as the detail hero. This is the effect native apps have lorded over the web for a decade, and it's two lines of CSS. One rule to respect: a view-transition-name must be unique on the page at transition time. For a list of cards that means assigning the name dynamically to the clicked card only — bind a style on click, or you'll get a console warning and no animation.

Customizing without an animation library

The snapshots are exposed as pseudo-elements, so the timing and easing are plain CSS:

::view-transition-old(root) {
  animation: 150ms ease-out both fade-slide-out;
}
::view-transition-new(root) {
  animation: 200ms ease-in both fade-slide-in;
}

Slide-ins, directional wipes, staggered headers — it's keyframes on pseudo-elements, not a TypeScript DSL. The root argument targets the whole page; named transitions get their own pair.

Skipping when you should

Two navigations deserve no theatrics: back/forward (users expect instant), and anything under prefers-reduced-motion. The router hands you the hook:

withViewTransitions({
  onViewTransitionCreated: ({ transition }) => {
    const reduced =
      matchMedia('(prefers-reduced-motion: reduce)').matches;
    if (reduced) transition.skipTransition();
  },
})

skipTransition() aborts the animation but not the navigation. Reduced motion isn't a nice-to-have flourish — vestibular users report actual nausea from full-page movement, so treat the media query as a contract.

The honest caveats

First, support: Chromium and Safari have it; if a visitor's browser doesn't, they get an ordinary instant navigation — acceptable by design. Second, the API snapshots the page, and on a very long, very busy DOM that snapshot isn't free; if a route is heavy, a janky transition is worse than none, and skipTransition() is your friend. Third, don't mix systems: router-outlet animations from @angular/animations and view transitions both want to own the same moment, and they fight. I deleted the old trigger entirely. The browser compositor does this job better than a JavaScript animation engine ever did — and the code I got to remove was exactly the code I never wanted to maintain.

hostDirectives ended my BaseComponent inheritance

Ali — Fri, 26 Jun 2026 12:00:00 +0000

Somewhere in every mature Angular codebase there is a BaseButtonComponent. It started innocently — shared disabled handling, maybe a loading spinner. Then someone added analytics to it. Then keyboard handling. Then a BaseIconButtonComponent extends BaseButtonComponent, and now there's a class four levels up the chain that nobody can modify without re-testing thirty components, because inheritance gives you everything your ancestors ever did, forever, whether you wanted it or not.

The directive composition API is Angular saying: stop inheriting behaviors, apply them.

@Component({
  selector: 'app-save-button',
  hostDirectives: [
    DisabledStateDirective,
    {
      directive: TooltipDirective,
      inputs: ['tooltipText: hint'],
    },
  ],
  template: '...',
})
export class SaveButtonComponent {}

SaveButtonComponent now behaves as if DisabledStateDirective and TooltipDirective were written on its host element by every consumer, automatically. Each behavior lives in its own small, individually testable directive. No chain, no god-class.

Inputs and outputs are private by default

This is the design decision I appreciate most. A host directive's inputs and outputs are not exposed on the component unless you list them. In the example above, DisabledStateDirective might have inputs of its own, but consumers of app-save-button can't see them; the tooltip's tooltipText input is exposed, renamed to hint. Compare that to inheritance, where every @Input up the chain leaks into your public API and removing one is a breaking change you don't discover until a template somewhere fails to compile. With composition, your component's surface is a deliberate allowlist.

They share the host's DI node

Host directives are instantiated alongside the component, on the same element injector. Which means the component can just ask for them:

export class SaveButtonComponent {
  private disabled = inject(DisabledStateDirective);

  save() {
    if (this.disabled.isDisabled()) return;
    // ...
  }
}

The directive holds the state and the host-element bindings; the component reads it through DI. This is the same relationship a base class gave you via this.isDisabled, except the dependency is explicit, mockable in a test, and swappable. It also works the other way — the directive can inject the host component when it genuinely needs to — though every time I've been tempted by that direction it was the design telling me the directive knew too much.

The sharp edges

Three constraints, all consequences of host directives being a compile-time feature. The directives must be standalone — NgModule-declared ones don't qualify. Application is static: you cannot conditionally attach a host directive at runtime, so if a behavior should sometimes be inert, put the condition inside the directive (an input that gates its listeners) rather than trying to gate its application. And the same directive reaching one host via two paths — say, directly and through another host directive that also applies it — is a compile error, not a silent double application.

Ordering is worth knowing too: host directives' lifecycle hooks run before the host component's own, in the order they're listed. Their host bindings are applied first as well, which lets the component win when both write the same attribute — usually what you want, occasionally a surprise when it isn't.

Where it changed my defaults

The pattern that sold me was aria wiring. We had accessibility logic — role, aria-disabled, keyboard activation on Space/Enter — copy-pasted across a dozen interactive components because putting it in a base class would have forced unrelated widgets into one hierarchy. It's one directive now. Each widget adds it to hostDirectives, exposes nothing, and the behavior has one home and one test file. Inheritance answers "what is this component?" with an ancestry; composition answers with a parts list. For UI behaviors, the parts list is almost always the truthful answer.

My dashboard renders components it has never met

Ali — Wed, 24 Jun 2026 12:00:00 +0000

The requirement sounds exotic until the day it lands on your sprint: the server sends a JSON layout — a list of widget descriptors — and the app has to render whatever comes back. A chart here, a KPI tile there, a table if the user configured one. The template can't @if its way through this, because the template doesn't know the shape. The component type itself is data.

If your memory of dynamic components involves ComponentFactoryResolver, entry components, and a ceremony that felt like summoning something, good news: all of that is gone. The factory resolver was removed back in v13. What's left is almost embarrassingly small.

@Component({ /* ... */ })
export class DashboardComponent {
  private host = viewChild.required('slot', { read: ViewContainerRef });

  renderWidget(descriptor: WidgetDescriptor) {
    const ref = this.host().createComponent(WIDGETS[descriptor.type]);
    ref.setInput('config', descriptor.config);
    return ref;
  }
}

createComponent takes the component class. Directly. The registry WIDGETS is a plain object mapping descriptor types to imported classes. That's the entire trick.

setInput is not optional

The mistake that costs an afternoon: setting inputs by assigning to the instance. ref.instance.config = descriptor.config compiles, appears to work in a demo, and then betrays you twice in production. Under OnPush, a bare property assignment doesn't mark the component for check, so the widget renders stale. And if the widget uses signal inputs — config = input.required<WidgetConfig>() — the instance property isn't even writable that way.

ref.setInput('config', value) is the API that goes through the front door: it sets the input the same way a template binding would, marks for check, and works identically for decorator inputs and signal inputs. It's also what makes re-rendering on config change trivial — call it again with the new value instead of destroying and recreating the widget.

Outputs and cleanup

Outputs are just there on the instance. With the modern output() function they expose subscribe directly:

const ref = this.host().createComponent(ChartWidget);
const sub = ref.instance.pointSelected.subscribe((p) => {
  this.openDetail(p);
});

Cleanup has one rule worth memorizing: a component created into a ViewContainerRef is part of that view tree, so when the container's host dies, your dynamic components die with it. You only call ref.destroy() yourself when a widget is removed while the dashboard lives on — user deletes a tile, layout reloads. Forgetting that case leaks the component and its subscriptions; I register the output subscription with DestroyRef or tie it to the ref's own destruction so the two can't drift apart.

NgComponentOutlet, for when the template should decide

A surprising number of "dynamic component" cases don't need any of the imperative machinery. If you just need render this type with these inputs in a template position:

@for (w of widgets(); track w.id) {
  <ng-container
    [ngComponentOutlet]="registry[w.type]"
    [ngComponentOutletInputs]="w.config"
  />
}

ngComponentOutletInputs (since v16.2) does the setInput dance for you, including diffing the object between checks. No ViewContainerRef, no refs to track, no manual destroy — the @for owns the lifecycle. I reach for the imperative API only when I need the ComponentRef itself: subscribing to outputs, calling methods on the instance, moving it between containers.

When not to do any of this

The boundary that keeps a codebase sane: dynamic instantiation is for when the component type arrives as data. If the set of possibilities is known at build time and you're choosing based on state, a @switch over the cases — or @defer if the goal is loading less upfront — is simpler, type-checked against actual inputs, and friendlier to the optimizer. A registry object holding component classes makes every one of them eagerly-bundled and invisible to template type checking; setInput('confg', ...) is a runtime error, not a compile error. I've seen a plugin architecture built where three @if branches would have done. The JSON-driven dashboard genuinely needs this machinery. Most screens don't — and now that the machinery is this small, the temptation to use it everywhere is the real danger.

My star-rating widget is a real form control now

Ali — Sun, 21 Jun 2026 12:00:00 +0000

Every custom input widget reaches the same fork in the road. The team builds a star rating, or a tag picker, or a duration field. It works. Then someone tries to drop it into an existing reactive form — formControlName="rating" — and it does nothing, so they "solve" it with a value input, a valueChange output, and a subscription gluing the two to the form in the parent. Multiply by every form the widget appears in, and validators, dirty tracking and disabling all live somewhere else, reimplemented, badly.

ControlValueAccessor is the actual answer: the interface Angular's own <input> directives implement behind the scenes. Implement it, and your component plugs into formControlName, formControl and ngModel like it was born there.

The contract is four methods

@Component({
  selector: 'app-star-rating',
  providers: [{
    provide: NG_VALUE_ACCESSOR,
    useExisting: forwardRef(() => StarRatingComponent),
    multi: true,
  }],
  template: '...',
})
export class StarRatingComponent implements ControlValueAccessor {
  readonly value = signal(0);
  readonly disabled = signal(false);

  private onChange: (v: number) => void = () => {};
  private onTouched: () => void = () => {};

  writeValue(v: number | null) { this.value.set(v ?? 0); }
  registerOnChange(fn: (v: number) => void) { this.onChange = fn; }
  registerOnTouched(fn: () => void) { this.onTouched = fn; }
  setDisabledState(d: boolean) { this.disabled.set(d); }

  rate(stars: number) {
    if (this.disabled()) return;
    this.value.set(stars);
    this.onChange(stars);
    this.onTouched();
  }
}

Read it as two directions of traffic. writeValue is the form talking to you: initial value, setValue, reset. The two registered callbacks are you talking to the form: onChange when the user changes the value, onTouched when they've interacted enough that blur-style validation should wake up. The NG_VALUE_ACCESSOR provider — multi: true, forwardRef because the class isn't defined yet at decorator evaluation — is how the formControlName directive sitting on your tag finds you. Internal state as a signal is my one modernization: the template gets clean reactive reads, and nothing about the CVA contract objects.

The three bugs everyone ships

Silent touched state. Forgetting onTouched is invisible in the demo and obvious in production: any error message gated on control.touched — which is the convention almost every form uses — never appears for your widget. Call it on blur, or on first interaction if your control has no meaningful blur.

Ignoring setDisabledState. form.disable() reaches your component exclusively through this method. Skip it and your widget stays merrily clickable inside a disabled form — worse than a compile error because nobody tests disabling until a submit button starts double-firing.

The echo loop. writeValue must update internal state silently. If it calls onChange — directly, or indirectly because your setter fires the same path user interaction does — then every programmatic setValue bounces back into the form model. Best case it re-runs validators and marks the form dirty from a non-user change; worst case, with value normalization in the middle, it ping-pongs forever. Keep the paths separate: writeValue writes the signal; rate() writes the signal and reports.

When CVA is the wrong tool

The ceremony earns its keep when the component owns a genuinely non-input interaction model — stars, chips, a canvas signature pad. If your "custom control" is a styled wrapper around native inputs (a labeled input with an icon, an address group), you don't need a value accessor; pass the FormControl in as an input, or reach for ControlContainer injection so child and parent share the form group. I've reviewed CVAs wrapping a single <input> that re-forwarded every event by hand — forty lines that replaced zero.

But when it fits, it's one of Angular's best contracts: the day our star rating became a real control, three components deleted their glue subscriptions, validation messages started appearing on blur like everywhere else, and the widget stopped being special. That's the goal — not a clever component, an unremarkable one.

disabled finally means disabled: input transforms

Ali — Fri, 19 Jun 2026 12:00:00 +0000

Here's a bug that has existed in every Angular design system I've touched. You build a button with a boolean input, someone uses it the way HTML has trained them to for thirty years:

<app-button disabled>Save</app-button>

And the button stays clickable. Because without brackets that's not a boolean binding — it's a static attribute, and static attributes bind the string "". Even better: disabled="false" passes the string "false", which is truthy, so the button that was told false renders disabled. The type system said boolean; the DOM had other plans.

For years the workaround was the coercion ritual — a getter/setter pair with coerceBooleanProperty from the CDK on every single boolean input, eight lines of ceremony per flag, so pervasive that the CDK shipped BooleanInput types just to annotate the pattern. The framework finally absorbed the ritual:

export class ButtonComponent {
  disabled = input(false, { transform: booleanAttribute });
  tabIndex = input(0, { transform: numberAttribute });
}

A transform is a function that runs on every value the input receives, before it lands. booleanAttribute implements the HTML attribute semantics you actually wanted: absent is false, present-but-empty is true, and real booleans pass through. numberAttribute does the string → number conversion, so tabindex="3" from a template arrives as the number 3. Both work identically on decorator inputs — @Input({ transform: booleanAttribute }) — if you're not on signal inputs yet.

The type-level trick

The clever part is that a transform splits the input's type in two. The template side may now pass string | boolean — the template type checker knows about the transform and accepts disabled, disabled="false" and [disabled]="expr" alike. The class side reads a clean boolean, always, because everything funnels through the coercion. Write-type and read-type diverge, and both are checked. That's the exact contract the getter/setter pattern was hand-rolling, now expressed in one option and visible to the compiler.

Custom transforms

The built-ins cover the attribute cases; the option takes any function of the right shape:

function trimmed(v: string | null | undefined): string {
  return (v ?? '').trim();
}

export class SearchBoxComponent {
  query = input('', { transform: trimmed });
}

Normalizing whitespace, clamping a number into a range, defaulting null to a sentinel — anything that answers "what shape should this value have once it's mine." The constraint to respect: the transform must be a standalone, statically analyzable function. A top-level function or a static method works; an inline arrow that closes over this does not, and the compiler will tell you so. Transforms also run on every write, including setInput from dynamic-component code, so keep them cheap and pure — a transform with side effects is an input that changes behavior depending on how often change detection looked at it.

Normalization, not validation

The temptation once you have a function hook is to validate in it — throw on out-of-range, reject bad enum strings. Resist. A throw inside a transform surfaces as a change-detection error pointing vaguely at the parent template, which is miserable error locality for the consumer. Transforms are for making sloppy-but-well-meaning input shapes correct ("3" → 3); actual invariants belong where failures can be reported properly — a computed() that clamps, an effect that warns in dev mode, a form validator.

It's a small feature. It deleted more lines from our component library than any small feature has a right to — and it closed the gap between how our components claimed to be used and how HTML users were always going to use them. <app-button disabled> does what it says now. It only took a decade.

I deleted my CanActivate classes and my routing got readable

Ali — Wed, 17 Jun 2026 12:00:00 +0000

For years a route guard meant a class: @Injectable, implements CanActivate, a constructor full of services, and an entry in some providers array you'd inevitably forget. The guard was usually four lines of actual logic wrapped in twenty lines of ceremony. Functional guards deleted the wrapper, and the same inject() move that cleaned up interceptors did it again here.

export const authGuard: CanActivateFn = (route, state) => {
  const auth = inject(AuthService);
  const router = inject(Router);
  return auth.isLoggedIn() || router.createUrlTree(["/login"], {
    queryParams: { returnUrl: state.url },
  });
};

That's the whole thing. No class, no provider registration — you reference the function directly in the route. But the syntax win is the boring part. The interesting part is that going functional made the three jobs guards do finally feel like three different tools instead of one overloaded interface.

Return a UrlTree, not false

The most common guard bug I find in review isn't a logic error — it's a guard that returns false. Returning false cancels the navigation and leaves the user exactly where they were, with no explanation. They clicked a link, nothing happened, and now they think the app is broken. Half the time they're sitting on a blank shell because the click came from a fresh page load.

Returning a UrlTree is almost always what you meant: it cancels the original navigation and redirects in one step. Blocked from a page → send them to /login with a returnUrl so you can bounce them back after they sign in. The rule I use: a guard should either say yes, or say where to go instead. false is for the rare case where staying put with a toast is genuinely the right UX, and even then I'd rather show the toast and redirect.

canActivate vs canMatch — they answer different questions

These get used interchangeably and they shouldn't be. canActivate asks "this route matched the URL — is the user allowed to land on it?" It runs after the router has picked the route. canMatch asks the earlier question: "does this route even apply?" It runs during route matching, before the component is chosen.

That timing difference is the whole point. With canMatch you can have two routes for the same path and let the guard decide which one wins:

const routes: Routes = [
  { path: "dashboard", component: AdminDashboard, canMatch: [isAdmin] },
  { path: "dashboard", component: UserDashboard },
];

Admins match the first route, everyone else falls through to the second. You can't express that with canActivate — by the time it runs, the route is already locked in. The other canMatch superpower: on a lazy route, a failed canMatch means the chunk never even downloads. Guarding a whole admin feature behind canActivate still ships its JavaScript to anonymous visitors; canMatch keeps it on the server.

Small guards compose; god-guards don't

Because canActivate takes an array, I stopped writing guards that check three things and started writing three guards that check one thing each:

{ path: "billing", component: Billing,
  canActivate: [isLoggedIn, hasBillingRole, orgIsActive] }

They run in order and the first one to return a UrlTree wins, so the redirects naturally prioritize: not logged in beats wrong role beats suspended org. Each guard is independently testable and reusable across routes. A single guard doing all three reads fine the day you write it and becomes a tangle of nested conditions the third time someone adds a rule.

Resolvers: powerful, and the easiest way to make your app feel frozen

ResolveFn got the same functional treatment, and it's genuinely useful — but it's the guard-family tool I reach for least, on purpose. A resolver fetches data before the route activates, so the component renders with everything already present. No loading spinner inside the page, no flash of empty state.

export const orderResolver: ResolveFn<Order> = (route) => {
  const id = route.paramMap.get("id")!;
  return inject(OrderService).getOrder(id);
};

The catch is in that word "before." Navigation blocks on the resolver. If the API takes two seconds, clicking the link does nothing visible for two seconds — the user is stuck on the previous page with no feedback. You've moved the loading state from "a spinner on the new page" to "the entire app appears to hang." If you use resolvers, you almost have to wire a progress bar to the router's NavigationStart/NavigationEnd events, or the UX is worse than just fetching in the component.

So my line is: a resolver earns its place when the page is genuinely meaningless without the data — an order detail page with no order isn't a page, it's a 404 waiting to happen, and resolving lets you redirect on a missing record before anything renders. For everything else, fetching in the component with httpResource gives you the same data with an honest, local loading state and no global freeze.

The decision rule

Deciding whether the route applies, or want to skip downloading a lazy chunk → canMatch. Deciding whether this user may enter a route that does apply → canActivate, returning a UrlTree when the answer is no. The page is structurally meaningless without server data, and you've got a progress indicator → ResolveFn. Otherwise, let the component fetch its own data. All three are just functions now, which means all three are just unit tests now too.

My route params bind straight to inputs now

Ali — Tue, 16 Jun 2026 12:00:00 +0000

Here's a pattern every Angular dev has typed a hundred times: a component needs the :id from the URL, so you inject ActivatedRoute, subscribe to paramMap, pull the value, remember to unsubscribe, and handle the fact that the component is reused when only the id changes so ngOnInit won't fire twice. Six lines of plumbing to read one string off the URL.

withComponentInputBinding() deletes all of it. You turn it on once:

bootstrapApplication(App, {
  providers: [provideRouter(routes, withComponentInputBinding())],
});

and now the router sets your component's inputs from the route, matched by name. A route param :id binds to an input called id. That's the entire mental model.

@Component({ /* ... */ })
export class OrderDetail {
  id = input.required<string>(); // <- comes straight from :id
}

Four sources feed the same inputs

It's not just path params. The router binds from four places, and once you know all four you stop reaching for ActivatedRoute almost entirely: resolved data and static data on the route, path params (:id), matrix params, and query params (?tab=invoices). A search page reads its filters as inputs; a wizard reads its step; a detail page reads its id. All by name, all without a subscription.

The one thing you have to internalize is precedence, because all four write to the same input slots. If the same key exists in more than one source, resolved/static data wins, then path params, then query params. The practical consequence: don't name a query param the same thing as something in your resolver data, or the data value silently shadows it and you'll swear the query param "isn't binding." Give colliding things distinct names and the whole feature stays predictable.

The real payoff is signal inputs

Input binding is nice on its own, but combined with input() signals it changes how route-driven components are written. The route param isn't a value you grabbed in ngOnInit — it's a signal that updates when the URL changes. Which means you can derive from it and the reactive graph handles the rest:

id = input.required<string>();

// re-runs automatically when the URL id changes — no subscription,
// no ngOnChanges, no manual refetch
order = httpResource(() => `/api/orders/${this.id()}`);

Navigate from order 7 to order 8 and the component instance is reused, the id signal flips to "8", and httpResource refetches because its url depended on id(). The "component reuse won't re-run my init" problem — the one that sent everyone subscribing to paramMap in the first place — just isn't a problem anymore, because nothing was keyed on a lifecycle hook to begin with.

Where it stops, and that's fine

Two honest limits. First, it binds to the routed component — the one named in the route config. A deeply nested child that wants the parent route's params still reads ActivatedRoute, or you pass them down as inputs yourself. Second, this is a router feature, not magic on every component; a component you drop into a template the normal way gets its inputs from the template, as always.

I treat ActivatedRoute the way I now treat ngOnDestroy: still there, occasionally necessary, but no longer the default reflex. For the common case — a routed component that wants a value off the URL — the value just arrives as an input, and if it's a signal input, it stays correct on its own.

SignalStore is the first NgRx I'd actually reach for

Ali — Mon, 15 Jun 2026 12:00:00 +0000

I've spent a good chunk of my career talking teams out of NgRx. Not because the Redux pattern is wrong — because most apps that adopted it didn't have a Redux-shaped problem. They had a "two components need the same list" problem, and they paid for it with an action, a reducer case, an effect, a selector, and three files, per feature. The ratio of ceremony to value was brutal.

SignalStore is the first time the NgRx name has shown up in my projects without me wincing. It throws out the dispatch/reducer machinery and builds on signals directly. State is signals you read; methods are functions that change them. That's the model.

export const CartStore = signalStore(
  { providedIn: "root" },
  withState({ items: [] as Item[], loading: false }),
  withComputed(({ items }) => ({
    count: computed(() => items().length),
    total: computed(() => items().reduce((s, i) => s + i.price, 0)),
  })),
  withMethods((store) => ({
    add(item: Item) {
      patchState(store, { items: [...store.items(), item] });
    },
    clear() {
      patchState(store, { items: [] });
    },
  })),
);

count and total are signals. add and clear are methods. A component injects the store and reads store.count() in its template like any other signal. No store.select(...), no string action types, no switch statement. The thing that used to be five concepts is now two: withState and withMethods.

patchState, and the immutability you can't skip

You never assign to state directly — you call patchState with a partial update or an updater function. And the array spread in add above isn't optional styling: SignalStore state follows the same rule signals always do. Mutating the existing array in place (items().push(item)) changes the contents without changing the reference, so the signal never fires and your computed count goes stale. Treat state as immutable, produce new references, and the reactive graph stays honest. This is the one rule that trips people coming from the mutate-anything world.

rxMethod is where the async lives

Real stores fetch. rxMethod is the bridge to RxJS for exactly that — it takes a stream of inputs and lets you run an Observable pipeline per emission, with proper cancellation:

loadItems: rxMethod<string>(
  pipe(
    tap(() => patchState(store, { loading: true })),
    switchMap((cartId) =>
      cartService.fetch(cartId).pipe(
        tapResponse({
          next: (items) => patchState(store, { items, loading: false }),
          error: () => patchState(store, { loading: false }),
        }),
      ),
    ),
  ),
)

The switchMap there is doing the work an NgRx effect used to: a second call cancels the first in-flight request, so a fast-typing user doesn't race two responses into your state out of order. This is the spot where the "signals killed RxJS" crowd gets corrected — streams are still the right tool for events over time, and SignalStore is happy to let them feed the signals. It's the same boundary as everywhere else in modern Angular: signals hold state, streams describe the async.

The decision that actually matters: where you provide it

providedIn: "root" gives you one global instance — right for genuinely app-wide state like the cart or the current user. But you can also leave that out and list the store in a component's providers array. Now you get a fresh instance scoped to that component and its children, created when the feature mounts and destroyed when it unmounts. State that belongs to one screen lives and dies with that screen, no manual reset.

This is the call I see teams get wrong most often. They make every store global, then write cleanup code to wipe stale feature state on every navigation — reinventing component scope by hand. If the state is "this page's state," scope it to the page. If it's "the app's state," put it in root. withEntities is worth knowing for the collection cases — it gives you normalized add/update/remove over an entity map so you're not hand-rolling the same dictionary logic again.

Do you even need it?

Honest answer: often not. A plain @Injectable service holding a few signal()s and exposing computed() getters covers a surprising amount of shared state, and it's the lighter choice for a single feature with simple needs. SignalStore earns its dependency when you want conventions a team will follow without a meeting — a predictable shape for every store, async that's already cancellation-safe, and withEntities/custom withX features you can compose and reuse across stores.

The way I'd put it: plain signals service is the answer until you find yourself reinventing the same store skeleton for the fourth time. At that point SignalStore is the skeleton, already written, and unlike the NgRx of five years ago it doesn't make you pay for a Redux you don't have.