DEV Community: Alexander Nenashev

A Declarative Naming Layer for the View Transition API

Alexander Nenashev — Tue, 13 Oct 2026 13:32:33 +0000

For a long time, I treated interface animation as mostly decorative. It could make a product feel more polished or visually impressive, but I rarely considered it functionally important. In fact, I usually preferred to disable animations wherever possible. A dropdown did not seem to need an animation. Smooth scrolling often felt slower than an immediate jump. Waiting for UI motion to finish could feel like unnecessary latency.

Working on more complex interfaces changed my view.

Transitions can be a form of user feedback. When an interaction causes a substantial change in the interface, the developer already knows exactly what happened: which component disappeared, which one replaced it, which panel expanded, and where the new state came from. A user who is still learning the interface does not have that internal model.

An abrupt state change can therefore be difficult to interpret. A transition can preserve visual continuity between the old and new states. When an element moves, expands, collapses, or transforms into another part of the interface, the motion gives the user additional information about the relationship between those states. It helps explain what their action changed and how the new layout relates to the previous one.

That makes transitions part of UX rather than merely visual styling. They can reduce the cognitive cost of navigating an unfamiliar interface and make its behavior easier to learn.

This is one of the reasons I became interested in the View Transition API. It gives the browser a native mechanism for creating complex transitions between DOM states without manually implementing every animation and coordinating the old and new layouts yourself. For me, this changed View Transitions from a visual extra into a useful part of interface architecture.

Once I started using them more extensively, however, a different problem appeared: managing view-transition-name across a large component hierarchy quickly became verbose and difficult to maintain.

That is the problem this article is about.

The View Transition API is one of the browser APIs I enjoy using most. For simple cases, it is remarkably compact: update the DOM inside document.startViewTransition(), assign a few view-transition-name values, and let the browser handle the snapshots and interpolation.

The complexity changes quickly once the interface contains many independently changing elements.

In a real application, the same element may participate in different transitions depending on the operation. A transition may involve elements distributed across several Vue components. Some elements should inherit a transition namespace from their ancestors, while others should start a new namespace or stop propagation. Multiple independent transition hierarchies may coexist in the same DOM tree.

I initially handled these cases individually, including with coding agents. The individual implementations worked, but the amount of imperative orchestration kept growing: find elements, assign names, coordinate old and new DOM states, wait for Vue updates, remove temporary state, handle dynamic instances, and repeat similar logic for the next transition.

The code was becoming substantially more verbose than the UI behavior it described.

I eventually moved the problem into a separate declarative naming layer.

The result is a small internal system used in AlekLabs Eye Trainer. View transition participation is described directly in component templates using attributes, while a runtime function activates the required transition hierarchy only for the duration of a transition. Vite compiler transforms, generated TypeScript types, and a VS Code grammar provide the tooling around it.

The browser still performs the actual View Transition. The new layer deals with naming and orchestration.

Moving Transition Identity Out of CSS

A normal View Transition implementation often starts with CSS such as:

.card {
    view-transition-name: card;
}

That works well while an element has one permanent transition identity.

My application needed something more dynamic. A DOM element can participate in one transition when a panel changes, another when a dialog opens, and a more specific child transition when only part of the same UI changes.

Keeping all of that identity in CSS made the relationship between the component structure and transition structure increasingly difficult to see.

I wanted the template itself to answer a simple question:

Which View Transition hierarchies can this element participate in?

CSS could then remain responsible for the visual behavior of the generated View Transition pseudo-elements.

The distinction became important. The attributes in my templates do not directly set view-transition-name. They are persistent metadata describing possible transition relationships. The actual view-transition-name values exist only while a particular transition is running.

First Attempt: Vue Directives

Vue directives initially looked like a natural solution.

Something like this would have been expressive:

<al-panel v-transition="'settings'">

The limitation appeared as soon as the directive was placed on components.

Vue directives used on components are applied to the component root. Unlike fallthrough attributes, they cannot be forwarded to another element with v-bind="$attrs". Multi-root components add further restrictions.

My UI has a deep component hierarchy, including many internal UI components. I needed transition metadata to move naturally through those abstraction layers.

Ordinary attributes already have exactly this property in Vue.

That made attributes a much better transport mechanism.

A Small Attribute Language

The initial attribute names were too verbose. Repeating a long view-transition-* or application-specific prefix throughout large templates made the transition structure visually noisy.

I introduced $ as a source-level marker for View Transition metadata.

A simplified example looks like this:

<al-panel-expandable :$modulator-panel="num">
    <modulation-curve-setting $-motion />
    <al-adjust $-amount />
</al-panel-expandable>

The first attribute establishes a transition family. If num is 2, its resolved name can become:

modulator-panel-2

The child attributes extend the inherited family:

modulator-panel-2-motion
modulator-panel-2-amount

The interesting part is that $-motion contains no knowledge of modulator-panel, the instance number, or the component in which the hierarchy started.

It simply declares its position inside the current transition family.

This makes transition structure composable across components.

Hierarchical Names

The naming layer behaves as a hierarchy rather than a flat collection of unrelated IDs.

A direct attribute starts a family:

<al-panel :$al-setting="targetId">

A descendant can extend it:

<al-slider $-value />

For a target ID of rotation, the runtime can resolve this as:

al-setting-rotation
al-setting-rotation-value

The hierarchy can cross Vue component boundaries because the compiler output consists of normal attributes.

Several transition families can also coexist in the same area of the application. An element can permanently declare metadata for several possible scenarios while receiving only the actual view-transition-name relevant to the transition currently being executed.

This avoids a major practical problem of the native property: a rendered element taking part in a named View Transition has one view-transition-name, and custom names must be unique among participating rendered elements.

My layer therefore treats names as potential roles rather than permanent CSS state.

Controlling Participation and Propagation

The syntax gradually acquired a few compact controls as real cases appeared.

The current model can be summarized like this:

Source syntax	Meaning
`$panel`	Start or participate in a transition family
`$-value`	Extend the inherited family with `value`
`:$panel="id"`	Add a dynamic instance value
`$panel!`	Define the transition here without propagating it further
`$panel-`	Establish a family for descendants without making this element participate

The last two are particularly useful in reusable component trees.

Sometimes a component is only a structural boundary. Its children need a shared transition namespace, while the component root itself should not get its own snapshot. In other cases a transition applies to one level and should stop before unrelated nested UI starts inheriting it.

These controls make that decision part of the template rather than additional JavaScript.

The runtime also supports compact shortcut definitions and the browser's match-element mode for cases where element identity itself should supply the unique transition matching. Internally, the parser resolves all of these forms into the same transition definition model.

The `$` Syntax Exists Only During Authoring

I did not want unconventional $... attributes to become the permanent runtime DOM representation.

A Vue compiler transform rewrites them during compilation.

Conceptually:

$modulator-panel
$-amount

becomes runtime metadata in the form:

data-transition-modulator-panel
data-transition--amount

Additional marker attributes are generated when propagation or parent-only behavior is requested. The transform operates on the Vue compiler AST, including both static attributes and static v-bind argument names.

For example, the source-level ! suffix becomes an internal --no-propagate marker, while a trailing - on a named family produces a --parent-only marker. vite-plugin-vue-transition-attr…

This gives me two representations with different purposes.

The source representation is optimized for developer experience:

$modulator-panel
$-motion
$-amount

The DOM representation is explicit and conventional enough for runtime inspection:

data-transition-modulator-panel
data-transition--motion
data-transition--amount

Runtime Orchestration

All imperative orchestration is concentrated in one startTransition() function.

Application code can start a transition by name:

await startTransition(`al-setting-${targetId}`, () => {
    dialogTarget.value = target;
});

It can also start from a DOM element:

