DEV Community: Artyom

A11Y is UI architecture

Artyom — Sat, 14 Feb 2026 09:06:10 +0000

I once had what seemed like a straightforward task: clicking a button in a list item should pop up a form asking for additional info, with submit and cancel actions. We decided to think about good UX from the start, and that's when the questions began.

The design called for the form to appear right where the user clicked. Is that a popup? Or a dialog? Do we need a backdrop? Should it close on Esc? What about the Android back button — should it dismiss just the overlay or navigate away from the page entirely? And next sprint we had socket-based notifications coming, which raised a whole new set of questions about transient UI.

This was one of those rare cases where we decided to skip off-the-shelf component libraries and build everything ourselves. The questions kept piling up, so I went straight to the WAI-ARIA spec.

The discovery: accessibility is architecture

As I dug into accessibility, I found something I didn't expect — a rigorously defined system for describing interfaces in terms of their behavior, not their visual appearance.

ARIA APG isn't just a set of guidelines for making interfaces usable by people with disabilities. It's a coherent architectural system that helps you structure components and their interactions correctly. It covers nearly every edge case that, if left unhandled, would leave users in a frustrating situation. And that turns out to be incredibly useful for day-to-day development.

I'd recommend every UI developer read the ARIA Authoring Practices Guide. It's a surprisingly friendly document, and it will change how you think about components.

Accessibility helps everyone

Before diving into the details, it's worth reframing what "accessibility" actually means. It benefits a much wider audience than you might think. Plenty of people experience temporarily limited abilities every day:

One hand is holding a grocery bag, a child, or is in a cast
The screen is washed out by sunlight or set to low brightness
The mouse is broken, the trackpad is awkward
Eyes are strained after a long workday, or you're just not feeling well

Accessibility isn't about serving a special-needs minority. It's about solid application architecture that makes the interface work well for everyone — including the user who's walking down the street in bright sunlight trying to dismiss a confirmation dialog with one thumb.

The right vocabulary

Here's a problem most frontend teams have: the words we use are wrong. "Modal," "toast," "snackbar," "drawer" — these are informal names that different people interpret differently. The WAI-ARIA spec gives us precise terms that map to behavior, not looks (see Live Region Roles and Window Roles):

dialog — content that doesn't require user action. A product detail card, a photo viewer with comments. Requirements: backdrop, autofocus and focus lock, aria-describedby or aria-labelledby, aria-modal.
alert — important information that demands the user's attention but doesn't require a response. It disappears on its own. A timer going off, an error notification.
alertdialog — information that requires a user response. Same requirements as dialog. Confirming a file deletion, an error with recovery options.
status / log / marquee — similar to alert but don't demand immediate attention. A new message in a chat, an order processing status update.

Notice the pattern: these roles define what the component does, not what it looks like. A "toast" could be an alert, a status, or even an alertdialog depending on whether it needs user action. When you start design and development from these behavioral roles, composing the final visual components becomes obvious. You stop arguing about naming and start reasoning about function.

From spec to code: headless UI

This is where the architectural insight becomes practical. Studying accessibility helped me understand why libraries like Ariakit and React Spectrum separate state from presentation. When you decouple a component's logic and behavior from its visual rendering, grounding it in WAI-ARIA semantics, you get:

A clear layering — the spec defines behavior, a headless layer implements that behavior (focus management, keyboard navigation, ARIA attributes), and your visual components just consume it. Each layer has a single responsibility.
Composition over configuration — you don't have to figure out how to bolt a new feature onto an existing component. Need a dialog that also has a form? Compose the dialog behavior with the form behavior. The visual layer stays thin and flexible.
Easier conversations with designers — when you share the same vocabulary of roles and behaviors, design reviews become about intent ("is this an alert or an alertdialog?") rather than implementation ("should the toast have an X button?").

When you organize code around accessibility patterns, the architecture almost writes itself. WAI-ARIA gives you a ready-made component taxonomy — all you have to do is follow it.

It's a living standard (and that's okay)

WAI-ARIA doesn't have all the answers. How should a modal react to the browser's back button? Should the Android system back button close an open modal or navigate away from the page? The APG guides don't give a direct answer, and the debate is still ongoing. There are even open questions about Menu and Menubar navigation.

That's fine. A living standard with gaps is still better than no standard at all. It gives you a foundation to build on and a community to reference when you hit an edge case.

Takeaways

Using WAI-ARIA as the foundation for UI component architecture gives you unexpected advantages:

Faster development — proven patterns for most scenarios, out of the box
Easier refactoring — clear behavioral layers make changes straightforward
Better communication — shared terminology between engineers and designers
Higher quality — you won't forget critical details like focus management or keyboard navigation
Regulatory readiness — your product won't run into compliance issues down the road

Accessibility isn't an extra feature you can defer to "someday." It's the foundation of good architecture that helps you build quality interfaces faster and more efficiently. WAI-ARIA isn't dogma, but it's the baseline every web developer needs.

Practical resources

Component patterns with clear explanations — share these with your designers
Example index with reference implementations
Practices guide with detailed behavior descriptions
WAI-ARIA specification for a deep dive
Open issues to see what's still being figured out

When React Hooks Start Feeling Heavy

Artyom — Mon, 09 Feb 2026 22:01:29 +0000

I have shipped a lot of React in production, and the same pain points keep returning:

Writable computed state is unnatural.
Custom hooks are hard to extend.
Hook order and effect-based sync add performance and reliability costs.

This is not about "React bad". React is excellent at rendering and ecosystem compatibility. The point is practical: when state derivation gets complex, many teams end up with key reset tricks, sync setState, useEffect syncing, and extra glue variables.

Problem 1: Writable Computed State Feels Unnatural

The classic case is reset-on-parent-change. For example: reset pagination when search changes, or reset one draft field when fresh backend data arrives.

The `key` reset trick is coarse

function SearchPage({ query }: { query: string }) {
  return <SearchPanel key={query} query={query} />
}

This resets everything in SearchPanel. It does not help when a component has several local states and you need to drop only one, for example: reset page but keep filters, sort, viewMode, or an unsaved draft input.

The common React fallback is sync logic

function SearchPanel({ query }: { query: string }) {
  const [page, setPage] = useState(1)
  const [filters, setFilters] = useState({ onlyActive: false })

  useEffect(() => {
    setPage(1)
  }, [query])

  return null
}

This works, but introduces an extra render cycle and opens room for visual glitches in real UIs.

A custom `useStateComputed` can help, but still has limits

function useStateComputed<State>(
  initState: State,
  compute: (state: State) => State,
  deps: ReadonlyArray<unknown>,
) {
  const [state, setState] = useState(initState)
  const computedRef = useRef({ value, deps: [] })
  const { value, deps: prevDeps } = computedRef.current

  if (
    prevDeps.length !== deps.length ||
    prevDeps.some((dep, index) => !Object.is(dep, deps[index]))
  ) {
    computedRef.current = { value: compute(state), deps }
  }

  return computedRef.current.value
}

