Attributes vs Directives
Plain HTML attributes set static values; directives are framework instructions that hook into the render lifecycle and change behavior. They aren't interchangeable — directives are attributes with a brain.
The short answer
Directives over Attributes for most cases. Attributes describe; directives do.
- Pick Attributes if writing static markup, setting ARIA/data-* values, or passing literal config that never changes at runtime. Attributes are simpler, cheaper, and don't drag in a framework
- Pick Directives if need behavior — *ngIf/v-if, *ngFor/v-for, two-way binding, or reusable DOM logic you want to attach declaratively across many elements. This is 90% of real app work
- Also consider: They coexist by design. Bindings (Angular's [attr.x], Vue's :attr) are the bridge — a directive that writes an attribute. Don't pit them against each other in the same line of code; know which layer you're operating on.
— Nice Pick, opinionated tool recommendations
What they actually are
An HTML attribute is a static key/value baked into markup: class="btn", href="/x", data-id="7". The browser reads it once at parse time and that's the end of the story. A directive is a framework construct — Angular's ngFor, ngClass, or a custom @Directive; Vue's v-if, v-model, or a custom directive — that looks like an attribute but is actually a hook the compiler wires into the component lifecycle. It can read component state, mutate the DOM, attach listeners, and re-run on every change-detection cycle. The visual similarity is deliberate and also the source of every junior's confusion: anything with a leading or v- or [] isn't a passive label, it's executable intent. Attributes are nouns. Directives are verbs wearing a noun's clothes.
Where attributes win
Attributes are unbeatable when nothing changes. Setting role, aria-label, tabindex, data-testid, or a literal id needs zero machinery — no framework, no compiler, no re-render. They're declarative, inspectable in DevTools exactly as written, and free. There's also a correctness angle people miss: some things MUST be real attributes, not DOM properties — SVG attributes, ARIA, and custom data-* only exist in the attribute namespace, which is why frameworks ship escape hatches like Angular's [attr.aria-label] or Vue's :aria-label to force an actual attribute write. If you reach for a directive to stamp a constant onto an element, you've added a change-detection dependency to do a job a six-character attribute did better. Don't gold-plate static markup. Use the plain attribute and move on.
Where directives earn their weight
The moment your DOM depends on state, attributes are dead weight and directives take over. ngIf/v-if add and remove elements from the tree. ngFor/v-for materialize lists. ngModel/v-model wire two-way binding without you writing event plumbing. ngClass/ngStyle toggle presentation reactively. And the real payoff is custom directives: cross-cutting DOM behavior — autofocus, click-outside, tooltips, intersection observers, drag handles — packaged once and attached declaratively to any element, no wrapper component, no copy-paste. That's reuse attributes physically cannot express, because attributes can't run code. The cost is real: directives carry framework lock-in, a learning curve, and a debugging surface (structural directives quietly rewriting the tree trip up everyone once). But that cost buys behavior, and behavior is the entire reason you adopted a framework instead of shipping a static HTML file.
The verdict, no hedging
This isn't a fair fight and pretending it is wastes your time. Attributes and directives operate on different layers: attributes are the static substrate, directives are the dynamic layer your framework built on top of it. You will use both in every component you write — a real attribute for the constant, a directive for the behavior, and a binding (Angular [attr.x], Vue :x) as the seam between them. But if the question is which one defines modern frontend work, it's directives, decisively. They're the superset. Everything an attribute does, a binding-as-directive can do dynamically; nothing an attribute does reaches conditional rendering, loops, or reusable DOM logic. Master attributes in an afternoon. Spend the rest of your career getting directives right. Pick directives — and stop using one where a plain attribute would've done.
Quick Comparison
| Factor | Attributes | Directives |
|---|---|---|
| Dynamic behavior | None — static value set once at parse time | Full lifecycle hooks, reactive re-rendering, DOM mutation |
| Cost / simplicity | Free, zero framework, inspectable as written | Carries framework lock-in and a learning curve |
| Reusable DOM logic | Impossible — attributes can't run code | Custom directives package behavior, attach anywhere |
| Conditional rendering & loops | Not supported at all | *ngIf/v-if, *ngFor/v-for are the core use case |
| Required for ARIA/SVG/data-* | Native namespace — the only correct home | Must use [attr.x]/:x bindings to force a real attribute |
The Verdict
Use Attributes if: You're writing static markup, setting ARIA/data-* values, or passing literal config that never changes at runtime. Attributes are simpler, cheaper, and don't drag in a framework.
Use Directives if: You need behavior — *ngIf/v-if, *ngFor/v-for, two-way binding, or reusable DOM logic you want to attach declaratively across many elements. This is 90% of real app work.
Consider: They coexist by design. Bindings (Angular's [attr.x], Vue's :attr) are the bridge — a directive that writes an attribute. Don't pit them against each other in the same line of code; know which layer you're operating on.
Attributes describe; directives do. Once you need anything dynamic — conditional rendering, loops, reusable DOM behavior, two-way binding — attributes run out of road and you reach for a directive. Directives are the superset that makes modern component frameworks usable. Attributes are the floor; directives are the building.
Related Comparisons
Disagree? nice@nicepick.dev