await startTransition(panel, () => {
    item.amountCurveOn = value;
});

The second form is useful when the caller does not need to know the hierarchy name. The runtime examines the element and its subtree and determines which declared transition names belong to it.

Multiple prefixes can also be supplied to activate several declarative hierarchies during the same View Transition.

Internally, startTransition() performs the lifecycle that I previously had scattered across individual features.

Before calling document.startViewTransition(), it resolves the requested prefixes and temporarily assigns viewTransitionName to matching elements. During the update callback it performs the application state change, waits for Vue's nextTick(), removes the old assignments, scans the updated DOM, and assigns names again for the new state. After the browser reports the transition as finished, all temporary names are removed.

The second scan is important. A transition frequently changes which elements exist. The old snapshot and new snapshot therefore cannot rely on a single static set of DOM nodes.

The declarative attributes remain stable metadata. The runtime derives the correct active names independently on both sides of the DOM update.

Prefix matching provides another useful property. Starting:

startTransition('modulator-panel-2', update);

can activate the family rooted at that prefix, including more specific descendants such as:

modulator-panel-2-motion
modulator-panel-2-amount

The runtime performs that matching centrally instead of requiring every call site to enumerate all participating elements.

Keeping CSS Generic

The system also assigns a shared view-transition-class to participating elements.

This allows generic snapshot behavior to remain very small:

::view-transition-old(.view-transitioned),
::view-transition-new(.view-transitioned) {
    width: 100%;
    height: 100%;
    object-fit: fill;
}

view-transition-class is designed exactly for this kind of shared styling: unlike view-transition-name, the class does not need to be unique and can style multiple named transition pseudo-elements. MDN Web Docs

Specific transitions can still have their own CSS where required. The naming, hierarchy, selection, and lifecycle no longer have to be encoded there.

Editor Tooling Became Part of the Design

Once transition metadata moved into templates, another problem became obvious: attributes disappear visually inside large Vue files.

I wanted transition structure to be immediately recognizable while reading a component.

I added a tiny VS Code extension with a TextMate grammar that highlights $... transition attributes separately from ordinary attributes. The grammar is injected directly into Vue template syntax. transition-attributes.tmLanguage package

This turned out to be more valuable than I initially expected.

When opening a large template, I can visually scan the transition structure without tracing JavaScript. Parent families, child segments, and dynamic transition bindings stand out immediately.

The transition layer became visible as part of the component architecture.

Generating Transition Names and Types

The next step was eliminating manually maintained name lists.

A second Vite plugin scans Vue files, parses each SFC with @vue/compiler-sfc, parses the template with @vue/compiler-dom, walks the AST, and collects $... transition names. It runs initially and again when Vue files are added, changed, or removed. vite-plugin-transition-names

It then generates a TypeScript source file:

export const transitionNames = [
    'al-setting',
    'modulator-panel'
] as const;

That generated constant feeds the runtime type:

type TransitionPrefix = typeof transitionNames[number] | `${typeof transitionNames[number]}-${string}`;

As a result, creating a new transition family in a template automatically makes the name available to TypeScript autocomplete at startTransition() call sites. The same generated information also catches many naming mistakes during development.

There is no separate registry to remember to update.

The template is the source of truth.

The Real Production Case

This system grew out of AlekLabs Eye Trainer rather than an isolated animation experiment.

A single modulation component already contains several examples: dynamically identified modulator panels, motion and amount children, target settings, slider values, dialog transitions, and transitions started both from DOM elements and from explicit hierarchical prefixes.

That is the kind of component where a collection of one-off View Transition implementations becomes difficult to maintain. Several independent UI operations coexist, and each operation may involve a different subset of the same component tree.

With the naming layer, most of that information remains close to the markup.

The behavioral code describes the state update.

The template describes transition participation.

The runtime connects the two.

This Is Not Fundamentally Vue-Specific

My current implementation is integrated deeply with Vue because AlekLabs Eye Trainer uses Vue. The compiler transform uses Vue's compiler packages, the generated-name plugin scans .vue templates, and the transition runtime waits for nextTick() before resolving the new DOM.

The underlying model is framework-independent.

The browser only sees DOM attributes and document.startViewTransition().

A React, Svelte, Web Components, or plain HTML implementation could use the same architecture with a different authoring transform and a framework-appropriate mechanism for waiting until the DOM update completes.

The important part is the separation between persistent declarative metadata and temporary native View Transition state.

What I Learned From Building It

The View Transition API itself remained small throughout this process. Most of the engineering work appeared around naming, composition, lifecycle, discoverability, and developer tooling.

For isolated transitions, direct view-transition-name declarations are sufficient.

For a larger application, I found it much more manageable to treat transition participation as its own declarative application layer.

The final workflow is now straightforward: mark potential participants in the template, compose them into hierarchical namespaces, start a transition from a typed prefix or DOM element, and let one runtime function assign and clean up the browser state.

Vite handles the source transformation and name discovery. TypeScript provides autocomplete and validation. The editor makes the structure visually recognizable. CSS focuses on the resulting animation.

This changed View Transitions in AlekLabs Eye Trainer from feature-specific imperative code into reusable infrastructure.

And, more importantly for a growing UI, adding the next transition no longer requires inventing another orchestration mechanism.

A Useful Side Effect: Agent-Friendly Transitions

A pleasant side effect of this architecture is how well coding agents work with it.

Once an agent is told that $... attributes describe View Transition participation, it can usually extend fairly complex transitions without needing to understand the runtime implementation. For many tasks, the instruction can be as small as: use the $ transition attributes to connect these elements into the same transition hierarchy.

Even transitions involving several components and multiple moving elements can often be implemented without adding feature-specific JavaScript or CSS. The shared runtime already handles name resolution, DOM updates, View Transition lifecycle, and cleanup.

This also makes agent-generated changes much easier to review. Instead of inspecting a new block of transition-specific JavaScript together with additional CSS selectors and animation rules, I can often review only a few attribute changes in the template. The transition structure is visible directly in the markup, and the diff stays small.

In practice, modern coding agents handle this declarative syntax very well. Once the pattern exists in the codebase, they can infer the hierarchy from nearby examples and produce complex multi-element transitions with surprisingly little guidance.

For me, this has become another argument for moving repeated UI behavior into declarative infrastructure: it improves developer experience for humans, and it also gives coding agents a much smaller and more constrained surface to modify.

Hard Object References: Stable Object References for Mutable Application State

Alexander Nenashev — Mon, 06 Jul 2026 18:21:29 +0000

In JavaScript and TypeScript, object references are often treated as disposable. An object is created, assigned to a variable, passed around, replaced, copied, spread, cloned, and eventually discarded.

That is normal language behavior, but in larger mutable systems it creates a specific class of bugs: stale aliases.

A stale alias appears when one part of the program still holds a reference to an old object while another part has already replaced that object with a new one. The old reference is still valid JavaScript, but it no longer points to current data.

Hard Object References is a discipline for avoiding that class of bugs.

The idea is simple:

Object and array references should be stable. Do not replace them as a normal update mechanism. Copy data into existing objects instead.

This rule is useful for application state, but it is not limited to global stores. It applies to ordinary variables, local component state, nested fields, arrays, drafts, snapshots, runtime models, and temporary objects.

The broader principle is:

Replace primitive values. Do not replace object and array references.

The First Rule: `const` for Objects and Arrays

The first level is variable bindings.

If a variable holds an object or array, it should normally be declared with const:

const user = { /* ... */ };

const items = [ /* ... */ ];

not:

let user = { /* ... */ };

let items = [ /* ... */ ];

The point is not that the object becomes immutable. It does not.

This is still possible:

user.name = 'Alex';
items.push(nextItem);

The point is that the variable should not be rebound to a different object:

user = nextUser;
items = nextItems;

