DEV Community: DevUnionX

HTML?

DevUnionX — Thu, 12 Nov 2026 16:46:34 +0000

DevUnionX

Nov 12

10 Things Even AI Can't Do in HTML

#html #css #webdev #web3

11 min read

10 Things Even AI Can't Do in HTML

DevUnionX — Thu, 12 Nov 2026 16:46:24 +0000

Give it a prompt, and it can create a navigation bar, build a landing page, generate forms, organize content, and even produce a complete website structure.

The result might look perfectly fine at first glance.

But there's a difference between generating HTML and knowing how to use HTML properly.

A page can render without errors and still have a confusing structure. A button can look correct but behave like the wrong element. A form can collect information without considering whether users actually need to provide it.

This is where things get interesting.

I've been thinking about what makes a developer valuable in a world where generating code is becoming easier. The answer isn't simply writing more code or memorizing more HTML elements. It's understanding why something should be built, making the right decisions, and knowing when an apparently correct solution isn't good enough.

Here are ten things AI still cannot reliably handle on its own when working with HTML.

1. Understand the Problem Before Writing the Markup

The first mistake in many development tasks happens before anyone writes a single line of HTML.

Someone describes a feature, and the immediate reaction is to start implementing it.

AI follows this approach particularly well. Give it a request for a dashboard, navigation menu, or registration page, and it will probably generate something that matches the description.

But does the requested interface actually solve the problem?

Imagine a company asking for a registration form with fifteen fields.

AI can generate all fifteen fields. It can add labels, placeholders, and validation attributes.

A developer should ask a different question:

Do we really need all fifteen fields?

Perhaps the application only needs an email address and a password. Maybe the remaining information can be collected later, when it becomes relevant.

This is what problem definition means. Before deciding how to implement something, you need to understand why it is necessary.

The HTML might look like this:

<form action="/subscribe" method="post">
  <label for="email">Email address</label>

  <input
    type="email"
    id="email"
    name="email"
    autocomplete="email"
    required
  >

  <button type="submit">
    Subscribe
  </button>
</form>

It's simple because the task itself is simple. There's no reason to add unnecessary fields or interactions.

AI can help implement a requirement, but deciding whether that requirement is worth implementing requires product understanding, communication, and judgment.

The point: A good developer doesn't just ask how to build something. They ask whether it should be built in the first place.

2. Give HTML Elements Their Actual Meaning

HTML is not just a collection of tags used to arrange content on a page.

It is a language for describing the structure and meaning of a document.

This distinction is easy to forget when working with modern frontend frameworks and CSS-heavy interfaces.

Consider this:

<div class="button">
  Save changes
</div>

It looks like a button. With CSS, you can make it look exactly like one.

But it isn't a native button. It doesn't automatically provide the same keyboard interaction, focus behavior, or semantics.

The more appropriate version is:

<button type="button">
  Save changes
</button>

The same principle applies to links, lists, headings, tables, and page sections.

For example:

<a href="/about">About us</a>

A link navigates somewhere.

<button type="button">Open settings</button>

A button performs an action.

These elements might look similar after styling, but their purposes are different.

AI can generate semantic HTML when asked. The problem is that it may choose elements based on how the output should look rather than what the elements actually represent.

Understanding the difference requires knowledge of the browser platform and the purpose of the interface.

The point: HTML should describe what something is, not just how it should appear.

Reference: MDN — HTML Elements Reference

3. Build a Structure That People Can Actually Navigate

A web page isn't only consumed visually.

Some users navigate through headings, landmarks, and document regions using a screen reader. Others use a keyboard or rely on browser features to move through the content.

This is why document structure matters.

Consider a basic page:

<body>
  <header>
    <nav aria-label="Main navigation">
      <a href="/">Home</a>
      <a href="/articles">Articles</a>
      <a href="/contact">Contact</a>
    </nav>
  </header>

  <main>
    <article>
      <h1>Understanding HTML Semantics</h1>

      <p>
        HTML provides structure and meaning to web content.
      </p>

      <section aria-labelledby="importance">
        <h2 id="importance">Why semantics matter</h2>

        <p>
          Semantic elements help browsers and assistive
          technologies understand a document.
        </p>
      </section>
    </article>
  </main>

  <footer>
    <p>© 2026 Example Website</p>
  </footer>
</body>

Elements such as <header>, <nav>, <main>, <article>, and <footer> communicate the purpose of different regions.

Headings also establish relationships between sections.

One important detail: a <section> does not automatically become a named accessibility landmark. When it represents a distinct region users need to navigate to, give it an accessible name, usually through a heading.

This isn't about adding as many semantic elements as possible. It's about choosing the right structure for the content.

A page with ten unnecessary sections isn't automatically better than a page with three meaningful ones.

AI can generate a structure, but it doesn't automatically know which parts of a particular document deserve to be grouped together.

The point: A good HTML structure makes sense to people, browsers, and assistive technologies.

References: MDN — Structuring Documents · W3C — Page Structure

4. Make Content Understandable Beyond Its Visual Appearance

A page can look beautiful while communicating very little to machines or users who cannot see its visual presentation.

Think about a product listing containing ten images, prices, and buttons.

If the HTML contains only generic containers and images without meaningful text, it becomes harder for different technologies to understand what the content represents.

The same applies to page metadata.

A descriptive document title is more useful than a generic one:

<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">

  <title>HTML Semantics: A Practical Guide</title>

  <meta
    name="description"
    content="Learn how semantic HTML improves document structure,
    accessibility, and maintainability."
  >
</head>

The title and metadata help describe the document.

Google Search can use the <title>, visible page headings, and other signals when generating search result titles. However, providing good metadata does not guarantee a particular ranking or an exact search result title.

