alex ▲

Software Engineer 👨🏼‍💻 · Tech Lover 🌐 · Lead Frontend Architect 👷🏻 · AI Researcher 🤖

[alex ▲ @aldexdev]

Cost is a first-class UI primitive in AI products. Design it in from the start — hiding it churns your subscribers when the bill arrives.

Three places every AI feature needs cost surfaced:

Before the action. Estimated $ + token count next to the Run button. Let users switch models if they don't want to pay Sonnet prices for a Haiku task.

Live budget bar. Monthly usage vs cap, always visible. Warn when approaching. Users cancel from surprise bills, not from cost — surprise is the churn driver.

Per-message receipt. After each action: duration, tools used, tokens in/out, cost. Users learn which of their patterns are expensive and adjust behavior.

The 2024 default was "hide the meter, hope for the best." The 2026 default is a cost widget in every AI-native surface. If you're building an AI feature without cost surfaced, you're building your churn plan.

[alex ▲ @aldexdev]

"We need real-time" is the vaguest requirement in frontend. Here are the 4 tools and when to pick each.

SSE (Server-Sent Events) — one-way server → client. Pick for LLM token streaming, notification feeds, live logs, receive-only dashboards. Simplest primitive on the platform.

WebSockets — bidirectional, low-latency. Pick for chat, multiplayer, trading floors, anywhere the client also emits. Pay for reconnect + scaling complexity.

Convex/Supabase Realtime — reactive database subscriptions. Pick for any app where "live" = "query result changed." Skip building the sync layer.

Liveblocks/PartyKit/Yjs — CRDT presence + collaboration. Pick for Figma-style multiplayer, live cursors, offline-first. Conflict resolution comes free.

The mistake: WebSockets for everything. It's the sledgehammer of the four. Start with SSE. Add the others only when the shape demands it.

[alex ▲ @aldexdev]

PRDs are dead. Specs replaced them. If you're still writing 6-page PRDs in Confluence in 2026, you're documenting for a workflow that no longer exists.

The old PRD: written by PM alone, debated with eng after the fact, filled with user stories + acceptance criteria, read once, forgotten by week 2.

The 2026 spec: written by design engineer + PM in the same doc, in the same hour. Precise props · states · a11y · motion · error paths. Committed next to the code. Read by engineers, tests, docs, and every AI agent that touches the feature.

The mental shift: the PRD was documentation for humans who might build the thing. The spec is executable input for the systems that will.

If your PM writes PRDs that no engineer reads twice, kill the template this week. Rewrite the next feature as a spec. Feel the difference in review speed.

[alex ▲ @aldexdev]

If your AI product feels like ChatGPT 2023, you built the clone. Four UI patterns became table stakes in 2026.

Streaming responses. Token-by-token paint. Users read while the model writes. Buffering server-side and flushing at the end is the tell of a team who copied a demo, not a product.

Agent loops with visible plans. Multi-step runs need a task list, each step toggling done live. Hidden progress = users abandon.

Cost/token indicators. $ and token counts visible next to every action. Users decide between a $2 query and a $0.02 one — if you let them.

Generative blank slate. Empty state is 3–6 example prompts, not "Get started" copy. Users don't know what to ask. Pre-seed the good questions.

None of these were considered "UI" in 2022. In 2026, they're where AI products differentiate. The chatbox is now the least important surface.

[alex ▲ @aldexdev]

@alexabelonix Thaaanks!😊

[alex ▲ @aldexdev]

Cursor · Zed · VS Code — pick by the loop you're in, not by tribe.

Cursor wins when you're mostly generating. Inline AI edits, agent tabs, tight loop with the model. Startup-solo and AI-heavy teams live here.

Zed wins when latency compounds. Rust-native, GPU-accelerated, Vim keys, collab built in. Senior ICs on large codebases where every 100ms of editor lag adds up.

VS Code wins when the extension ecosystem is the moat. Enterprise, regulated teams, existing tooling investment. Copilot + Claude side by side in one place.

Every senior I know runs 2 of these — Zed for reading, Cursor for generating. Or reversed. The single-editor loyalty conversation is over.

[alex ▲ @aldexdev]

The senior principle for 2026: push code down the stack.

Three layers:

The web platform — browser, CSS, HTML, Wasm, JS runtime. Container queries, view transitions, anchor positioning, speculation rules, popover API. Thicker every year. Absorbs what was framework-only last year.

The framework — Next.js, Astro, SvelteKit. Routing, streaming, cache primitives, DX. Thinner every year. Compiler over runtime. What used to be framework code is now compiler output or platform primitive.

Your product — business logic, data model, design. Should be as thin as possible. Every line here that could live in a lower layer is a maintenance liability you're paying for by choice.

The senior audit: once a quarter, walk your product code and ask each abstraction: does this belong here, or one layer down? The thing you built last year that the platform now does natively is your quarterly deletion goal.

Frontend engineers in 2026 don't add. They subtract, and lean harder on the layers underneath.

[alex ▲ @aldexdev]

The design engineer isn't a hybrid. It's the role that absorbed everyone else's boring middle 20%.