That replacement changes which object the variable points to. Any other code that still holds the old reference now points to obsolete data.

So the first rule is:

Use const for object and array references. Mutate or copy data into the object. Do not rebind the reference.

This rule also applies to temporary objects. A temporary object may be short-lived, but while it exists, its reference should still be stable.

The Stale Alias Problem

Consider this code:

const user = {
    name: 'John',
    address: {
        city: 'Paris',
        street: 'Main'
    }
};

const address = user.address;

Now another part of the code replaces the nested object:

user.address = {
    city: 'Berlin',
    street: 'Main'
};

After this assignment:

address === user.address; // false

The variable address still points to a valid object, but it points to obsolete data.

That is the dangerous part. The program does not necessarily crash. It continues to operate on the wrong object.

A Hard Object References approach avoids the replacement:

HardObject.set(user.address, {
    city: 'Berlin'
});

address === user.address; // true
address.city; // 'Berlin'

The reference stayed stable. The data changed.

Temporary Objects Are Not an Exception

A temporary object is not an excuse to use unstable references.

This is fine:

const draft = {
    // ...
};

HardObject.set(draft, {
    name: 'Alex',
    address: {
        city: 'Berlin'
    }
});

This is suspicious:

let draft = {
    // ...
};

draft = {
    name: 'Alex',
    address: {
        city: 'Berlin'
    }
};

The object may be temporary, but rebinding the reference still breaks the same mental model.

If a temporary object needs new data, copy the data into it:

HardObject.set(draft, nextDraftData);

not:

draft = nextDraftData;

This matters because temporary objects often become inputs to state updates:

const draft = {
    // ...
};

HardObject.set(draft, formData);
HardObject.set(state.user, draft);

The draft is not necessarily installed application state, but it still follows the same reference discipline.

So the stronger rule is:

The reference-stability discipline applies to objects in general. Application state is where violating it becomes most expensive.

Application State Makes the Rule Critical

In small local code, replacing an object may be harmless.

In application state, the same operation becomes dangerous because many parts of the program may retain references to the same object:

const selectedAddress = state.user.address;
const editorTarget = state.user.address;
const validationTarget = state.user.address;
const renderTarget = state.user.address;

If this happens later:

state.user.address = nextAddress;

all previous references may become stale.

This is why Hard Object References is especially important for state graphs:

state.user
state.user.address
state.settings
state.document
state.document.pages
state.selection

These are not just values. They are live reference nodes.

Once an object participates in such a graph, replacing its reference should not be the normal update mechanism.

From Principle to Utility

The principle can be followed manually:

const state = {
    // ...
};

HardObject.set(state.user, nextUser);
HardObject.set(state.settings, nextSettings);
HardObject.set(state.items, nextItems);

But a consistent helper can make the rule explicit.

For explanation, call that helper HardObject.

HardObject is not the principle itself. It is only one possible way to express the principle:

const state = HardObject.create(rawState);

The purpose of HardObject.create() is to install an object graph under a hard-reference contract.

The matching update operation is:

HardObject.set(state.user, nextUser);

This means:

Copy compatible data from nextUser into state.user without replacing object or array references.

So the conceptual pair is:

const state = HardObject.create(rawState);

HardObject.set(state.user, nextUser);

create() establishes the hard-reference boundary.
set() updates data inside that boundary.

Type-Level Installation

In the simplest implementation, HardObject.create() can be only a TypeScript-level identity function.

At runtime, it may simply return the same object:

class HardObject {
    public static create<T>(value: T): Hard<T> {
        return value as Hard<T>;
    }
}

The value is returned as-is, but TypeScript can expose it as a type where object and array references are readonly.

A simplified type could look like this:

type Primitive =
    | string
    | number
    | boolean
    | bigint
    | symbol
    | null
    | undefined;

type Hard<T> =
    T extends Primitive
        ? T
        : T extends Array<infer TItem>
            ? ReadonlyArray<Hard<TItem>>
            : {
                readonly [TKey in keyof T]: Hard<T[TKey]>;
            };

This version is intentionally simplified. A real implementation may use a more refined type where primitive fields remain writable while object and array references become readonly.

The architectural point is:

HardObject.create() gives the object graph a hard-reference contract.

That contract can start as TypeScript-only. Later, it can add runtime enforcement without changing the call site.

Runtime Enforcement

TypeScript can catch many mistakes during development, but it does not enforce the rule at runtime.

If runtime enforcement is needed, HardObject.create() can recursively walk the object graph.

Whenever it finds a property whose value is an object or array, it can make that property non-writable on its parent object:

Object.defineProperty(target, key, {
    value,
    writable: false,
    configurable: false,
    enumerable: true
});

Then it continues recursively into that nested object or array and applies the same rule to its children.

The developer does not manually lock every nested property. HardObject.create() is the centralized installation point.

So HardObject.create() can evolve in stages:

Stage	Runtime behavior	Purpose
Type-only	Returns the same object	Provides a TypeScript hard-reference contract
Runtime-enforced	Recursively locks object/array fields	Prevents object-reference replacement at runtime
Framework adapter	Installs the graph into a reactive/store system	Integrates with a specific environment

The rule is not:

Nothing can change.

The rule is:

Primitive values may change. Object and array references should remain stable.

So this is a normal update:

state.user.name = 'Alex';
state.user.address.city = 'Berlin';

But this is not:

state.user.address = {
    city: 'Berlin',
    street: 'Main'
};

The address reference is hard.

The correct update path is:

HardObject.set(state.user, {
    address: {
        city: 'Berlin'
    }
});

Updating a Hard Object Graph

HardObject.set() is a copy-in operation:

HardObject.set(state.user, {
    name: 'Alex',
    address: {
        city: 'Berlin'
    }
});

It means:

Copy compatible data from the source object into the target object without replacing object and array references.

Primitive fields can be assigned directly:

name: 'Alex'

Nested objects are updated recursively:

address.city = 'Berlin'

But the address object itself is not replaced.

Arrays follow the same principle: the array reference remains stable, while its contents are updated through controlled logic.

The exact implementation can vary. HardObject may be a utility, a base class, a model method, a store helper, or a framework-specific adapter. The concept is lower-level than any one implementation.

Change Tracking

A common objection is:

If references do not change, how do you detect changes?

The answer depends on the environment.

In a reactive system, reference replacement does not have to be the primary change signal. If primitive fields and nested object properties are reactive, then normal mutation tracking can already observe changes inside the stable object graph.

For example, in Vue or a similar reactive system, a deep watcher, computed dependency, proxy trap, or framework-level reactive effect may observe this operation:

HardObject.set(state.user, {
    name: 'Alex',
    address: {
        city: 'Berlin'
    }
});

The reference stays stable, but reactive property writes still occur.

In that case, HardObject.onChange() may not be necessary. The reactive system already provides change tracking.

In a non-reactive system, HardObject can provide a simple explicit notification mechanism:

HardObject.onChange(change => {
    // mark dirty, update UI, notify observers, sync state, etc.
});

HardObject.set() can emit a change only if it actually changed at least one value. If the incoming data is equal to the current data, no change event is needed.

So the rule is:

Do not require object replacement to be the change signal.

Use the mechanism that fits the environment: framework reactivity, deep watchers, proxy-based tracking, explicit events, dirty flags, version counters, or observers.

Hard Object References only says that object references should remain stable. It does not prescribe one universal change-tracking system.

Contrast with Immutable State

Immutable update style treats state as a value. Updating state usually means producing a new object graph:

const nextState = {
    ...state,
    user: {
        ...state.user,
        name: 'Alex'
    }
};

Reference replacement is intentional. Changed references are used to detect changed branches.

Hard Object References uses a different model:

HardObject.set(state.user, {
    name: 'Alex'
});