The content itself matters just as much.

For example, a product page should communicate the product name, relevant details, price, and available actions through actual content rather than relying entirely on images or decorative elements.

A developer has to understand what information matters and how it should be represented.

AI can generate metadata and markup, but it cannot independently guarantee that the information accurately represents the page.

The point: HTML should communicate the meaning of the content, not merely display it.

References: Google Search Central — Title Links · Google Search Central — SEO Guide

5. Provide Meaningful Experiences for Users Who Cannot See the Page

Accessibility is one of those areas where an interface can look completely correct while still having serious problems.

A developer can create a beautiful image gallery, but what happens when someone using a screen reader visits it?

Consider:

<img src="product.jpg" alt="Image">

The markup includes alternative text, but it doesn't communicate anything useful about the image.

A better example would be:

<img
  src="running-shoes.jpg"
  alt="Black running shoes with white soles, shown from the side"
>

The description communicates relevant visual information.

There is another important distinction: not every image needs descriptive alternative text.

Decorative images that don't provide meaningful information should generally use an empty alt attribute:

<img src="decorative-pattern.png" alt="">

This prevents screen readers from announcing irrelevant content.

The same thinking applies to other elements:

Use meaningful text for links.
Provide labels for controls.
Preserve logical heading order.
Make interactive elements keyboard-accessible.
Avoid communicating important information through color alone.

AI can generate many of these attributes, but it doesn't necessarily know what an image contributes to a particular page or what information a user needs.

Accessibility is not a box you check by adding alt to every image.

The point: You need to understand the content before deciding how to make it accessible.

Reference: W3C WAI — Images Tutorial

6. Design Forms Around People, Not Just Input Fields

Forms are among the most common places where poor HTML decisions affect real users.

AI can generate a form with every input type imaginable. But a useful form is not defined by how many fields it contains.

It is defined by how easily someone can complete the task.

For example, consider a simple registration form:

<form action="/register" method="post">
  <fieldset>
    <legend>Create your account</legend>

    <label for="name">Full name</label>
    <input
      type="text"
      id="name"
      name="name"
      autocomplete="name"
      required
    >

    <label for="email">Email address</label>
    <input
      type="email"
      id="email"
      name="email"
      autocomplete="email"
      required
    >

    <label for="password">Password</label>
    <input
      type="password"
      id="password"
      name="password"
      autocomplete="new-password"
      required
    >

    <button type="submit">Create account</button>
  </fieldset>
</form>

Notice a few details:

Labels are explicitly connected to their inputs.
The appropriate autocomplete values help browser autofill.
Required fields are marked clearly.
Related controls are grouped using <fieldset> and <legend>.
Native form behavior is preserved.

HTML also provides built-in validation:

<input
  type="email"
  name="email"
  required
>

The browser can check whether the field is empty or whether the entered value has an appropriate email format.

However, client-side validation is not a security mechanism. The server must validate submitted data independently.

The W3C Forms Tutorial also emphasizes clear instructions, understandable error messages, and giving users a chance to review or correct their input.

These details are easy to overlook when the only goal is generating a form that looks correct.

The point: A good form asks for the right information, explains what is expected, and helps users recover from mistakes.

References: W3C — Forms Tutorial · W3C — Labeling Controls · W3C — Input Validation

7. Understand That Localization Is More Than Changing Words

A website can be translated into twenty languages and still feel foreign to users in every one of them.

That's because localization involves more than replacing English sentences with translated alternatives.

It also includes writing direction, date formats, currencies, terminology, cultural references, and the way information is presented.

For example, a page intended for Arabic readers should communicate its language and direction correctly:

<html lang="ar" dir="rtl">
  <head>
    <meta charset="UTF-8">
    <title>مرحباً بك</title>
  </head>

  <body>
    <main>
      <h1>مرحباً بك</h1>
      <p>نحن سعداء بزيارتك.</p>
    </main>
  </body>
</html>

The lang attribute identifies the language of the document, while dir establishes its text direction.

For content that can contain text in different writing directions, the <bdi> element can help isolate text whose direction should be determined independently:

<p>
  Username:
  <bdi>developer_محمد</bdi>
</p>

This matters when displaying user-generated names or text that might mix left-to-right and right-to-left characters.

But technical direction is only one part of localization.

An expression that sounds friendly in one language may sound too informal or even inappropriate in another. A symbol or color can also carry different meanings depending on the audience.

AI can translate words and generate locale-aware markup. Understanding whether the complete experience feels natural in a particular culture requires local knowledge and human review.

The point: A localized website should feel like it was designed for its audience, not simply translated for it.

8. Preserve the Browser's Native Capabilities

Modern frontend development often involves JavaScript frameworks, custom components, and complex application architectures.

Sometimes, developers forget that the browser already provides a lot of useful functionality.

A simple link can navigate between pages:

<a href="/articles">
  Read articles
</a>

A native form can submit information:

<form action="/search" method="get">
  <label for="search">Search articles</label>

  <input
    type="search"
    id="search"
    name="q"
  >

  <button type="submit">Search</button>
</form>

Neither example requires JavaScript to provide its basic browser behavior.

You can add JavaScript later to improve the experience, but the essential functionality already exists.

This is closely related to progressive enhancement.

The idea is simple: start with meaningful HTML that provides the core experience, then add CSS and JavaScript to improve it.

For example, a navigation link should still be a useful link before any client-side routing enhancement is added.

Not every interface needs to be a fully custom JavaScript component.

Sometimes the native element is the better solution.

The PDF's discussion of smart reuse is relevant here. Originality doesn't require rebuilding everything from scratch. It often comes from combining existing tools and capabilities in a more appropriate way.

