DEV Community: DevUnionX

Node.js in 2026: The Event Loop, Safe Singletons, and Modern Parallelism

DevUnionX — Fri, 30 Oct 2026 15:56:32 +0000

Node.js has evolved significantly, but its core architecture remains built around one important principle: keep the main JavaScript thread non-blocking.

As applications become more complex, understanding asynchronous execution alone is no longer enough. Developers also need to understand event loop performance, shared state, request isolation, and parallel processing.

In this article, we'll explore how these concepts work together and how to build scalable Node.js applications in 2026.

1. Understanding the Node.js Event Loop

Node.js runs JavaScript on a single main thread by default. However, this doesn't mean it can only handle one operation at a time.

It relies on libuv, a C library that manages asynchronous I/O and provides a thread pool for operations that cannot be handled directly through non-blocking operating system APIs.

This architecture allows Node.js to handle multiple network requests, file operations, and other asynchronous tasks without waiting for each one to finish.

Event Loop Phases

The event loop processes callbacks through several phases:

Timers: Executes eligible setTimeout() and setInterval() callbacks.
Pending Callbacks: Handles certain deferred system-level I/O callbacks.
Poll: Processes incoming I/O events and waits for new events when necessary.
Check: Executes setImmediate() callbacks.
Close Callbacks: Handles events such as socket closures.

The idle and prepare phases also exist but are primarily internal to Node.js.

An important change arrived with Node.js 20, through libuv 1.45.0: timers are now processed after the poll phase on each event loop iteration, rather than both before and after it. This can affect the interaction between timers and setImmediate().

setTimeout() vs setImmediate()

These two functions are often confused.

setTimeout(() => {
  console.log("Timeout");
}, 0);

setImmediate(() => {
  console.log("Immediate");
});

When called from the main module, their execution order is not guaranteed.

However, inside an I/O callback, setImmediate() executes before the timer callback:

import fs from "node:fs";

fs.readFile(import.meta.filename, () => {
  setTimeout(() => console.log("Timeout"), 0);
  setImmediate(() => console.log("Immediate"));
});

Understanding this difference helps prevent timing-related bugs.

Microtasks and process.nextTick()

Promises use the microtask queue, while process.nextTick() uses a separate next-tick queue.

Both are processed at specific points before Node.js continues normal event loop execution.

However, recursively scheduling process.nextTick() can prevent the event loop from reaching I/O operations.

function recursiveTask() {
  process.nextTick(recursiveTask);
}

recursiveTask();

This is an example of event loop starvation. Avoid creating endless chains of high-priority callbacks.

2. Event Loop Performance: What Should You Monitor?

Knowing how the event loop works is useful, but measuring its performance is even more important.

Event Loop Delay measures how late the event loop executes scheduled callbacks compared with their expected execution time.

High delay can indicate:

CPU-intensive JavaScript operations.
Synchronous file system operations.
Expensive JSON processing.
Complex regular expressions.
Excessive callback execution.

Node.js provides monitorEventLoopDelay() through the built-in perf_hooks module.

import { monitorEventLoopDelay } from "node:perf_hooks";

const histogram = monitorEventLoopDelay({
  resolution: 20
});

histogram.enable();

setInterval(() => {
  const p99 = histogram.percentile(99) / 1e6;

  console.log(`Event Loop Delay P99: ${p99.toFixed(2)} ms`);

  histogram.reset();
}, 10000);

Monitoring event loop delay alongside CPU usage, memory consumption, and request latency provides a much clearer picture of application health.

Another important component is the libuv thread pool.

Some file system, DNS, cryptographic, and compression operations use this pool. Its default size is four threads, and it can be configured using UV_THREADPOOL_SIZE.

When too many expensive operations compete for these threads, otherwise unrelated tasks may experience delays.

Remember: asynchronous does not automatically mean unlimited scalability.

3. The Evolution of the Singleton Pattern

The Singleton pattern is a familiar design pattern that ensures a resource is created once and reused.

In Node.js, module caching makes this relatively easy.

For example, CommonJS caches modules after their first load. Subsequent calls to require() for the same resolved file return the cached module.

With modern ES modules, module-level variables are also a convenient way to share resources.

// database.js

export const database = createDatabaseConnection();

Other modules importing this resource can reuse the same instance within that runtime.

However, this simplicity introduces an important problem: shared mutable state.

Imagine multiple HTTP requests using the same singleton service. If the service stores request-specific information in its properties, one request may accidentally affect another.

This is especially dangerous when dealing with authentication, user sessions, tenant information, and temporary request data.

The Solution: AsyncLocalStorage

Node.js provides AsyncLocalStorage to maintain isolated context across asynchronous operations.

It allows request-specific information to follow an asynchronous execution chain without passing it manually through every function.

import { AsyncLocalStorage } from "node:async_hooks";
import { randomUUID } from "node:crypto";

export const requestContext = new AsyncLocalStorage();

// Express middleware
app.use((req, res, next) => {
  requestContext.run(
    {
      requestId: randomUUID(),
      userId: req.user?.id
    },
    next
  );
});

Any service can access the current request context:

export function log(message) {
  const context = requestContext.getStore();

  console.log({
    requestId: context?.requestId,
    message
  });
}

This provides request-level context while allowing shared services to remain singletons.

A useful distinction: AsyncLocalStorage isolates context, not arbitrary mutable objects. Keep request data inside its own context and avoid placing user-specific state on shared singleton instances.

4. Async Initialization: Avoid Duplicate Instances

Singletons also introduce another common problem: asynchronous initialization.

Consider a database client that takes time to initialize.

If multiple requests call the initialization function before the first operation finishes, the application may accidentally create multiple connections.

A simple solution is to cache the initialization Promise.

let clientPromise;

export function getDatabaseClient() {
  if (!clientPromise) {
    clientPromise = createDatabaseClient().catch((error) => {
      clientPromise = undefined;
      throw error;
    });
  }

  return clientPromise;
}

Now, concurrent callers receive the same Promise and wait for the same initialization process.

Resetting the Promise after failure also allows a later call to retry initialization.

For production applications, remember to combine this approach with proper connection lifecycle management and reconnection handling.

5. Moving Beyond One Thread: Worker Threads

The event loop is excellent for handling asynchronous I/O, but CPU-intensive JavaScript can still block the main thread.

Examples include:

Image processing.
Large data transformations.
Complex mathematical calculations.
Machine learning inference.
Expensive parsing operations.

For these workloads, Node.js provides the built-in worker_threads module.

Workers execute JavaScript in separate threads, each with its own V8 instance and event loop.

Importantly, Worker Threads and the libuv thread pool are not the same thing.

The libuv pool handles certain background operations. Worker Threads allow developers to execute their own JavaScript workloads in parallel.

Why Worker Pools Matter

Creating a new worker for every incoming request is usually inefficient.

Worker startup introduces memory and initialization overhead. Instead, a better approach is to maintain a fixed number of workers and distribute tasks between them.

This is known as the Worker Pool pattern.

Incoming Tasks
      |
      v
  Task Queue
      |
      v
  Worker Pool
   /   |   \
  v    v    v
 W1   W2   W3
   \   |   /
      Results

A worker pool reuses existing threads rather than creating new ones for every task.

For ordinary network requests, database queries, and asynchronous file operations, Node.js's built-in asynchronous APIs are generally the better choice.

6. Sharing Data Between Worker Threads

Workers need a way to communicate and exchange information.

Node.js provides two common approaches.

1. Message Passing

Workers can exchange messages using postMessage().

worker.postMessage({
  task: "process-data",
  payload: [10, 20, 30]
});

worker.on("message", (result) => {
  console.log(result);
});

Objects are generally transferred using structured cloning. This provides isolation because each worker receives its own copy.

For large buffers, transferable ArrayBuffer objects can avoid unnecessary copying by transferring ownership.

2. SharedArrayBuffer and Atomics

For scenarios requiring shared memory, Node.js supports SharedArrayBuffer.

Multiple threads can access the same memory region without copying data.

However, this introduces synchronization challenges.

const sharedBuffer = new SharedArrayBuffer(4);
const sharedArray = new Int32Array(sharedBuffer);

Atomics.add(sharedArray, 0, 1);

Atomics provides operations that help coordinate access to shared memory.

Without proper synchronization, concurrent writes can produce inconsistent results and difficult-to-debug race conditions.

For most applications, message passing is the simpler starting point. Use shared memory only when its performance benefits justify the additional complexity.

7. Framework Choices in 2026

The Node.js ecosystem offers several approaches to building backend applications.

Express

Express remains a flexible option with a large ecosystem and minimal architectural restrictions. It works well for smaller services, prototypes, and existing applications.

Fastify

Fastify focuses on performance, schema-based validation, and efficient request handling. It is worth considering for high-throughput APIs.

NestJS

NestJS provides a structured architecture with dependency injection, modules, decorators, and lifecycle management. It is particularly useful for large TypeScript applications and teams.

There is no universally best framework.

The right choice depends on performance requirements, application complexity, team experience, and maintainability. Always benchmark using your actual workload rather than relying entirely on generic benchmark results.

8. Singleton Patterns in Serverless Applications

Singleton behavior becomes more interesting in serverless environments such as AWS Lambda.

A serverless execution environment may be reused across multiple invocations. Therefore, module-level variables and singleton instances can survive between requests.

This can be useful for expensive resources such as database clients and SDK instances.

For example:

import { S3Client } from "@aws-sdk/client-s3";

const s3 = new S3Client({
  region: process.env.AWS_REGION
});

export const handler = async (event) => {
  // Reuse the existing client
};

Creating a new SDK client for every invocation is often unnecessary.

However, never store user-specific mutable information in a global singleton.

A useful rule is:

Reuse expensive infrastructure clients where supported.
Keep request-specific data local to each invocation.
Never assume module-level state is durable.
Use lazy initialization for expensive optional dependencies.
Keep deployment bundles small to reduce cold-start overhead.

Also remember that multiple serverless execution environments can run independently. A singleton is never a replacement for shared, durable distributed storage.

just added a new versiyon of css features

DevUnionX — Tue, 27 Oct 2026 18:40:12 +0000

DevUnionX

Oct 27

The 10 Best New CSS Features in 2026 Already Supported in All Major Browsers

#webdev #website #html #css

16 min read

The 10 Best New CSS Features in 2026 Already Supported in All Major Browsers

DevUnionX — Tue, 27 Oct 2026 18:37:46 +0000

CSS has evolved far beyond styling colors, spacing, and layouts. Modern CSS can respond to a component's available space, react to elements inside a selector, generate more consistent color palettes, improve typography, and handle UI behavior that once required JavaScript.

But there is an important distinction: a feature being available in 2026 does not mean it was invented in 2026, or that every browser version supports it.

In this updated guide, we'll look at ten practical groups of CSS features worth knowing in 2026, including several from my 2025 CSS roundup. We'll also explore three newer capabilities that deserve attention but should be introduced progressively.

The support notes use Web Platform Baseline and current MDN documentation. Baseline is a useful starting point for cross-browser decisions, but it doesn't guarantee compatibility with older browsers, embedded webviews, or every detail of a feature.

Let's get into it.

1. Container Queries: Make Components Responsive to Their Own Space

Traditional media queries respond to the viewport. That's useful for page layouts, but it can become awkward when the same component appears in different places.

Imagine a product card used in a full-width grid, a narrow sidebar, and a mobile layout. A viewport media query tells the card how wide the screen is, not how much room the card actually has.

Container queries solve this problem by letting a component respond to its container's size.

.product-card {
  container-type: inline-size;
}

.product-card__content {
  display: grid;
  gap: 1rem;
}

@container (min-width: 34rem) {
  .product-card__content {
    grid-template-columns: 9rem 1fr;
    align-items: center;
  }
}

The card's content switches to a two-column layout when the container becomes wide enough. The same component can now work in different layouts without relying on viewport-specific breakpoints.

This is especially useful for reusable components in design systems, dashboards, product grids, and component-driven React applications.

Why it matters: You can make components more independent of the page layout in which they are used.

Browser support: Container size queries are widely available in modern browsers. See MDN's container queries guide.

2. Container Style Queries: Let Components React to Their Context

Size queries ask, "How much space does my container have?"

Style queries ask a different question: "What styling context does my container provide?"

For example, a component might need a different appearance when its parent declares a dark theme or a compact layout. Container style queries can check a custom property on the container and apply styles to its descendants.

.theme-context {
  --theme: dark;
}

@container style(--theme: dark) {
  .card {
    background: #111827;
    color: #f9fafb;
    border-color: #374151;
  }
}

Here, the .card can react to the value of --theme on an ancestor container rather than requiring JavaScript to attach another class to every card.

You can use the same principle for design-system variants, compact components, and other context-dependent styling decisions.

One important detail: style queries can use custom properties, but their support and syntax should still be checked against the browser versions your application targets.

Why it matters: CSS can express more component-level styling rules without making every variation a JavaScript-managed state.