Designers kept: visual language, UX flows, user research, Figma systems. Ceded: micro-interactions in prod, motion tokens, a11y fine-tuning.

Engineers kept: data flow, API contracts, perf, infra. Ceded: UI component library, design system enforcement, "how does it feel" reviews.

Design engineers picked up the ceded 20% from both sides. Ship the component library in code. Own tokens.json as the source of truth. Run v0/Lovable/Claude Code + Figma MCP as their daily toolkit. Ship prototypes to prod.

The reason the role exploded in 2026: the Figma→code handoff was the biggest bottleneck in every product team. AI tools made it cheap to skip. Someone had to own the space between the two disciplines.

If your team ships slowly at the "design done, engineering starting" boundary, you're not short an engineer. You're short a design engineer.

[alex ▲ @aldexdev]

The 2015 pyramid: many unit tests at the bottom, some integration in the middle, few E2E at the top. It made sense when writing tests was slow and browsers were expensive.

The 2026 pyramid is inverted: many Playwright E2E tests, some component + integration tests, few unit tests. Why:

Playwright cost collapsed. Cloud-parallelized, sharded, sub-minute for hundreds of tests. What used to justify the "few E2E" line no longer holds.

AI writes 60%+ of implementation code. The implementations change constantly. Unit tests tied to those implementations become churn. Tests should validate outcomes, not the implementation-of-the-week.

Users hit combinations. Unit tests validate isolated functions. Nobody in production is running functions in isolation.

Kill your snapshot tests. Kill your provider-mocking React unit suites. Move the coverage up the pyramid. The team ships faster and catches more real bugs.

[alex ▲ @aldexdev]

Progressive enhancement was declared dead in 2018. It's not just back — AI browsers made it a compatibility requirement.

Three layers, bottom-up:

Layer 01 — Works for everyone. Real HTML forms, real links, Server Actions submit as regular POSTs. Works with JS disabled, on 2G, in screen readers, in scrapers, in AI browsers — before a single hydration boundary runs.

Layer 02 — Better with JS. Optimistic updates, client-side transitions, instant feedback. Layers on top. If it fails to load or the agent bypasses JS, everything under still works. Enhancement, not requirement.

Layer 03 — Best-case path. Real-time, presence, collab. Only for users on modern clients with the JS bundle loaded. Everyone else already had a working app from layer 01.

The 2026 twist: AI browsers and coding agents access your site with JS off half the time. Every senior team I know is instrumenting for "did our app work without JS?" as a first-class metric.

Progressive enhancement isn't a philosophy anymore. It's compatibility with the audience you don't see.

[alex ▲ @aldexdev]

Three data-fetching tools coexist in every serious 2026 codebase. Picking one for everything is the tell of a team that skipped the design conversation.

Server Components — for reads. Page-level loads, SEO-critical content, anything the user waits on before paint. Fetch runs on the server, client never sees the request.

Server Actions — for mutations. Form submits, create/update/delete, optimistic updates, progressive-enhancement-friendly writes. A server function you can call from a form or from client JS.

TanStack Query — for live client state. Infinite scroll, polling, websocket-driven UI, cache-heavy dashboards. Client cache over any API, with dedupe + stale-while-revalidate for free.

The don't:
– Don't use RSC for anything interactive after first paint – Don't use Server Actions for reads or read-heavy loops (they're not fetch endpoints)
– Don't use TanStack Query for initial page data (you're re-inventing SSR badly)

Every serious app in 2026 runs all three, each on its strengths. Picking one tool as the hammer costs your team weeks per feature.

[alex ▲ @aldexdev]

Astro's "islands" got the credit. Server-first was the actual innovation.

The old default: ship 200KB of framework, hydrate the entire page, re-render on every state change. Every component paid the framework tax whether it needed to or not.

The Astro shift: static HTML is the default. JS is opt-in, component by component. Hydration is a strategy (client:load, client:visible, client:idle), not a state you're born into.

This won the argument. React copied it via Server Components. Next.js reorganized around it. Even Remix loader/action mental model rhymes.

When to pick Astro directly: content-heavy sites (docs, blogs, marketing) where 90% is prose. When to pick Next / SvelteKit: app-heavy products where interactivity dominates.

But steal the mental model everywhere: server-first, JS opt-in. The framework name is secondary.

[alex ▲ @aldexdev]

State management got boring in 2026. That's the whole story.

2020 stack: Redux + Redux Toolkit + Redux-Saga + Reselect + normalizr. Five libraries to manage what you didn't need most of the time.

2026 stack: Zustand for UI state (~30 lines), TanStack Query for server state, or nothing at all if you're in Server Components.

The winner isn't a library. It's the realization that most "state" is really server cache, and everything else fits in a single tiny store.

If your team still has a Redux migration on the roadmap in 2026, delete the roadmap. Delete the tickets. Rewrite the affected files in an afternoon. You'll ship faster next week.

[alex ▲ @aldexdev]

Vibe coding works. Until it doesn't. The line is sharper than the discourse admits.