The point: Knowing when not to write additional code is also a development skill.

Reference: web.dev — Learn Forms

9. Create Something Original Without Ignoring Existing Standards

This is probably the most interesting part of the discussion.

What does originality actually mean in software development?

Does writing an entirely new HTML structure make a developer original? Does avoiding existing patterns automatically make a project better?

Not necessarily.

The PDF introduces an important distinction: originality is not simply creating something that has never existed before. It can come from the creator's distinctive contribution and the way existing knowledge is combined.

I think this idea applies directly to HTML development.

Consider the following three dimensions:

Product-focused originality

The structure and content should serve the specific product. A documentation website, an online store, and a portfolio do not need the same document structure.

Person-focused originality

The content, writing style, presentation, and decisions should reflect a meaningful identity rather than simply copying a generic template.

Social and strategic originality

The implementation should make sense for the intended audience, the team, and the goals of the project.

For example, using <details> and <summary> to create an FAQ section is not a completely new invention.

<section aria-labelledby="faq-heading">
  <h2 id="faq-heading">Frequently Asked Questions</h2>

  <details>
    <summary>What is semantic HTML?</summary>
    <p>
      Semantic HTML uses elements that describe
      the meaning and purpose of content.
    </p>
  </details>

  <details>
    <summary>Why should I use it?</summary>
    <p>
      It helps browsers, developers, and assistive
      technologies understand the document.
    </p>
  </details>
</section>

The originality is not in inventing a new element. It's in recognizing that a native HTML feature is the right solution for a particular problem.

A developer who understands HTML can combine existing elements, patterns, and ideas in ways that produce a more useful experience.

AI can suggest combinations, but choosing the right combination depends on understanding the product and its users.

The point: Originality doesn't mean avoiding existing solutions. It means knowing how to use them in a way that creates something valuable.

10. Take Responsibility for the Final Result

This is where technical knowledge, experience, and professional judgment come together.

AI can produce a complete HTML document, but that doesn't mean the document is ready for production.

Someone still needs to check whether:

The markup follows the HTML standard.
Interactive elements behave correctly.
The document has a logical structure.
Forms are usable and provide appropriate feedback.
Accessibility requirements have been considered.
The content and metadata are accurate.
The implementation fits the existing codebase.

And importantly, someone needs to take responsibility when something goes wrong.

A useful starting point is validating the generated markup with the Nu HTML Checker.

But passing validation doesn't guarantee a good user experience. You should also test the page using a keyboard, screen reader, different browsers, and realistic content.

There is another part of responsibility that often gets overlooked: working with other developers.

The PDF makes a valuable point about shared coding conventions. A developer's originality should not mean introducing a completely different style into every project.

Imagine joining an established codebase where every page follows consistent naming, indentation, component boundaries, and document conventions.

Adding your own personal style everywhere might feel creative, but it can make the code harder for the next developer to understand.

A professional developer knows when to follow an existing pattern and when there is a strong reason to improve it.

That decision often requires discussion, explanation, and collaboration.

The point: Generating code is an activity. Owning the quality and consequences of that code is a responsibility.

So, What Makes a Developer Valuable in the AI Era?

I don't think the answer is writing HTML faster than an AI model.

AI can generate basic markup, create forms, suggest semantic elements, and explain unfamiliar parts of the standard. It can save a considerable amount of time on repetitive work.

But speed alone doesn't define a good developer.

The more important skills are becoming increasingly clear:

Defining the right problem before implementation.
Understanding the technology beyond copying examples.
Combining existing solutions in useful ways.
Making thoughtful architectural and design decisions.
Communicating with teammates and understanding users.
Maintaining code that other people can work with.
Continuously learning and developing deeper expertise.

One idea from the PDF is especially relevant here: technical execution is becoming easier to automate, while the value of judgment, problem-solving, and meaningful contribution becomes more important.

That doesn't mean technical knowledge is becoming irrelevant. Quite the opposite.

The deeper your understanding of HTML, browser behavior, accessibility, and web standards, the better you can evaluate generated code and recognize when something is wrong.

AI can help you move faster, but understanding what deserves to be built is still a major part of the job.

10 Things Even AI Can't Do in Frontend Development (At Least Not on Its Own)

DevUnionX — Sun, 08 Nov 2026 00:31:46 +0000

AI can build a React component, generate a landing page, write CSS, connect an API, and even create an entire frontend from a short description.

A few years ago, getting that much code generated automatically would have sounded unrealistic. Today, it's part of a normal development workflow.

But here's something worth remembering: generating a working interface and building a good user experience are two very different things.

An AI-generated page might look impressive in a screenshot. Open it, resize the browser, navigate with a keyboard, test it on a slower connection, or use it with real content. That's usually when the missing details start to appear.

I've been thinking about this from a frontend developer's perspective. AI is becoming a useful part of the job, but there are still areas where generated code needs human judgment, experience, and a proper review process.

Here are ten of them.

1. Understand What the User Actually Needs

AI is very good at following instructions. The problem is that users don't always know how to describe what they need.

A product owner might ask for a dashboard with five charts, three filters, and a sidebar. AI can generate that layout without much trouble.

But does the dashboard actually help anyone make a decision?

Maybe users only need two important metrics. Maybe the filters are unnecessary. Maybe the information should be organized around tasks rather than categories.

These are product decisions, not coding problems.

A frontend developer needs to understand the reason behind a feature before deciding how to implement it. That includes business goals, user behavior, accessibility needs, and the context in which the interface will be used.

AI can suggest solutions based on the information it receives. It cannot reliably discover missing requirements or know which assumptions are wrong without additional evidence.