The object remains the same. Its data changes.

The central contrast is:

In immutable systems, references are change signals.
In Hard Object References, references are stable addresses.

Comparison

Topic	Immutable Update Style	Hard Object References
Main model	State as value	State as object graph
Update mechanism	Produce new state	Copy into existing graph
Object binding	May be replaced	Prefer `const` for object/array references
Object field replacement	Normal	Forbidden or controlled
Object identity	Often disposable	Stable
Nested references	Commonly replaced	Preserved
Change signal	Reference change	Reactivity, event, dirty flag, version counter, observer
Best fit	Serializable state, reducers, snapshots	Complex mutable runtime state
Main risk	Stale captured old state	Uncontrolled mutation

Neither model is universally better.

Immutable updates are excellent when state is mostly plain data and the architecture benefits from treating every update as a value transformation.

Hard Object References is useful when state is a mutable object graph and references are used as live handles.

Where This Works Well

Hard Object References fits systems where object references are retained and reused over time:

complex frontend state
large component-local state
document editors
visual editors
reader engines
graph editors
timeline editors
canvas or layout tools
class-based domain models
runtime controllers
selection models
render pipelines
async processes that keep object handles

The boundary is not global state versus local state.

A large component with complex internal state can suffer from the same stale-reference problems as an application-level store. If nested objects are passed around inside that component and later replaced, local aliases can become obsolete too.

The real boundary is:

Can another piece of logic keep this object reference and later expect it to remain current?

If yes, the reference should usually be hard.

When This Rule Is Less Important

This discipline is less critical for:

primitive values
short-lived scalar calculations
small isolated functions
pure transformation pipelines
immutable reducer-based architectures
throwaway objects that never escape their local scope

Even in these cases, the rule can still be useful as a default bias, because reference stability depends on a question that is often hard to answer upfront:

Can this reference escape, be retained, or become obsolete after replacement?

Benefits

The main benefit is not less code. The main benefit is a stronger state invariant.

Object references remain valid.

Retained object handles do not silently become obsolete.

Nested state ownership becomes clearer.

Debugging gets a simple rule:

If an object reference changed, something violated the reference discipline.

This is especially useful in systems where many subsystems interact with the same mutable object graph.

Costs

The costs are real.

Mutation must be controlled. If every part of the application mutates everything freely, the system becomes unstable.

Change tracking must exist. In reactive systems, this may already be handled by the framework. In non-reactive systems, it may require explicit events, observers, dirty flags, or version counters.

The approach is also less natural for tooling built around immutable snapshots, reducer replay, time travel, and structural sharing.

Hard Object References is not a replacement for immutable architecture in every application. It is a different tradeoff for a different kind of state.

Conclusion

Hard Object References treats object references as stable addresses, not disposable values.

The rule starts with mandatory use of const with objects and arrays and continues inside object graphs:

HardObject.set(user.address, nextAddress);

not:

user.address = nextAddress;

A utility such as HardObject can make the rule explicit. HardObject.create() establishes a hard-reference contract. It can start as a type-level identity function and later add runtime enforcement without changing the call site. HardObject.set() updates the graph by copying data into existing references.

This is not presented as a newly invented universal pattern. The underlying concerns are old: object identity, aliasing, ownership, mutation control, and stable object graphs. Hard Object References is my practical formulation of those concerns after repeatedly seeing the same class of bugs in mutable applications: references becoming obsolete because some part of the object graph was replaced instead of updated.

In my own code, this discipline became a stability rule. It reduces Heisenbug-like behavior where the program still runs but some logic works with a detached object. It also changes the mental model: objects are no longer disposable containers that can be swapped at any level. They become stable addresses, and updates become explicit data transfer into those addresses.

The core rule is:

Replace primitive values. Do not replace object and array references.

Or shorter:

References are not change signals. They are stable addresses.

Why Every Frontend Project Should Have Its Own UI Layer

Alexander Nenashev — Wed, 20 May 2026 11:22:55 +0000

Modern frontend development is heavily centered around component frameworks: Vue, React, Svelte, Solid, Angular, and others. The ecosystem also provides endless UI libraries: Vuetify, PrimeVue, Naive UI, MUI, Ant Design, Chakra, Radix, Headless UI, shadcn/ui, and hundreds more.

Most teams directly import these libraries into application code.

I think that is a long-term architectural mistake.

Every serious frontend project should have its own internal UI layer — its own component system — even if internally it relies almost entirely on third-party libraries.

Not because reinventing buttons is fun.
Because abstraction boundaries matter.

The Problem With Directly Using UI Libraries

Direct usage tightly couples the application to external implementation details.

You start with something simple:

<ElButton type="primary" size="small">
    Save
</ElButton>

A year later:

the library changes APIs,
design requirements evolve,
accessibility requirements appear,
dark theme becomes mandatory,
SSR breaks,
bundle size becomes a problem,
a component becomes abandoned,
or the team simply wants another UI system.

Now the entire codebase depends on thousands of scattered library-specific decisions.

The UI library stops being a dependency.

It becomes infrastructure.

Your UI Layer Is An Architectural Boundary

Instead of using third-party components directly, create your own application-level components:

<AppButton>
<AppInput>
<AppDialog>
<AppTable>
<AppDatePicker>
<AppPageLayout>
<AppEntityEditor>

Internally, these components may use:

PrimeVue
Vuetify
Radix
native browser APIs
custom rendering
or completely different implementations

The application itself should not care.

This creates a stable internal contract between the product and external dependencies.

The application talks to your UI architecture.

Your architecture talks to vendor libraries.

Wrappers Are Not "Extra Boilerplate"

A common objection:

"Why wrap everything? That's just unnecessary abstraction."

It is not abstraction for abstraction's sake.

It is containment.

The wrapper layer centralizes:

naming conventions,
defaults,
accessibility,
theme propagation,
behavior normalization,
analytics hooks,
keyboard handling,
validation,
localization,
performance workarounds,
SSR compatibility,
browser quirks,
and migration strategy.

Without wrappers, all of this leaks into product code.

Then every page becomes infrastructure code.

The Biggest Advantage: Replaceability

This is the most important benefit.

When UI libraries are hidden behind your own components, replacing them becomes feasible.

Example:

<AppDatePicker>

Today internally:

PrimeVue DatePicker

Tomorrow:

Flatpickr

Or:

Native browser date input

Or:

Custom implementation

The application code remains unchanged.

This matters more than most teams realize.

UI ecosystems move extremely fast. Libraries become abandoned surprisingly often.

A thin internal UI layer dramatically reduces migration cost.

Mixing Multiple UI Libraries Becomes Safe

Direct usage of multiple UI systems usually creates chaos.

Different:

design languages,
spacing systems,
keyboard behavior,
focus handling,
overlay logic,
animation systems,
theming models,
and accessibility semantics.

But with an internal UI layer, multiple libraries can coexist safely.

Example:

one library provides excellent tables,
another has better dialogs,
another has superior date pickers,
another has accessible comboboxes.

Your application never sees this complexity directly.

Your wrapper layer normalizes it.

This is extremely powerful.

Your UI Layer Is Also A Design System

The important shift:

Your design system should not belong to the UI vendor.

It should belong to the product.

That means:

your naming,
your semantics,
your defaults,
your UX patterns,
your layout philosophy,
your interaction rules.

Not whatever the library authors decided.

Example:

<AppDangerButton />

is far more meaningful than:

<ElButton type="danger" plain />

The first expresses product semantics.

The second expresses vendor implementation details.

That distinction becomes critical at scale.

Default Configuration Reduces Massive Verbosity

One underrated benefit of internal wrappers:

They eliminate repetitive configuration.

Without wrappers:

<ThirdPartyInput
    size="small"
    variant="filled"
    density="compact"
    clearable
    rounded
    theme="dark"