Where it works: greenfield + throwaway. Prototypes, internal tools used by <10 people, landing pages with a 2-week shelf life, hackathons, side projects, anything you'd rewrite if it caught on. Low blast radius, short half-life.

Where it breaks: long-lived production. Codebases anyone else will maintain, multi-tenant apps with auth + billing, regulated data, cross-team contracts, migration paths, performance budgets you can't violate. Compounding cost, multi-year liability.

The mistake isn't using vibe coding. It's not knowing which side of the line you're on when you start. A team that vibe-codes its first version and ships it to enterprise customers is paying interest on the gap between the two for years.

Before you start the next thing, ask: which side of the line is this? Then pick the toolchain that matches.

[alex ▲ @aldexdev]

Most frontend teams measure things that don't change their next decision. That's not telemetry, that's journaling.

Three swaps that fix 90% of dashboards:

Pageviews / clicks → task success rate per flow. "X% of users completed checkout / signup / deploy in the last 24h." That's a business signal. Pageviews is a vanity number.

Core Web Vitals averages → p75 + p95 by route + device. Averages hide the long tail. Your fastest users drown the suffering of your slowest. Sentry and PostHog will group this for free if you ask.

Error counts → errors per session, per release, tied to deploy SHAs. "12,000 errors" is a number. "Errors per session jumped 4× after the 14:00 deploy" is an action.

The frontend telemetry question is not what can we measure. It's what would change our next decision. If a dashboard doesn't change a decision, kill it. The team will move faster with fewer, sharper signals than with more, noisier ones.

[alex ▲ @aldexdev]

Don't build auth in 2026. A decision tree.

Is auth your product?

NO (99% of teams) → do you need enterprise SSO + SCIM?

No → Better Auth, Auth.js, or Lucia. Open-source, you own the DB, free forever.
Yes → WorkOS, Clerk, or Auth0. SAML + SCIM + audit logs in one SDK call.

YES → fine, build it. But hire a security specialist and accept that you've made auth a permanent line item.

Every senior I respect has built auth from scratch once. None of them want to do it again. The 2026 ecosystem is mature enough that "we'll do it better ourselves" is wrong unless identity is literally the product.

Save the engineering hours. Spend them on the thing your competitors can't replace with an SDK.

[alex ▲ @aldexdev]

The junior frontend pipeline is collapsing.

Junior postings are down ~70% since 2022. Companies extracted short-term wins by replacing entry-level output with AI. That bill comes due in 2029, when nobody has the on-ramp to senior anymore.

Three things teams should be doing now:

1. Hire for review, not write. Juniors who can critique AI output learn faster than juniors who only generate.
2. Pair them with AI, not seniors. Free up senior time. Make the AI an always-on rubber duck.
3. Ship spec-writing first. Specs teach systems thinking before they teach code. Inverted ladder.

The market is solving the short-term problem (faster output) by creating the long-term one (no pipeline). Senior engineers in 2029 don't grow on trees.

[alex ▲ @aldexdev]

Monorepos won the debate. The 2026 stack is boring on purpose:

pnpm for the package manager. Content-addressable store, strictest defaults, fastest installs at scale.

Turborepo for task orchestration. Remote caching, dependency-aware incremental builds. Every team I know hit ROI in week one.

workspace:* + tsconfig paths for internal deps. No publish step internally, IDE jumps work everywhere.

GitHub Actions + Turbo remote cache for CI. Only re-run what changed.

When to pick Nx instead: you're polyglot (React + Angular + Node services in one repo), or you need generators / executors / graph-based scope rules.

Otherwise stop relitigating. The boring stack ships.

[alex ▲ @aldexdev]

4 CSS features that quietly killed your JS libraries in 2026.

container — components respond to their container, not the viewport. Killed react-use-measure, react-resize-detector, every JS responsive hook.

anchor-positioning — native popovers tethered to a trigger, edge-aware, scroll-aware. Killed popper.js and ~80% of floating-ui.

animation-timeline — parallax, scroll-triggered reveals, progress indicators. Compositor-driven, 60fps free. Killed scroll-bound react-spring and GSAP ScrollTrigger usage.

view-transition — cross-document transitions, shared element morphs. 0 KB, a11y-correct. Killed framer-motion layoutId for route transitions.

The audit to run this quarter: open your package.json. Cross-reference every UI dep against the WICG roadmap. There's at least one library in there that's now JS-for-JS-sake.

[alex ▲ @aldexdev]

The senior frontend deliverable changed in 2026. It used to be code. Now it's the spec.

A good spec is read by four consumers: generation (Claude / Cursor / v0), tests (Playwright + Vitest), LLM review ("does this match the spec?"), and docs (auto-generated from the same source).

When you write a spec well, the code, the tests, the review, and the docs all line up. When you skip it, every layer drifts independently and you discover the drift in production.

The shift in mental model: – 2022: spec is documentation overhead before you write the code. – 2026: spec is the source of truth. Code is the by-product that should be the cheapest layer of the stack.
Try this for one week: spend 60% of your time on the spec, 40% on review. Generate the code from the spec. The team's output velocity goes up, not down.