Browser support: Container style queries became Baseline Newly Available in 2026. That makes them worth learning, but older browser versions may not support them. See MDN.

3. The `:has()` Selector: CSS Can React to Descendants

For a long time, styling an element based on what it contained often meant adding a class with JavaScript.

The :has() pseudo-class gives CSS a way to select an element based on matching descendants or related elements.

For example, you can highlight an entire form group when one of its inputs is invalid:

.form-group:has(input:invalid) {
  border: 1px solid crimson;
  background: #fff5f5;
}

.card:has(img) {
  padding: 0;
  overflow: hidden;
}

The first selector reacts to the state of an input inside the form group. The second changes a card's layout when it contains an image.

You can also combine :has() with other selectors to build more expressive UI rules:

.form-group:has(input:focus-visible) label {
  color: #6d28d9;
}

This is useful for forms, navigation, selected cards, and UI states that can be described through the DOM.

There is one limitation worth remembering: :has() doesn't replace all JavaScript state management. Use JavaScript when the behavior involves application logic, asynchronous data, or state that cannot be inferred reliably from the document.

Why it matters: It reduces the need for extra classes and DOM-manipulation code when the desired style depends on element relationships.

Browser support: :has() is widely available in modern browsers. It was also one of the most-used features in the State of CSS 2026 survey.

4. CSS Nesting, Cascade Layers, and `:where()`: Keep Large Stylesheets Manageable

CSS projects become difficult to maintain when component rules are scattered throughout a stylesheet, specificity keeps increasing, and third-party styles conflict with application styles.

Three established features can help: native CSS nesting, cascade layers, and the :where() selector.

Native CSS nesting

You can group related selectors inside a parent rule:

.card {
  border: 1px solid #e5e7eb;
  border-radius: 0.75rem;
  overflow: hidden;

  .card__title {
    font-size: 1.25rem;
    font-weight: 700;
  }

  &:hover {
    box-shadow: 0 8px 24px rgb(0 0 0 / 10%);
  }
}

The card's title and hover styles now live beside the styles they belong to. This is built into CSS, so a preprocessor such as Sass is not required just to nest selectors.

Cascade layers

Use @layer to define a deliberate order for your stylesheet:

@layer reset, base, components, utilities;

@layer base {
  :where(h1, h2, h3) {
    line-height: 1.15;
  }
}

@layer components {
  .button {
    padding: 0.75rem 1rem;
    border-radius: 0.5rem;
  }
}

@layer utilities {
  .text-red {
    color: crimson;
  }
}

For normal declarations, later named layers take precedence over earlier layers, regardless of selector specificity. There is an important caveat: normal declarations outside named layers take precedence over normal layered declarations. For predictable results, plan how your project uses layered and unlayered styles.

Reduce specificity with `:where()`

The :where() pseudo-class has zero specificity:

:where(.button, .link) {
  border-radius: 0.5rem;
  text-decoration: none;
}

This makes it useful for resets, default styles, and shared design-system rules that should be easy to override.

Why it matters: These features help make CSS easier to read, organize, and maintain as a project grows.

Browser support: CSS nesting, cascade layers, and :where() are widely available in modern browsers. See MDN's CSS nesting documentation and cascade layers guide.

5. Better Typography: `text-wrap`, `font-size-adjust`, and Ruby Layout

Good typography is more than choosing a font. Line breaks, fallback fonts, and annotations can all affect readability.

Balance headings with `text-wrap: balance`

A heading can look awkward when a single word is left on its own line. text-wrap: balance asks the browser to distribute text across lines more evenly.

h1,
h2,
h3 {
  text-wrap: balance;
}

It's especially useful for titles, hero headings, and short text blocks. Avoid applying it indiscriminately to every long paragraph: balancing text has a computational cost, and browsers limit how many lines they balance.

Improve paragraph wrapping with `text-wrap: pretty`

For longer text, text-wrap: pretty asks the browser to favor more pleasing line breaks, including reducing awkward short final lines.

.article-content {
  text-wrap: pretty;
}

It's a useful enhancement for blogs, documentation, and editorial websites. However, support for this value varies more than support for text-wrap: balance, so test the browsers your readers use.

Keep fallback fonts more consistent with `font-size-adjust`

When a preferred font is unavailable or hasn't loaded, the fallback may have very different lowercase letter proportions.

body {
  font-family: "MyWebFont", Arial, sans-serif;
  font-size-adjust: 0.52;
}

The value is only an example; choose one appropriate to your intended font metrics. This property adjusts font sizing to help preserve visual proportions when different fonts are rendered.

Use Ruby layout for annotated text

For languages and learning materials that use ruby annotations, such as Japanese furigana, the ruby-align and ruby-position properties can provide more control.

ruby {
  ruby-align: center;
  ruby-position: over;
}

This is a specialized feature rather than a universal requirement, but it is valuable for multilingual education and reference content.

Why it matters: These properties make it possible to improve readability and text layout with less manual adjustment.

Browser support: text-wrap is broadly available, but individual values can differ in support. font-size-adjust and Ruby layout properties are also available in current browsers; check their precise compatibility before relying on a particular value. Useful references: text-wrap, font-size-adjust, and ruby-position.

6. More Stable Layouts and Faster Long Pages: `aspect-ratio` and `content-visibility`

Two features can make visual content more predictable and reduce unnecessary rendering work.

Reserve the right shape with `aspect-ratio`

When an image container has a known aspect ratio, the browser can reserve the correct space before the image is displayed.

.thumbnail {
  aspect-ratio: 16 / 9;
  overflow: hidden;
}

.thumbnail img {
  display: block;
  width: 100%;
  height: 100%;
  object-fit: cover;
}

This is handy for video thumbnails, product images, article cards, and galleries. Consistent dimensions help keep surrounding content from jumping around.

Skip unnecessary rendering work with `content-visibility`

Long pages often contain large sections that are far outside the visible area. content-visibility: auto allows the browser to skip much of the rendering work for off-screen content until it becomes relevant.

.article-section {
  content-visibility: auto;
  contain-intrinsic-size: 42rem;
}

The intrinsic size provides a placeholder estimate so the browser can account for the section's space while its contents are not being rendered normally.

This can help with long articles, large repeated lists, and other pages with expensive off-screen content. It's not a substitute for measuring performance, though: choose a sensible placeholder size and test scrolling, anchor links, and layout stability with realistic content.

Why it matters: aspect-ratio helps create predictable layouts, while content-visibility can reduce work on pages with a lot of content.

Browser support: Both features are widely available in modern browsers. References: aspect-ratio and content-visibility.

7. Modern Color: `oklch()`, `color-mix()`, `light-dark()`, and Relative Colors

Color management is another area where CSS has become considerably more capable.

Use `oklch()` for more controlled color palettes

oklch() represents a color using perceptual lightness, chroma, and hue. This can make it easier to generate coherent variants of a brand color than manually guessing a collection of unrelated hex values.

:root {
  --brand: oklch(62% 0.2 255);
}

Changing the lightness while keeping chroma and hue stable can produce more consistent visual variations, although the resulting color should still be checked for gamut and contrast.

Mix colors with `color-mix()`

.button {
  background: var(--brand);
}

.button:hover {
  background: color-mix(in oklch, var(--brand) 85%, white);
}

This lets you generate color variations in CSS rather than maintaining a separate hard-coded value for every state.

Support light and dark themes with `light-dark()`