/>

Repeated hundreds or thousands of times.

With wrappers:

<AppInput />

The wrapper already encodes:

project defaults,
theme defaults,
accessibility defaults,
density rules,
validation behavior,
localization behavior,
analytics integration,
focus handling.

This massively reduces UI noise in application code.

The application becomes more declarative.

Theme Propagation Becomes Centralized

Third-party UI libraries usually bring their own theme systems.

That becomes problematic when multiple libraries coexist.

Each library wants:

its own tokens,
its own variables,
its own dark mode implementation,
its own color system.

Your internal UI layer solves this.

The application owns the real design tokens:

:root {
    --color-bg: #ffffff;
    --color-text: #111111;
    --color-primary: #3b82f6;
}

Then wrapper components propagate these tokens into underlying libraries.

Your product controls the visual system.

Libraries adapt to you, not the other way around.

This is one of the cleanest ways to support:

dark mode,
white-labeling,
custom themes,
enterprise branding,
runtime theme switching.

Modern Browser APIs Make Custom UI More Realistic

Five years ago, fully custom UI infrastructure was expensive.

Today browsers provide much better primitives.

Examples:

<dialog>
Popover API
anchor positioning
:has()
CSS nesting
container queries
inert
view transitions
modern focus management
top-layer behavior

Especially important are the newer overlay-related APIs.

Historically, dialogs, dropdowns, popovers, tooltips, and context menus were extremely difficult because of:

z-index wars,
focus traps,
scroll locking,
portal systems,
positioning,
stacking contexts.

Modern browser primitives increasingly solve these problems natively.

This changes the economics of UI architecture.

Building internal abstractions is becoming cheaper and more maintainable.

UI Architecture Is More Than Form Controls

Many teams think only about atomic components:

buttons,
inputs,
selects,
checkboxes.

But the real value appears higher in the hierarchy.

Your internal UI layer can orchestrate:

page layouts,
entity editors,
filter panels,
data tables,
toolbar systems,
sidebars,
navigation structures,
CRUD workflows,
master-detail layouts,
save/cancel flows,
loading orchestration,
permissions handling.

Example:

<EntityPage>
    <EntityToolbar />
    <EntityFilters />
    <EntityTable />
</EntityPage>

Now your product develops consistent workflow patterns.

Not just reusable buttons.

This is where frontend architecture starts becoming a platform.

Internal UI Layers Improve Long-Term Stability

Projects live longer than frontend trends.

The average enterprise frontend outlives:

multiple framework trends,
multiple design trends,
multiple UI libraries,
and sometimes even multiple frontend teams.

A dedicated UI layer creates isolation from ecosystem volatility.

It reduces the blast radius of change.

That is not premature abstraction.

That is operational risk management.

This Applies Beyond Vue

Vue examples are convenient because Vue component composition is extremely ergonomic.

But the idea is framework-agnostic.

The same architecture works in:

React
Svelte
Angular
Solid
Web Components
even server-rendered systems

Any component-based frontend benefits from stable internal UI contracts.

A Practical Rule

One of the first architectural tasks in a frontend project should be:

Define the project's internal UI hierarchy before building product pages.

Not after.

Not during migration.

Not after technical debt accumulates.

At the beginning.

Because once product code directly depends on third-party UI libraries, decoupling becomes expensive.

Potential Downsides

This approach is not free.

Possible drawbacks:

initial setup cost,
additional maintenance,
risk of over-abstraction,
wrapper drift from underlying libraries,
documentation burden,
onboarding complexity,
temptation to reinvent mature solutions.

Poorly designed wrappers can absolutely become worse than direct usage.

The goal is not to hide everything.

The goal is to own the architectural boundary.

Final Thought

Frontend developers often discuss frameworks.

But frameworks are transient.

Architecture lasts much longer.

A frontend codebase should not structurally depend on the internal API decisions of a third-party UI vendor.

It should depend on its own UI language.

That language becomes one of the most valuable assets in the entire frontend architecture.

What additional advantages or disadvantages have you seen with internal UI layers and wrapper-based component systems?

Stop Turning the Mobile Web Into a Second-Class Platform

Alexander Nenashev — Sat, 16 May 2026 21:57:41 +0000

There is a long-term trend in the software industry that I think developers should pay more attention to:

We are slowly replacing the open mobile web with isolated app containers.

And I think this is a mistake.

Not because native applications are inherently bad. Some categories absolutely need them: low-latency audio, advanced camera processing, heavy offline workloads, games, Bluetooth integrations, system-level services, etc.

But a huge percentage of modern mobile apps are not really “native applications” anymore.

They are portals to web content wrapped inside a native shell.

And yet, by moving users from the browser into apps, we lose many of the properties that made the web powerful in the first place.

The Mobile Browser Is More Powerful Than People Realize

On desktop, most developers understand the value of the browser immediately:

tabs
deep linking
bookmarking
extensions
history
multi-window workflows
interoperability
inspectability
copyable URLs
open standards

But on mobile, many companies push users toward applications even when the actual product experience is fundamentally web-shaped.

The result is fragmentation of workflows that the browser already solved decades ago.

A Browser Tab Is a Better UX Primitive Than Most Mobile Apps

This sounds controversial until you compare them directly.

In a browser:

I can open 20 conversations in separate tabs.
I can preserve reading state naturally.
I can bookmark specific content.
I can restore sessions.
I can share exact URLs.
I can use ad blockers.
I can use browser extensions.
I can search across tabs.
I can keep temporary research contexts alive for weeks.

In many mobile apps:

navigation state is fragile
deep linking is inconsistent
opening multiple contexts is awkward
content is trapped inside proprietary navigation systems
session management is opaque
there is no universal multitasking model

The browser already solved these problems with universal primitives.

Apps often reinvent them poorly.

Many Mobile Apps Are Just Embedded Websites

A lot of modern applications are effectively:

React Native shells
Electron-like architectures
WebViews
remote-rendered interfaces
thin API clients around server-driven UI

And that is fine technically.

But if the experience is fundamentally web-centric anyway, why are we abandoning the actual web platform?

Especially when the browser gives users:

portability
inspectability
interoperability
lower installation friction
better discoverability
easier sharing
less platform lock-in

The “App-First” Strategy Hurts the Mobile Web

This is the part that concerns me most.

When companies prioritize native applications aggressively, something predictable happens:

the mobile app becomes the primary platform
the mobile website becomes “good enough”
feature parity disappears
browser support stagnates
investment into web capabilities declines

Eventually the mobile web experience degrades into:

limited functionality
missing features
constant “Open in App” interruptions
intentionally degraded UX
broken navigation
artificial restrictions

This creates a feedback loop:

weaker mobile web → more users forced into apps → even less incentive to improve the web

That is dangerous long term.

We Are Accidentally Weakening the Open Platform

One of the biggest historical advantages of the web was openness.

A browser is a universal runtime.

A website can be indexed, linked, archived, shared, inspected, extended, and accessed without asking permission from a platform gatekeeper.

Apps move the industry toward:

closed ecosystems
proprietary distribution
platform dependency
duplicated implementations
reduced interoperability

The web was never perfect, but it created an environment where small teams could ship globally accessible software instantly.

That matters.

Especially for developers.

Progressive Web Apps Were Supposed to Bridge This Gap

PWAs are one of the most important ideas the industry produced in the last decade.

The promise was compelling:

installable web apps
offline support
push notifications
background sync
richer device APIs
app-like UX without abandoning the web

But mobile platforms still treat the browser as a second-class citizen in many areas.

And this directly affects innovation.

A Real Example: Voice Interfaces on Mobile Web

I built a voice-command-oriented web application.