The difference: AI can implement a requested feature. Understanding whether that feature should exist in the first place requires product thinking.

2. Create a Distinctive Design, Not Just Another Familiar Interface

There is a reason so many AI-generated dashboards and landing pages look similar.

The same gradients, rounded cards, purple buttons, oversized headings, and familiar layouts appear again and again.

These patterns aren't necessarily bad. In fact, many are perfectly reasonable design choices. The problem starts when every product ends up looking like a variation of the same template.

A good interface needs more than visual consistency. It needs an identity.

A developer working with a designer considers questions that are difficult to reduce to a prompt:

What should users notice first?
Which elements deserve visual emphasis?
Does the design communicate the personality of the product?
Is the layout appropriate for the audience?
Does the interface feel different for a meaningful reason?

A 2026 study comparing AI-generated and human-created interface prototypes found that participants could evaluate generated interfaces positively on practical usability dimensions, while the more experience-oriented dimensions, such as originality and innovation, were less convincing. It's one study, not a universal verdict, but it illustrates an important distinction.

Read the study: Usable but Conventional — An Empirical Study on the UX of AI-Generated Interface Prototypes.

AI can give you a good starting point. Turning that starting point into a recognizable product experience takes design direction.

3. Make Animations Feel Natural

Animations are easy to underestimate.

A button changes color. A modal appears. A card moves into place. Technically, everything works.

But good motion design is not simply about making elements move. It communicates relationships, provides feedback, and helps users understand changes in the interface.

AI-generated code often starts with generic transitions. That is fine for a prototype, but applying the same duration and easing curve to every interaction can make an application feel mechanical.

Consider the difference between a quick button response and a page transition. They shouldn't necessarily have the same timing or visual weight.

Performance is another part of the problem. Animating layout-heavy properties such as width, height, or position can cause additional layout work. Sometimes a transform-based animation is a better choice.

There is also a simple accessibility detail that should not be forgotten:

.card {
  transition: transform 220ms ease;
}

.card:hover {
  transform: translateY(-4px);
}

@media (prefers-reduced-motion: reduce) {
  .card {
    transition: none;
  }

  .card:hover {
    transform: none;
  }
}

The prefers-reduced-motion media query lets the interface respect users who have enabled reduced motion in their operating system.

The goal isn't to remove every animation. It's to make sure that unnecessary movement doesn't get in the way.

The difference: AI can generate transitions. Deciding how motion should communicate an interaction, remain performant, and respect user preferences takes more than generating CSS.

Reference: MDN — prefers-reduced-motion.

4. Personalize an Experience Without Making It Feel Intrusive

Personalization is one of the most interesting areas of modern frontend development.

An application can recommend content, remember preferences, adapt its interface, and respond to previous interactions.

AI can help implement these features, but there is a subtle problem: more personalization does not automatically mean a better experience.

Imagine a fitness application that recommends a difficult workout because the user hasn't exercised recently.

That recommendation might be based on real activity data. But perhaps the user is recovering from an injury, travelling, or simply taking a planned break.

The application has information, but it doesn't necessarily have enough context to make a useful decision.

Personalization should have a clear purpose. It should solve a problem rather than demonstrate how much information an application has collected.

Good implementations also give users control over their preferences and explain why certain recommendations appear.

For example, a recommendation such as:

"You saved a similar article last week. Here are three related resources."

Feels more relevant than a random recommendation with no explanation.

Developers need to decide what data is appropriate, which recommendations are useful, and when personalization becomes uncomfortable.

The difference: AI can recognize patterns. Deciding whether those patterns should influence someone's experience requires context and judgment.

5. Understand Localization Beyond Translation

Translating an interface is not the same as localizing it.

AI can translate a collection of interface strings into multiple languages very quickly. However, a technically correct translation can still sound unnatural or communicate the wrong meaning.

Idioms, humor, cultural references, tone, and local expectations are difficult to handle with literal translations.

The same problem applies to visual design.

A layout designed for a left-to-right language may need adjustments for Arabic or Hebrew. Dates, currencies, address formats, number formatting, and even familiar symbols can differ between markets.

For example, an interface should not assume that every language uses the same text direction.

<html lang="ar" dir="rtl">
  <body>
    <main>
      <h1>مرحباً بك</h1>
      <button>متابعة</button>
    </main>
  </body>
</html>

CSS logical properties also make layouts easier to adapt:

.card {
  padding-inline: 1.25rem;
  margin-inline-start: 1rem;
  border-inline-start: 3px solid #6366f1;
}

Instead of hardcoding left and right, logical properties work with the document's writing direction.

The W3C explains that localization involves adapting an application to the language, cultural, and other requirements of a target market. It goes well beyond translating text.

W3C — Localization vs. Internationalization.

The difference: AI can translate strings. Making a product feel native to another audience requires cultural understanding and real local feedback.

6. Build Accessibility Into the Experience

This is one of the most important points on the list.

A frontend can look perfect and still be difficult to use for someone navigating with a keyboard or screen reader.

AI-generated interfaces sometimes contain buttons without meaningful labels, poor color contrast, confusing heading structures, missing alternative text, or controls that are difficult to operate without a mouse.

The issue is that accessibility is not always visible.

A screenshot cannot tell you whether a screen reader announces a button correctly or whether a keyboard user can reach every important interaction.

Consider this example:

<div class="button" onclick="submitForm()">
  Submit
</div>

It may look like a button, but it does not provide the native keyboard and accessibility behavior of an actual button.

A better implementation is straightforward:

<button type="submit">
  Submit
</button>

Native HTML elements already provide important semantics and interaction behavior.