It improves ergonomics, but:

it still depends on useEffect synchronization;
it is still local and isolated from extension composition;
ref-based sync can be fragile in StrictMode and concurrent rendering;
it does not solve "add persistence/validation/logger to existing state atomically".

Problem 2: Hooks Are Not Naturally Extensible

Imagine a hook from internal or npm code:

function useSomeData(url: string) {
  const [data, setData] = useState<null | { value: string }>(null)

  useEffect(() => {
    let active = true
    fetch(url)
      .then((r) => r.json())
      .then((next) => {
        if (active) setData(next)
      })

    return () => {
      active = false
    }
  }, [url])

  return data
}

Now you want to add:

persistence before state initialization;
schema validation and transformation on updates;
conditional synchronization behavior.

In React, if the author did not design an extension API for this, you usually duplicate state and synchronize through effects and flags.

function useSomeDataWithPersist(url: string) {
  const remote = useSomeData(url)
  const [persisted, setPersisted] = useState<null | { value: string }>(null)
  const [ready, setReady] = useState(false)

  useEffect(() => {
    const raw = localStorage.getItem('someData')
    if (raw) setPersisted(JSON.parse(raw))
    setReady(true)
  }, [])

  useEffect(() => {
    if (!ready || !remote) return
    setPersisted(remote)
    localStorage.setItem('someData', JSON.stringify(remote))
  }, [ready, remote])

  return ready ? persisted : null
}

This is boilerplate-heavy and hard to keep consistent.

Problem 3: Hook Order, Conditional Logic, and Effect Cost

This is where React usually needs more discipline and conventions. We can absolutely make it work, but in complex flows we often pay with:

extra unions/default values for conditional hook params;
all hooks still being created by rule-of-hooks order;
larger "enabled" condition surfaces, which are easy to overcomplicate;
additional effect synchronization when data flow is not strictly linear.

The real production useBalanceState case is shown at the end of this article with a direct Reatom comparison.

Reatom: Writable Computed State Without Effects

In Reatom, mutable atoms can have dependent writable computation with withComputed.

import { atom, withComputed } from '@reatom/core'

type Tab = { id: string }

export const tabs = atom<Array<Tab>>([], 'tabs')

export const currentTab = atom<Tab | null>(null, 'currentTab').extend(
  withComputed((state) => tabs().at(-1) ?? state),
)

A practical pagination reset:

import { atom, withComputed, withSearchParams } from '@reatom/core'

const search = atom('', 'search').extend(withSearchParams('search'))

const page = atom(1, 'page').extend(
  withSearchParams('page'),
  withComputed((state) => {
    search()
    return 1
  }),
)

No extra sync effects. No duplicated state machine.

Reatom Extensibility: Compose Behavior Instead of Forking Hooks

Reatom atoms are designed for composition through extensions.

import {
  reatomEnum,
  withComputed,
  withLocalStorage,
  reatomMediaQuery,
} from '@reatom/core'

const isDarkModeMedia = reatomMediaQuery('(prefers-color-scheme: dark)')

const theme = reatomEnum(['system', 'light', 'dark'], 'theme').extend(
  withComputed((state) => {
    if (state === 'system') return isDarkModeMedia() ? 'dark' : 'light'
    return state
  }),
  withLocalStorage('theme'),
)

This pattern solves the common "theme + persistence + system preference" case without custom hook duplication.

The same extension model works for adapters from library code or teammates. You can attach persistence, mapping, validation, analytics, and middleware behavior to existing atoms.

Core pieces used in this article are implemented in:

packages/core/src/primitives/reatomEnum.ts
packages/core/src/web/reatomMediaQuery.ts
withLocalStorage from Reatom persist adapters

Conditional Reactivity and Better Runtime Efficiency

With reatomComponent, you read only what you need, when you need it.

import { reatomComponent } from '@reatom/react'

const Panel = reatomComponent(() => {
  if (!isFeatureEnabled()) return null
  return <div>{expensiveState()}</div>
}, 'Panel')

When a branch does not read a state, there is no subscription to that state in that branch.

Also, reatomMediaQuery subscribes to window.matchMedia events only when someone actually uses it, which avoids waste in inactive features and scales better in large apps.

Debugging: Tracing Through Effects and Update Chains

Reatom has first-class tracing and logging for update causes, including chains through effects and async boundaries. In practice, this means less guessing and less "where did this update come from?" time.

In React-heavy flows, rerender-driven debugging is often noisy: you get many extra renders in typical apps, so logs become harder to read and signal-to-noise drops quickly. Reatom devtools/logs focus on cause chains and state transitions, which keeps the timeline clearer.

Quick Comparison

Case	React hooks typical solution	Reatom solution
Reset one dependent state	`key`, `useEffect`, sync `setState`	`withComputed` on the target atom
Add persistence to existing logic	duplicate state + effects	add `withLocalStorage` extension
Add derived rules to existing state	new custom hook or refactor source	compose `withComputed` and other extensions
Conditional subscriptions	constrained by hook order	subscribe only by actual reads
Trace update causes	fragmented logs and effects	built-in cause-aware logs and tooling

Extra: Real Production Case (`useBalanceState`)

This case is from a real production codebase.
You will see the original React hooks implementation first, then a Reatom-oriented variant with the same business intent. The goal is not to shame the React code. The goal is to show how the same production rules can be modeled with fewer coordination points and clearer data flow.

React hooks version

function useBalanceState() {
  const user = useUser()
  const { id, startDate, isCanceled, isPrepaid } = useAgreement() ?? {}

  const isNewAgreement =
    !startDate ||
    differenceInDays(endOfToday(), startOfDay(new Date(startDate))) <
      NEW_AGREEMENT_DAYS

  const hasAccess = Boolean(user?.rules.includes(Rules.ViewBalance))
  const isBalanceAlertPossible =
    !isCanceled && isPrepaid && isNewAgreement && hasAccess && id

  const agreementBalanceParams = isBalanceAlertPossible
    ? { enabled: true, agreementId: id }
    : { enabled: false, agreementId: '' }

  const { balanceData, bonusData } = useAgreementBalance(agreementBalanceParams)

  const dailyConsumptionParams = isBalanceAlertPossible
    ? {
        agreementId: id,
        startDate: startOfYesterday().toISOString(),
        endDate: endOfYesterday().toISOString(),
      }
    : { agreementId: '' }

  const { data: dailyConsumption } = useDailyProjectConsumptionQuery(
    dailyConsumptionParams,
    { options: { enabled: Boolean(isBalanceAlertPossible) } },
  )

  if (isCanceled) return BalanceStatus.ResourcesStopped
  if (!isBalanceAlertPossible || !balanceData || !bonusData)
    return BalanceStatus.None

  const yesterdayConsumption = dailyConsumption?.consumptions?.[0]?.amount ?? 0
  if (
    balanceData.balance < 0 ||
    yesterdayConsumption <= balanceData.balance + bonusData.bonuses
  ) {
    return BalanceStatus.LowBalance
  }

  return BalanceStatus.None
}