:root {
  color-scheme: light dark;

  --surface: light-dark(#ffffff, #171717);
  --text: light-dark(#171717, #f5f5f5);
}

body {
  background: var(--surface);
  color: var(--text);
}

The color-scheme declaration tells the browser that the page supports both schemes. light-dark() then chooses a value based on the active color scheme.

Derive colors from an existing color

Relative color syntax lets you create a new color from an existing one:

:root {
  --brand: oklch(62% 0.2 255);
  --brand-light: oklch(from var(--brand) calc(l + 0.12) c h);
}

Here, the lightness is increased while chroma and hue are retained. The exact result still depends on the source color and the target color space.

Why it matters: These features help build consistent themes and interactive color states with fewer duplicated values.

Browser support: oklch(), color-mix(), and light-dark() are available in current mainstream browsers. Relative color syntax should be checked for the browser versions you support. Always test color contrast rather than assuming that a perceptually uniform color space guarantees accessibility. References: OKLCH and color functions, light-dark(), and relative colors.

8. Better Forms with `field-sizing` and `accent-color`

Form controls are essential to most applications, but custom styling can become complicated when developers rebuild native inputs from scratch.

Two properties offer simpler alternatives.

Let fields size themselves around their content

.comment-box {
  field-sizing: content;
  min-height: 3rem;
  max-height: 14rem;
  width: 100%;
}

On a supported browser, a textarea can grow or shrink with its content instead of remaining at a fixed preferred size. Minimum and maximum constraints help keep it usable.

<textarea
  class="comment-box"
  rows="2"
  placeholder="Write a comment..."
></textarea>

This can reduce the need for JavaScript that measures text and updates the field's height.

Match native controls to your theme

input[type="checkbox"],
input[type="radio"],
input[type="range"] {
  accent-color: #7c3aed;
}

This changes the accent color of supported native controls while preserving their standard behavior. For many forms, that's a better starting point than hiding native inputs and recreating their appearance and interactions manually.

Why it matters: Native form controls can look more consistent with your design while retaining familiar behavior and accessibility features.

Browser support: accent-color is widely supported. field-sizing became Baseline Newly Available in 2026, so it may not work on older browser versions. Keep the default field behavior usable as a fallback. References: field-sizing and accent-color.

9. More Declarative UI with `:open`, Exclusive Accordions, and Popovers

HTML already provides useful building blocks for interactive interfaces. Modern CSS and browser features make it easier to style these controls without implementing every state from scratch.

Style open elements with `:open`

details:open > summary {
  color: #7c3aed;
  font-weight: 700;
}

The :open pseudo-class can select elements in an open state, including relevant details and dialog elements.

For a straightforward disclosure widget, the traditional attribute selector is also a useful fallback:

details[open] > summary {
  color: #7c3aed;
}

Create exclusive accordions with native HTML

When only one item in an accordion group should stay open, the name attribute on <details> can provide that behavior without a custom JavaScript controller.

<details name="faq">
  <summary>What is container querying?</summary>
  <p>It lets a component respond to its container's size.</p>
</details>

<details name="faq">
  <summary>What is CSS nesting?</summary>
  <p>It lets related selectors be written inside a parent rule.</p>
</details>

Give the related <details> elements the same name value to place them in the same exclusive group.

Use the Popover API for simple overlays

<button popovertarget="help-panel">
  Open help
</button>

<div id="help-panel" popover>
  <p>Helpful information goes here.</p>
</div>

The browser handles showing and hiding the popover through the built-in HTML behavior. An automatically dismissed popover can close when the user clicks outside it or presses Escape, depending on its configuration.

The Popover API is not a replacement for a modal dialog in every situation. A modal has different focus and interaction requirements; use <dialog> and its appropriate behavior when a truly modal interaction is needed.

Why it matters: Native HTML behavior can replace fragile custom interaction code, while CSS handles the appearance of each state.

Browser support: :open became Baseline Newly Available in 2026. The Popover API is available in current major browsers, but version support differs. For older targets, use the appropriate fallback or keep the essential interaction independent of the newer selector. References: :open, HTML <details>, and Popover API.

10. Small Improvements That Make Interfaces Feel More Polished

Not every useful CSS feature transforms an entire architecture. Sometimes, a tiny improvement solves a persistent UX problem.

Prevent scrollbar-related layout shifts

.scroll-panel {
  overflow: auto;
  scrollbar-gutter: stable;
}

On systems that use classic scrollbars, reserving the gutter can help prevent content from shifting when a scrollbar appears. Overlay scrollbars behave differently, so the visible result depends on the platform.

Style the scrollbar

.scroll-panel {
  scrollbar-color: #64748b #e2e8f0;
}

This sets the thumb and track colors in browsers that support scrollbar-color. Keep adequate contrast and avoid making the scrollbar difficult to see or operate.

Highlight text reached through a text fragment

::target-text {
  background: #fef08a;
  color: #111827;
}

When a supported text-fragment link navigates to a specific part of a page, ::target-text lets you style the matched text. This can be helpful for documentation and long articles.

Keep ruby annotations readable

For text that uses ruby annotations, ruby-align and ruby-position provide finer control over alignment and placement. These are especially useful for Japanese learning materials and similar content, rather than a requirement for most websites.

Why it matters: These improvements refine usability, navigation, and content presentation without requiring a larger JavaScript framework.

Browser support: scrollbar-gutter and font-size-adjust are Baseline 2024 features, while scrollbar-color and ::target-text became Baseline Newly Available in later cycles. Ruby properties also have broad support in current browsers, but individual values can vary. See scrollbar-gutter, scrollbar-color, and ::target-text.

Three More Capabilities to Adopt Progressively

The ten groups above cover many practical improvements. Three additional capabilities are worth experimenting with, but they deserve more care when supporting a broad range of browsers.

11. CSS Anchor Positioning: Position UI Relative to Another Element

Tooltips, menus, and small popovers often need to stay attached to a trigger button. Traditionally, developers used JavaScript to measure element positions and update them during scrolling or resizing.

CSS Anchor Positioning lets a positioned element refer to another element through an anchor relationship.

.trigger {
  anchor-name: --help-trigger;
}

.tooltip {
  position: absolute;
  position-anchor: --help-trigger;
  top: anchor(bottom);
  left: anchor(left);
  margin-top: 0.5rem;
}

This is a simplified example of the relationship; real interfaces may also need fallbacks for collisions with the viewport or other layout constraints.

Some anchor-positioning capabilities reached Baseline Newly Available during 2026, but support for the wider set of positioning and fallback behaviors is not identical across all browsers. Don't assume that one supported declaration guarantees all the advanced behavior you want.

For production use, provide a sensible fallback and feature-detect the functionality you rely on:

.tooltip {
  position: absolute;
  top: 100%;
  left: 0;
}

@supports (position-anchor: --help-trigger) {
  .tooltip {
    position-anchor: --help-trigger;
    top: anchor(bottom);
    left: anchor(left);
  }
}

Best use cases: Tooltips, dropdown menus, contextual labels, and other UI elements positioned relative to a trigger.

Support note: Check the precise feature and browser versions using MDN's anchor-positioning documentation before replacing a mature positioning library.

12. Scroll-Driven Animations: Let Scrolling Control the Animation

Traditional CSS animations progress with time. Scroll-driven animations can tie an animation's progress to scrolling or to an element entering the viewport.

For example, you can enhance a content-reveal effect without making it a requirement for the page to work:

.reveal {
  opacity: 1;
  transform: none;
}

@supports (animation-timeline: view()) {
  .reveal {
    animation: reveal linear both;
    animation-timeline: view();
    animation-range: entry 0% cover 40%;
  }

  @keyframes reveal {
    from {
      opacity: 0;
      transform: translateY(1rem);
    }

    to {
      opacity: 1;
      transform: translateY(0);
    }
  }
}

The normal state remains visible when the browser doesn't support scroll-driven animation timelines. Supported browsers receive the additional effect.

Use motion thoughtfully. Animations should help users understand changes rather than distract them, and you should consider reduced-motion preferences.

Best use cases: Reading-progress indicators, subtle content reveals, scroll-linked visual effects, and other experiences that benefit from a scroll-based timeline.

Support note: Scroll-driven animations remain a feature to adopt progressively. Check MDN's documentation and use feature detection.

13. `transition-behavior: allow-discrete`: Transition Properties Such as `display`

Not every CSS property can interpolate smoothly between two values. Properties with discrete values, such as display, normally switch from one value to another rather than gradually changing.

The transition-behavior property adds an allow-discrete option for certain discrete transitions:

.panel {
  transition:
    opacity 200ms,
    display 200ms allow-discrete;
}

.panel.is-hidden {
  opacity: 0;
  display: none;
}

This can be useful when combining visibility changes with opacity transitions. Entry animations from display: none often need additional setup, such as @starting-style; consult the relevant documentation rather than assuming the simple example covers every case.

Best use cases: Small UI transitions where content appears or disappears, including some popover and panel effects.

Support note: transition-behavior is not yet Baseline across all major browsers. Keep the basic show/hide functionality working without it. See MDN's transition-behavior reference.

A Related Platform Feature: The Navigation API

The 2026 research also covers the Navigation API. It is worth knowing about, but it is a JavaScript web API, not a CSS feature, so it shouldn't be presented as another CSS property.

The Navigation API provides browser navigation events and methods that can simplify certain client-side routing implementations. Whether it's a good fit depends on your routing architecture, browser targets, and framework.

For a broader look, see MDN's Navigation API documentation.

How to Use These Features in Production

Learning a new property is only half the job. The other half is deciding when to use it and how to handle browsers that don't support it.

1. Start with the support status

Web Platform Baseline distinguishes widely available features, newly available features, and features with limited availability.

Widely available: A good starting point for most new projects, while still considering your actual browser targets.
Newly available: Supported in recent Baseline browsers, but older browser releases may lack support.
Limited availability: Use feature detection or a fallback when the feature matters to your design.

Baseline is a compatibility signal, not a guarantee that every user will see identical results. Older devices, embedded webviews, assistive technology, and specific feature details may require additional testing.

Read the official Baseline overview.

2. Prefer progressive enhancement

Start with a working interface. Add the advanced behavior only when the browser supports it.

For CSS, @supports is often enough:

.card {
  padding: 1rem;
}

@supports (container-type: inline-size) {
  .card {
    container-type: inline-size;
  }
}

The fallback should preserve essential readability and functionality. A visual enhancement shouldn't make the entire component unusable when it's unavailable.

3. Measure performance instead of assuming

A feature can reduce code without automatically improving performance in every situation. content-visibility, for example, is most helpful when it avoids work on substantial off-screen content. Adding it everywhere without measuring can lead to disappointing results.

Test actual workloads using browser developer tools and realistic content. Pay attention to rendering, scrolling, input responsiveness, and layout shifts.

4. Avoid JavaScript when CSS or native HTML already solves the problem

You don't need JavaScript for every visual state. Container queries can handle component sizing, :has() can respond to DOM relationships, and native controls can provide useful behavior without custom event handlers.

But CSS isn't a replacement for application logic. Keep state, validation rules, data fetching, and other complex interactions in the parts of your application that are designed to manage them.

read and learn, use better ereactnative for your app

DevUnionX — Mon, 26 Oct 2026 17:51:31 +0000

DevUnionX

Oct 26

5 Things AI Cannot Do at React Native

#reactnative #react #mobile #web

9 min read

5 Things AI Cannot Do at React Native

DevUnionX — Mon, 26 Oct 2026 17:51:09 +0000

1. Compute and Power Constraints

Mobile CPUs/GPUs are orders of magnitude slower than datacenter hardware. Running complex models continuously can overheat devices and deplete batteries. For example, on-device object detection may take tens of milliseconds per frame, far slower than server GPUs. One case study found that enabling GPU delegation reduced inference from ~28 ms to ~11 ms per image, illustrating how hardware accelerators help but only partially bridge the gap. In practice, heavy inference slows the UI and degrades UX. Developers must mitigate this by using quantized (INT8) or pruned models, leveraging mobile NN accelerators (NNAPI on Android, Metal on iOS), and limiting workload (e.g. reducing camera frame rate or downscaling images). Offloading to edge/ cloud (e.g. sending data to a server) avoids local load but adds network latency. In sum, AI features that demand high throughput or low latency (e.g. real-time video analysis) are often beyond pure on-device execution.

2. Model Size and Architecture

State-of-the-art AI (LLMs, deep vision nets) contains hundreds of megabytes or more. Mobile storage is limited and models can’t be compressed by standard obfuscation. Large models inflate app size and may not fit in RAM. In one comparison, TensorFlow Lite’s library was ~20 MB smaller than PyTorch Mobile’s (minimized) binary, underscoring how framework choice affects footprint. Very large models simply won’t load on most devices. This means some AI tasks (e.g. on-device GPT-3) are infeasible. Mitigations include using compact models (MobileNet, DistilBERT) or on-device-specialized frameworks (LiteRT/TFLite, Core ML) that optimize size and performance. Techniques like pruning and quantization shrink models. Developers may also download models on demand or load from storage if necessary. Nonetheless, any feature requiring a “heavy” model forces trade-offs (e.g. degrade to simpler heuristic, or rely on cloud inference).

3. Connectivity and Latency

Complex AI often needs backend support. For large models or up-to-date data (e.g. user personalization), cloud APIs are used. But sending images or audio adds round-trip delays and requires bandwidth. One developer notes that even fast cloud inference suffers “massive overhead” serializing data, transmitting it, and encrypting it. Without a network (offline mode), these AI features fail outright. Conversely, on-device inference avoids connectivity needs and protects privacy, but then accuracy/complexity may suffer. A practical strategy is hybrid (“edge vs cloud”): run lightweight models locally and escalate harder tasks to the cloud if connected. Caching previous results, using quantized models for offline fallback, or pre-downloading data (e.g. language packs) can help. For non-real-time tasks, background syncing to the cloud when on Wi-Fi is another pattern. In short, AI features must gracefully degrade when offline or slow, for UX continuity.

4. Integration and Platform Constraints

React Native does not natively run AI models in JavaScript at production speeds. Developers must integrate ML frameworks via native modules or JSI. As one example showed, implementing a TFLite image classifier in React Native required ~50 lines of Android (Kotlin) and iOS (Swift) code to preprocess frames and invoke the interpreter each time. This bridging adds development complexity and can be a maintenance burden. Cross-platform differences compound it: Android typically uses LiteRT/TFLite or PyTorch Mobile, while iOS favors Core ML or Metal-based inference. Code must handle both paths. Moreover, traditional RN bridge calls are asynchronous and could add latency; the new Hermes/JSI architecture (as used in react-native-vision-camera) helps by running code as native “worklets” to cut overhead. Still, any bug in the native side can crash the app. Developers mitigate integration pain by relying on well-maintained libraries (e.g. react-native-tflite, react-native-vision-camera frame processors) and using architecture patterns that isolate ML logic. Employing Hermes or TurboModules also improves performance. But in general, RN’s JavaScript core cannot perform heavy AI by itself – native collaboration is required.

5. Privacy and Security

AI features often process sensitive data (camera, microphone, personal info). Offloading to the cloud risks leaking user data unless encrypted – and even then, trust is a concern. On-device ML “avoids sending user-private data through the network”, which is great for privacy (e.g. facial analysis can stay local). However, embedding models on the device introduces intellectual property risk: attackers could extract or reverse-engineer your model. Studies warn that on-device ML models are targets for extraction attacks, exposing both the model and possibly training data. Developers should weigh these: for highly sensitive data (health, finance) on-device inference is safer for users, whereas for proprietary models cloud execution can better protect model IP. Mitigations include on-device encryption of model files, obfuscating code, or using secure enclaves/TrustZones. In either case, clear user consent and compliance (GDPR, etc.) are essential.

Custom Native Modules & Bridging (TurboModules)

React Native’s native modules require manual specification and binding code. For example, creating a TurboModule involves writing a typed specification in TypeScript or Flow, running RN’s Codegen, and implementing native code on each platform. AI can generate a basic template, but it cannot reliably configure the native build environment or resolve platform-specific details. Official docs emphasize that a TurboModule is defined by “your specification, the native code you write, and the Codegen interfaces generated from your specification”.

// specs/NativeLocalStorage.ts (TypeScript spec for a TurboModule)
import type {TurboModule} from 'react-native';
import {TurboModuleRegistry} from 'react-native';

export interface Spec extends TurboModule {
  setItem(value: string, key: string): void;
  getItem(key: string): string | null;
  removeItem(key: string): void;
  clear(): void;
}
export default TurboModuleRegistry.getEnforcing<Spec>('NativeLocalStorage');

Beyond codegen, many subtleties arise. For instance, Apple’s Swift language cannot call C++ (JSI) APIs directly, so bridging requires an Objective-C++ “glue” layer. React Native’s documentation specifically notes that iOS Swift modules need an adapter pattern with minimal Objective-C++ code to interoperate with RN’s C++ core. A human developer must correctly set up bridging headers, adjust symbol linkage, and handle issues (nil pointers, load-order quirks) that an AI model won’t foresee. In practice, you might define an Objective-C++ wrapper that calls Swift code, as in the React Native guide (e.g. creating a NativeLocalStorage.mm that instantiates a Swift class). AI can’t test this on-device or catch linkage errors, so solving such integration bugs falls to developers.

Migration Tip: When migrating to the new architecture, enable TurboModules and Fabric carefully. For Android, set newArchEnabled=true in gradle.properties; for iOS, add ENV['RCT_NEW_ARCH_ENABLED'] = '1' to the Podfile. Then rebuild and watch for crashes or missing modules (issues often show up in Xcode or Logcat).

Performance Profiling and Optimization

React Native apps require manual performance tuning. The official docs state that RN “cannot determine the best optimization approach for you” in all cases – some problems need custom fixes. For example, large lists in a FlatList must be configured with props like windowSize, initialNumToRender, and updateCellsBatchingPeriod to balance rendering and memory. The performance guide lists defaults (e.g. windowSize = 21) and notes that increasing it can reduce blank areas but raise memory use. Adjusting these requires testing on target devices; AI cannot predict the optimal settings for your data. Likewise, stripping out debug code (e.g. console.log) is often necessary. The docs even recommend using a Babel plugin to remove logs before production builds.

Moreover, RN runs two frame loops: the JS thread and the native UI thread. The docs explain that animations performed on the native thread (e.g. using @react-navigation/native-stack) are smoother and not blocked by JS work. An AI model might suggest a JS-based animation, but a human developer can recognize when to switch to a native-driven animator or optimize JavaScript batching. As React Native notes, “native stack navigators… provide better performance… because the transition animations are executed on the native main UI thread”. Achieving 60 FPS often means profiling with device tools (Android Studio Profiler, Xcode Instruments), something only a human can operate. Even RN’s in-app Perf Monitor is just a guide – developers are advised to use native profilers for accurate metrics.

Practical Example: To tune a heavy list, try increasing maxToRenderPerBatch and updateCellsBatchingPeriod:

<FlatList
  data={items}
  windowSize={21}
  initialNumToRender={10}
  maxToRenderPerBatch={15}
  updateCellsBatchingPeriod={30}
  // ...
/>

Then test on device to ensure scrolling remains smooth.

Mitigation: Profile on real hardware and iteratively tune. Use the React Profiler (in DevTools) to identify JS bottlenecks and native tools (CPU/GPU traces) for UI lags. Automating this reasoning is beyond current AI, so human analysis is key.

Native Debugging & Tooling

Debugging React Native issues often requires human-driven, platform-specific tools. You can’t simply ask an AI to attach Xcode breakpoints or parse adb logcat output in real time. Official docs explain that for native code, one typically “launches the app from Android Studio or Xcode and takes advantage of native debugging features (setting breakpoints, etc.)”. Likewise, checking platform logs uses CLI commands (npx react-native log-android or log-ios) or IDE consoles. For example, native modules should log via Android’s Log.d or iOS’s NSLog, which developers then view in Logcat or Xcode. These live-run tasks – attaching to a process, stepping through C++ code, observing thread contention – cannot be done by a static AI model.

Moreover, diagnosing memory leaks or concurrency bugs requires monitoring. RN’s Dev Menu can show a simple perf overlay, but as docs caution, it’s only a guide and “native tooling under Android Studio and Xcode” is recommended for accurate analysis. Tools like Flipper or the Chrome debugger help inspect the JS side, but many timing issues or crashes stem from native threads or JSI. AI code suggestions won’t capture the actual runtime state.

Debugging Tip: If your app freezes, attach the native debugger. In Android Studio use Run → Attach debugger, and in Xcode use Debug → Attach to Process. Then set breakpoints in Java/Kotlin or Objective-C++ code. This hands-on step-by-step inspection is something only a developer can perform. Rely on LogBox and console logs for JS errors, but remember that true native crashes (e.g. EXC_BAD_ACCESS) need native debugging, not just console output.

// Example: remove console logs for production
// Babel config in .babelrc or babel.config.js
{
  "env": {
    "production": {
      "plugins": ["transform-remove-console"]
    }
  }
}

(Configuring the build is another manual task; RN docs recommend removing logs for release builds to avoid JS thread bottlenecks.)

New Architecture Migration & UI Quirks

With React Native’s new architecture (Fabric and TurboModules), developers must adopt new patterns that AI can’t auto-insert. As the RN team notes, the new architecture allows synchronous layout measurement and concurrent rendering features. For example, instead of using the asynchronous onLayout callback (which may cause visual jumps), developers can use useLayoutEffect to synchronously measure views in Fabric, eliminating intermediate states. AI tools won’t automatically refactor your code to this model or understand the subtle timing benefits.

Similarly, enabling features like React 18 automatic batching requires opting into the new renderer. The documentation highlights that useLayoutEffect in the new architecture performs measurements “in a single commit, avoiding the visual ‘jump’” seen in the legacy flow. Knowing when to use these new patterns versus old callbacks is something a seasoned developer decides during optimization.

Finally, the new architecture’s strict typing and codegen add hurdles. For instance, Swift-based AppDelegates cannot directly work with JSI C++ code, as noted earlier. Setting the newArchEnabled flag requires touching multiple files (Gradle and Podfile edits) and understanding build nuances. If something goes wrong (e.g. a missing TurboModule causes startup to fail), a human must trace through native codegen logs.

Migration Example: Suppose you enabled Fabric (newArchEnabled=true). You may find certain libraries need manual updates to their codegen specs. Check RN’s “What can I expect from enabling the New Architecture?” guide for version-specific notes. Always test on both iOS and Android after toggling the flag. Issues like symbols not found (RCTCxxBridge errors) often require adjusting Podfile or rebuilding native modules.

Platform Quirks and Build Configuration

Each platform and OS version can introduce unique issues that AI can’t anticipate. For example, iOS’s new privacy permission dialogs or Android’s scoped storage changes often require platform-specific code or manifest edits. React Native’s native modules sometimes behave differently on device vs simulator. Only by testing on real hardware can a developer catch these quirks. The official docs do not enumerate every nuance (e.g. Bluetooth permissions, background task constraints), so developers rely on forums and GitHub issues for fixes.

Another example is build configuration: adjusting the Android AndroidManifest.xml, editing the iOS Info.plist, setting up push notification certificates, or configuring Google services JSON. These steps are manual and tightly coupled to the native environment. An AI model cannot set up your Xcode signing, Gradle keystores, or handle merge conflicts in android/app/build.gradle.

Developer Tip: Use the React Native Upgrade Helper to compare changes when bumping versions. For AndroidX or library incompatibilities, consult GitHub threads. AI-generated suggestions might miss these details. Document and script your platform-specific changes (e.g., CocoaPods post-install hooks or Gradle plugin settings) to avoid errors.

do you believe your sql skill?

DevUnionX — Wed, 16 Sep 2026 21:56:47 +0000

DevUnionX

Sep 16

5 Things AI Cannot Do at PostgreSQL

#postgressql #sql #sqlserver #ai

5 min read

5 Things AI Cannot Do at PostgreSQL

DevUnionX — Wed, 16 Sep 2026 21:55:53 +0000

AI has become surprisingly good at PostgreSQL. Give it a schema and it can write a query in seconds. Paste an EXPLAIN ANALYZE result into a chat and it may suggest an index or point to an expensive join.

That is useful. But there is a difference between writing PostgreSQL code and understanding why the database should work that way.

After looking at the practical side of PostgreSQL, five gaps stand out. They are less about syntax and more about context, trade-offs, investigation, responsibility, and situations where there is no obvious answer.

1. AI Cannot Understand Your Business Logic

This is probably the easiest mistake to make because the SQL can look completely correct.

Imagine someone asks:

“Show total customer revenue for this year.”

AI can produce a query immediately. But what does “revenue” mean in your application?

Does it include refunds? Discounts? Tax? Returned products? An order created in December but refunded in January?

Those are business questions, not SQL questions.

For example:

SELECT customer_id, SUM(total)
FROM orders
WHERE created_at >= '2026-01-01'
GROUP BY customer_id;

The query is valid. It can still be completely wrong.

A developer who knows the system will ask which table is authoritative, what the order data represents, and whether total is gross or net. AI may not know any of that unless the context is provided.

That creates a dangerous type of result: a query that looks reasonable enough to survive a quick code review while producing the wrong answer.

2. AI Cannot Make the Architecture Trade-Off for You

PostgreSQL gives you many options. You can add indexes, partition tables, change memory settings, introduce replicas, redesign a schema, or add an extension for a specialized workload.

The difficult part is not knowing these options exist. It is deciding which cost you are willing to pay.

Take indexes:

CREATE INDEX idx_orders_customer_id
ON orders(customer_id);

An AI assistant may suggest this after seeing a slow query. It might help, but every index also consumes storage and adds maintenance work. On a write-heavy system, too many indexes can hurt INSERT and UPDATE performance.

The same thing happens with larger architecture decisions. A time-series workload may push you toward partitioning or an extension. A busy application may need pooling or read replicas. Memory settings depend on total RAM, concurrent workloads, and query behavior.

AI can list the choices. A person still has to decide what matters most for this particular system.

3. AI Cannot Reliably Find the Root Cause of a Production Incident

This is where database work becomes much less like writing code.

Suppose an application suddenly becomes slow. CPU is only 25%. Memory looks fine. The network seems normal.

Then you notice old row versions, unusual vacuum behavior, stale statistics, and blocked sessions.

Now you have a detective story.

PostgreSQL uses MVCC, so concurrent transactions work with snapshots and older row versions may remain until they can be cleaned up. PostgreSQL also has several isolation levels, row and table locks, deadlocks, and serialization failures.

AI can read logs, summarize pg_stat_statements, and explain an execution plan. The difficult part is connecting several weak signals into one explanation.

For example:

SELECT pid,
       wait_event_type,
       wait_event,
       query
FROM pg_stat_activity
WHERE wait_event IS NOT NULL;

That output is evidence. It is not the diagnosis.

Maybe PostgreSQL is the problem. Maybe an ORM created an N+1 query pattern. Maybe a deployment changed transaction behavior. Maybe a cleanup job created severe bloat.

This is exactly the kind of PostgreSQL troubleshooting where symptoms can point in several directions at once. The provided research highlights how vacuum behavior, statistics, locks, storage, and application behavior can interact in ways that are not obvious from a single metric.

4. AI Cannot Take Responsibility for Security Decisions

PostgreSQL has roles, grants, and row-level security. AI can help write policies and spot obviously broad permissions.

But security is not only a SQL problem.

Imagine the requirement is: “Support agents can see customer records.”

Should they see addresses? Payment information? Internal notes? Deleted accounts? Customers from another region?

An AI model could generate:

CREATE ROLE support_agent;

GRANT SELECT ON customers TO support_agent;

The SQL is fine. The policy could still be terrible.

Real security decisions involve risk tolerance, internal rules, auditing, incident response, and sometimes legal obligations. AI can help draft controls, but humans still decide what risk is acceptable and what happens when something goes wrong.

AI can suggest a control. It cannot own the consequences of choosing it.

5. AI Cannot Invent the Right Answer When the Problem Is New

This is probably the most interesting limitation.

AI is very good at combining known patterns. PostgreSQL has decades of documentation, discussions, bug reports, and production experience for a model to learn from.

But sometimes there is no established answer.

The research report points to ongoing PostgreSQL discussions around issues such as global indexes for partitioned tables. These problems involve deep trade-offs and active experimentation rather than one universal best practice.

When a production system has an unusual workload and a failure mode nobody has seen before, you have to experiment.

Build a small reproduction. Change one variable. Compare plans. Maybe the first idea fails.

That loop of hypothesis → experiment → failure → adjustment is still a major part of database engineering.

AI Is a PostgreSQL Tool, Not a PostgreSQL Engineer

None of this means AI is bad at PostgreSQL. Quite the opposite.

It is excellent for repetitive work. It can generate SQL, explain commands, draft migrations, summarize logs, and give you another angle when you are stuck.

The important distinction is assistance versus authority.

I would happily ask AI to draft:

ALTER TABLE users
ADD COLUMN last_login_at timestamptz;

I would not blindly run a risky production migration just because the generated SQL looks correct.

PostgreSQL is full of decisions where correctness depends on context: schema design, indexing, concurrency, vacuum behavior, permissions, and operational constraints. PostgreSQL's current documentation also treats concurrency as a broader system involving isolation, locks, deadlocks, and serialization failures rather than a single setting or command.

The Human Part Still Matters

The interesting thing about AI and PostgreSQL is that the technology does not necessarily remove the need for database engineers. It changes where their time is spent.

Writing a basic query may take seconds now.

Understanding whether that query belongs in production can take much longer.

AI can generate the first version. A developer can then test it, question its assumptions, compare the execution plan, check the business rules, and decide whether the result actually makes sense.

That is probably the most useful way to think about AI in PostgreSQL.

Use AI to move faster, but do not confuse a plausible answer with a verified one.

The database still needs someone who understands the system behind the SQL.

[Boost]

DevUnionX — Fri, 11 Sep 2026 22:30:38 +0000

DevUnionX

Sep 11

5 Things AI Cannot Do at Firebase

#firebase #claude #database #ai

6 min read

5 Things AI Cannot Do at Firebase

DevUnionX — Fri, 11 Sep 2026 22:30:06 +0000

5 Things AI Cannot Do at Firebase (Yet)

AI has changed the way we build software. Give an AI assistant a
Firebase project and it can generate Firestore queries, Cloud Functions,
authentication flows, and even Security Rules in seconds.

That is useful. But there is a difference between generating code that
looks correct and understanding what that code will do with real
users, real traffic, failures, and security requirements.

Firebase makes this distinction especially important. Firestore,
Realtime Database, Cloud Functions, and Authentication hide a lot of
infrastructure complexity. Development becomes faster, but a small
architectural mistake can stay invisible until the application is under
load.

AI is good at patterns and boilerplate. The harder part is understanding
the system around those patterns.

1. AI Cannot Properly Reason About Concurrency

One of the easiest ways to create a serious Firebase bug is to write
code that works perfectly for one user.

Then 10,000 users arrive.

Consider a simple read-then-write operation:

const user = await getUser(uid);

if (user.balance >= amount) {
  user.balance -= amount;
  await updateUser(uid, user);
}

What happens if two requests run at almost exactly the same time?

Both can read the same balance. Both can decide there is enough money.
Both can write their result. One update may overwrite the other.

This is a classic race condition. AI sees a sequence of operations,
but it does not automatically reason about how those operations interact
when many requests happen concurrently.

Firestore provides transactions and batched writes, but choosing
between them is an architectural decision. Transactions are useful when
a write depends on current data. Batched writes are better for atomic
write-only operations.

Sometimes neither is the real solution. Imagine thousands of users
joining a queue simultaneously. A better design may be to separate event
capture from processing with Cloud Tasks, rather than trying to
solve everything with database transactions.

The same applies to query ordering. If your application needs
deterministic results, do not assume equal sort values will always
produce a stable order. Add a reliable secondary ordering when the
application depends on it.

AI can write the query.

The developer has to decide whether the query is safe under real
concurrency.

2. AI Cannot Understand the Security Context of Your Data

Firebase Security Rules are powerful, but they are easy to get wrong.

An AI assistant might generate:

allow read, write: if request.auth != null;

It works for authenticated users, but that may be far too permissive.

Being logged in does not mean a user should be able to modify another
user's document.

A more appropriate ownership check might look like:

allow write: if request.auth.uid == userId;

A particularly dangerous pattern is Broken Object Level Authorization
(BOLA). AI-generated CRUD code can accidentally allow any
authenticated user to read, update, or delete documents without checking
ownership.

There is also an important difference between Firestore and Realtime
Database Security Rules. Realtime Database permissions cascade through
the data tree, while Firestore rules do not work the same way. Copying a
rule pattern from one Firebase database to another can therefore produce
serious security problems.

AI can also treat sensitive fields as ordinary properties:

isAdmin
balance
plan
createdAt
updatedAt

But should the client be able to change them?

A request containing:

{
  "isAdmin": true
}

should obviously not make somebody an administrator.

Sensitive fields need trusted server-side control. Firebase
Authentication custom claims can also be used for server-controlled
roles and authorization decisions.

The research behind this article makes the same broader point: Security
Rules should be treated as executable security code, tested and reviewed
rather than accepted as generated boilerplate.

Security is not a feature AI can safely infer from field names.

3. AI Cannot Design Reliable Event-Driven Systems by Itself

Cloud Functions are one of Firebase's biggest advantages. A database
change, signup, or upload can automatically trigger backend code.

But event-driven systems have an uncomfortable property:

A function can run more than once.

Imagine:

exports.sendWelcomeEmail = onUserCreated(async (event) => {
  await sendEmail(event.data.email);
});

The email may be successfully sent, but the function could fail
immediately afterward. A retry can then send the email again.

The code is syntactically fine. The problem is that the operation is not
idempotent.

For important operations such as payments, rewards, notifications,
inventory updates, and third-party API calls, you need to think about
duplicate execution.

A simple pattern is:

if (await alreadyProcessed(eventId)) {
  return;
}

await processPayment();
await markAsProcessed(eventId);

The exact implementation depends on the application, but the question is
always the same:

"What happens if this runs twice?"

AI will often generate the happy path first. Developers have to design
for retries, partial failures, timeouts, and state recovery.

For multi-step workflows, this becomes even more important. If one API
call succeeds and the next one fails, blindly replaying the entire
workflow can create duplicate side effects.

4. AI Cannot Understand Your Business Rules

This is perhaps the most important limitation.

AI knows the code you show it. It does not truly know why your business
works the way it does.

Imagine a subscription document:

plan
balance
isAdmin
createdAt

An AI can easily generate CRUD operations for all four fields.

But maybe plan can only change after payment.

Maybe balance can only be changed by a trusted backend operation.

Maybe createdAt must never change.

Maybe isAdmin requires manual approval.

Those are not JavaScript problems. They are business decisions.

This connects to a broader limitation of AI-assisted development: AI can
suggest solutions, but it cannot independently choose the correct
strategy for your specific constraints and product goals.

The problem becomes bigger as the application evolves.

Today your document might contain:

name
email
photoURL

Six months later:

internalNotes
accountStatus
billingTier

The data model changed, so the security model may need to change too.

A rule that was reasonable months ago may no longer be sufficient after
a schema change. Developers have to continuously review permissions,
validation, and business logic.

This is where human context matters most.

5. AI Cannot Manage the Production Black Box for You

Getting the application to work is only the beginning.

Once real users arrive, new questions appear:

Why did a Cloud Function become slow?

Why did costs suddenly increase?

Why are requests timing out?

Why are users receiving duplicate notifications?

AI-generated code does not automatically give you good observability.

Production systems need logs, metrics, alerts, and performance
monitoring. Without them, debugging a chain of interconnected
functions can become detective work.

Cost is another problem. Code can be functionally correct and still be
expensive.

For example, additional reads caused by certain Security Rule checks,
inefficient queries, or poorly distributed document IDs can become
expensive at scale. AI generally optimizes for plausible functionality,
not your monthly cloud budget.

The difference is simple:

AI asks: "Does this code work?"

Production engineering asks: "Does it still work efficiently with a
million users?"

Firebase AI features add another operational layer. Developers need to
consider model usage, latency, billing, and what information is stored
in monitoring or logs, especially when sensitive user data is involved.

AI can help investigate these problems, but someone still has to own the
monitoring strategy and make the final decisions.

AI Is a Tool, Not the Architect

None of this means AI is bad for Firebase development.

Quite the opposite.

AI is excellent for boilerplate, documentation, test generation, query
writing, refactoring, and explaining unfamiliar APIs. It can make one
developer dramatically faster.

The mistake is expecting it to replace engineering judgment.

The five gaps are closely connected:

Concurrency requires reasoning about simultaneous operations.
Security requires understanding who should access what.
Reliability requires designing for retries and failures.
Business logic requires understanding the product and its future.
Operations requires understanding what happens after deployment.

These are not simply coding problems.

They are system-design problems.

So instead of asking, "Can AI build my Firebase backend?", ask:

"Which parts can AI accelerate, and which parts require me to think?"

Let AI write the repetitive parts. Let it suggest implementations and
explain documentation.

But when money, permissions, shared state, retries, or production
reliability are involved, slow down and review the design yourself.

Because in Firebase, code that looks correct is not always code that
remains correct when real users, real failures, and real traffic
arrive.

Sources

5 Things Even AI Can’t Do: Context, Creativity, and Human Touch in Node/NestJS Development

DevUnionX — Fri, 17 Jul 2026 22:40:32 +0000

MY GAME JUST LAUNCHED

Flip Duel: Online Card Game - Apps on Google Play

1v1 card duel! Bluff, beat your rival. Combine your cards, raid the dungeon!

play.google.com

Introduction

AI is powerful and getting smarter – it can generate code, answer questions, and even help design systems. Yet seasoned engineers know there are tasks only people can do. A recent industry overview bluntly states: “it does not understand meaning… it cannot create independent judgment… [and] it lacks emotional intelligence”. In other words, AI excels at narrow, data-driven tasks but fails where true understanding, empathy, or accountability is required. This article – aimed at Node.js/NestJS developers and engineers – digs into five such areas. Each section explains the concept, provides real-world dev examples (with code snippets in JavaScript/TypeScript when relevant), and notes where AI helps and where it stumbles. We cite the latest research and official docs to back up these points. By the end, you’ll have a grounded perspective on AI-assisted development: how to benefit from code generation tools and LLMs while knowing when human judgment must step in.

1. AI Can’t Truly Understand Context

AI models do a fantastic job spotting patterns in data and text, but real context remains elusive. LLMs process words based on statistical associations, not on meaning the way humans do. As one AI analyst notes, “AI… operates by detecting patterns in historical data. It does not understand meaning. It does not know consequences”. In practice, that means an LLM won’t “get” the broader situation behind your code or data. It has no sense of what happened a minute ago in the team standup or what business rules apply to a request.

Context in Software Systems

Consider NestJS’s ExecutionContext, which provides metadata about a request or event handler. In a HTTP context, a guard or interceptor can see exactly which controller and method are handling the request. For example, Nest’s docs show that when handling a POST to CatsController.create(), getHandler() returns the create() function and getClass() returns CatsController. This allows the code to adapt behavior based on context:

@Injectable()
export class LoggingInterceptor implements NestInterceptor {
  intercept(context: ExecutionContext, next: CallHandler) {
    const httpCtx = context.switchToHttp();
    const req = httpCtx.getRequest<Request>();
    console.log(`Incoming ${req.method} ${req.url}`);  
    console.log(`Handler: ${context.getClass().name}.${context.getHandler().name}`);
    return next.handle();
  }
}

Here, the developer explicitly uses runtime context (HTTP request, handler info) to log or branch logic. An AI given only a code snippet and a prompt might not infer all those details about when and how the code executes. It lacks true awareness of the request lifecycle and runtime state.

Where AI Excels and Falls Short

Modern LLMs can “remember” recent conversation (via a context window) and even long documents. For example, Google’s Gemini can handle over a million tokens. But larger windows aren’t a magic fix: as the Anthropic team points out, “LLMs, like humans, lose focus… as the number of tokens in the context window increases, the model’s ability to recall information decreases”. This “context rot” means that even if you feed the AI pages of documentation, it may still get confused about which part is relevant to the current query.

In practice, developers use Retrieval-Augmented Generation (RAG) to mitigate this. RAG fetches specific data from external sources into the prompt. As NVIDIA explains, RAG “enhances the accuracy and reliability of generative AI models with information from specific and relevant data sources”. In other words, you build a “knowledge base” (say, your own code docs) and include facts in the prompt. This helps ground the AI’s answers. NVIDIA even notes that RAG “reduces the possibility that a model will give a very plausible but incorrect answer, a phenomenon called hallucination”.

For example, in Node.js you might write a simple RAG function to answer questions about your project:

async function answerWithRAG(query, vectorStore) {
  const docs = await vectorStore.retrieveRelevant(query);  // fetch related docs
  const prompt = `
    Use the following information to answer the question.
    ${docs.join("\n")}
    Q: ${query}
    A:
  `;
  const completion = await openai.createChatCompletion({
    model: "gpt-4",
    messages: [{ role: "user", content: prompt }]
  });
  return completion.data.choices[0].message.content;
}

Here the code explicitly retrieves context (docs from a vector store) and injects it into the prompt. The AI no longer has to recall everything; it sees targeted context. This improves reliability but also highlights AI’s gap: it needed human help (the vector store, curation of docs) to supply true context. AI by itself would likely hallucinate or miss important facts without that.

Lessons for Developers

Use prompt and context engineering: Carefully craft prompts, provide relevant docs, and manage the token window. Treat context as finite. Anthropic advises thinking “in context” – iteratively curating only the smallest set of high-signal tokens needed for the task.
Validate outputs: Even with RAG or careful prompting, always test AI-generated code or answers against known facts. The AI might produce fluent but incorrect text once you exceed its context capacity.
Combine AI with logic: Use static types, unit tests, and logging (as in the NestJS example) to catch context mismatches early. AI can suggest code, but you must check it in the full system context.

In summary, AI struggles with hidden context and system state. It can automate low-level coding, but developers must manage broader context, architecture and integration – tasks that require human insight.

2. AI Can’t Take Responsibility

AI will help write the code or suggest a design, but it won’t own the results. Machines don’t have accountability or intention. A recent discussion on AI accountability emphasizes: “it cannot assume responsibility for the outcomes of those decisions… The emphasis must remain on ensuring that humans are equipped and willing to take accountability”. In other words, if an AI-driven system causes a bug, outage, or even an ethical breach, the responsibility ultimately falls on the human developers, operators, or managers involved.

Real-World Software Example

Imagine deploying a NestJS microservice that uses an AI to classify user inputs. If the AI misclassifies sensitive data, who fixes it? Engineers must detect it, debug the model or logic, and apologize to stakeholders – tasks no AI can do. Similarly, an AI-generated pull request still requires a developer to review, merge, and be ready to revert if things go wrong.

Consider DevOps and CI/CD: AI tools can suggest pipeline configurations or even generate Kubernetes YAMLs. But when a deployment fails or a security issue emerges, a human is on-call to investigate and respond, not the AI. If the pipeline says “build succeeded” but a hidden error slipped through, the engineer digs into logs and patches the code.

The need for human oversight is often summed up: “you can outsource execution; you can’t outsource consequences. If it goes wrong, 'AI said so' won’t save you”. (An Instagram quote puts it simply: accountability cannot be automated – and in a production system, someone must own every decision.)

AI’s Strengths vs. Weaknesses (Accountability)

Aspect	AI Role (Strength)	Limitation (Responsibility)
Decision Support	Generates options and analysis rapidly	Cannot endorse or guarantee outcomes; doesn’t understand ethics
Consistency	Follows rules consistently in code generation	Lacks judgment; blindly follows flawed instructions without question
Speed	Suggests fixes or configs in seconds	May miss context that a human would catch; not liable for mistakes

As the Lumenalta report on AI limits notes, “high-stakes work still depends on judgment about tradeoffs, ambiguity, and consequences. AI can support that work. It will not own it well.”. AI can accelerate the “explore” phase (e.g., propose database schemas or microservice structures), but the final decision (“commit” phase) remains human-led.

Lessons for Developers

Always review and test: Never merge AI-generated code or configs unreviewed, especially for critical paths. Pair AI with code reviews, automated tests, and staging deployments.
Human-in-the-loop: Design systems so that important decisions (security, product priorities, unusual conditions) require a human sign-off. As one AI executive advises: “treat outputs as hypotheses, keep decision-making human-led”.
Clear ownership: In agile teams, use clear ownership or responsibility matrices. Document which team/person is responsible for each AI-assisted component. This way, when an issue arises, it doesn’t become “AI’s fault,” it’s traceable to the responsible owner.

By acknowledging that AI isn’t accountable, teams avoid the trap of over-reliance. AI is a tool that suggests – but we, the developers and architects, must decide and own the results.

3. AI Can’t Replace Human Creativity

AI can recombine existing code patterns in novel ways, but it does not originate new ideas with intent the way developers and designers do. It might surprise you with an unusual code snippet, but that’s remixing what it “saw” during training. As one expert pithily puts it, “AI recombines patterns. Humans create with purpose, emotion, and narrative.”.

Creativity in Software Engineering

Consider a developer brainstorming a new feature or user story. They think of product vision, user needs, and constraints. They sketch architectures, whiteboard ideas, and iterate. AI can help flesh out details – for instance, suggesting class structures or API endpoints – but it cannot conceive the original vision or the “why” behind the feature.

For example, writing a complex Node.js application often involves creative design: deciding the right microservices boundaries, naming conventions, or novel algorithms. An AI model can suggest code snippets (like a clever function), but it doesn’t understand the problem domain. It doesn’t know your startup’s unique value proposition or the UX story your frontend needs. It only knows patterns.

One way to see this is how AI deals with unexpected situations. The Lumenalta analysis gives a marketing use case: AI can generate campaign variants and test subject lines quickly. The same system will not recognize that a market shift makes the campaign premise wrong, or that a customer reaction signals a brand risk that historical data cannot capture. The AI is excellent at extending existing patterns, but it “does not originate a better frame on its own.” It takes a human to see beyond the data and pivot creatively.

Even in coding, creativity shows up in choosing algorithms or patterns. Given two approaches, an engineer might innovate a hybrid or use domain knowledge. AI will tend to use common design patterns. It might suggest a decorator or service for a NestJS app, but it won’t invent a brand-new architecture style or fix a deep UX issue in ways never documented.

AI’s Strengths vs. Weaknesses (Creativity)

Capability	AI Strength	Limitation
Code Generation	Generates boilerplate and known patterns fast	Lacks original intent or problem framing
Problem Solving	Offers multiple solution variants	Doesn’t understand when to break the mold
Innovation	Can suggest combinatorial recombinations	“Surprising output” comes from scale, not true novel ideas

In fact, a data scientist notes that the common saying “AI can’t be creative – it only recombines what already exists” has truth, but also nuance. Modern LLMs with huge context windows can produce surprisingly novel-seeming outputs (thanks to exploring massive combinatorial spaces). But those surprises are still rooted in the training data, not some internal “imagination.”

Lessons for Developers

Focus AI on repetitive creativity: Let AI handle rote creativity tasks (e.g. generating code templates, unit test stubs, or design variations). For truly open-ended innovation, rely on human brainstorming.
Use AI to augment, not replace design: For example, ask an LLM to propose NestJS service names or database schema from a docstring – it can speed things up. But always vet them: humans must ensure these proposals fit the product’s unique needs.
Break down big problems: If AI suggestions seem “stuck,” break the task into smaller parts. Then use your own creativity for the overall structure and let AI assist with the details.

By embracing that creativity is ultimately human, teams can use AI to rapidly prototype and experiment, while reserving the “big idea” work for developers’ insight.

4. AI Can’t Build Genuine Human Relationships

No matter how friendly a chatbot sounds, it isn’t a human colleague or friend. Machines lack authentic empathy, trust, and emotional intelligence. As a therapist writes, AI “aids with facts but lacks emotional depth and intuition. Professionals offer empathy and care that AI cannot replicate.”. In software teams, this means AI cannot truly motivate developers, resolve interpersonal conflicts, or mentor junior engineers.

Team and Customer Context

On a project, relationships matter. A senior developer encourages a newcomer, understands frustration, and adapts feedback to their learning style. An AI code reviewer might suggest changes, but it won’t pick up on a dev’s confusion or morale. It can’t shake hands, share a joke, or build trust after a deployment outage. In DevOps incidents, an on-call engineer consoles stakeholders, while AI tools only log errors.

In customer-facing systems (like chatbots), scripted “compassion” is limited. A customer unhappy with a bug needs understanding; an AI response can sound polite, but it doesn’t actually feel urgency or remorse. If a chatbot just repeats instructions, the user feels unheard. Real human support engineers will empathize and maybe go the extra mile. This reflects the Psychology Today point that “genuine connection… [from AI] is missing” – when people use digital support, “the missing piece? Real connection”.

AI’s Strengths vs. Weaknesses (Relationships)

Aspect	AI Role (Strength)	Limitation (Relationships)
User Engagement	Can handle routine queries quickly	Lacks true empathy; misses unspoken cues
Team Support	Provides answers or suggestions 24/7	Cannot inspire, trust, or genuinely motivate
Social Interaction	Can mimic friendly tone in text	Has no self, no genuine care or understanding

Rafiq Wayani, a leadership coach, lists candidly that “AI cannot build relationships: Business is still built on trust… No algorithm can replicate genuine human connection”. In other words, while AI can simulate conversation, it can’t feel the emotional currents between people. It won’t notice if a team member is anxious, nor remember a manager’s leadership style to tailor its output.

Lessons for Developers

Use AI for tasks, but invest in people skills: Let chatbots handle FAQs or generate resource links, freeing time for your team to focus on empathetic communication and collaboration.
Preserve human contact points: For example, in customer support, use AI to draft responses but have a human review them. Or use AI to process logs and let engineers do the actual user outreach.
Build trust in processes: When adopting AI tools (like Copilots or code reviews), be transparent. Don’t promise the AI understands your code; instead say it offers suggestions. This way developers feel in control, maintaining trust in the tool.

Ultimately, AI can aid productivity and consistency, but the “glue” of any engineering effort remains human relationships and trust. Machines support us; people support each other.

5. AI Can’t Decide What Should Be Built

Perhaps most fundamentally: AI can’t decide the vision. It doesn’t know your users’ deepest needs, your company’s mission, or which product idea will really move the needle. No matter how much data it has, it can’t set priorities or conceive what to build first.

Strategic Decision-Making

In startup or product work, deciding what to build involves strategy, ethics, and foresight – “dirty work” beyond data patterns. Craig Sullivan summarizes it: “No LLM is going to tell you which deal to prioritize… or when a prospect needs a human conversation instead of another automated touchpoint… Treat outputs as hypotheses, keep decision-making human-led”. For example, an LLM can analyze customer feedback for topics, but it won’t know that shifting market trends mean the feedback signals a new feature idea. Only human product managers with market context can interpret that.

In system architecture, this shows up too. AI might generate microservice code or suggest a database (OK for boilerplate), but choosing between architectural paradigms (e.g. REST vs. GraphQL, monolith vs. microservices) requires understanding team skills, legacy constraints, and future roadmap. AI lacks that broader perspective and cannot weigh the trade-offs beyond statistical patterns.

Where AI Helps and Falls Short

AI is great at the exploration phase of problem solving – generating lots of ideas or code variants. But it’s weak at convergence. As one engineer puts it, “LLMs are great at divergence (getting more ideas), and weak at convergence (picking the right one).” Even with large-scale outputs, picking the best solution relies on human context: team culture, performance constraints, and politics.

For example, RAG or agents can gather and summarize information to inform a decision – they scale knowledge. But they won’t say “build this feature because we’ll capture X market.” They lack business acumen and on-ground insight. An LLM might suggest moving a block of code to a new file; it cannot suggest building a whole new component because “Team A is overworked, and Team B has expertise.”

Lessons for Developers

Keep humans in the loop for vision: Always have senior engineers or product owners steer the high-level roadmap. Use AI to gather data or simulate user scenarios, then decide the plan yourself.
Use AI as a tool, not a boss: When an AI suggests many solutions, treat them as hypotheses. Score them using metrics you care about and choose with human judgment.
Invest in domain expertise: Your knowledge of customers, business, and technical debt are irreplaceable. As one summary reminds us: “Jobs evolve. Judgment does not disappear.”.

In short, AI can never replace the creative spark and responsibility of deciding what to build. It lacks purpose. That means it’s up to the team to set direction and ensure technology serves human goals.

Key Takeaways

Context is limited: LLMs handle text in isolation and have finite memory (context window). Use techniques like RAG to inject relevant data, and always test AI-generated code in the full system context.
AI is assistive, not accountable: AI can generate code or suggestions, but it cannot own mistakes or make judgment calls. Human engineers must review outputs and bear responsibility.
Creativity stays human: AI recombines patterns at scale but does not innovate with intent. Use AI for prototyping, but rely on developers for vision and strategy.
Relationships need humans: No matter how “smart,” AI lacks real empathy or emotional intelligence. Preserve human interaction in teamwork and user support.
Humans decide what to build: AI can suggest and explore, but picking the right path requires human judgment and domain knowledge. Treat AI output as hypotheses, not decisions.

Conclusion

AI and LLM tools are reshaping software development – they’re incredibly powerful assistants. They can write boilerplate, suggest fixes, summarize logs, and even generate initial system designs. But they have clear limitations. They don’t understand systems the way we do, they don’t own outcomes, they aren’t truly creative, they can’t form real relationships, and they won’t set the product vision. These aren’t flaws; they’re just the nature of current AI.

As developers, our mission is to harness AI’s strengths while managing its weaknesses. That means leveraging prompt engineering, retrieval systems, and CI/CD pipelines to get the best outputs – while always keeping humans in the loop for testing, oversight, and final decisions. When a chatbot “hallucinates,” or Copilot writes vulnerable code, it’s a reminder that context, responsibility, and human values still require us.

The future is not humans vs AI, but humans with AI. By understanding these five boundaries, we can use AI to accelerate development without losing sight of what only people can do. As one developer put it, AI “accelerates the explore phase; humans own the commit phase”. Remember that rule of thumb, and AI becomes an advantage – not a liability.

Call to Action: Have you encountered situations where an AI’s suggestion went wrong? Or where human judgment caught an AI error? Share your experiences and thoughts in the comments below. Let’s learn from each other about the real-world limits of AI in development.

FAQ

Q: Can AI ever fully replace software developers?

A: Not in the foreseeable future. Current AI lacks true understanding, ethics, and responsibility. It’s best used as a coding assistant. Developers still need to review, integrate, and make judgment calls about AI outputs.

Q: How do we guard against AI “hallucinations” in code?

A: Always validate AI-generated code with tests and type checks. Use retrieval-augmented generation (RAG) and prompt constraints to ground answers. Never trust the AI blindly – treat it as a collaborator, not an oracle.

Q: What is the role of prompt engineering?

A: Prompt engineering helps focus the AI on desired outcomes. By crafting clear, specific prompts (and including context via system messages or RAG), you improve the quality of AI assistance. However, even perfect prompts can’t teach the model empathy or responsibility.

Q: If AI can’t be creative, why do some say it is creative?

A: AI can generate novel-looking combinations because it has seen vast amounts of data. Technically, it’s remixing patterns at scale. Some surprising results can feel creative, but AI doesn’t conceive ideas from first principles or feelings. It lacks intent and can’t do strategic innovation without human guidance.

Q: How should DevOps teams handle AI tools?

A: Treat AI tools (like infrastructure-as-code generators or monitoring bots) as helpers. Use them to automate routine tasks, but maintain human oversight on critical deployment steps. For example, an AI can draft a Kubernetes manifest, but a human must review security settings and verify it in a dev cluster.

Q: Can prompt-based agents (AI that calls APIs and tools) overcome these limitations?

A: Agents can mimic multi-step reasoning and use tools, improving task execution. But they still rely on underlying LLMs. They don’t truly understand business context or own outcomes. They reduce some manual work but raise new concerns (e.g., uncontrolled API usage). Even advanced agents need carefully defined boundaries and human supervision.

Q: How does AI impact architecture and system design?

A: AI can suggest design patterns and even draw diagrams from high-level descriptions, which is useful for brainstorming. But choosing the right architecture (monolith vs microservices, specific frameworks, database technologies) requires weighing long-term factors. AI suggestions should be one input, not a final design, as it won’t know your team’s full constraints and goals.

Feel free to drop additional questions or comments below. We encourage discussion on how to balance AI tools with human expertise in your development workflow!

5 Things AI Cannot Do at Node.js

DevUnionX — Mon, 13 Jul 2026 19:21:28 +0000

Flip Duel: Online Card Game - Apps on Google Play

1v1 card duel! Bluff, beat your rival. Combine your cards, raid the dungeon!

play.google.com

Executive Summary

This report examines five fundamental tasks and limitations that artificial intelligence cannot reliably perform for Node.js developers. AI models generally operate through statistical approaches based on large datasets, which can lead to problems such as factual mismatch (hallucination), loss of context, and security vulnerabilities. For example, an LLM (Large Language Model) may suggest a piece of code that looks attractive but is incorrect or fabricated. In the Node.js context, errors of this kind can create serious problems such as blocking the single-threaded event loop or degrading performance. Throughout the report, we address the causes of each limitation, its impact on Node.js, and the design patterns that can be used to mitigate it. We illustrate these solutions with code examples and architectural diagrams, and we also offer insights into future research trends along with recommended resources. Ultimately, the report emphasizes that in order to maximize the benefits of AI tools, developer oversight, testing, and sound architectural planning remain critically important.

1. Hallucination and Accuracy Problems

Although current AI models produce convincing, template-consistent answers, they provide no guarantee of accuracy. Because LLMs rely on statistical language modeling, they frequently produce the phenomenon known as "hallucination" — that is, they can generate fabricated answers that are entirely inconsistent with the user's request. For example, when given a legal writing assignment, an LLM may produce fabricated citations and unsupported arguments on a topic; similarly, when asked for Node.js code, it may output code containing nonexistent functions, missing parameters, or faulty logic. Hallucinations generally stem from biases or contradictory information in the model's training data. An arXiv study showed that roughly 95% of the errors arising in LLM-assisted code generation were caused by incorrect functionality (failure to meet requirements). This means that when you attempt to produce "production code," you will encounter unexpected errors and unreliable output.

For Node.js developers, this creates two fundamental risks. First, if AI-generated code is used directly, the application may experience functional errors and unexpected crashes. For example, even when AI-assisted code constructs an API request, it may fail to perform proper authentication or parameter validation; or an operation may return an unexpected result. Such code may not even appear to be broken while running, yet the application's business logic breaks down or security vulnerabilities emerge. Second, hallucinations make code harder to maintain. When complex, unnecessary, or unexplainable pieces of code are generated, maintenance becomes more expensive over time and developer productivity declines. The ambiguities contained in AI-generated code require extra testing and review to separate out the real bugs.

Mitigation Approaches: In the Node.js world, there are various approaches to overcoming this problem. First and foremost, AI-generated code must pass through human oversight and be verified with unit tests. Within the code flow, critical outputs can be checked using assertion libraries or a type system (TypeScript). In addition, balancing (prompt engineering) methods can be applied: specifying all necessary context and constraints in detail before the code prompt can reduce the likelihood of hallucination. For example, OpenAI's system message can be used to describe the code environment or fixed variables. A Node.js example is given below:

// Example: AI call (OpenAI API)
import { Configuration, OpenAIApi } from 'openai';
const openai = new OpenAIApi(new Configuration({ apiKey: process.env.OPENAI_KEY }));

async function generateValidatedCode(prompt) {
  // First, provide context by adding a test scenario
  const messages = [
    { role: 'system', content: 'You are a JavaScript expert and must produce only correct, tested code.' },
    { role: 'user', content: prompt }
  ];
  const res = await openai.createChatCompletion({ model: 'gpt-4', messages });
  return res.data.choices[0].message.content;
}

// Usage
const code = await generateValidatedCode('Write a function that adds two numbers.');
console.log(code);

With this approach, the responses coming from the AI can become more reliable in terms of accuracy. Furthermore, with methods similar to Chain of Thought, the AI can be encouraged to evaluate the logical steps of its answers one by one and correct them where necessary. Finally, methods such as Retrieval-Augmented Generation (RAG) — which draw on existing databases or documentation — also reduce the risk of hallucination; when responding to a request, the AI can first consult sources such as a manual or a code repository.

2. Architectural and Performance Reasoning

Node.js's single-threaded event loop architecture provides a major advantage under high I/O-intensive loads, but it introduces architectural constraints for CPU-intensive operations. AI tools generally offer a standard solution when writing code, yet they cannot foresee a Node application's architectural decisions or performance bottlenecks. As noted on the Full Scale blog, AI can code an Express route; however, it cannot recognize that this route contains a blocking file system call, or that it will crash due to a missing await. In other words, AI produces code but cannot analyze that code's effects under real system load. For Node.js developers, this can lead to performance bugs and scalability problems.

For example, when an endpoint runs too slowly, an experienced developer immediately suspects that the event loop is being blocked. But even when an AI model sees a blocking call such as fs.readFileSync in the code, it "cannot understand" the load this will place on the system and may proceed with its recommendation regardless. In such a case, the application struggles to handle all incoming requests at once. Similarly, situations such as a memory leak or an unhandledRejection also cannot be foreseen by AI; these errors only emerge through real production experience and require a human eye.

Effects on Node.js: This limitation leads to the following effects on the architecture of Node.js services:

Single-Threaded Limitation: If any operation blocks the event loop, the entire application slows down. For this reason, synchronous methods should be avoided for critical operations, even in scenarios recommended by AI.
Resource Management: Efficient memory usage is required during large file uploads or multiple concurrent user requests. AI-generated code may overlook this complex flow and backpressure management, which can lead to memory overflows.
Error Recovery and Logging: Understanding the causes of errors that occur in distributed systems is difficult for AI. In Node.js, recovery mechanisms for unexpected shutdowns (e.g., a job queue, restart strategies) rely on developer experience; an LLM cannot foresee these automatically.

Practical Solutions and Design Patterns: To mitigate these problems, developers use the following methods:

Using Threads: CPU-intensive tasks (image processing, video encoding, etc.) should not block the main event loop. Instead, Node.js's worker_threads module can be used. For example, the simple Node.js code below runs a heavy operation in a thread so that the event loop is not blocked:

// worker-pool.js
import { Worker } from 'worker_threads';

export function runHeavyTask(data) {
  return new Promise((resolve, reject) => {
    const worker = new Worker(new URL('./worker-task.js', import.meta.url), { workerData: data });
    worker.once('message', resolve);
    worker.once('error', reject);
  });
}

// worker-task.js
import { parentPort, workerData } from 'worker_threads';
// CPU-intensive computation
const result = computeFibonacci(workerData);
parentPort.postMessage(result);

Using Multiple Processes (Cluster): To take advantage of multiple CPU cores, the Node.js cluster module can be used. This module creates multiple instances (Workers) of the application and distributes incoming requests among them to achieve parallelism. For example:

// cluster-example.js
import cluster from 'node:cluster';
import { availableParallelism } from 'node:os';
import http from 'node:http';

if (cluster.isPrimary) {
  const cores = availableParallelism();
  for (let i = 0; i < cores; i++) {
    cluster.fork();
  }
  cluster.on('exit', (worker) => console.log(`Worker ${worker.process.pid} died`));
} else {
  // Each worker opens its own HTTP server
  http.createServer((req, res) => {
    res.end('Hello World\n');
  }).listen(8000);
}

Stream-Based I/O Processing: When processing large data loads (files, network packets), using the Node.js stream API keeps memory usage constant. For example, to process a file line by line, code like the following can be used:

import { createReadStream } from 'fs';
import readline from 'readline';

async function processLargeFile(path) {
  const fileStream = createReadStream(path);
  const reader = readline.createInterface({ input: fileStream });
  for await (const line of reader) {
    // A small line is processed each time
    handleLine(line);
  }
}

In this way, since the entire file is not loaded into memory, the risk of an out-of-memory overflow decreases. Likewise, large data chains can be built with pipeline and Transform streams.

Performance Testing and Profiling: Rather than using the AI's code suggestions directly, load tests and profiling tools (e.g., clinic.js, V8 profilers) are used to detect and optimize bottlenecks. A Node developer should test an AI-suggested code snippet with these tools before moving it into production.

The patterns above carry developers' hierarchical decision-making abilities (which task should be solved with which method, and what is suitable for whom) beyond the reach of AI. Although AI accelerates coding, the weakest link in the system can only be detected through human oversight. Design quality, the selection of the right asynchronous patterns, and efficient resource usage ultimately remain dependent on developers' expertise.

3. Security and Contextual Knowledge Gaps

AI models are generally trained on publicly available and historical code datasets. However, these datasets often contain outdated or weak security practices. Because AI is fundamentally a statistical model, it learns the most frequently encountered code patterns; yet it has no knowledge of how secure those learned patterns are or whether they conform to an application's specific security requirements. This means that even when it runs seemingly functional code, it will bypass hidden security layers.

For example, an AI tool may fail to add input validation when constructing a SQL query, because it is difficult for it to understand the situations in which input sanitization is required. A study cited above concludes that "AI models generate code without deeply understanding your application's security needs, business logic, or architecture." For a developer, this carries the risk that the generated code may contain injection points (injection, XSS, CSRF, etc.). According to a Veracode report, in 2025, 45% of AI-generated code contained one of the OWASP Top 10 security vulnerabilities. For JavaScript specifically, this rate was reported as 43%.

Possible effects for Node.js developers:

Endpoint Security: AI-assisted code may fail to add proper validation when receiving user data such as req.body on the server side. This leaves the door open to malicious requests. In Node.js applications, libraries such as helmet and express-validator should be used; in addition, encryption/security functions should be manually reviewed.
Dependency Chains: AI may add npm packages for the functionality it needs. However, the owner or version of these packages may contain security vulnerabilities. When adding a new package, the developer should check the transitive (indirect) dependency chain and perform package signature and CVE scanning. Tools that detect library vulnerabilities (Snyk, npm audit, etc.) should be used in the environment.
Personal and Confidential Data: AI models cannot check for the presence of a hardcoded secret or confidential information within the code. If a server key or password has been mistakenly placed inside the code, the AI cannot catch this error. On the developer's side, environment variables and secret-management practices (secret manager) should be adopted.

Mitigation Methods: To overcome this limitation, the following can be done:

Static and Dynamic Security Analysis: All code suggested by AI should be examined with static analysis tools (e.g., ESLint + security rules, SonarQube) and dynamic scans. For example, OpenAI's security code review API or open-source tools can inspect the code. If security tests are integrated into the continuous integration (CI) pipeline, known weaknesses in AI code can be caught in advance.
Security Libraries and Frameworks: Critical operations can be standardized by using security-focused libraries built for Node.js (e.g., express-validator, csurf, or bcrypt). When obtaining output from AI, it is helpful to explicitly request (state in the prompt) that these libraries be used. Whether the code sanitizes user input when receiving it must be checked.
Security in the Software Development Lifecycle (DevSecOps): Adding security after the fact can be difficult when writing code with AI tools. For this reason, threat modeling should be performed at the outset, and the potential attack surfaces should be identified. For example, if a chatbot is being developed, precautions such as reviewing database access queries and adding XSS protection should be planned from the start.
Role-Based Controls: Some decisions require human judgment. For example, for code snippets that require user consent or legal compliance, human intervention should be preferred over an automated solution. AI output can also be run through human-approved security code reviews (peer review).

In general, however much AI accelerates code writing, "automatic convenience" can be a trap when it comes to security. Ensuring flawless security practices is still the job of experienced developers and security specialists. In the Node.js context, only humans can notice and fix the potentially dangerous aspects of code. For this reason, AI code should be treated as a "first draft," and security checks should never be skipped.

4. Lack of Context and Long-Term Memory

Modern LLMs are quite effective within short-term context (the context window), but they have limited memory. A model's context window is bounded by the amount of text it can "remember" at once. For example, GPT-4's context length is not billions of tokens — it is limited. This prevents the model from considering a very long conversation history or a large code repository all at once. In long interactions with a user or in large datasets, the AI may forget information that was passed in an earlier glance.

In a Node.js development environment, this shortcoming is felt in the following situations:

Stateful Context: Cross-process or long-term session information is not retained by the AI. For example, a chatbot that does not know what a user did in previous requests may, over time, forget information it needs to remember. As a solution, Node.js applications should store state in a session store or in databases and re-supply this state to the AI at each interaction.
Project and Code Recall: It is not practical to give an entire large codebase to an AI model. The AI may not remember the specific configurations used in your Node.js project (file paths, custom packages). In this case, it may be necessary to summarize important configuration information (e.g., database schemas) in advance and add it to the input, or to have the AI read part of the project incrementally. Otherwise, the model may make incorrect suggestions by overlooking the current code's dependencies or architecture.

As IBM has noted, an LLM's context window is like "working memory"; if too much information is fed in, the parts that cannot fit into the model are consumed, or must be summarized and passed along. This limits how much information the AI can learn at once. In Node.js services, when there are continuously running long-lived tasks or multi-step workflows, this situation can lead to synchronization problems.

Precautions and Patterns:

Chunking: Breaking long operations into small pieces enables the AI to remember the context in each one. For example, if a large dataset is being processed, a summary query can be made first; the AI is then guided to answer each step incrementally.
Persistent Memory Mechanisms: For information such as conversation history or user preferences, a long-term data storage system can be used. For example, a Node.js application can save user messages to a vector database or a simple database. On the next AI call, the relevant historical information is queried again and added as model input. This is part of the Retrieval-Augmented Generation (RAG) strategy.
Model Updating and Incremental Learning: Some approaches suggest reaching a result without retraining the AI each time by adding a dedicated RAG server or memory layer. For example, it is possible to set up a Node.js API that records user feedback and turn this data into a data source for the project. In the future, giving models the ability to "retain what they learned in a task" is also a research topic.

In short, AI models are limited in terms of short-term memory. Rather than continuously feeding the AI all the information the application needs, Node.js developers should design their systems to keep important state externally and feed it in when needed. This way, both context loss is prevented and the model is spared from information overload.

5. Lack of Creativity and Human Judgment

AI can produce content that appears "creative" to the extent of the data it was trained on; however, it does not possess a genuine capacity for original artistic or conceptual creation. AI draws inferences from templates it has previously seen or been given; it cannot create a solution from scratch, on its own, within an entirely new paradigm. For example, when a design problem or an original algorithmic optimization is required, human creativity still lies beyond AI. As IBM has said, "creativity is still a final frontier for artificial intelligence."

Similarly, AI models lack ethical and emotional reasoning. For instance, a Node.js chatbot may write sentences that appear to offer emotional support to a distressed user, but this is not genuine empathy; the AI does not have the ability to "understand sadness." In decision-support systems or in areas that touch on human matters, human intervention is still required. This situation has the following effects on Node.js development processes:

Design Understanding: AI can make suggestions about code or architecture, but it does not grasp the reasons behind design choices. For example, high-level decisions such as why a microservice architecture should be preferred, or that an endpoint is actually unnecessary, do not come from AI. This kind of strategic "completing the scenario" task relies on human expertise.
Developer Experience and the Human Factor: AI is limited in human-centered matters such as an application's ease of use, workflow design, or user interface. For example, when designing a new API, assessments such as "did this make things harder for the developer to use" are related to human perception. In the Node.js community, an application's fit with teams' workflows is critical — often more so than the technical perfection of the code.
Learning and Adaptation: AI cannot instantly learn from experience and adapt (no incremental learning). A developer, by contrast, can change their code by drawing lessons from problems experienced in a live system. An LLM cannot add this kind of feedback to its own model. Consequently, it requires human analysis again for each new problem.

Precautions: To address this weakness of AI, developers need to reinforce creative thinking and human judgment. AI outputs should be seen as mere suggestions and used as a "decision-support" tool. For example, if a code template is provided, the developer should confirm whether it is appropriate based on their own experience. Simply clarifying questions is also important: before a business requirement description is given to the AI, one should make sure it is fully understood (which in turn requires human communication). Full Scale experts emphasize this point by saying, "reviewing and correcting AI outputs is like the leadership a senior engineer exercises." A Node developer should show the same diligence, questioning the AI's statements with "okay, but is this really correct?"

Comparative Summary Table

Limitation / Task	Impact on Node.js	Solution / Mitigation Approach
Information Hallucination and Accuracy	AI-assisted code may produce incorrect functional results; the burden of readability and maintenance increases.	Code review, unit testing, type checking. Developer oversight and feeding current context via Retrieval. Human-approved vs. automated checks against AI output.
Performance / Event Loop	When the single thread is blocked, the entire Node service slows down; CPU-heavy operations tie up the processor.	Parallelizing heavy workloads with worker_threads or cluster. Processing large data piece by piece with the Stream API.
Security and Privacy	AI code often does not include security checks; it may harbor undetected security vulnerabilities (e.g., XSS, SQL inj.).	Static/dynamic security scanning, code review. Security-focused libraries (express-validator, csurf, etc.). Dependency auditing, version updates.
Context and Long-Term Memory	The LLM's memory limit causes past context to be lost in long conversations or large data processing. Process management becomes outdated.	Storing conversation/session data in a database. Using external memory via Retrieval-Augmented Generation. Feeding the LLM by breaking requests into small pieces.
Creativity / Ethical Judgment	AI cannot produce innovative architectural or design solutions, nor make ethical or emotional decisions. Developer inference is essential.	Design decisions and user experience under human oversight. AI output should always be treated as a "draft." Requirements should be re-examined and human judgment brought in.

Architecture Example Diagram

The mermaid diagram below is an example of a typical architectural pattern showing interaction with an AI service in Node.js applications. Requests from the client are routed to the Node.js API; based on the type of work, the API connects to components such as LLM services, the database, or job queues. Work-intensive tasks are processed in separate services or threads:

flowchart LR
  A[Client Application] --> B[Node.js API Server]
  B --> C[LLM Service]
  B --> D[Database]
  B --> E[Job Queue]
  E --> F[CPU-Heavy Worker]
  C --> D
  style A fill:#D6EAF8,stroke:#1B4F72,stroke-width:2px
  style B fill:#D1F2EB,stroke:#145A32,stroke-width:2px
  style C fill:#F9E79F,stroke:#7D6608,stroke-width:2px
  style D fill:#FADBD8,stroke:#7B241C,stroke-width:2px
  style E fill:#D7BDE2,stroke:#512E5F,stroke-width:2px
  style F fill:#AED6F1,stroke:#154360,stroke-width:2px

In the architecture above, the Node.js API is designed in an asynchronous (non-blocking) manner. Large data jobs are placed onto the Job Queue and processed in parallel by background Worker processes. When AI support is required (e.g., text summarization, analysis), queries are sent to the LLM Service. This service makes a request to the AI model, receives the response, and forwards it to the API. This design prevents a single service from bearing the entire load and provides scalability.

Looking Ahead and Research Directions

In the coming years, many advances are expected in AI technology. Work continues on increasing model context lengths, on long-term memory models, and on enabling AI systems to explain their own decision processes. Researchers are focusing on improving LLMs' real-time learning capabilities and on enhancing secure code generation. For example, chain-of-thought methods reduce hallucinations, while algorithmic learning models may play a role in optimizing code. On the Node.js side, new releases may bring stronger concurrency (advances in worker_threads, new protocols) and built-in security scanning.

The timeline below shows important milestones in both AI and Node.js:

gantt
  dateFormat  YYYY
  title AI and Node.js Development Timeline
  section AI Developments
    GPT-3 Released         :milestone, 2020,    1d
    ChatGPT Launch         :milestone, 2022,    1d
    GPT-4 Released         :milestone, 2023,    1d
    Hallucination Research :milestone, 2024,    1d
    GPT-5 Anticipated      :milestone, 2025,    1d
  section Node.js Versions
    Node.js 14 LTS         :milestone, 2020,    1d
    Node.js 18 LTS         :milestone, 2022,    1d
    Node.js 20 LTS         :milestone, 2023,    1d
    Node.js 26 (latest)    :milestone, 2026,    1d

The diagram above includes large models such as GPT-3 (2020) and GPT-4 (2023), as well as new research areas (hallucination categories, etc.). Important Node.js LTS versions have also been added. This technology development line points to upcoming changes for both the AI and Node.js communities. For example, the development of GPT-5's logical reasoning and security orientations may indicate that integration with Node.js applications will become safer. Likewise, in future Node.js releases, stream management and process parallelism may be further improved.

References

Matt Watson, AI-proof Node.js Developer Interview Questions, Full Scale (June 2026).
Jens Wessling, "We Asked 100+ AI Models to Write Code. Here's How Many Failed Security Tests." Veracode Blog (July 2025).
SoftwareSeni, Why 45 Percent of AI Generated Code Contains Security Vulnerabilities (November 2025).
Fang Liu et al., "Beyond Functional Correctness: Exploring Hallucinations in LLM-Generated Code", ArXiv (April 2024).
Laurence Santy, 15 Things AI Can — and Can't Do (So Far), Invoca Blog (March 2025).
Veracode 2025 GenAI Code Security Report, Veracode (July 2025).
IBM, What is a context window? (IBM Think).
Node.js Documentation, worker_threads, cluster, stream (v26.5.0).
DEV Community (Atlas Whoff), Node.js Streams: Processing Large Files Without Running Out of Memory (April 2020).
Full Scale Booklet (Matt Watson), Product Driven: Build Something People Want (2023) — Node.js best practices.

Flip duel

DevUnionX — Tue, 23 Jun 2026 15:17:07 +0000

DevUnionX

Jun 23

(New!)5 Things Even AI Can't Do, Fetch API

#api #webdev #programming #productivity

19 min read

DEV Community: DevUnionX

Node.js in 2026: The Event Loop, Safe Singletons, and Modern Parallelism

1. Understanding the Node.js Event Loop

Event Loop Phases

setTimeout() vs setImmediate()

Microtasks and process.nextTick()

2. Event Loop Performance: What Should You Monitor?

3. The Evolution of the Singleton Pattern

The Solution: AsyncLocalStorage

4. Async Initialization: Avoid Duplicate Instances

5. Moving Beyond One Thread: Worker Threads

Why Worker Pools Matter

6. Sharing Data Between Worker Threads

7. Framework Choices in 2026

8. Singleton Patterns in Serverless Applications

just added a new versiyon of css features

The 10 Best New CSS Features in 2026 Already Supported in All Major Browsers

The 10 Best New CSS Features in 2026 Already Supported in All Major Browsers

1. Container Queries: Make Components Responsive to Their Own Space

2. Container Style Queries: Let Components React to Their Context

3. The :has() Selector: CSS Can React to Descendants

4. CSS Nesting, Cascade Layers, and :where(): Keep Large Stylesheets Manageable

Native CSS nesting

Cascade layers

Reduce specificity with :where()

5. Better Typography: text-wrap, font-size-adjust, and Ruby Layout

Balance headings with text-wrap: balance

Improve paragraph wrapping with text-wrap: pretty

Keep fallback fonts more consistent with font-size-adjust

Use Ruby layout for annotated text

6. More Stable Layouts and Faster Long Pages: aspect-ratio and content-visibility

Reserve the right shape with aspect-ratio

Skip unnecessary rendering work with content-visibility

7. Modern Color: oklch(), color-mix(), light-dark(), and Relative Colors

Use oklch() for more controlled color palettes

Mix colors with color-mix()

Support light and dark themes with light-dark()

Derive colors from an existing color

8. Better Forms with field-sizing and accent-color

Let fields size themselves around their content

Match native controls to your theme

9. More Declarative UI with :open, Exclusive Accordions, and Popovers

Style open elements with :open

Create exclusive accordions with native HTML

Use the Popover API for simple overlays

10. Small Improvements That Make Interfaces Feel More Polished

Prevent scrollbar-related layout shifts

Style the scrollbar

Highlight text reached through a text fragment

Keep ruby annotations readable

Three More Capabilities to Adopt Progressively

11. CSS Anchor Positioning: Position UI Relative to Another Element

12. Scroll-Driven Animations: Let Scrolling Control the Animation

13. transition-behavior: allow-discrete: Transition Properties Such as display

A Related Platform Feature: The Navigation API

How to Use These Features in Production

1. Start with the support status

2. Prefer progressive enhancement

3. Measure performance instead of assuming

4. Avoid JavaScript when CSS or native HTML already solves the problem

read and learn, use better ereactnative for your app

5 Things AI Cannot Do at React Native

5 Things AI Cannot Do at React Native

1. Compute and Power Constraints

2. Model Size and Architecture

3. Connectivity and Latency

4. Integration and Platform Constraints

5. Privacy and Security

Custom Native Modules & Bridging (TurboModules)

Performance Profiling and Optimization

Native Debugging & Tooling

New Architecture Migration & UI Quirks

Platform Quirks and Build Configuration

do you believe your sql skill?

5 Things AI Cannot Do at PostgreSQL

5 Things AI Cannot Do at PostgreSQL

1. AI Cannot Understand Your Business Logic

2. AI Cannot Make the Architecture Trade-Off for You

3. AI Cannot Reliably Find the Root Cause of a Production Incident

4. AI Cannot Take Responsibility for Security Decisions

3. The `:has()` Selector: CSS Can React to Descendants

4. CSS Nesting, Cascade Layers, and `:where()`: Keep Large Stylesheets Manageable

Reduce specificity with `:where()`

5. Better Typography: `text-wrap`, `font-size-adjust`, and Ruby Layout

Balance headings with `text-wrap: balance`

Improve paragraph wrapping with `text-wrap: pretty`

Keep fallback fonts more consistent with `font-size-adjust`

6. More Stable Layouts and Faster Long Pages: `aspect-ratio` and `content-visibility`

Reserve the right shape with `aspect-ratio`

Skip unnecessary rendering work with `content-visibility`

7. Modern Color: `oklch()`, `color-mix()`, `light-dark()`, and Relative Colors

Use `oklch()` for more controlled color palettes

Mix colors with `color-mix()`

Support light and dark themes with `light-dark()`

8. Better Forms with `field-sizing` and `accent-color`

9. More Declarative UI with `:open`, Exclusive Accordions, and Popovers

Style open elements with `:open`

13. `transition-behavior: allow-discrete`: Transition Properties Such as `display`