On desktop Chrome, continuous speech recognition works surprisingly well. You can create fluid voice-driven workflows with near real-time interaction.

But on mobile, the experience degrades dramatically.

The browser often allows only short-lived microphone capture sessions for speech recognition workflows. Continuous recognition behavior is heavily restricted compared to desktop environments.

As a result:

recognition sessions restart constantly
UX becomes fragmented
latency increases
conversational interaction becomes unreliable

Meanwhile native apps can often access far more persistent audio capabilities.

This creates a structural imbalance:

developers are pushed toward native apps not because the web model is fundamentally wrong, but because the platform capabilities are artificially constrained.

And when users stop using the mobile web, platform vendors have even less incentive to improve it.

Browser Features Benefit Everyone

The browser ecosystem creates positive externalities.

When users rely on browsers:

browser vendors compete harder
standards evolve faster
accessibility improves
performance tooling improves
privacy tooling improves
extension ecosystems grow
cross-platform compatibility matters more

The web encourages shared infrastructure.

Apps encourage isolated silos.

Browsers Give Users More Control

Permissions are usually:

visible
revocable
origin-scoped
standardized

Users can:

clear site data
inspect permissions
block trackers
isolate sessions
use privacy extensions
sandbox activity more predictably

Native mobile apps often request much broader persistent access with significantly less transparency around internal behavior.

Again, some applications genuinely need this access.

Many do not.

“But Native Apps Are Faster”

Sometimes yes.

But this argument is increasingly overstated for many categories.

Modern mobile browsers now support:

hardware acceleration
WebAssembly
IndexedDB
service workers
advanced caching
streaming APIs
GPU APIs
installable PWAs

For content-centric products, dashboards, social systems, productivity tools, knowledge platforms, AI interfaces, admin panels, marketplaces, and communication tools, the gap is often far smaller than people assume.

In many cases, the biggest differences are organizational priorities rather than technical impossibilities.

The Web Is Still the Most Important Software Platform Ever Created

The web won because it was:

linkable
composable
open
searchable
decentralized
low-friction

We should be extremely careful about replacing those properties with ecosystems built around opaque application containers.

Especially when many “apps” are already websites internally.

My Personal Rule

If a service can function well as a mobile website, I increasingly prefer using the website over installing the app.

Not because I hate apps.

But because every time we choose the browser:

we reinforce open standards
we increase pressure for better browser APIs
we support interoperable software
we encourage better PWAs
we reduce unnecessary platform fragmentation

And over time, that shapes the direction of the ecosystem.

Final Thought

I think developers underestimate how much collective user behavior influences platform evolution.

If users continuously abandon the mobile web in favor of closed app ecosystems, companies and platform vendors will naturally invest less into browser capabilities.

But if developers and users actively use and demand high-quality mobile web experiences, the opposite can happen:

better APIs
stronger PWAs
richer browser capabilities
more powerful web runtimes
less dependence on app stores
more open software ecosystems

The mobile web does not become stronger automatically.

It becomes stronger only if people continue using it.

What do you think?

Are mobile apps genuinely superior for most modern products, or are we underinvesting in the mobile web ecosystem?

Avoid intermediate arrays (parsing strings) to make you Javascript fast

Alexander Nenashev — Sat, 18 May 2024 16:42:30 +0000

In the previous post there was argued why we should avoid intermediate arrays for performance in cases like filter/map chains.

I'd say String#split() is heavily overused when parsing strings. A common scenario is to get the first word in a string. The first thought is to split a string into words and get the first one. Again, an intermediate array is created, worse, only the first element is used, the rest is just waste of space and time. Use String#indexOf() and String#slice() instead:

let $length = 1;
const str = Array.from({length: $length + 1}, () => 'test').join(' ');

// @benchmark Array#split
str.split(' ')[0];

// @benchmark String#indexOf
str.slice(0, str.indexOf(' '));

// @benchmark regex
str.match(/^\S+/)[0];

` Chrome/125
-----------------------------------------------------------------------------------------------
>                       n=1        |       n=10        |       n=100       |       n=1000      
String#indexOf   ■ 1.00x x100m 972 | ■ 1.00x x100m 959 | ■ 1.00x  x10m  94 |  ■ 1.00x x100m 967
regex              2.99x  x10m 291 |   3.06x  x10m 293 |   3.07x  x10m 289 |    2.96x  x10m 286
Array#split        6.49x  x10m 631 |  22.52x   x1m 216 | 165.96x x100k 156 | 1509.82x  x10k 146
----------------------------------------------------------------------------------------------- `
` Firefox/126
------------------------------------------------------------------------------------------------
>                       n=1        |       n=10        |       n=100       |       n=1000       
String#indexOf   ■ 1.00x x100m 105 | ■ 1.00x x100m 120 | ■ 1.00x x100m 108 |   ■ 1.00x x100m 109
regex             35.90x  x10m 377 |  27.83x  x10m 334 |  33.15x  x10m 358 |    32.11x  x10m 350
Array#split       39.05x  x10m 410 | 105.00x   x1m 126 | 944.44x x100k 102 | 10000.00x  x10k 109
------------------------------------------------------------------------------------------------ `

Open in the playground

Pre-allocate arrays to make Javascript fast

Alexander Nenashev — Sat, 18 May 2024 14:05:11 +0000

If you ever implemented a dynamic array in low level languages like C++ you allocate a chunk of memory for several elements at once, when there's no more space for new elements you allocate a new chunk. I guess this is valid and for Javascript arrays. Allocation of a memory on the heap is an expensive operation.

Let's try in Chrome's console (several times, the output is the most frequent):

const start = performance.memory.usedJSHeapSize;
const arr = new Array(1);
setTimeout(() => {
    const diff = performance.memory.usedJSHeapSize - start;
    console.log('heap allocated', diff);
}, 100);

> heap allocated 1688

const start = performance.memory.usedJSHeapSize;
const arr = new Array(1_000_000);
setTimeout(() => {
    const diff = performance.memory.usedJSHeapSize - start;
    console.log('heap allocated', diff);
}, 100);

> heap allocated 4001684

As we see with 1_000_000 array length we have 3.8Mb allocated.

Of course the reason behind the optimization could be different or composite, I'm not a developer of any current JS engines, but it seems that changing the length of an array is generally an expensive operation.

Regardless of the actual JS implementation if we follow the rule:

When the final size of an array is known during creation of the array - allocate it:

const arr = Array(knownSize);

This immediately boosts your Javascript speed:

let $length = 10;
const arr = Array.from({length: $length}, (_, i) => i);

// @benchmark non pre-allocated
{
  const result = [];
  for(let i = 0; i < arr.length; i++){
    result.push(arr[i]);
  }
  result;
}

// @benchmark pre-allocated
{
  const result = Array(arr.length);
  for(let i = 0; i < arr.length; i++){
    result[i] = arr[i];
  }
  result;
}

// @benchmark Array#map
arr.map(i => i);

` Chrome/125
-----------------------------------------------------------------------------------------------
>                         n=10       |      n=100       |      n=1000       |      n=10000     
pre-allocated       ■ 1.00x x10m  85 | ■ 1.00x x10m 669 | ■ 1.00x   x1m 474 | ■ 1.00x x100k 560
Array#map             1.69x x10m 144 |   1.79x  x1m 120 |   2.15x x100k 102 |   3.20x  x10k 179
non pre-allocated     3.22x x10m 274 |   3.57x  x1m 239 |   4.11x x100k 195 |   3.66x  x10k 205
----------------------------------------------------------------------------------------------- `
` Firefox/126
---------------------------------------------------------------------------------------------
>                         n=10       |      n=100      |      n=1000       |     n=10000     
pre-allocated       ■ 1.00x x10m 227 | ■ 1.00x x1m 162 | ■ 1.00x x100k 192 | ■ 1.00x x10k 208
non pre-allocated     1.44x x10m 327 |   1.45x x1m 235 |   1.16x x100k 222 |   1.53x x10k 319
Array#map             1.46x x10m 332 |   1.06x x1m 172 |   1.73x x100k 333 |   2.17x x10k 452
--------------------------------------------------------------------------------------------- `