For more complex interfaces, developers also need to manage focus, labels, keyboard navigation, error messages, and dynamic content.

The WCAG 2.2 guidelines organize accessibility around four principles:

Perceivable: Users must be able to perceive the information.
Operable: Users must be able to interact with the interface.
Understandable: Content and behavior should be understandable.
Robust: Content should work with current and future assistive technologies.

Recent research continues to identify accessibility issues in AI-generated interfaces. A 2026 IEEE study of AI-generated UI components reported problems including missing labels, incorrect ARIA usage, focus issues, and keyboard navigation failures.

Read the IEEE study.

Automated accessibility tools are useful, but they are not a replacement for manual testing with keyboards and assistive technologies.

The difference: AI can help write accessible markup. Making sure the whole experience is accessible requires testing with real interaction methods and users.

7. Make Responsive Design Work Beyond a Screenshot

A layout that looks good at 1440 pixels is not automatically responsive.

Real users have different devices, browser settings, text sizes, orientations, input methods, and screen dimensions.

A navigation bar that works on a desktop may become unusable on a narrow screen. A heading may overflow when translated. A card may look fine with short sample text but break when real content arrives.

AI can generate media queries, flexible grids, and responsive components. But it doesn't automatically prove that the result works across the situations your users encounter.

For example, this is a reasonable starting point:

.product-grid {
  display: grid;
  grid-template-columns:
    repeat(auto-fit, minmax(min(100%, 16rem), 1fr));
  gap: 1.25rem;
}

The layout adapts to the available space without requiring a separate breakpoint for every device.

But responsive design is not just about screen width.

Consider:

Does the interface still work with larger text?
Are buttons comfortable to use on touchscreens?
Does the navigation support keyboard interaction?
Does the layout handle long translations?
What happens in landscape orientation?

These details need to be tested.

MDN's Responsive Design guide covers the platform features used to build layouts that adapt to different environments.

The difference: AI can write responsive CSS. Verifying the experience across real devices, content, and interaction methods is a separate job.

8. Optimize Performance Based on Real Users

AI can suggest code optimizations, lazy loading, code splitting, caching, and image compression.

However, performance is not something you can judge by looking at the source code alone.

A page can load quickly on a developer's laptop and feel painfully slow on an older phone or a poor network connection.

The actual experience depends on many things:

Device capabilities.
Network conditions.
JavaScript execution.
Third-party scripts.
Image and font loading.
Layout and rendering work.
User interactions.

That's why modern frontend performance uses real-world measurements.

Google's Core Web Vitals provide three important signals:

Metric	What it measures	Good target
LCP	Loading performance	2.5 seconds or less
INP	Interaction responsiveness	Less than 200 ms
CLS	Visual stability	Less than 0.1

These targets are useful, but hitting them in a local test doesn't guarantee that every user has the same experience.

You need both controlled testing during development and field data from actual users.

Google — Core Web Vitals

The difference: AI can suggest performance improvements. Knowing which improvement matters requires profiling, measurement, and an understanding of the application's real usage.

9. Debug Problems That Only Exist in Production

A bug report that says "the page sometimes freezes" is not very helpful.

What browser was being used? Which device? What happened immediately before the freeze? Was the network slow? Did a third-party script fail? Was the user working with unusual data?

These questions matter.

AI can analyze logs, explain stack traces, and suggest possible fixes. That's genuinely useful. But it can only reason from the information available to it.

Production problems are often difficult because several things happen together.

For example, a race condition might only appear when a user quickly changes filters while a previous API request is still running.

A basic implementation might look like this:

async function searchProducts(query) {
  const response = await fetch(
    `/api/products?q=${encodeURIComponent(query)}`
  );

  if (!response.ok) {
    throw new Error("Failed to load products");
  }

  return response.json();
}

The function is reasonable, but it doesn't handle the situation where users trigger multiple searches quickly and responses return in a different order.

A more complete implementation might use AbortController to cancel outdated requests:

let controller;

async function searchProducts(query) {
  controller?.abort();
  controller = new AbortController();

  try {
    const response = await fetch(
      `/api/products?q=${encodeURIComponent(query)}`,
      { signal: controller.signal }
    );

    if (!response.ok) {
      throw new Error("Failed to load products");
    }

    return await response.json();
  } catch (error) {
    if (error.name === "AbortError") {
      return null;
    }

    throw error;
  }
}

Even this solution is only one part of the problem. The application still needs correct loading states, error handling, and a decision about what to display when a request fails.

Production debugging requires logs, monitoring, reproduction steps, browser knowledge, and an understanding of the complete system.

The difference: AI can help investigate a bug. It cannot reliably diagnose an environment it cannot observe.

10. Take Responsibility for Security and Long-Term Code Quality

A frontend project is not finished when the interface compiles.

The code needs to be understandable, secure, maintainable, and compatible with the rest of the application.

AI can generate a component quickly, but it may not know all the architectural decisions behind an existing codebase. It might introduce unnecessary dependencies, duplicate existing logic, bypass established patterns, or place too much responsibility inside a single component.

Security deserves particular attention.

For example, consider rendering user-provided content:

element.innerHTML = userInput;

This can create a cross-site scripting vulnerability when untrusted input is interpreted as HTML.

For plain text, use a safer approach:

element.textContent = userInput;

In framework-based applications, use the framework's normal escaped text-rendering mechanisms. Avoid bypassing those protections with raw HTML unless the content has been properly sanitized.

There is another important rule: frontend code is visible and controllable by the user. Business-critical authorization, secrets, and security decisions must not rely on client-side checks.

The OWASP Web Frontend Security Cheat Sheet explains why client-side input, API responses, browser storage, and third-party data should all be treated carefully.