Reatom-oriented variant

import { atom, computed, withAsyncData, wrap } from '@reatom/core'

const userAtom = atom<User | null>(null, 'user')
const agreementAtom = atom<Agreement | null>(null, 'agreement')

const balanceState = computed(async () => {
  const agreement = agreementAtom()
  if (!agreement) return BalanceStatus.None

  const { id, startDate, isCanceled, isPrepaid } = agreement
  if (isCanceled) return BalanceStatus.ResourcesStopped

  const isNewAgreement =
    !startDate ||
    differenceInDays(endOfToday(), startOfDay(new Date(startDate))) <
      NEW_AGREEMENT_DAYS

  const hasAccess = Boolean(userAtom()?.rules.includes(Rules.ViewBalance))
  const isBalanceAlertPossible =
    Boolean(id) && isPrepaid && isNewAgreement && hasAccess

  if (!isBalanceAlertPossible) return BalanceStatus.None

  const [{ balanceData, bonusData }, dailyConsumption] = await wrap(
    Promise.all([
      getAgreementBalance({ agreementId: id }),
      getDailyProjectConsumption({
        agreementId: id,
        startDate: startOfYesterday().toISOString(),
        endDate: endOfYesterday().toISOString(),
      }),
    ]),
  )

  if (!balanceData || !bonusData) return BalanceStatus.None

  const yesterdayConsumption = dailyConsumption?.consumptions?.[0]?.amount ?? 0
  if (
    balanceData.balance < 0 ||
    yesterdayConsumption <= balanceData.balance + bonusData.bonuses
  ) {
    return BalanceStatus.LowBalance
  }

  return BalanceStatus.None
}, 'balanceState').extend(withAsyncData({ initState: BalanceStatus.None }))

Why this shape is often easier to maintain:

early returns naturally cut off unnecessary subscriptions/work;
no enabled parameter choreography across multiple hooks;
one place for business rules and data dependency flow;
async chain is visible and traceable in Reatom logs/devtools.

Final Take

React hooks are a strong default for many UIs. As state orchestration grows, writable computed state, extension layering, and effect coordination can become expensive in both code and runtime behavior.

Reatom gives a cleaner model:

writable computed state through withComputed;
open extension system for composition;
conditional reactivity without hook-order gymnastics;
robust tracing for real production debugging.

If your team keeps writing "state + effect + sync + flags" patterns, that is usually a signal that the model is fighting your domain.

Reatom: State Management That Grows With You

Artyom — Mon, 08 Dec 2025 12:47:38 +0000

The Fragmentation Problem

Modern frontend development has a familiar pattern:

Start with simple useState hooks
Need shared state? Add Context
Context re-renders too much? Add a state manager
State manager doesn't handle async well? Add a data fetching library
Need forms? Another library
Routes need data loading? Router with loaders
Persistence? Yet another library
Logging and analytics? Here we go again...

Each tool has its own mental model, API quirks, and bundle cost. The stack grows, complexity multiplies, and new team members need weeks to understand it all. Versioning and maintaining compatibility across multiple libraries becomes a nightmare.

Reatom is a different approach. One coherent system that can handle all of these concerns — from the simplest counter to the most complex enterprise data flows. Use what you need, integrate with what you have.

For fast overview, you can check out our site: https://v1000.reatom.dev/

The Zen

Four principles guide Reatom's design:

Primitives outperform frameworks — A few powerful building blocks beat a complex framework
Composition beats configuration — Stack simple pieces instead of configuring monoliths
Explicit specifics, implicit generics — Be clear about what matters, hide the boilerplate
Compatibility worth complexity — Works with your stack, not against it

These aren't marketing slogans. They're the result of six years of production use and continuous refinement, starting with the first LTS release in December 2019.

Start Simple

If signals are familiar, Reatom will feel natural:

import { atom, computed } from '@reatom/core'

const counter = atom(0)
const isEven = computed(() => counter() % 2 === 0)

// Read
console.log(counter()) // 0
console.log(isEven()) // true

// Write
counter.set(5)
counter.set((prev) => prev + 1)

No providers, no boilerplate, no ceremony. The core is less than 3KB gzipped — smaller than some "lightweight" alternatives.

You can stop there, but here's where it gets interesting...

Grow Infinitely

The same primitives that power a counter can handle enterprise-grade complexity:

import { atom, computed, withSearchParams, withAsyncData, wrap, sleep } from '@reatom/core'

// Sync with URL search params automatically
const search = atom('', 'search').extend(withSearchParams('search'))
const page = atom(1, 'page').extend(withSearchParams('page'))

// Async computed with automatic cancellation
const searchResults = computed(async () => {
  const url = `/api/search?q=${search()}&page=${page()}`
  await wrap(sleep(300)) // The wrap provides debouncing here

  const response = await wrap(fetch(url))
  return await wrap(response.json())
}, 'searchResults').extend(withAsyncData({ initState: [] }))

// Now you have:
searchResults.ready() // loading state
searchResults.data() // the results
searchResults.error() // any errors

What happens here:

search and page atoms automatically sync with URL params
The computed re-runs only when dependencies change AND when something subscribes to it (lazy!)
If the user types faster than the API responds, previous requests are automatically cancelled
Race conditions? Handled. Memory leaks? Impossible.

This is the same atom from the counter example — just extended.

The Extension System

Instead of a monolithic framework, Reatom provides composable extensions that stack cleanly:

const theme = atom('dark').extend(
  // Persist to localStorage
  withLocalStorage('theme'),
)

const list = atom([]).extend(
  // Memoize an equal changes
  withMemo(),
)

const unreadCount = atom(0).extend(
  // React to state changes
  withChangeHook((count) => {
    document.title = count > 0 ? `(${count}) My App` : 'My App'
  }),
  // Sync across tabs
  withBroadcastChannel('notificationsCounter'),
)

Each extension does one thing well. Compose exactly what's needed.

Beyond State: Complete Solutions

Reatom provides full solutions for common frontend challenges:

Forms

Type-safe form management with first-class support for:

Field-level and form-level validation (sync and async)
Integration with Standard Schema validators (Zod, Valibot, etc.)
Dynamic field arrays with add, remove, reorder operations
Focus tracking, dirty detection, error management
No weird string paths — just objects and atoms
Extremely optimized and performant

https://v1000.reatom.dev/start/forms/

Routing

Type-safe routing with automatic lifecycle management:

Parameter validation and transformation
Data loading with automatic cancellation on navigation
Nested routes with shared layouts
Search parameter handling
Isomorphic cross-framework support
Factory pattern — state created in route loaders is automatically garbage collected on navigation, solving the "global state cleanup" problem

https://v1000.reatom.dev/start/routing/

Persistence

A ton of built-in storage adapters with general advanced features:

localStorage, sessionStorage, BroadcastChannel, IndexedDB, Cookie and Cookie Store
Integration with Standard Schema validators (Zod, Valibot, etc.)
Version migrations for data format changes
TTL (time-to-live) support
Graceful fallback to memory storage when unavailable

https://v1000.reatom.dev/handbook/persist/

Deep Technical Advantages

Cause Tracking

Reatom emulates TC39 AsyncContext and gets a TON of benefits from it:

Automatic cancellation of concurrent asynchronous chains (kinda debounce): https://v1000.reatom.dev/handbook/async-context/
Some sort of IoC and DI possible: https://v1000.reatom.dev/reference/methods/#variable-1
Async transactions: https://v1000.reatom.dev/reference/methods/#withrollback
Process tracking and logging: https://v1000.reatom.dev/start/tooling/

The last feature is a game changer for complex async flows. You can easily inspect the cause of your concurrent operations and reduce debugging time from hours to minutes.

Performance

Reatom has the best possible performance given its feature set. The more complex the application, the faster Reatom performs compared to alternatives.

Benchmarks for complex computations show Reatom outperforming MobX in moderately sized dependency graphs — impressive given that Reatom uses immutable data structures and operates in a separate async context, features that bring significant benefits but typically add overhead.

Explicit Reactivity, No Proxies

Proxy-based reactivity can be convenient for simple cases but becomes harder to trace in large codebases. With Reatom, hover over any property for a type hint — it's always clear what's reactive.

Reatom encourages atomization — transforming backend DTOs into application models where mutable properties become atoms:

// Backend DTO
type UserDto = { id: string; name: string }

// Application model with explicit reactivity
type User = { id: string; name: Atom<string> }

const userModel = { id: dto.id, name: atom(dto.name) }

// Now it's always clear:
userModel.id // static value — no reactivity
userModel.name() // reactive — tracks changes

This pattern gives you fine-grained control: define reactive elements precisely where needed, avoid the uncontrolled creation of observers, and never need toJS-like conversions to inspect or pass data.

Less complexity with atomization

In immutable state managers, updating one item in a list requires recreating the entire array — O(n) complexity. Reatom's atomization pattern provides O(1) updates:

// Traditional immutable approach: O(n)
const updateName = (state, idx, name) => ({
  ...state,
  users: state.users.map((u, i) => (i === idx ? { ...u, name } : u)),
})

// Reatom with atomization: O(1)
users()[idx].name.set(newName)

For lists with thousands of items, this difference matters.

Framework Agnostic, Ecosystem Friendly