Open in the playground

Keep in mind though that you create a sparse array with Array(size) so some methods like map(), forEach() wouldn't work as expected, but the iterators works fine like [...arr].

Avoid iterators/generators to make Javascript fast

Alexander Nenashev — Fri, 17 May 2024 12:09:43 +0000

If we look at the iterator protocol we'd notice it comes at a cost of creating {value, done} objects, accessing their props, and calls of next() (a function call is generally is an expensive operation).

Given all the hurdles we have a quite inefficient tool to iterate our data. Moreover when we implement an iterator with a generator we suddenly notice that performance got even worse. I guess that's because of the cost of keeping a generator's scope and its state between calls.

Don't get me wrong, iterators and generators are good abstractions, for await is exceptionally amazing when dealing with async data and abstracting backend API calls, so generally used in business logic they bring benefits but when we descend into the realm of transforming data, generic data handling functions and algorithms we should care to avoid them when possible.

Here's a benchmark of several ways to iterate an array and you see the iterator and generator fail considerably. I'm not the only one complaining, I've seen several comments that generators' speed keeps people from using them widely.

class Iter {
  *gen(arr) {
    for (let i = 0; i < arr.length; i++) {
      yield arr[i];
    }
  }
  iter(arr) {
    let i = 0;
    const out = { value: null, done: false };
    const iter = {
      [Symbol.iterator]: () => iter,
      next: () => {
        if (i === arr.length) out.done = true, out.value = null;
        else out.value = arr[i++];
        return out;
      }
    };
    return iter;
  }
}

const $chunk = () => Array.from({length: 10}, (_, i) => i);
const $input = [], arr = $input;
const iter = new Iter;

// @benchmark generator
for(const e of iter.gen(arr));

// @benchmark iterator
for(const e of iter.iter(arr));

// @benchmark for..of
for(const e of arr);

// @benchmark for
for(let i = 0; i < arr.length; i++) arr[i];

// @benchmark forEach
arr.forEach(e => {});

` Chrome/125
-----------------------------------------------------------------------------------------
>                 n=10        |       n=100       |      n=1000       |      n=10000     
for           1.17x x100m 336 |   1.20x  x10m 354 |   1.01x   x1m 235 | ■ 1.00x x100k 218
for..of       1.19x x100m 340 |   1.21x  x10m 355 | ■ 1.00x   x1m 232 |   1.00x x100k 219
forEach     ■ 1.00x x100m 286 | ■ 1.00x  x10m 294 |   1.00x   x1m 233 |   4.54x  x10k  99
iterator     64.34x   x1m 184 |  13.71x   x1m 403 |  10.86x x100k 252 |  10.96x  x10k 239
generator    43.01x   x1m 123 |  36.05x x100k 106 |  45.69x  x10k 106 |  43.58x   x1k  95
----------------------------------------------------------------------------------------- `
` Firefox/126
-----------------------------------------------------------------------------------------
>                 n=10        |       n=100       |      n=1000       |      n=10000     
for         ■ 1.00x x100m 512 | ■ 1.00x  x10m 505 | ■ 1.00x   x1m 453 | ■ 1.00x x100k 449
forEach       1.62x x100m 828 |   1.48x  x10m 746 |   4.26x x100k 193 |   6.57x  x10k 295
for..of      11.07x  x10m 567 |   9.35x   x1m 472 |   9.98x x100k 452 |  10.11x  x10k 454
iterator     23.44x   x1m 120 |  10.93x   x1m 552 |  11.24x x100k 509 |  10.71x  x10k 481
generator    82.62x   x1m 423 |  64.75x x100k 327 |  66.67x  x10k 302 |  68.37x   x1k 307
----------------------------------------------------------------------------------------- `

Open in the playground

One would argue that for..of in Chrome performs nice despite of using an array's iterator but that's an optimization of using a native iterator. Firefox is generally more honest in benchmarks if we want generic evaluation of Javascript code, but about that is in the next post.

Avoid intermediate arrays (filter/map) to make Javascript fast

Alexander Nenashev — Wed, 15 May 2024 08:21:51 +0000

If you aim to write fast Javascript avoid intermediate arrays when transforming data or making an algorithm. This could happen both with imperative and functional code. Always ask yourself a question while writing code - are there any intermediate arrays I could avoid.

Often I see a common pattern filter + map:

const arr = Array.from({length: 100}, () => ({num: Math.random()}));

arr.filter(n => n.num > .5).map(n => n.num * 2);

Sometimes the chain is quite long, hosting several filter/map/sort in various configurations.

Replace the chain with Array#reduce() which in mostly all cases will give you better performance over any chain of other methods, since you remove the array created by Array#filter():

arr.reduce((r, n) => (n.num > .5 && r.push(n.num * 2), r), []);

@tracygjg asked in a comment why not to use:

arr.reduce((r, n) => n.num > .5 ? [...r, n.num * 2] : r, []);

Thank @tracygjg for this one, that's another great example where you create an intermediate array, moreover an array is created for every element in the result array!

So basically each time we want to add an element to the result, a bigger array is created thus the bigger the source array the slower the solution.

Moreover the spread syntax is used which should be avoided too if you want a performant solution (my next post is about that). Let's benchmark all the 3 options:

const $chunk = Array.from({length: 10}, () => ({num: Math.random()}));
const $input = []; 

// @benchmark filter + map
$input.filter(n => n.num > .5).map(n => n.num * 2);

// @benchmark reduce
$input.reduce((r, n) => (n.num > .5 && r.push(n.num * 2), r), []);

// @benchmark Tracy Gilmore
$input.reduce((r, n) => n.num > .5 ? [...r, n.num * 2] : r, []);

` Chrome/124
-------------------------------------------------------------------------------------------
>                     n=10       |       n=100       |      n=1000       |     n=10000     
reduce          ■ 1.00x x10m 355 | ■ 1.00x   x1m 155 | ■ 1.00x x100k 263 | ■ 1.00x x10k 431
filter + map      1.88x x10m 669 |   1.74x   x1m 269 |   1.41x x100k 370 |   1.55x  x1k  67
Tracy Gilmore     3.32x  x1m 118 |  20.13x x100k 312 | 196.20x   x1k 516 | 893.27x  x10 385
------------------------------------------------------------------------------------------- `
` Firefox/126
-------------------------------------------------------------------------------------------
>                     n=10       |       n=100       |      n=1000       |     n=10000     
reduce          ■ 1.00x x10m 647 | ■ 1.00x   x1m 433 | ■ 1.00x x100k 390 | ■ 1.00x x10k 470
filter + map      1.41x  x1m  91 |   1.27x x100k  55 |   2.51x  x10k  98 |   1.32x x10k 620
Tracy Gilmore     1.90x  x1m 123 |   9.70x  x10k  42 | 175.64x   x1k 685 | 359.57x  x10 169
------------------------------------------------------------------------------------------- `

Open in the playground

As you can see with 10000 array items we could have a hundreds of times slower solution if we don't care enough about avoiding intermediate arrays.

In the next post we will discuss how to avoid intermediate arrays while parsing strings.

Every millisecond matters in Javascript

Alexander Nenashev — Tue, 14 May 2024 11:05:51 +0000

Premature optimization is the root of all evil -- Donald Knuth

In light of modern trends of increasing complexity of modern JS frameworks, high end developer hardware and the premature optimization mantra we ended up with some performance problems with modern web and especially modern mobile web (deserves a separate article).