Long-term quality requires more than passing tests today. It means being able to understand the code six months later, update dependencies safely, investigate regressions, and add features without breaking unrelated parts of the application.

The difference: AI can generate and refactor code. Developers remain responsible for the security boundaries, architecture, and consequences of shipping it.

Does This Mean AI Is Bad at Frontend Development?

Not at all.

I use AI as a development tool, and there are plenty of situations where it saves time.

It is useful for generating boilerplate, explaining unfamiliar code, creating prototypes, suggesting CSS solutions, writing tests, and exploring implementation alternatives.

The problem starts when we confuse speed with quality.

A generated component can be technically correct and still create a poor experience. A design can look professional and still be inaccessible. A translation can be understandable and still feel unnatural.

The better approach is to give AI the repetitive work while keeping developers involved in the decisions that affect users.

A practical workflow looks something like this:

Define the user problem and requirements before generating code.
Use AI to create a first implementation or explore alternatives.
Review the code for accessibility, responsiveness, security, and maintainability.
Test the experience with real content, devices, and interaction methods.
Measure performance and fix problems based on actual evidence.
Keep human review in the process before shipping.

AI becomes much more useful when it is part of a feedback loop rather than the final decision-maker.

Did you notice anything wrong with Flutter?

DevUnionX — Thu, 05 Nov 2026 04:12:17 +0000

DevUnionX

Nov 5

5 Things AI Still Gets Wrong When Building Flutter Apps

#flutter #dart #mobile #motivation

9 min read

5 Things AI Still Gets Wrong When Building Flutter Apps

DevUnionX — Thu, 05 Nov 2026 04:10:47 +0000

AI can generate a Flutter screen in seconds. It can create widgets, connect APIs, suggest animations, and even put together an entire prototype from a short prompt.

That's impressive. And honestly, it makes development much faster.

But there's a difference between generating an interface and building an app that people actually enjoy using.

I've noticed that many AI-generated Flutter interfaces can look convincing in a screenshot. The problems become more obvious when you start interacting with them. Animations feel unnatural, recommendations lack context, translations sound strange, and accessibility is often treated as an afterthought.

The issue isn't that AI is useless at these tasks. It can help with all of them. The problem is that a generated solution doesn't automatically understand the people who will use it.

Here are five areas where AI-assisted Flutter development still needs a lot of human judgment.

1. Animations That Work, But Don't Feel Natural

One of the first things I notice in AI-generated mobile interfaces is the animation.

A button fades in. A card slides onto the screen. A dialog appears with a default transition. Everything technically works, but something feels off.

The problem is usually not the animation itself. It's how the animations work together.

Good motion design has a purpose. It helps users understand what happened, where something came from, and what they should focus on next.

For example, pressing a button should provide quick feedback. Opening a new screen might need a more noticeable transition. Removing an item from a list should feel different from adding one.

AI-generated code often uses similar durations and curves across unrelated interactions. The result can feel repetitive and mechanical.

Performance matters too

Consider this simple example:

AnimatedContainer(
  duration: const Duration(milliseconds: 300),
  width: isExpanded ? 300 : 150,
  height: isExpanded ? 200 : 100,
  child: const Card(
    child: Center(
      child: Text('Product'),
    ),
  ),
)

There's nothing inherently wrong with AnimatedContainer. It's a useful Flutter widget for animating changes to properties such as size, decoration, and padding.

However, changing layout-related properties can trigger additional layout work. In more complex interfaces, that can become expensive.

For movement that doesn't need surrounding widgets to change their layout, a transform-based animation may be a better choice:

AnimatedScale(
  scale: isSelected ? 1.05 : 1.0,
  duration: const Duration(milliseconds: 220),
  curve: Curves.easeOutCubic,
  child: const ProductCard(),
)

This doesn't mean transforms are always faster. Rendering performance depends on the complete widget tree and the work required to paint each frame. Profile the actual application instead of assuming one animation approach is always better.

Flutter provides several tools for this, including AnimatedBuilder, AnimatedOpacity, SlideTransition, and physics-based animations.

Don't forget reduced motion

Another detail that's easy to miss is the user's motion preference.

Flutter exposes accessibility information that developers can use when deciding whether to simplify custom animations:

bool shouldReduceMotion(BuildContext context) {
  final disableAnimations =
      MediaQuery.disableAnimationsOf(context);

  final reduceMotion = WidgetsBinding
      .instance
      .platformDispatcher
      .accessibilityFeatures
      .reduceMotion;

  return disableAnimations || reduceMotion;
}

For example:

AnimatedScale(
  scale: isSelected ? 1.05 : 1.0,
  duration: shouldReduceMotion(context)
      ? Duration.zero
      : const Duration(milliseconds: 220),
  child: const ProductCard(),
)

There is an important platform detail here: disableAnimations corresponds to Android's animation-removal setting, while reduceMotion is exposed separately on iOS. They are not interchangeable flags.

The takeaway: AI can generate an animation, but deciding whether it feels right, performs well, and respects the user's preferences still requires careful testing and design judgment.

Useful references: Flutter Animations · Flutter Performance Best Practices · AccessibilityFeatures API

2. Personalization Without Understanding the User

Personalization is one of the most attractive promises of AI-powered applications.

Imagine a fitness app that recommends a workout based on your activity, schedule, and previous sessions.

That sounds useful. But there's a big difference between showing a recommendation based on a few conditions and providing something that genuinely fits the user's situation.

For example, an app might recommend a difficult workout because the user hasn't exercised for several days.

But what if they haven't exercised because they're recovering from an injury?

What if they have been travelling?

What if they simply want a rest day?