Right now Reatom works best with React (https://v1000.reatom.dev/reference/react), but we already have draft packages for Vue, Preact, Solid, and Lit, with plans for Svelte and Angular (signals). You can also bind any library using reatomObservable.

Write your state and effects once, get a reusable model for complex tests and any view framework. Perfect for modularity in general, and microfrontends especially.

Reatom isn't a walled garden. It plays well with the native web APIs and the entire npm ecosystem: use Zod for validation, any fetch wrapper for HTTP, use built-in AbortController's, bind any UI library for components. Adopt Reatom incrementally in existing projects — no need to rewrite everything at once.

Try It

npm install @reatom/core @reatom/react

Start with atoms. Add extensions as needed. Scale to any complexity.

Links:

Building a Lightning-Fast i18n Alternative: Why I Ditched i18next for Native JavaScript

Artyom — Sat, 09 Aug 2025 11:37:15 +0000

The Performance Crisis in Modern i18n

If you're using i18next with TypeScript, you've probably felt the pain. Despite performance improvements, the reality is sobering:

tested on Apple M1

TypeScript compilation: Each 1,000 translation keys adds ~1 second to tsc build time
IDE responsiveness: Type hints slow down by 0.3+ seconds with large dictionaries
Bundle size: i18next weighs 41.6 kB (13.2 kB gzip) before you even add translations
Runtime performance: Custom DSL parsing becomes a bottleneck at scale

Real developers are feeling this pain:

"We had to remove i18n typing entirely due to CI memory overflow with ~3k translations" - Production developer

"Removing i18next improved our SSR performance by 3x without losing functionality" - Performance engineer

But here's the thing: modern JavaScript has everything we need built-in.

Why Go Native?

The Internationalization API has matured significantly. We have:

Intl.NumberFormat for numbers, currencies, units
Intl.DateTimeFormat for dates and times
Intl.PluralRules for pluralization logic
Intl.RelativeTimeFormat for "2 days ago" formatting

These APIs are zero-cost, tree-shakeable, and blazing fast.

The Solution: A 5-File i18n System

Here's a complete internationalization system that's simpler, faster, and more maintainable than traditional libraries:

1. Language Detection & Management

// translations/lang.ts
import { cookie } from "../cookie";

const LANGS = {
  en: "en",
  ru: "ru",
} as const;
export type LANGS = keyof typeof LANGS;

const userLang = cookie.get("lang") ?? window.navigator.language;
export const LANG = userLang in LANGS ? (userLang as LANGS) : "en";

export const changeLang = (lang: string) => {
  cookie.set("lang", lang);
  window.location.reload();
};

// Native formatters - zero overhead
export const degree = new Intl.NumberFormat(LANG, {
  style: "unit",
  unit: "degree",
  unitDisplay: "long",
});

2. Dynamic Translation Loading

// translations/index.ts
import { LANG } from "./lang";

export * from "./lang";

const vocabModule = {
  en: () => import("./en"),
  ru: () => import("./ru"),
} as const;

// Only load the language we need
export const { vocab: t } = await vocabModule[LANG]();

3. Type-Safe Translation Files

// translations/en.ts
import { degree } from "./lang";

export const vocab = {
  hi: "Hello",
  temperature: (n: number) => `Temperature is ${degree.format(n)}`,
};

export type Vocab = typeof vocab;

4. Simple Cookie Utility

// cookie.ts
const getCookieRec = () =>
  Object.fromEntries(document.cookie.split('; ').map((rec) => rec.split('=')));

export const cookie = {
  get(name: string): string | undefined {
    return getCookieRec()[name];
  },
  set(name: string, value: string) {
    document.cookie = `${name}=${value}`;
  },
};

5. Usage in Components

// App.tsx
import { useState } from 'react';
import { LANG, changeLang, t } from './translations';

export function App() {
  const [count, setCount] = useState(0);

  return (
    <main>
      <p>{t.hi}</p>
      <p>
        <button onClick={() => setCount((s) => s + 1)}>{count}</button>
      </p>
      <p>{t.temperature(count)}</p>
      <p>
        <select value={LANG} onChange={(e) => changeLang(e.target.value)}>
          {['ru', 'en'].map((lang) => (
            <option key={lang} value={lang}>{lang}</option>
          ))}
        </select>
      </p>
    </main>
  );
}

The Benefits

✅ Blazing Fast Types: Direct object access, no complex mapping.

✅ Zero Runtime Overhead: No DSL parsing, no library weight.

✅ Automatic Code Splitting: Only load translations you need

✅ Full Type Safety: TypeScript infers everything automatically

✅ Native Formatting: Leverage browser APIs for numbers, dates, plurals

✅ Simple API: t.key instead of t('key')

✅ SSR out of the box: no additional setup for SSR

✅ Framework agnostic: use with Svelte, React, Vue or jQuery 😁

Advanced Patterns

Namespace Support

Create subdirectories for different feature areas:

const vocabModule = {
  en: () => import("./en"),
  ru: () => import("./ru"),
} as const;

const authModule = {
  en: () => import("./auth/en"),
  ru: () => import("./auth/ru"),
} as const;

Pluralization with Intl.PluralRules

For complex plural forms, integrate the native Intl.PluralRules API directly into your vocabulary:

// translations/en.ts
import { degree } from "./lang";

const pluralRules = new Intl.PluralRules('en-US');

const createPlural = (forms: Record<Intl.LDMLPluralRule, string>) => 
  (count: number) => {
    const rule = pluralRules.select(count);
    return forms[rule].replace('{count}', count.toString());
  };

export const vocab = {
  hi: "Hello",
  temperature: (n: number) => `Temperature is ${degree.format(n)}`,
  items: createPlural({
    zero: 'No items',
    one: '1 item',
    two: '{count} items', // for languages that distinguish "two"
    few: '{count} items', // for languages with "few" category  
    many: '{count} items', // for languages with "many" category
    other: '{count} items'
  }),
  // More complex example with gender/case variations
  notifications: createPlural({
    zero: 'No new notifications',
    one: 'You have 1 new notification',
    other: 'You have {count} new notifications'
  })
};

export type Vocab = typeof vocab;

Usage remains beautifully simple:

<p>{t.items(0)}</p>  // "No items"
<p>{t.items(1)}</p>  // "1 item" 
<p>{t.items(5)}</p>  // "5 items"

The beauty is that each language can define its own plural rules - Russian has different categories than English, and the Intl.PluralRules API handles all the complexity for you.

Server-Side Rendering

One of the biggest advantages of this approach becomes apparent with Server-Side Rendering. It just works out of the box - no complex server configuration, no hydration mismatches, no locale detection headaches.

For serverless environments (Lambda, Vercel Functions, etc.), this solution is perfect as-is. Each request gets its own execution context, so the static imports work beautifully.

For stateful servers (Express, Fastify, etc.), you have a simple migration path. Convert the dot notation t.key to function calls t().key, then implement the t function using Node.js's AsyncLocalStorage:

// translations/variable.ts
import { AsyncLocalStorage } from "async_hooks";

export const tVariable = new AsyncLocalStorage<string>();

// translations/index.ts

// ...

const { vocab } = await vocabModule[LANG]();

export let t = () => vocab;

if (SSR) {
  const vocabs = {
    en: import("./en"),
    ru: import("./ru"),
  } as const;

  const { tVariable } = await import("./variable");

  t = () => {
    const locale = tVariable.getStore() ?? "en";
    return vocabs[locale];
  };
}

import { tVariable } from "translations/variable";

app.use((req, res, next) => {
  const locale = detectLocale(req);
  tVariable.run(locale, next);
});

This gives you per-request locale isolation without any global state pollution - exactly what you need for concurrent request handling.

The Trade-off

The main downside: Translations live in code, making it harder for non-technical team members to edit them. This isn't always a problem - many teams prefer developer-controlled translations for better version control and review processes.

For teams that need non-technical editing, consider:

Build-time generation from external sources
Git-based workflows with translation management tools
Hybrid approaches for different content types

Try It Out

Live Demo on StackBlitz

This approach has transformed how I think about internationalization. Sometimes the best solution isn't the most popular one - it's the one that leverages what's already built into the platform.

What's your experience with i18n performance? Have you found other lightweight alternatives? Share your thoughts in the comments!

Review of an interview with the author of TypeScript about porting it to Go

Artyom — Tue, 11 Mar 2025 22:02:24 +0000

I’m excited to share insights from a one-hour interview with Anders Hejlsberg, the creator of TypeScript, about an impressive new port of TypeScript to Go. This development promises significant improvements, and I’d love to walk you through the details!

What could unlock even better performance for Node.js? Let’s explore.

Official Announcement: A 10x Faster TypeScript

Source Code: github.com/microsoft/typescript-go

Here are my notes and reflections based on the interview.

The TypeScript community has long prioritized performance enhancements, often highlighting this need more than requests for new features. It’s inspiring to see this focus come to life.

The team rewrote 80% of the functionality in just six months, starting in August 2024. While features like JSDoc and JSX aren’t supported yet, and the remaining 20% will take a couple more years to refine, this is a promising step forward. For large, established projects, this timeline matters, but new projects—or those not relying on less common features—might adopt the new compiler as early as this year!

Why Go?

While I was writing this article, Anders described his thoughts: https://github.com/microsoft/typescript-go/discussions/411#discussioncomment-12466988

Rewriting a project of this scale from scratch wasn’t feasible, so the team chose to port it file-by-file, aiming to keep changes minimal. A key priority was maintaining nearly identical behavior—99.999% of it—to support smooth transitions for development teams.

Go stood out as the ideal choice for several reasons:

It’s designed with performance in mind and operates at a lower level.
It aligns beautifully with TypeScript’s recursive data structures (unlike Rust, for example).
It offers excellent cross-platform support (unlike C#, which was less suitable).

Performance Gains

TypeScript’s current codebase uses a clear, functional approach—simple functions and mostly immutable data structures, avoiding complex OOP or FP abstractions. I really appreciate this thoughtful design.

Immutable data structures are vital for tasks like quickly and safely reloading code during IDE edits, which benefits developers working on real-world products.

Go’s multi-threading capabilities brought an immediate 3x performance boost. Some processes are still limited to four threads, and full parallelization isn’t complete yet. Anders didn’t emphasize this, but I suspect there’s even more potential to unlock.

One challenge with multi-threading was shifting away from relying on single-thread predictability. This sparked my curiosity—sometimes, designs that seem less optimal at first glance can quietly offer advantages. For instance, immutability is naturally thread-safe. Anders noted how single-threaded code could depend on predictable initialization order, which becomes less certain in a multi-threaded setup—an intriguing trade-off to consider.

That said, this shift has led to some divergence from the original codebase, which the team is working diligently to minimize.

Another 3x performance gain comes from structs, which improve memory access and simplify multi-threading. Anders explained that the reduced memory usage isn’t just about easing the load on a developer’s machine—it’s about optimizing individual processes, helping avoid CPU cache limits and performance hiccups.

I do wish there were more progress in JavaScript itself. For example, TC39 paused work on Record & Tuple and is moving slowly on Structs. These could potentially deliver a 5x performance boost for Node.js, and I’d love to see more momentum there. It’s an interesting area to think about as the ecosystem evolves.

Anders also praised Go for its variety of numeric types, contrasting this with JavaScript’s single, bulky number type, where little change seems on the horizon.

Interoperability

Anders highlighted another challenge: TypeScript’s API. While some might say it’s barely there—often extended through creative workarounds in JS—the Go version closes those gaps entirely. The exciting part? With the ecosystem’s need for customization and the compiler’s newfound speed, the team is now focused on building a reliable public interface for external use.

This could also lead to a proper LSP for TypeScript, improving tooling support—a welcome development. They’re even exploring ways to integrate with LLMs, enabling them to better understand code with greater accuracy, rather than just parsing it.

The Future of TypeScript’s Codebase

You might wonder if moving away from TypeScript’s original language would discourage contributors. However, external contributions aren’t a huge factor here, and Go is much more approachable for JavaScript developers than, say, Rust.

One question I’m still pondering: how will they address the lack of dogfooding? I’d be curious to hear more.

Anders reassured us that the original TypeScript codebase could be supported for years, even after a full shift to Go. This feels like a carefully planned strategy, not just an experiment.

Final Thoughts

This interview was truly engaging, offering a glimpse into a thoughtful and ambitious project. I’m encouraged by the team’s commitment to a gradual, considerate migration.

Here’s to hoping we’ll soon see DOOM running on typescript-go!

Let’s Discuss:

I’d love to hear your thoughts in the comments! Imagine you’re starting a new project—would you:

Jump into typescript-go this year with its 10x performance boost?
Wait a couple of years for native ECMAScript structures and use TypeScript with a 5x performance gain?

What would you choose, and why? I’m genuinely curious to see how everyone weighs these options!

Rethinking JavaScript. Partial Application, Referential Transparency, and Lazy Operations

Artyom — Sat, 30 Nov 2024 13:10:10 +0000

Hi folks! Some time ago, while browsing the latest TC39 proposals, I stumbled upon one that got me excited — and a little skeptical. It’s about partial application syntax for JavaScript. At first glance, it seems like the perfect fix for many common coding headaches, but as I thought it over, I realized there’s both a lot to like and some room for improvement.

Even better, these concerns sparked a whole new idea that could make JavaScript even more powerful. Let me take you on this journey, complete with realistic examples of how these features could change the way we code every day.

TLDR: the article come from my old issue to the proposal: https://github.com/tc39/proposal-partial-application/issues/53

The Proposal

Partial application lets you “preset” some arguments of a function, returning a new function for later use. Our current code looks like this:

const fetchWithAuth = (path: string) => fetch(
  { headers: { Authorization: "Bearer token" } },
  path,
);
fetchWithAuth("/users");
fetchWithAuth("/posts");

The proposal introduces a ~() syntax for this:

const fetchWithAuth = fetch~({ headers: { Authorization: "Bearer token" } }, ?);
fetchWithAuth("/users");
fetchWithAuth("/posts");

See what’s happening? The fetchWithAuth function pre-fills the headers argument, so you only need to supply the URL. It’s like .bind() but more flexible and easier to read.

The proposal also allows you to use ? as a placeholder for unfilled arguments and ... for a rest parameter. For example:

const sendEmail = send~(user.email, ?, ...);
sendEmail("Welcome!", "Hello and thanks for signing up!");
sendEmail("Reminder", "Don't forget to confirm your email.");

My favorite part is that I don't need to duplicate the type annotations!

Sounds useful, right? But there’s a lot more to unpack.

The Case for Referential Transparency

Let’s start with a practical pain point: function closures and stale variable references.

Say you’re scheduling some notification. You might write something like this:

function notify(state: { data?: Data }) {
  if (state.data) {
      setTimeout(() => alert(state.data), 1000)
  }
}

Did you already see the problem? The "data" property might change during timeout and the alert will show nothing! Fixing this requires explicitly passing the value reference, hopefully, "setTimeout" accept additional arguments to pass it into the callback:

function notify(state: { data?: Data }) {
  if (state.data) {
      setTimeout((data) => alert(data), 1000, state.data)
  }
}

Not bad, but it’s not widely supported across APIs. Partial application could make this pattern far more universal:

function notify(state: { data?: Data }) {
  if (state.data) {
      setTimeout(alert~(state.data), 1000)
  }
}

By locking in state.data at the time of function creation, we avoid unexpected bugs due to stale references.

Reducing Repeated Computations

Another practical benefit of partial application is eliminating redundant work when processing large datasets.

For example, you have a mapping logic, which needs to calculate additional data for each iteration step:

class Store  {
  data: { list: [], some: { another: 42 } }
  get computedList() {
    return this.list.map((el) => computeElement(el, this.some.another))
  }
  contructor() {
    makeAutoObservable(this)
  }
}

The problem is in proxy access to this.some.another, it is pretty heavy for calling each iteration step. It would be better to refactor this code like so:

class Store  {
  data: { list: [], some: { another: 42 } }
  get computedList() {
    const { another } = this.some
    return this.list.map((el) => computeElement(el, another))
  }
  contructor() {
    makeAutoObservable(this)
  }
}

With partial application we can do it less verbose:

class Store  {
  data: { list: [], some: { another: 42 } }
  get computedList() {
    return this.list.map(computeElement~(?, this.some.another))
  }
  contructor() {
    makeAutoObservable(this)
  }
}

By baking in shared computations, you make the code more concise and easier to follow, without sacrificing performance.

Why Add New Syntax?

Now, here’s where I started scratching my head. While the proposed syntax is elegant, JavaScript already has a lot of operators. Especially the question mark operators 😅. Adding ~() might make the language harder to learn and parse.

What if we could achieve the same functionality without introducing new syntax?

A Method-Based Alternative

Imagine extending Function.prototype with a tie method:

function notify(state: { data?: Data }) {
  if (state.data) {
      setTimeout(alert.tie(state.data), 1000)
  }
}

It’s a bit more verbose but avoids introducing an entirely new operator. Using an additional special symbol for placeholders we can replace the question mark.

const fetchWithAuth = fetch.tie(
  { headers: { Authorization: "Bearer token" } },
  Symbol.skip
);
fetchWithAuth("/users");
fetchWithAuth("/posts");

It is perfectly polypiling without additional built-time complexity!

class Store  {
  data: { list: [], some: { another: 42 } }
  get computedList() {
    return this.list.map(computeElement.tie(Symbol.skip, this.some.another))
  }
  contructor() {
    makeAutoObservable(this)
  }
}

But this is only the top of the iceberg. it makes the placeholder concept reusable across different APIs.

Lazy Operations: Taking It Further

Here’s where things get really interesting. What if we expanded the symbol concept to enable lazy operations?

Example 1: Combining `.filter()` and `.map()`

Suppose you’re processing a list of products for an e-commerce site. You want to show only discounted items, with their prices rounded. Normally, you’d write this:

const discountedPrices = products
  .filter(p => p.discount > 0)
  .map(p => ({ price: Math.round(p.price * (1 - p.discount)) }));

But this requires iterating over the array twice. With lazy operations, we could combine both steps into one pass:

const discountedPrices = products.map(p =>
  p.discount > 0
    ? { name: p.name, price: Math.round(p.price * (1 - p.discount)) }
    : Symbol.skip
);

The Symbol.skip tells the engine to exclude items from the final array, making the operation both efficient and expressive!

Example 2: Early Termination in `.reduce()`

Imagine calculating the total revenue from the first five sales. Normally, you’d use a conditional inside .reduce():

const revenue = sales.reduce((acc, sale, i) => 
  i < 5 ? acc + sale.price : acc, 
  0
);

This works, but it still processes every item in the array. With lazy reductions, we could signal early termination:

const revenue = sales.reduce((acc, sale, i) => 
  i < 5 ? acc + sale.price : Symbol.skip, 
  0
);

The presence of Symbol.skip could tell the engine to stop iterating as soon as the condition is met, saving precious cycles.

Why This Matters

These ideas — partial application, referential transparency, and lazy operations — aren’t just academic concepts. They solve real-world problems:

Cleaner API usage: Lock arguments upfront and avoid stale references.
Improved performance: Eliminate redundant computations and enable more efficient iteration.
Greater expressiveness: Write concise, declarative code that’s easier to read and maintain.

Whether we stick with ~() or explore alternatives like tie and Symbol.skip, the underlying principles have enormous potential to level up how we write JavaScript.

I vote for the symbol approach as it is easy to polyfill and has various uses.

What’s Next?

I’m curious—what do you think? Is ~() the right direction, or should we explore method-based approaches? And how would lazy operations impact your workflow? Let’s discuss in the comments!

The beauty of JavaScript lies in its community-driven evolution. By sharing and debating ideas, we can shape a language that works better for everyone. Let’s keep the conversation going!

Is Temporal still temporal?

Artyom — Sat, 01 Jun 2024 23:13:23 +0000

Temporal is the new JavaScript standard for date manipulations. It has a long, difficult journey that I want to share with you. Is it ready for production or not? Let's find out!

Introduction

On May 13, 2017, the first commit of the Temporal Proposal was made, heralding a new API for date manipulation, inspired by popular libraries like moment.js and luxon.

Temporal aims to correct many of the pain points associated with the existing Date object in JavaScript, providing a better, more reliable framework for handling dates and times. Over the years, Temporal has evolved significantly, incorporating numerous features and improvements.

Key Differences from Date

Temporal introduces several significant improvements over the traditional Date object:

Correct Time Zone Handling: Temporal is designed with thoughtful time zone management, allowing developers to handle cross-time zone scenarios seamlessly.
Immutable API: The API is immutable, ensuring that date objects aren't accidentally modified and every operation returns a new object.
Duration Handling: Temporal includes robust support for intervals through the Duration object, making it easier to work with time durations.

Here's an example to demonstrate the ease of use:



const start = Temporal.PlainDateTime.from('2024-01-01T10:00');
const duration = Temporal.Duration.from({ hours: 3, minutes: 15 });
const end = start.add(duration);

console.log(start.toString()); // 2024-01-01T10:00
console.log(end.toString()); // 2024-01-01T13:15
console.log(duration.toString()); // PT3H15M

And another example:



const date1 = Temporal.PlainDate.from('2024-01-01');

const date2 = Temporal.PlainDate.from('2024-12-31');

const difference = date1.until(date2);

console.log(difference.toString()); // P11M30D (11 months and 30 days)

Comprehensive Entity Model

Temporal's design incorporates a comprehensive model for date and time entities:

PlainDate: Represents a date without a time zone.
PlainTime: Represents a time of day without a date or time zone.
PlainDateTime: Represents a combination of date and time without a time zone.
ZonedDateTime: Represents a date and time in a specific time zone.
Duration: Represents a time interval.
Instant: Represents an exact moment in time.

You can read more about the schematic of key entities here.

Active Development and Polyfill

In 2020, there was intensive work on the polyfill. Igalia played a crucial role, investing significant effort into the development process. They wrote extensive tests, ensured type safety, and added numerous runtime assertions—adhering to best practices meticulously.

I personally used this polyfill for a year while developing a Node.js project and was extremely satisfied. I didn't encounter any bugs and even submitted a PR to improve typings. It's gratifying to make even a small contribution to such a major project.

Why Temporal?

By 2021, I considered the Temporal proposal and its polyfill the most well-thought-out tool for date manipulation, and I still hold this view. However, the polyfill weighs 200 kB (50 kB gzip), making it somewhat heavy for front-end use. Nonetheless, it's worth noting that once Temporal is natively supported in browsers, you can simply remove the polyfill without altering your code—a luxury not available with other date libraries from NPM.

However, I couldn't afford to drag such a heavy library into every web application, and I forgot about Temporal for a while. Three years have passed since I used a well-crafted polyfill, so why hasn't it been shipped to all browsers yet?

Roadblocks to Becoming a Standard

A key feature of the new API is sophisticated time zone management. However, this couldn't be implemented fully due to inadequacies in the existing time zone standard. Ujjwal, an Igalia employee and the primary developer of Temporal, proposed extending the internet's date-time standard to allow for additional information. For instance, while Hawaiian law mandates a single standard time, locals often follow a different time zone. This issue isn't theoretical; it was an actual problem for my friend, a developer. The proposed extension permits specifying not just the time zone but also the specific "calendar", accommodating such nuances.

The proposal's acceptance was a significant milestone. As of October 23, 2023, the proposal was approved!

Platform Support

It's hard to predict when Temporal will become a standard and be available in all browsers, but there's progress. For instance, the V8 implementation of Temporal now occupies over 2.6% of the binary, and you can already use it in Deno.

Current Status and Future Outlook

Development on Temporal continues, with seemingly no remaining major blockers. You can track the current status here: GitHub Issues - Proposal Temporal.

For example, recently (May 2024), a method was removed - an intriguing change for a proposal on its way to becoming a standard. Does this mean Temporal is not ready yet? No, I think for a long time we can imagine Temporal as a mature date library that evolves and develops smoothly, just like any other NPM library.

So, what's better — a library with specific APIs without feature, or Temporal - a well-done, comprehensive date framework with ongoing improvements?

Polyfill

The only complexity with Temporal is the size of the polyfill. However, an alternative polyfill has been in development for some time now — temporal-polyfill by FullCalendar. Its size is much more appealing: 60.7 kB to 21.7 kB (gzip). And I plan to use it in my next project! How about you?

My criticism about the new Observables API

Artyom — Wed, 20 Dec 2023 20:38:40 +0000

"Observable" is a common pattern for composing a pipeline of sync and async operations. The meaning of this pattern is to give the ability to simplify code decoupling, which is an important and powerful architectural technique. It is already used in various libraries and seems pretty solid.

So, is it worth making it a part of the platform? I don't think so, and here is why...

This article is a summary of my thoughts on these issues: https://github.com/WICG/observable/issues/56 and https://github.com/WICG/observable/issues/41.

When we build a worldwide platform that has no possibilities for breaking changes, we should choose new primitives very carefully. Let's investigate all the pros and cons.

Advantages

It is important to understand that we are talking not about "Observable" as it is, but specifically about adding it to the platform and what benefits this standardization could give us.

bundlesize improvements, but the proposed core features took only ~1kb, which is not much.
API standardization for better ecosystem compatibility is an important point, but the interface is simple as it is and there are not many ways to do it wrong.
event reliability and boilerplate improvements are the most useful and important points of this proposal, but the Observable pattern is not the only way to achieve them.

Drawbacks

What could go wrong if we add Observables to the platform?

It would introduce another way to accomplish the same thing, which would confuse beginners and make the platform more complex. We already have callbacks, promises, async/await, events, streams, and generators.
There will always be a shortage of operators. Definitely check out rxjs.dev/api.
We are uncertain about how it should work. The popular observables library RxJS is constantly improving and changing. Its internal logic and codebase are not simple. So, why do we assume that the current proposed API will be sufficient for us in the future?

The last question is the most important for the web platform.

I have been researching and developing reactive primitives for more than 5 years already, and what I'm sure of is that we still don't know enough about it.

A lot of problems developers encounter are due to the glitch problem. There are many ways to handle it, but there is no universal solution. Here is a brief overview from the "Angular Reactivity with Signals" topic.

Even Angular recently moved a part of the "reactive work" from observables to the new (or old?) "signals". Is this the beginning or the end of the journey?

A good reactive platform should cover a lot of cases: glitches, priority scheduling, contextual execution, aborting, and error handling. And there are no standards in these questions, we are still in the middle of researching and working on it.

So, okay, we will add the current proposal to the platform. Will it still be relevant after 5 or 10 years?

Requirements

The only way we could accept this whole new paradigm on the platform is if it is investigated and integrated well.

We should have strong guidelines (or APIs) for glitch solving. It is heavily related in general with scheduling and the new Prioritized Task Scheduling API, which is currently supported only in Chromium.

I am sure that people will not be satisfied with the current built-in methods and will continue to import libraries with prototype patches (here we go again)! The exact set of methods is a sensitive topic, and I don't think there can be a good design. The only reasonable option is to reuse existing methods from other APIs, which is why iterator-helpers should be investigated and implemented first.

That was my objective opinion as an experienced developer and team lead.

Now, I want to share my personal opinion as a library author.

Workaround

Don't get me wrong, but for me, streams are a very specific and archaic programming model that can only handle a strict pipeline of operations well. When we have conditions in the pipeline, things get a lot more complicated.

One of the most complicated aspects of streams is that you can't put a debugger point on a line of the source code and see all the related variables. In a regular async function, you can easily inspect all the variables in the closures, but stream debugging is much more complicated and not user-friendly.

I have been searching for ways to solve this for many years, and at a certain point, I realized that we don't need additional decorators at all. We can use regular functions and native async/await if we accept cancellation context for all our computations. This problem is perfectly solved with the new AsyncContext proposal. The code looks much simpler but remains more flexible for inspections and refactoring.

Let's take a look at the code example from the Observable proposal.

input
  .on("input")
  .debounce(1000)
  .switchMap((promiseOptions /* ??? */) =>
    fetch(`/somelookup?q=${input.value}`, { signal: promiseOptions.signal })
  )
  .switchMap((response) => response.json())
  .forEach(updateLookaheadList);

Here is how it could be done differently.

input.oninput = concurrent(async () => {
  await sleep(1000); // "lodash" or whatever you want.
  const response = await bind(
    fetch(`/somelookup?q=${input.value}`, { signal: asyncAbort.get().signal })
  );
  updateLookaheadList(await bind(response.json()));
});

The utils realization is pretty simple.

let controller = new AbortController();
const asyncAbort = new AsyncContext.Variable(controller);
function concurrent(cb) {
  controller.abort();
  return asyncAbort.run((controller = new AbortController()), cb);
}
async function bind(promise) {
  const result = await promise;
  asyncAbort.get().throwIfAborted();
  return result;
}

In the code above, the "async" code style is more naive and native, making it much easier to inspect and debug. It's also easier to add conditions to the logic without using additional operators. You can use regular if, switch, custom pattern matching, or whatever you want. You only need to care about the async/Promise interface, which has been a more general part of the platform for a long time already.

You could add sampling (takeUntil) easily.

input.oninput = concurrent(async () => {
  await promisifyEvent(input, "blur");
  const response = await bind(
    fetch(`/somelookup?q=${input.value}`, { signal: asyncAbort.get().signal })
  );
  updateLookaheadList(await bind(response.json()));
});

Utils.

function promisifyEvent(target, type) {
  const { promise, resolve, reject } = Promise.withResolvers();
  const unsubscribeEvent = onEvent(target, type, resolve);
  const unsubscribeAbort = onEvent(asyncAbort.get().signal, "abort", reject);
  return promise.finally(() => {
    unsubscribeEvent();
    unsubscribeAbort();
  });
}
function onEvent(target, type, cb) {
  target.addEventListener(type, cb);
  return () => target.removeEventListener(type, cb);
}

But what about reactivity? It is a challenging topic with numerous edge cases, and I believe it would be preferable to depend on the expertise of library authors to have the ability to choose the needed behavior for your task exactly.

Here is the "streamStock" example from the proposal with my own library: https://www.reatom.dev/package/web/#onevent. I used the explicit ctx as the first argument in all methods instead of the implicit "AsyncContext". With Reatom, you can have more debugging abilities for your code and manage the streams' lifetimes. I'm not advertising my library; it has limitations that may not be acceptable for some people. I just want to show that everything is possible in many ways. We have different general ideas that we should investigate first. There are no significant reasons to choose Observables until the end of our web trip.

Choosing the right primitive for such a huge platform, as we have, is an important decision. I don't think the Observable will be profitable enough. It could only solve a limited set of tasks, but it would add a huge mental load for newcomers.