Probably you can't comfortably use modern web sites on a 5 year old mid/low budget device, at least the most people don't expect to upgrade their PCs used just for web surfing every year. I've ended up buying a high end android phone just to use social sites comfortably.

One could tell that a user couldn't tell a difference between 1 and 5 ms, but given the fact we could have hundreds of operations on page or data loading, all these small overheads lead to a noticeable performance hit and poor user experience.

So I'd say that every millisecond matters in Javascript. Premature optimization is bad when you spend significant amount of time on a code piece that is thrown away later due refactoring. But what if you could write highly performant Javascript code from the beginning? You just don't need to optimize later and the whole premature optimization thing isn't relevant anymore. So learn how to write fast Javascript, I believe it will pay off.

In the next posts that would form a series I will be collecting tips how to write fast Javascript.

Conditional wrap component in Vue 3 pt.3

Alexander Nenashev — Fri, 10 May 2024 17:09:41 +0000

Previously we observed 2 options to create a conditional wrap component in Vue 3. Now it's time for the most complex one which exploits vnodes in a deeper way.

On the client side it's pretty ordinary with the wrapper provided in a wrapper slot and the wrapped content in the default one. But we do some magic inside the wrap component:

We collect all leaf vnodes in the wrapper slot's vnode tree
We inject our content into the leaves like they'd support a default slot. For that we should set shapeFlag of the leaves as ShapeFlags.ARRAY_CHILDREN | ShapeFlags.ELEMENT.

See on Vue SFC Playground

import { ShapeFlags } from "@vue/shared";
import { cloneVNode} from "vue";

const findLeaves = (vnode, cb) => 
  vnode.children?.length ? 
    vnode.children.forEach(vnode => findLeaves(vnode, cb)) : 
    cb(vnode)
;

export default function Wrap({isWrapped}, {slots}){

  if (!isWrapped) return slots.default();

  const wrapper = slots.wrapper().map(vnode => cloneVNode(vnode));
  findLeaves({children: wrapper}, vnode => {
    vnode.shapeFlag = ShapeFlags.ARRAY_CHILDREN | ShapeFlags.ELEMENT;
    (vnode.children ??= []).push(...slots.default());
  });

  return wrapper;
}

Wrap.props = { isWrapped: Boolean };

Usage:

  <wrap :is-wrapped>
    <template #wrapper>
      <div class="wrapper">
        <div class="inner-wrapper"></div>
      </div>
    </template>
    <p>
      I'm wrapped
    </p>
  </wrap>

As you see the DX is pretty good, with full ability to define our wrapper with any nesting fully inside a template.

Now you have a choice to select a wrap component from 3 options or probably combine them into one ultimate component.

Conditional wrap component in Vue 3 pt.2

Alexander Nenashev — Fri, 10 May 2024 14:14:32 +0000

In the previous post we create a pretty idiomatic component that would work well for simple cases. Let's explore more options. What can be done to present our wrapper as a template as more DX friendly? Of course we could compile it runtime, but for a simple 1 level wrapper we could use the following:

See on Vue SFC Playground

export default function Wrap({isWrapped}, {slots}){
  return isWrapped? 
    slots.default() : 
    slots.default().flatMap(vnode => vnode.children);
}

Wrap.props = { isWrapped: Boolean };

Usage:

  <wrap :is-wrapped>
    <div class="wrapper">
      <p>
        I'm wrapped
      </p>
    </div>
  </wrap>

Yes, it looks non idiomatic, also it generates the wrapper's vnode every time even it's discarded, but it was an interesting case to explore for better DX.

In the next post we'll explore a more idiomatic option with using 2 slots for the content and wrapper.

Conditional wrap component in Vue 3

Alexander Nenashev — Fri, 10 May 2024 08:45:37 +0000

Often it's needed to wrap some part of a template in a wrapper <div> for example. It seems easy using v-if but we have a duplication we'd like to avoid:

<div v-if="isWrapped" class="wrapper">
  <!-- some big chunk of markup -->
</div>
<template v-else>
  <!-- the same big chunk -->
</template>

Let's explore our options how we can solve this task without the duplication. Let's call our component <wrap> and our component that wraps the content a wrapper. Our wrap component is stateless so let's make it functional.

Our first option would be simple. We support a wrapper component and its props:

See on Vue SFC Playground

import { h } from 'vue';
export default function Wrap({wrapper}, {slots, attrs}){
  return wrapper ? h(wrapper, attrs, slots.default()) : slots.default();
}

Wrap.props = ['wrapper'];

Usage:

  <wrap :wrapper="isWrapped && 'div'" class="wrapper">
    <p>
      I'm wrapped
    </p>
  </wrap>

The result is pretty sufficient, you can use any wrapper component with a default slot. But a problem here is that for more complex cases like having multiple nested wrappers we should define the wrapper outside our markup since having a functional wrapper component inside :wrapper property looks pretty messy. In the next posts of this series we'll explore other options of defining our conditional wrap component.

DEV Community: Alexander Nenashev

A Declarative Naming Layer for the View Transition API

Moving Transition Identity Out of CSS

First Attempt: Vue Directives

A Small Attribute Language

Hierarchical Names

Controlling Participation and Propagation

The $ Syntax Exists Only During Authoring

Runtime Orchestration

Keeping CSS Generic

Editor Tooling Became Part of the Design

Generating Transition Names and Types

The Real Production Case

This Is Not Fundamentally Vue-Specific

What I Learned From Building It

A Useful Side Effect: Agent-Friendly Transitions

Hard Object References: Stable Object References for Mutable Application State

The First Rule: const for Objects and Arrays

The Stale Alias Problem

Temporary Objects Are Not an Exception

Application State Makes the Rule Critical

From Principle to Utility

Type-Level Installation

Runtime Enforcement

Updating a Hard Object Graph

Change Tracking

Contrast with Immutable State

Comparison

Where This Works Well

When This Rule Is Less Important

Benefits

Costs

Conclusion

Why Every Frontend Project Should Have Its Own UI Layer

The Problem With Directly Using UI Libraries

Your UI Layer Is An Architectural Boundary

Wrappers Are Not "Extra Boilerplate"

The Biggest Advantage: Replaceability

Mixing Multiple UI Libraries Becomes Safe

Your UI Layer Is Also A Design System

Default Configuration Reduces Massive Verbosity

Theme Propagation Becomes Centralized

Modern Browser APIs Make Custom UI More Realistic

UI Architecture Is More Than Form Controls

Internal UI Layers Improve Long-Term Stability

This Applies Beyond Vue

A Practical Rule

Potential Downsides

Final Thought

Stop Turning the Mobile Web Into a Second-Class Platform

The Mobile Browser Is More Powerful Than People Realize

A Browser Tab Is a Better UX Primitive Than Most Mobile Apps

Many Mobile Apps Are Just Embedded Websites

The “App-First” Strategy Hurts the Mobile Web

We Are Accidentally Weakening the Open Platform

Progressive Web Apps Were Supposed to Bridge This Gap

A Real Example: Voice Interfaces on Mobile Web

Browser Features Benefit Everyone

Browsers Give Users More Control

“But Native Apps Are Faster”

The Web Is Still the Most Important Software Platform Ever Created

My Personal Rule

Final Thought

Avoid intermediate arrays (parsing strings) to make you Javascript fast

Pre-allocate arrays to make Javascript fast

Avoid iterators/generators to make Javascript fast

Avoid intermediate arrays (filter/map) to make Javascript fast

Every millisecond matters in Javascript

Conditional wrap component in Vue 3 pt.3

Conditional wrap component in Vue 3 pt.2

Conditional wrap component in Vue 3

The `$` Syntax Exists Only During Authoring

The First Rule: `const` for Objects and Arrays