The application might have enough data to generate a recommendation, but not enough context to make that recommendation appropriate.

More data doesn't automatically mean better personalization

A common mistake is assuming that collecting more user data will automatically improve the experience.

It doesn't.

Good personalization needs to consider:

What the user actually wants to achieve.
Which information the user has agreed to share.
Whether the available data is recent and reliable.
Whether a recommendation is useful at this particular moment.
Whether the user can adjust or disable personalization.

Consider the difference between these two notifications:

"You might like this product."

"You saved a similar product last week. The item is now available at a lower price."

The second notification has a clear reason for appearing. It connects information to a useful situation.

But even that recommendation should respect the user's preferences. Someone who doesn't want promotional notifications shouldn't receive them simply because an algorithm thinks the timing is perfect.

AI can help identify patterns and generate recommendations. The product team still needs to decide which data is appropriate, what the recommendation is supposed to achieve, and when it should be shown.

The takeaway: Personalization should make an application feel more useful, not make users feel watched.

3. Translation Is Not the Same as Localization

AI has made translating application content incredibly easy.

You can provide a collection of English strings and ask a model to translate them into ten different languages. In many cases, the result will be understandable.

But understandable isn't always natural.

Consider an application that uses a casual, friendly tone in English. A literal translation into another language might sound overly formal, awkward, or even rude.

Idioms, jokes, cultural references, and informal expressions are particularly difficult to translate without losing their original meaning.

And this problem goes beyond text.

Localization affects the entire interface

A properly localized Flutter application needs to account for:

Date and time formats.
Currency and number formatting.
Pluralization and grammatical differences.
Right-to-left languages such as Arabic and Hebrew.
Different text lengths.
Cultural expectations and terminology.
Symbols, colors, and visual communication.

For example, a layout that assumes every language reads from left to right may feel awkward in an Arabic interface.

Flutter already provides tools for handling much of the technical side of localization.

MaterialApp(
  localizationsDelegates:
      AppLocalizations.localizationsDelegates,
  supportedLocales:
      AppLocalizations.supportedLocales,
  home: const HomePage(),
)

You can also use directional layout properties:

Padding(
  padding: const EdgeInsetsDirectional.only(
    start: 16,
    end: 12,
  ),
  child: const Text('Welcome back!'),
)

Using EdgeInsetsDirectional instead of hardcoding left and right helps layouts adapt to the current text direction.

Flutter's localization system can handle locale-specific messages and default text direction, but it cannot decide whether a phrase sounds culturally appropriate or whether a particular design choice makes sense in a specific market.

That still requires review by people who understand the language and culture.

The takeaway: A translated application speaks another language. A localized application feels like it belongs in that language.

Useful reference: Internationalizing Flutter Apps

4. Privacy, Transparency, and User Control

This is probably the most important issue on the list.

When an application introduces AI features, it often starts collecting or processing more information. Depending on the product, this could include user preferences, activity history, documents, conversations, location, or other personal information.

The technical implementation might work perfectly. But does the user understand what's happening?

Imagine using an AI assistant inside a Flutter application.

You ask it to write an email. It generates a response and sends it automatically without asking for confirmation.

Maybe the message is correct. Maybe it isn't.

Either way, the application has taken away an important decision from the user.

Users should know what AI is doing

A good AI-powered interface should make a few things clear:

What information is being used?

Users should understand which data is relevant to a feature and have meaningful control over optional data collection.

Why is this recommendation appearing?

A simple explanation can make an AI recommendation feel less random.

For example:

"Recommended because you frequently read articles about Flutter."

This is much more useful than showing an unexplained recommendation.

Can the user review the result?

Generating content and publishing it are two different actions. The user should remain in control of important decisions.

Can an action be reversed?

For operations that can be undone, provide an undo option. For irreversible or sensitive actions, request confirmation first.

For example, a confirmation dialog before sending an AI-generated message:

Future<void> confirmAndSend(BuildContext context) async {
  final confirmed = await showDialog<bool>(
    context: context,
    builder: (dialogContext) {
      return AlertDialog(
        title: const Text('Send this message?'),
        content: const Text(
          'Please review the generated message before sending.',
        ),
        actions: [
          TextButton(
            onPressed: () =>
                Navigator.pop(dialogContext, false),
            child: const Text('Cancel'),
          ),
          FilledButton(
            onPressed: () =>
                Navigator.pop(dialogContext, true),
            child: const Text('Send'),
          ),
        ],
      );
    },
  );

  if (confirmed != true) return;

  // Perform the actual send operation here.
}

Another small detail is loading feedback.

An AI request may take several seconds. Showing a spinner without any explanation can make the application feel frozen.

A better experience tells the user what's happening, handles errors clearly, and gives them a way to cancel or retry when appropriate.

For example:

"Analyzing your document..."
"Generating your summary..."
"Almost done..."

For longer operations, progress indicators or streamed responses can make waiting easier to understand.

The important thing is to avoid pretending that progress is measurable when it isn't. An honest loading state is better than a progress bar showing a made-up percentage.

The takeaway: An AI feature should never make users feel that the application is acting behind their back.

Useful reference: NIST AI Risk Management Framework

5. Accessibility Is Still Too Often an Afterthought

An application can look beautiful and still be difficult or impossible for some people to use.

This is especially noticeable in AI-generated interfaces, where the visual appearance is often prioritized over the experience of people using assistive technologies.

Flutter has built-in accessibility support, but generating widgets doesn't automatically guarantee that an application is accessible.

One important part of Flutter's accessibility system is the Semantics Tree.

Flutter uses this tree to describe the meaning and behavior of interface elements to assistive technologies such as TalkBack and VoiceOver.

For example, a custom icon might look like a button, but a screen reader needs to know what it does.

Semantics(
  button: true,
  label: 'Save article',
  hint: 'Adds this article to your reading list',
  onTap: onSave,
  child: ExcludeSemantics(
    child: GestureDetector(
      onTap: onSave,
      child: const Padding(
        padding: EdgeInsets.all(12),
        child: Icon(Icons.bookmark_border),
      ),
    ),
  ),
)

The visual icon alone doesn't communicate its purpose. The semantics information provides an accessible name and action.

For standard controls, prefer Flutter's built-in widgets whenever possible. For example, an IconButton with a meaningful tooltip already provides useful accessibility information.

Five accessibility details worth checking

1. Screen readers

Test the application with TalkBack on Android and VoiceOver on iOS. Make sure controls have meaningful labels and that the reading order makes sense.

2. Text scaling

Don't assume that every user has the default system font size. Flutter respects operating-system text scaling, so layouts should remain usable when text becomes significantly larger.

Avoid fixed-height containers that cut off their content.

3. Contrast

Text and interactive controls need sufficient contrast. WCAG 2.2 recommends a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text under its minimum-contrast criterion.

4. Touch targets

Small buttons can be difficult to use, especially for people with motor impairments. Flutter's accessibility guidance recommends minimum tap target sizes of 48 × 48 logical pixels on Android and 44 × 44 points on iOS.

5. Keyboard and interaction support

Don't make important functionality available only through a specific gesture. Interactive elements should have appropriate focus behavior and accessible actions.

Test accessibility instead of assuming it's correct

Flutter provides an Accessibility Guideline API that can be used in widget tests.

import 'package:flutter_test/flutter_test.dart';

void main() {
  testWidgets('Checks basic accessibility guidelines', (
    tester,
  ) async {
    final semanticsHandle = tester.ensureSemantics();

    await tester.pumpWidget(const MyApp());

    await expectLater(
      tester,
      meetsGuideline(labeledTapTargetGuideline),
    );

    await expectLater(
      tester,
      meetsGuideline(androidTapTargetGuideline),
    );

    await expectLater(
      tester,
      meetsGuideline(textContrastGuideline),
    );

    semanticsHandle.dispose();
  });
}

These checks are useful, but they don't replace manual testing with real assistive technologies.

A widget test can detect certain problems. It cannot tell you whether the entire application feels understandable to someone navigating it with a screen reader.

The takeaway: Accessibility isn't a final polish task. It should be part of the design and development process from the beginning.

Useful references: Flutter Accessibility · Flutter Accessibility Testing · WCAG 2.2

So, Should We Stop Using AI for Flutter Development?

Absolutely not.

AI is genuinely useful. It can speed up repetitive development tasks, generate boilerplate, explain unfamiliar APIs, build prototypes, suggest test cases, and help developers explore different implementation approaches.

The mistake is expecting generated code to be a finished product.

A generated screen might compile, but that doesn't mean its animations are good.

A translated message might be grammatically correct, but that doesn't mean it sounds natural.

A recommendation might be based on data, but that doesn't mean it's useful.

And a button might look clickable, but that doesn't mean someone using a screen reader can understand it.

I think the most practical approach is to treat AI as another tool in the development workflow, not as a replacement for product thinking.

Let AI help with the first implementation. Then review it from the perspective of someone who has never seen the application before.

Ask yourself:

Does this interaction feel natural?
Does this feature actually solve a user problem?
Does the interface make sense in other languages?
Does the user understand how their data is being used?
Can people with different abilities use the application comfortably?

These questions matter much more than whether the AI-generated code looks impressive.

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.

DEV Community: DevUnionX

HTML?

10 Things Even AI Can't Do in HTML

10 Things Even AI Can't Do in HTML

1. Understand the Problem Before Writing the Markup

2. Give HTML Elements Their Actual Meaning

3. Build a Structure That People Can Actually Navigate

4. Make Content Understandable Beyond Its Visual Appearance

5. Provide Meaningful Experiences for Users Who Cannot See the Page

6. Design Forms Around People, Not Just Input Fields

7. Understand That Localization Is More Than Changing Words

8. Preserve the Browser's Native Capabilities

9. Create Something Original Without Ignoring Existing Standards

10. Take Responsibility for the Final Result

So, What Makes a Developer Valuable in the AI Era?

10 Things Even AI Can't Do in Frontend Development (At Least Not on Its Own)

1. Understand What the User Actually Needs

2. Create a Distinctive Design, Not Just Another Familiar Interface

3. Make Animations Feel Natural

4. Personalize an Experience Without Making It Feel Intrusive

5. Understand Localization Beyond Translation

6. Build Accessibility Into the Experience

7. Make Responsive Design Work Beyond a Screenshot

8. Optimize Performance Based on Real Users

9. Debug Problems That Only Exist in Production

10. Take Responsibility for Security and Long-Term Code Quality

Does This Mean AI Is Bad at Frontend Development?

Did you notice anything wrong with Flutter?

5 Things AI Still Gets Wrong When Building Flutter Apps

5 Things AI Still Gets Wrong When Building Flutter Apps

1. Animations That Work, But Don't Feel Natural

Performance matters too

Don't forget reduced motion

2. Personalization Without Understanding the User

More data doesn't automatically mean better personalization

3. Translation Is Not the Same as Localization

Localization affects the entire interface

4. Privacy, Transparency, and User Control

Users should know what AI is doing

5. Accessibility Is Still Too Often an Afterthought

Five accessibility details worth checking

Test accessibility instead of assuming it's correct

So, Should We Stop Using AI for Flutter Development?

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

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`