DEV Community: Giuseppe Ciullo

The Day AI Argued With MDN (And Lost)

Giuseppe Ciullo — Tue, 16 Jun 2026 09:33:49 +0000

AI coding assistants have fundamentally changed the way we write software. Today it's perfectly normal to ask ChatGPT, Claude, Cursor, or Copilot to explain an API, generate a React component, review a pull request, or help debug a problem. For many developers, these tools have become part of the daily workflow.

Yet there's one area where they still struggle more than we'd like to admit: understanding the current state of the web platform.

Mozilla recently demonstrated this problem in a surprisingly direct way. While evaluating Claude Code on recently released Firefox features, the team discovered that the model confidently claimed Firefox didn't support the Web Serial API and that Mozilla had no plans to implement it. The answer sounded plausible, detailed, and authoritative.

There was just one issue.

Firefox had already shipped support for the API.

That experiment became one of the motivations behind Mozilla's new MDN MCP Server, a tool designed to give AI assistants direct access to MDN documentation and browser compatibility data. More importantly, Mozilla didn't just launch the service—they tested whether it actually improves the quality of AI-generated answers.

The results are worth paying attention to.

The Real Problem Isn't Hallucination

When discussions about AI reliability come up, the conversation usually focuses on hallucinations. But browser compatibility is a slightly different problem.

The web platform evolves continuously. Browsers ship new APIs, CSS features, HTML capabilities, and compatibility updates every few weeks. Specifications change, Baseline statuses evolve, and features that were experimental yesterday can become production-ready tomorrow.

Large language models, on the other hand, are trained on snapshots of information. Even highly capable models can only know what was available when they were trained. When they're asked about something that appeared later—or something that wasn't widely represented in their training data—they often have to rely on incomplete information.

The result isn't always a hallucination in the traditional sense. Sometimes it's simply an answer that would have been correct several months ago but is no longer accurate today.

As frontend developers, we've all developed the same habit: ask the AI first, then open MDN to verify the answer.

Mozilla's experiment explored what happens when the AI can consult MDN directly before answering.

Mozilla Decided to Test It

Rather than discussing the problem in theory, the MDN team decided to measure it.

They evaluated Claude Code Opus 4.7 using a set of recently released Firefox 151 features, including support for light-dark() images, the :buffering pseudo-class, the shadowrootslotassignment attribute, and the Web Serial API.

These aren't the kinds of features you'll find in every tutorial or blog post. They're recent additions to the platform, which makes them particularly useful for testing whether an AI model truly understands the current state of browser support or is relying on older information.

In other words, Mozilla deliberately chose questions that would expose the gap between what the model remembered and what was actually true.

The Web Serial API Example

The most striking result involved the Web Serial API.

When asked about browser support, Claude Code stated that Firefox didn't support the API. It went even further, claiming that Mozilla had no plans to support it in the future.

For someone unfamiliar with the feature, the response would have sounded completely reasonable. It contained enough context and confidence to feel trustworthy.

The problem was that Firefox 151 had already shipped Web Serial support.

What makes this example particularly interesting isn't simply that the answer was wrong. Developers expect AI systems to make mistakes occasionally. The real issue is that the answer looked credible. If you weren't already familiar with the feature, there would be little reason to question it.

This is one of the biggest challenges when using AI for frontend development. A response can be coherent, detailed, and technically sophisticated while still being disconnected from reality.

Why It Happens

Imagine asking an AI assistant a simple question:

Does Firefox support the Web Serial API?

Without access to current documentation, the model has to rely on whatever information was available during training. If support was added recently, the model may not know about it. If the feature wasn't widely discussed, it may have only partial information.

Unlike a search engine, the model isn't retrieving facts from a database. It's generating the most likely answer based on patterns it has learned.

That's why these mistakes can be so convincing. The model isn't intentionally inventing information—it is trying to produce a coherent response with incomplete knowledge.

And because language models are optimized for answering questions, they rarely respond with "I don't know."

Enter MCP

To address this problem, Mozilla launched the MDN MCP Server.

MCP, or Model Context Protocol, is an open standard that allows AI models to interact with external tools and data sources. Instead of relying entirely on training data, a model can retrieve information when it needs it.

The difference may sound subtle, but it's significant.

Without MCP, the workflow looks something like this:

Developer → AI Memory → Answer

With MCP, it becomes:

Developer → AI → MDN → Answer

Rather than answering solely from memory, the model can consult documentation, retrieve compatibility information, and verify assumptions before generating a response.

For a domain that changes as quickly as the web platform, that's a major advantage.

What Does the MDN MCP Server Provide?

The MDN MCP Server exposes MDN resources in a format specifically designed for AI systems.

This includes:

Documentation search
MDN documentation content
Browser Compatibility Data (BCD)

Instead of searching the web and parsing HTML pages, AI assistants can access structured information directly from one of the most trusted sources in web development.

The goal isn't to replace documentation. It's to make documentation part of the AI workflow.

Mozilla Ran the Tests Again

After enabling the MDN MCP Server, Mozilla repeated the same evaluation.

This time, Claude Code could retrieve information directly from MDN and Browser Compatibility Data rather than relying entirely on memory.

The improvement was substantial.

Recently released features were identified correctly. Browser compatibility information became significantly more reliable. Unsupported assumptions appeared less frequently, and responses aligned much more closely with the current state of the platform.

In practical terms, the model no longer had to guess. It could verify information before answering.

That distinction may sound small, but it's arguably the most important benefit MCP provides.

It Was Faster Too

One of the most surprising findings had nothing to do with accuracy.

Mozilla reported that responses generated with the MDN MCP Server enabled were roughly twice as fast.

At first glance, that seems counterintuitive. Querying an external service sounds like it should introduce additional overhead.

In practice, the opposite happened.

Without MCP, the assistant often needed to search the web, open multiple pages, parse HTML content, extract relevant information, and then synthesize a response. With MCP, that information was already available through structured tools designed specifically for machine consumption.

The model spent less time searching and more time answering.

The result was faster responses and better information at the same time.

Practical Examples

The value of this becomes clear almost immediately in day-to-day frontend work.

The Web Serial API example is a perfect illustration. Instead of receiving an answer based on potentially outdated knowledge, you can ask questions about browser support and get responses grounded in current MDN data.

Does Firefox support the Web Serial API?
What browsers can I safely target today?

The same becomes even more interesting when working with modern browser APIs in React.

Imagine asking an AI assistant:

Using the latest MDN documentation, create a React hook
for the View Transitions API.

Because the assistant has access to MDN, it can validate compatibility information before generating code and produce something like this:

import { useCallback } from "react";

export function useViewTransition() {
  return useCallback((update: () => void) => {
    if (!document.startViewTransition) {
      update();
      return;
    }

    document.startViewTransition(update);
  }, []);
}

The hook itself isn't particularly complex. What's interesting is the context that accompanies it. The assistant can explain which browsers currently support the API, whether the feature has reached Baseline status, what fallback strategy should be implemented, and whether it's safe to use in production today.

That's exactly the kind of information that tends to become outdated quickly when a model relies exclusively on training data.

You can also ask questions such as:

Using MDN compatibility data, explain whether
requestIdleCallback is safe to use in production.

Instead of answering from memory, the assistant can verify its response against current documentation before making a recommendation.

Compatible Clients

Although Mozilla's examples focus on Claude Code, the MDN MCP Server isn't tied to a specific AI vendor.

Any MCP-compatible client can potentially use it, including Claude Code, Claude Desktop, Cursor, VS Code MCP integrations, Zed, Codex CLI, Antigravity CLI, and other MCP-enabled applications.

As support for MCP continues to grow, direct access to authoritative documentation may become a standard feature of developer tooling rather than a niche capability.

For example, adding the MDN MCP Server to Claude Code is as simple as running:

claude mcp add --transport http mdn https://mcp.mdn.mozilla.net/

The Bigger Story

The most important takeaway from Mozilla's experiment isn't that they launched another developer tool.

It's that they exposed a fundamental limitation of modern AI systems.

The Web Serial API example demonstrates something every developer should keep in mind: confidence is not the same thing as correctness. An answer can be detailed, coherent, and technically sophisticated while still being wrong.

For years, conversations about AI have focused on building larger models with more knowledge. Mozilla's experiment suggests a different direction. The future may not belong to models that memorize everything. It may belong to models that know how to retrieve trustworthy information when their knowledge is incomplete.

That's a subtle distinction, but it has enormous implications for software development.

Final Thoughts

For a long time, the safest workflow looked something like this: ask the AI, open MDN, and verify everything manually.

Mozilla's MCP Server doesn't eliminate that responsibility, and it certainly doesn't make AI infallible. Developers should still think critically about the code and recommendations they receive.

What Mozilla's results suggest, however, is that giving AI systems direct access to authoritative sources can dramatically improve both accuracy and speed. The Web Serial API test showed just how easily a model can be confidently wrong when it's forced to rely solely on memory.

MCP won't solve every problem. But if the future of AI-assisted development is going to work, it will probably look less like AI replacing documentation and more like AI reading the documentation alongside us.

Orchestrating Scalable Frontends: The Power of the Composition Root

Giuseppe Ciullo — Fri, 20 Feb 2026 10:39:29 +0000

In previous chapters, we built the foundations of our frontend architecture. With Atomic Design, we organized our UI into shared/components, separating reusable, domain-agnostic elements from specific contexts. With Feature-Driven Architecture, we isolated the domain by introducing features/ as autonomous business units.

But a real-world application isn't just a collection of isolated modules. It is a system where domains must collaborate. The question becomes inevitable: How can we allow features to communicate with each other without destroying the isolation we just built?

The answer lies in introducing a higher level of orchestration: the Pages layer acting as a Composition Root.

Revisiting the Structure

Our architecture, consistent with our previous principles, looks like this:

src/
├─ shared/             # Reusable UI & utilities (Atomic Design)
├─ features/           # Isolated domains (Feature-Driven)
│   ├─ cart/
│   └─ checkout/
├─ pages/              # Orchestration & Composition Layer
└─ app/                # Global bootstrapping

We have already defined a fundamental rule: A feature can depend on shared/, but it must not know about the existence of other features. features/cart should never import anything from features/checkout. This is not a technical limitation; it is a design choice that preserves domain independence.

The Risk of the "Cannibal Feature" (God Feature)

Why can't we just let features talk to each other? Because refusing a higher orchestration layer exposes us to a fatal risk: Feature Cannibalization.

In a flat architecture, if the Cart needs to trigger the Checkout, a developer will eventually be forced to import the Checkout module into the Cart. At that moment, isolation vanishes. One of the two features "eats" the other, becoming a bloated module—a God Feature—that drags along dependencies, logic, and types that do not belong to it.

The Illusion of Simplicity

Eliminating the pages/ layer might seem like a simplification. In reality, we are just hiding complexity. If the Cart feature contains the navigation logic to the Checkout, that component is no longer truly reusable. If you wanted to use that Cart in an informational Sidebar without a checkout tomorrow, you couldn't do it without dragging along the entire payment system.

The principle is clear: A Feature must be "dumb" regarding the global context to be "smart" regarding its business logic.

Pages as a Composition Root

In the book Clean Architecture, Robert C. Martin introduces the concept of the Composition Root. It is the place where dependencies are assembled and modules are composed. In the frontend, the Page represents this architectural pivot.

The Page is not just a route container; it is the level where:

Features are instantiated.
Their contracts (callbacks, events) are connected.
Responsibilities are coordinated.

The Director and the Actors

Think of the Page as a Theater Director:

Features are the actors: they know how to play their part perfectly, but they don't decide when to enter the stage.
The Page is the director: it knows that when Actor A (Cart) emits an event, it must signal Actor B (Checkout) to step in.

Hierarchy of Responsibilities

The architecture takes a clear shape based on decreasing knowledge:

Layer	Responsibility	Knowledge Level
app/	Bootstrapping	Knows everything (Global State, Routing)
pages/	Orchestrate	Knows multiple features, but not their internal logic
features/	Domain	Knows only itself
shared/	Utility	Domain Agnostic (Knows nothing of business)

The correct flow is always vertical:
Feature A ← Page → Feature B
(Never: Feature A → Feature B)

Substitutability and Maturity

Many codebases start by allowing direct communication between modules. It works while the project is small. Over time, changes propagate unpredictably.

Introducing an explicit orchestration layer is the moment a project stops being just "functional" and becomes truly evolvable. Imagine wanting to replace the checkout/ domain entirely:

features/
├─ cart/
├─ checkout/
└─ new-checkout/

The only change occurs in the pages/ layer. The Cart remains untouched. This is possible because orchestration is centralized in the composition root, not distributed across features.

The Core Principle

Features solve business problems.
Pages solve coordination problems.

Atomic Design gave us order in the UI. Feature-Driven Architecture gave us domain isolation. The Pages layer gives us control over the flows. Separation is important, but knowing where to compose is even more vital.

Next Step: Toward the Page-Level Store

As long as the data flow is linear, composition via props in the Page is sufficient. But what happens when multiple features must stay synchronized in real-time or a complex dashboard requires shared state without violating isolation?

In the next article, we will explore the Page-Level Store: an ephemeral, page-scoped state that allows fluid communication while keeping domain boundaries intact.

Connect on LinkedIn for more updates and insights.

Feature-Driven Architecture: Designing Scalable Applications

Giuseppe Ciullo — Mon, 02 Feb 2026 10:02:27 +0000

Introduction

In the first article of this series, we discussed Atomic Design as a method to build coherent, reusable, and well-composed interfaces.
It’s an extremely effective approach when the main challenge is organizing the UI.

But as an application grows, the UI soon stops being the real problem.

Code increases, features multiply, requirements change faster than we’d like. At that point, new questions arise:

Where does the application logic really live?
How can we modify one feature without breaking others?
How can multiple people work on the same codebase without stepping on each other’s toes?

This is where architectural scalability comes into play.
And it’s exactly where Atomic Design alone is not enough.

Scalability is not just performance

When we talk about scalability, we often immediately think about performance, load, or infrastructure.
In reality, the first scalability problem is the code itself.

An application doesn’t scale when:

Every new feature requires changes in multiple places
Logic is scattered and hard to trace
Dependencies between parts of the application are implicit and fragile
Understanding the context of a change is more expensive than the change itself

In short: it doesn’t scale when cognitive overhead grows faster than the code.

Feature-Driven Architecture exists precisely to address this problem.

What a feature really is

A feature is not a single screen.
It’s not even an isolated function.

A feature is a unit of value for the user.

From an architectural point of view, a feature represents:

A clear objective
A complete behavior
A well-defined context

When a user says “I want to do X”, they are usually referring to a feature.

Thinking in terms of features shifts the focus:

From technology to domain
From technical layers to functional value

And this shift is what enables scalability.

Feature-Driven Architecture: the key principle

The core principle is simple:

Organize code around features, not technical layers.

Each feature becomes a cohesive container that includes everything needed to implement that behavior.

This doesn’t mean eliminating technical concepts, but reducing their visibility at a global level.
Details stay local to the feature, where they make sense.

The main advantage:

A feature can evolve independently
Context is clear and limited
The system grows by addition, not by entanglement

And this is how an architecture scales.

Example: the `cart` feature

To make this more concrete, here’s an example of how a single feature might be organized:

features/
└─ cart/
    ├─ components/   # UI elements specific to the cart
    ├─ helpers/      # reusable functions or logic helpers specific to the cart
    ├─ state/        # state management for the cart (local or global)
    ├─ views/        # pages or screens related to the cart
    ├─ types/        # type definitions or interfaces
    ├─ tests/        # tests for cart feature
    ├─ mocks/        # mock data or services for testing/development
    └─ index.ts      # entry point for exposing public parts of the feature

Example `index.ts`:

// Only expose what should be used outside the feature
export * from './components';
export * from './helpers';
export * from './types';

// Do NOT export state, views, tests, or mocks
// These remain internal to the feature

⚠️ Important rules for exposing feature parts

Expose only what is meant to be used outside the feature.
Components, helpers, and types are usually safe to export.
Keep everything else private.

state/ → internal state logic
views/ → screens or containers
tests/ → testing code
mocks/ → fake data

Always use the index.ts as the single entry point for external usage. This keeps the feature encapsulated and makes the boundaries clear.

Combining Atomic Design and Feature-Driven Architecture

Atomic Design and Feature-Driven Architecture are not mutually exclusive—they can complement each other perfectly.
While features contain the business logic, state, views, and tests, Atomic Design provides a shared language for building UI components that can be reused across multiple features.

Here’s an example of how the folder structure could look when combining both approaches:

features/
├─ cart/
│   ├─ components/
│   ├─ helpers/
│   ├─ state/
│   ├─ views/
│   ├─ types/
│   ├─ tests/
│   ├─ mocks/
│   └─ index.ts
├─ checkout/
└─ wishlist/

shared/
├─ components/
│   ├─ atoms/        
│   ├─ molecules/    
│   └─ organisms/    
└─ utils/            # shared utilities, helpers, and services

Key points:

shared/components/atoms, molecules, organisms → reusable UI building blocks
features/ → contains everything a feature needs to work independently
Features can use shared atomic components while keeping their own feature-specific components inside components/
This approach keeps reusability clear, modularity high, and boundaries well defined, allowing both UI and business logic to scale independently

By combining Atomic Design with Feature-Driven Architecture, we get the best of both worlds:

consistent, reusable UI
scalable, autonomous features

Features and reusability: a mindset shift

One of the most interesting effects of this approach is how it changes the concept of reusability.

In a Feature-Driven Architecture:

A feature is not reusable by default
Reusability is a conscious choice, not an initial requirement

This is very different from how we often think about architecture, especially on the UI side.

Atomic Design remains extremely useful, but its role changes:

It builds generic, stable elements
It doesn’t force reusability where it’s not needed

The feature becomes the place where complexity is accepted and managed.
Shared elements become few, solid, and truly generic.

Less premature abstraction, more clarity.

Scaling the team, not just the code

Another often overlooked aspect of scalability is the human factor.

When code is organized around features:

Responsibilities are easier to assign
The context is clearer
Conflicts decrease

Features become a natural unit for:

Planning
Parallel development
Testing
Maintenance

In practice, the architecture begins to reflect the way people think and work.
And that’s one of the strongest signs of a system that truly scales.

When it makes sense to adopt this approach

Feature-Driven Architecture is not a silver bullet.

It makes sense when:

The application is expected to grow
The domain is non-trivial
Multiple people work on the same codebase
Change is constant, not exceptional

In very small applications, the initial overhead might not be justified.
But when complexity is real, not organizing around features becomes more costly in the long run.

Conclusion

Feature-Driven Architecture teaches us to look beyond a single screen or component: organizing code around independent features reduces the risk of conflicts, isolates contexts, and makes the application clearer and easier to maintain.

Scalability, in this sense, is not just a technical goal—it’s the ability of both the code and the team to grow without chaos. Each feature becomes a manageable ecosystem that can evolve without compromising other parts of the application.

In the next article, we’ll explore how to combine multiple features, orchestrate them, and make them work together without losing cohesion—taking a collection of independent units and turning it into a truly scalable frontend.

Connect on LinkedIn for more updates and insights.

[Boost]

Giuseppe Ciullo — Fri, 16 Jan 2026 10:08:41 +0000

Atomic Design: From UI Composition to Real-World Applications

Giuseppe Ciullo ・ Jan 15

#frontend #webdev #architecture #react

Atomic Design: From UI Composition to Real-World Applications

Giuseppe Ciullo — Thu, 15 Jan 2026 15:49:07 +0000

Atomic Design is one of the most frequently mentioned patterns when talking about frontend architecture.
It’s easy to explain, easy to visualize, and it works really well… until the application starts to grow.

The problem is not Atomic Design itself, but the role we assign to it.
Using it as an application architecture leads to rigid structures that are hard to test and even harder to evolve.

In this article we’ll explore:

what Atomic Design does really well
where its structural limits begin to show
how to place it correctly inside a modern frontend architecture

This is the first chapter of a series dedicated to frontend application architectures.

Atomic Design is a composition pattern, not an architecture

Atomic Design was created to solve a specific problem:
building consistent user interfaces by composing small, reusable components.

The model is well known:

Atoms
Molecules
Organisms
Templates
Pages

All of this answers one question:

How do I build the UI?

It does not answer questions like:

where does the domain live?
who orchestrates application flows?
how does the application scale?

And this is where the misunderstanding often begins.

The real-world short circuit

Organisms that turn into mini applications

A typical “organism” that grows over time often ends up looking like this:

fetchData()
applyBusinessRules()
manageGlobalState()
renderUI()

At this point:

it is no longer a presentational component
it becomes hard to test
it is tightly coupled to a single feature

The UI turns into the place where logic accumulates, creating a monolith disguised as components.

The false Molecule vs Organism problem

Many teams spend time asking:

“Is this component a molecule or an organism?”

In practice, this distinction is often subjective and largely irrelevant.
In a healthy architecture, the real question is:

Does this component know about the domain?

If the answer is yes, it does not belong in Atomic Design, regardless of what you call it.

The problem is not Atomic Design

Atomic Design:

✅ organizes the UI
❌ does not define domain boundaries
❌ does not orchestrate application flows
❌ does not manage business state

Expecting it to do so means using it out of context.

A proposal: separate UI and application architecture

A sustainable frontend architecture is built on a clear separation between:

UI Composition
Application Architecture

Atomic Design should live only in the first layer.

Atomic Design as a UI library (with a key rule)

shared/
 └─ ui/
     ├─ atoms/
     ├─ molecules/
     └─ organisms/

UI state vs Business state

Components in shared/ui may have state, but only if it is:

ephemeral
interaction-related
not a business decision

Valid examples:

isOpen
isHovered
isActive

Invalid examples:

global data
backend-synchronized state
application-level cache

UI components should never be aware of:

Redux / Zustand
data-fetching libraries
domain logic

Dependency Rule (non-negotiable)

Components in shared/ui must never import anything from features/

This single rule:

prevents hidden coupling
keeps the UI truly reusable
preserves architectural clarity over time

Features as the primary architectural unit

features/
 ├─ products/
 ├─ cart/
 └─ checkout/

Features contain:

business state
side effects
orchestration
UI composition

This is where the intelligence of the application lives.

Testing strategy: an often underestimated benefit

This separation improves not only the codebase, but the way we test.

UI (Atomic Design)

Storybook
visual regression testing
visual snapshots
accessibility testing

Focus:
👉 “Does this component look and behave correctly?”

Features (Application Architecture)

integration tests
flow tests
interaction between state, APIs, and UI

Focus:
👉 “Does this use case work?”

Separating UI and architecture also means separating testing responsibilities.

Why this approach works

Atomic Design stays simple
the UI is predictable and reusable
features are isolatable
the domain is readable from the file system
the application scales without increasing chaos

Each layer has a clear responsibility.

Conclusion

Atomic Design is not your architecture.
And that’s exactly why it works so well.

Used as a UI composition pattern, it is an excellent tool.
Used as an application architecture, it becomes a source of complexity.

In the next article of this series, we’ll dive into a feature-driven architecture, designed to organize logic, state, and domain at scale.

Connect on LinkedIn for more updates and insights..

Still splitting text with .split(" ")? Intl.Segmenter is the native way to handle words, sentences, and characters — correctly, across languages. No regex. No hacks. Just smart, locale-aware segmentation.

Giuseppe Ciullo — Wed, 12 Nov 2025 09:57:57 +0000

Stop Splitting Strings the Wrong Way: Discover Intl.Segmenter

Giuseppe Ciullo ・ Nov 11

#webdev #javascript #programming #tutorial

Stop Splitting Strings the Wrong Way: Discover Intl.Segmenter

Giuseppe Ciullo — Tue, 11 Nov 2025 11:44:20 +0000

How many times have you done this?

const text = "I love pizza and pasta";
text.split(" ");
// ["I", "love", "pizza", "and", "pasta"]

Looks fine — until you deal with punctuation, multiple spaces, or languages that don’t even use spaces.
Try splitting a French sentence with apostrophes, or a Japanese one with no whitespace at all.
Suddenly .split(" ") feels more like a guess than a rule.

That’s where Intl.Segmenter comes in.

What Is `Intl.Segmenter`?

Intl.Segmenter is part of the JavaScript Internationalization API.
It splits text into human-perceived units — words, sentences, or characters — using the rules of a specific language.

In other words, it doesn’t just separate symbols.
It understands how people actually read and write.

Understanding Granularity

The secret sauce of Intl.Segmenter lies in its granularity — the level at which text is broken down.
You can choose between three modes:

grapheme → splits text into visible characters (user-perceived symbols)
word → splits into words, respecting language-specific rules
sentence → splits into sentences, automatically detecting punctuation and spacing

Each level serves a different purpose:
use graphemes for counting characters, words for tokenization, and sentences for text analysis.

Here’s the beauty: the same phrase can be segmented differently depending on the locale.

Example: One Sentence, Three Languages

Let’s see how Intl.Segmenter handles the same idea across English, French, and Japanese.

const sentences = {
  en: "I love sushi.",
  fr: "J’aime les sushis.",
  ja: "私は寿司が好きです。"
};

for (const [locale, text] of Object.entries(sentences)) {
  const segmenter = new Intl.Segmenter(locale, { granularity: "word" });
  const words = [...segmenter.segment(text)]
    .filter(s => s.isWordLike)
    .map(s => s.segment);

  console.log(locale, words, `(${words.length} words)`);
}

Output:

en [ 'I', 'love', 'sushi' ] (3 words)
fr [ 'J’aime', 'les', 'sushis' ] (3 words)
ja [ '私', 'は', '寿司', 'が', '好き', 'です' ] (6 words)

Same sentence.
Different segmentation — perfectly adapted to each language’s rules.

Example: Word Segmentation (English)

const text = "Pizza, pasta and ice cream!";
const segmenter = new Intl.Segmenter("en", { granularity: "word" });

const words = [...segmenter.segment(text)]
  .filter(s => s.isWordLike)
  .map(s => s.segment);

console.log(words);
// ["Pizza", "pasta", "and", "ice", "cream"]

Each element is not just a string — it’s a full object with metadata:

{
  segment: "Pizza",
  index: 0,
  input: "Pizza, pasta and ice cream!",
  isWordLike: true
}

Example: Grapheme Segmentation

Need to count or slice user-visible characters correctly?

const text = "Café résumé";
const graphemeSegmenter = new Intl.Segmenter("en", { granularity: "grapheme" });

const graphemes = [...graphemeSegmenter.segment(text)].map(s => s.segment);
console.log(graphemes);
// ["C", "a", "f", "é", " ", "r", "é", "s", "u", "m", "é"]

Each accented character counts as one, not two code units.
Perfect for counters, highlighting, or text selection logic.

Example: Sentence Segmentation

const paragraph = "I love pizza. Pasta is great too! Let's eat.";
const sentenceSegmenter = new Intl.Segmenter("en", { granularity: "sentence" });

for (const segment of sentenceSegmenter.segment(paragraph)) {
  console.log(segment.segment);
}

Output:

I love pizza.
Pasta is great too!
Let's eat.

Automatically handles punctuation and spacing.

Example: Real-world Use — Word Counter

You can build a word counter that works in any language:

function countWords(text, locale = "en") {
  const segmenter = new Intl.Segmenter(locale, { granularity: "word" });
  return [...segmenter.segment(text)].filter(s => s.isWordLike).length;
}

console.log(countWords("Pizza, pasta and ice cream!")); // 5
console.log(countWords("J’aime le chocolat et le café.")); // 6
console.log(countWords("私は寿司が好きです。")); // 6

No regex, no guesswork — fully locale-aware.

Conclusion

Splitting text isn’t just a technical task — it’s a linguistic one.
Intl.Segmenter gives JavaScript the power to understand words, sentences, and meaning, not just characters.

No regex. No libraries. No fragile logic.

To explore more, visit the official MDN Web Docs.
And connect on LinkedIn for more updates and insights.

[Boost]

Giuseppe Ciullo — Tue, 30 Sep 2025 09:22:08 +0000

Your .join(", ") Is Lying to You: Meet Intl.ListFormat

Giuseppe Ciullo ・ Sep 29

#javascript #frontend #programming #webdev

Your .join(", ") Is Lying to You: Meet Intl.ListFormat

Giuseppe Ciullo — Mon, 29 Sep 2025 07:15:17 +0000

How many times have you done this as a front-end developer?

["Pizza", "Pasta", "Ice Cream"].join(", ")
// "Pizza, Pasta, Ice Cream"

Looks fine… until you realize something’s wrong: the final “and” is missing.

So you patch it with slice, map, conditionals, maybe even a helper function that grows messier with every project.

But here’s the thing: you shouldn’t be solving this problem at all. There’s already a native API designed for this: Intl.ListFormat.

What Is `Intl.ListFormat`?

Intl.ListFormat is part of the Internationalization API. Its job is simple: turn an array into a human-friendly string that respects language and cultural conventions.

No custom utilities, no edge cases, no spaghetti code.

Styles and Types: Beyond `.join()`

Unlike .join(), Intl.ListFormat gives you control over style, meaning, and locale. Even small differences matter: a comma before “and” (Oxford comma), using “&” instead of “and”, or changing “and” to “or”.

Punctuation Matters: Automatic Commas and Localization

One of the benefits of Intl.ListFormat is automatic punctuation according to the locale. Small details like commas before “and” (the Oxford comma in American English) or the absence of it in British English are not something you have to implement manually anymore.

For example, in en-US, the list "Pizza, Pasta, and Ice Cream" includes the Oxford comma, making it clear and unambiguous. In en-GB, the same list becomes "Pizza, Pasta and Ice Cream", dropping the extra comma as per British conventions.

Even when you use types like unit or disjunction, Intl.ListFormat automatically inserts commas where needed and uses the appropriate conjunction (or none, if the type doesn’t require one). This removes a whole class of small localization bugs that would otherwise require custom logic.

In short, Intl.ListFormat not only formats the words in a list but also ensures your punctuation matches the expectations of your users’ language, making your app feel more polished and professional.

Examples

const foods = ["Pizza", "Pasta", "Ice Cream"];

// Long + conjunction (default, en-US)
new Intl.ListFormat("en-US", { 
  style: "long", 
  type: "conjunction" 
}).format(foods);
// "Pizza, Pasta, and Ice Cream"
// Oxford comma before 'and'

// Long + conjunction (en-GB)
new Intl.ListFormat("en-GB", { 
  style: "long", 
  type: "conjunction" 
}).format(foods);
// "Pizza, Pasta and Ice Cream"
// No Oxford comma in British English

// Short + conjunction
new Intl.ListFormat("en-US", { 
  style: "short", 
  type: "conjunction" 
}).format(foods);
// "Pizza, Pasta, & Ice Cream"
// Compact style, using "&"

// Long + disjunction
new Intl.ListFormat("en-US", { 
  style: "long", 
  type: "disjunction" 
}).format(foods);
// "Pizza, Pasta, or Ice Cream"
// Shows "or" instead of "and"

// Unit style (no conjunction, items treated as a unit)
new Intl.ListFormat("en-US", { 
  type: "unit" 
}).format(foods);
// "Pizza, Pasta, Ice Cream"
// Simple comma-separated listing

Notice how small changes in locale, style, or type completely affect the output. These are the details that make lists readable, natural, and culturally correct.

Real-World Use Cases

E-commerce → “Available in pizza, pasta, & ice cream.”
Social apps → “Liked by Anna, John, & 3 others.”
Dynamic lists → When you don’t know in advance how many items will show up.

In all these cases, .join() falls short. Intl.ListFormat handles these tiny but important differences for you.

Conclusion

Every time you render a list, you’re not just outputting text — you’re communicating.
And communication lives in details: a comma in the right place, the correct “and” or “or”, a style that feels natural to the user’s language.

Those details are what make your app feel professional instead of hacked together.

To dive deeper into Intl.ListFormat and explore additional features, visit the official MDN Web Docs. There, you'll find comprehensive documentation and practical examples to help you master this powerful API.

Connect on LinkedIn for more updates and insights.

Simplify Currency Formatting in React: A Zero-Dependency Solution with Intl API

Giuseppe Ciullo — Tue, 25 Feb 2025 09:56:58 +0000

Currency formatting is a crucial aspect of many web applications, especially in e-commerce or financial dashboards. A clear and intuitive interface helps users quickly understand costs, avoiding ambiguities due to differences in currency or numerical formats. Let's see how to create a React component to display monetary amounts using Intl.NumberFormat, avoiding external dependencies and keeping the code lightweight and performant.

What is `Intl.NumberFormat`?

The Intl.NumberFormat API is the native method for formatting numbers based on user localization. With this API, we can handle currency formatting efficiently without relying on additional libraries. Its advantages include:

Compatibility with modern browsers without the need for external libraries
Support for multiple currencies and formatting styles
Reduced bundle size, improving performance and reducing application load times.

How `Intl.NumberFormat` Works

The Intl.NumberFormat API works by taking a locale and an optional set of formatting options to produce a localized string representation of a number. When instantiated, it creates a formatter that applies the specified rules, such as currency, percentage, or decimal formatting. Under the hood, it leverages the JavaScript Intl (Internationalization) object to ensure proper number formatting based on the selected locale.

For example, different locales format the same number in distinct ways:

const usdFormatter = new Intl.NumberFormat("en-US", {
  style: "currency",
  currency: "USD",
});

const eurFormatter = new Intl.NumberFormat("de-DE", {
  style: "currency",
  currency: "EUR",
});

console.log(usdFormatter.format(1234.56)); // "$1,234.56"
console.log(eurFormatter.format(1234.56)); // "1.234,56 €"

By utilizing this approach, applications can seamlessly adapt to various user preferences and regional conventions without requiring external dependencies.

How to Use `Intl.NumberFormat`

Using Intl.NumberFormat in your application is simple. You initialize a new instance with a locale and a set of options, then call .format(value) to get the formatted output. The API allows for extensive customization, making it versatile for different use cases.

Here’s how to format a number as a currency value in US dollars:

const formatter = new Intl.NumberFormat("en-US", {
  style: "currency",
  currency: "USD",
});

console.log(formatter.format(1234.56)); // "$1,234.56"

Beyond currency formatting, you can adjust properties like minimumFractionDigits and maximumFractionDigits to control decimal precision:

const preciseFormatter = new Intl.NumberFormat("en-US", {
  style: "currency",
  currency: "USD",
  minimumFractionDigits: 3,
  maximumFractionDigits: 3,
});

console.log(preciseFormatter.format(1234.5)); // "$1,234.500"

For more details and advanced usage, refer to the official MDN documentation.

Creating the `CurrencyFormatter` Component

Let’s create a simple React component that leverages Intl.NumberFormat to format monetary values according to the selected currency and locale.

const CurrencyFormatter = ({ value, currency = "USD", locale = "en-US" }) => {
  const formattedValue = new Intl.NumberFormat(locale, {
    style: "currency",
    currency,
  }).format(value);

  return <span>{formattedValue}</span>;
};

export default CurrencyFormatter;

Using the Component

After creating our CurrencyFormatter component, we can easily use it within a React application. This allows us to display monetary amounts clearly and professionally without writing redundant code.

import CurrencyFormatter from "./CurrencyFormatter";

const App = () => (
  <div>
    <strong>Price:</strong>
    <CurrencyFormatter value={1999.99} currency="EUR" locale="it-IT" />
  </div>
);

export default App;

Additional Customizations

If we need more control over the formatting, we can add optional parameters such as the minimum and maximum number of decimal digits. This allows us to adapt the display to different contexts where the component will be used.

With this customization, we ensure that monetary values are displayed with the desired level of precision, enhancing the user experience and usability of the application.

const CurrencyFormatter = ({ value, currency = "USD", locale = "en-US", minimumFractionDigits = 2, maximumFractionDigits = 2 }) => {
  const formattedValue = new Intl.NumberFormat(locale, {
    style: "currency",
    currency,
    minimumFractionDigits,
    maximumFractionDigits,
  }).format(value);

  return <span>{formattedValue}</span>;
};

Conclusion

Using Intl.NumberFormat to format currencies is an efficient, high-performance, and dependency-free solution. This approach allows us to ensure the correct display of currencies based on user localization without adding unnecessary weight to our project.

Crush Date and Time Formatting Natively: Unleash the Hidden Power of Intl.DateTimeFormat

Giuseppe Ciullo — Fri, 10 Jan 2025 10:32:03 +0000

Introduction to Native `Intl` APIs

The Intl APIs in JavaScript are a powerful and native solution for handling localization and formatting of data such as dates and numbers in various languages. Unlike many third-party libraries, these APIs offer:

High performance: Integrated into the JavaScript engine.
Smaller bundle sizes: Eliminates the need for external dependencies.
Global support: Includes localization for a wide range of languages and regions.

Unlike external libraries, native APIs do not require updates or maintenance by the developer. Additionally, they are optimized for the underlying JavaScript engine, providing a lighter and faster approach to localization and formatting.

In this article, we will focus on Intl.DateTimeFormat, an API dedicated to formatting dates and times based on the desired localization. We will see how this API can replace popular libraries such as Moment.js, date-fns, or Day.js for formatting needs, offering a modern and native alternative.

Description of `Intl.DateTimeFormat`

Intl.DateTimeFormat is a class that allows for localized formatting of dates and times. It provides advanced features such as support for different localizations, customizable formats, and handling of alternative calendars and time zones.

Creating a Formatter

A formatter is an instance of Intl.DateTimeFormat that stores a specific configuration for date formatting. By using a formatter, you can repeatedly apply the same format to different dates, making your code more efficient and readable.

To create a formatter, use the Intl.DateTimeFormat constructor with the desired parameters:

const formatter = new Intl.DateTimeFormat(locale, options);

locale: A string defining the localization (e.g., "en-US" for American English, "it-IT" for Italian).
options: An optional object to specify date components (e.g., weekday, month, year, etc.).

While it is common to save the formatter instance in a variable for reuse, this step is not strictly required. The Intl.DateTimeFormat constructor can be invoked directly to format dates inline, as shown below:

console.log(new Intl.DateTimeFormat('en-US', { year: 'numeric', month: 'long', day: 'numeric' }).format(new Date(2024, 11, 19)));
// Output: "December 19, 2024"

However, creating a formatter instance becomes particularly useful when the same format needs to be applied to multiple dates, improving code consistency and avoiding redundancy:

const formatter = new Intl.DateTimeFormat('en-US', {
  year: 'numeric',
  month: 'long',
  day: 'numeric'
});

console.log(formatter.format(new Date(2024, 11, 19))); // Output: "December 19, 2024"
console.log(formatter.format(new Date(2023, 5, 15))); // Output: "June 15, 2023"

Basic Examples: Getting Started with `Intl.DateTimeFormat`

Explore the simplicity and power of Intl.DateTimeFormat with these foundational examples. We'll demonstrate how to create a formatter for default and custom formats that can be reused across your application.

1. Default Formatting

If no options are provided, the formatter uses the default format of the selected locale.

const date = new Date(2024, 11, 19);
const formatter = new Intl.DateTimeFormat('en-US');
console.log(formatter.format(date)); // Output: "12/19/2024"

2. Custom Formatting

Customize the output by specifying the desired options.

const date = new Date(2024, 11, 19);
const formatter = new Intl.DateTimeFormat('en-US', {
  weekday: 'long',
  year: 'numeric',
  month: 'long',
  day: 'numeric'
});
console.log(formatter.format(date)); // Output: "Thursday, December 19, 2024"

Advanced Examples: Unlocking the Full Potential of `Intl.DateTimeFormat`

Take your date and time formatting to the next level with advanced scenarios, such as handling multiple localizations, alternative calendars, and time zones. These examples showcase the versatility and adaptability of Intl.DateTimeFormat in complex applications.

1. Formatting with Alternative Calendars

const islamicFormatter = new Intl.DateTimeFormat('ar-SA-u-ca-islamic');
console.log(islamicFormatter.format(new Date(2024, 11, 19))); // Output: Date in the Islamic calendar

2. Handling Time Zones

const date = new Date(Date.UTC(2024, 11, 19, 15, 30)); // Ensure the date is set in UTC

// Formatter for UTC
const utcFormatter = new Intl.DateTimeFormat('en-US', {
  timeZone: 'UTC',
  year: 'numeric',
  month: 'short',
  day: '2-digit',
  hour: '2-digit',
  minute: '2-digit',
  timeZoneName: 'short',
});
console.log(utcFormatter.format(date)); 
// Output: "Dec 19, 2024, 03:30 PM UTC"

// Formatter for Tokyo time zone
const tokyoFormatter = new Intl.DateTimeFormat('ja-JP', {
  timeZone: 'Asia/Tokyo',
  year: 'numeric',
  month: 'short',
  day: '2-digit',
  hour: '2-digit',
  minute: '2-digit',
  timeZoneName: 'short',
});
console.log(tokyoFormatter.format(date)); 
// Output: "2024/12/20 00:30 JST"

// Formatter for Berlin time zone
const berlinFormatter = new Intl.DateTimeFormat('de-DE', {
  timeZone: 'Europe/Berlin',
  year: 'numeric',
  month: 'short',
  day: '2-digit',
  hour: '2-digit',
  minute: '2-digit',
  timeZoneName: 'short',
});
console.log(berlinFormatter.format(date)); 
// Output: "19. Dez. 2024, 16:30 MEZ"

TypeScript and `Intl.DateTimeFormat`

Using Intl.DateTimeFormat with TypeScript ensures type safety and better development experience. The TypeScript definitions for Intl.DateTimeFormat are built-in, providing autocomplete and documentation for its methods and properties.

Here's an example:

const formatter: Intl.DateTimeFormat = new Intl.DateTimeFormat('en-US', {
  year: 'numeric',
  month: 'long',
  day: 'numeric'
});

const formattedDate: string = formatter.format(new Date(2024, 11, 19));
console.log(formattedDate); // Output: "December 19, 2024"

The strict typing helps avoid runtime errors by catching potential issues at compile time, such as incorrect options or method calls.

Comparison with Popular Libraries

Why Consider `Intl.DateTimeFormat`?

Lightweight: It is native and does not require external libraries, reducing bundle size.
Performance: Often faster than solutions based on libraries.
Built-in Localization: Natively supports various languages and calendars.

Example: Simple Formatting

With Moment.js

const moment = require('moment');
console.log(moment("2024-12-19").format('dddd, MMMM Do YYYY'));

With date-fns

const { format } = require('date-fns');
console.log(format(new Date(2024, 11, 19), 'EEEE, MMMM do yyyy'));

With Day.js

const dayjs = require('dayjs');
console.log(dayjs("2024-12-19").format('dddd, MMMM D, YYYY'));

With Intl.DateTimeFormat

const formatter = new Intl.DateTimeFormat('en-US', {
  weekday: 'long',
  year: 'numeric',
  month: 'long',
  day: 'numeric'
});
console.log(formatter.format(new Date(2024, 11, 19)));

While external libraries might offer syntactic sugar, the native API provides equivalent functionality without sacrificing flexibility or efficiency.The slightly longer syntax of the native API is a small trade-off for its benefits in maintainability, performance, and simplicity.

Conclusion

Intl.DateTimeFormat provides a robust, native solution for date and time formatting, making it an excellent alternative to popular libraries like Moment.js, date-fns, and Day.js. With its high performance, built-in localization, and simplified maintenance, it's a valuable tool for modern JavaScript applications.

To dive deeper into Intl.DateTimeFormat and explore additional features, visit the official MDN Web Docs. There, you'll find comprehensive documentation and practical examples to help you master this powerful API.

Supercharge Your Web Animations: Optimize requestAnimationFrame Like a Pro

Giuseppe Ciullo — Thu, 26 Sep 2024 14:05:10 +0000

Smooth and performant animations are essential in modern web applications. However, managing them improperly can overload the browser’s main thread, causing poor performance and janky animations. requestAnimationFrame (rAF) is a browser API designed to sync animations with the display's refresh rate, ensuring smoother motion compared to alternatives like setTimeout. But using rAF efficiently requires careful planning, especially when handling multiple animations.

In this article, we will explore how to optimize requestAnimationFrame by centralizing animation management, introducing FPS control, and keeping the browser’s main thread responsive.

Understanding FPS and Why It Matters

Frames per second (FPS) is crucial when discussing animation performance. Most screens refresh at 60 FPS, meaning that requestAnimationFrame is called 60 times per second. To maintain smooth animations, the browser must complete its work within about 16.67 milliseconds per frame.

If too many tasks run during a single frame, the browser might miss its target frame time, causing stuttering or dropped frames. Lowering the FPS for certain animations can help reduce the load on the main thread, providing a balance between performance and smoothness.

Centralized Animation Manager with FPS Control for Better Performance

To manage animations more efficiently, we can centralize their handling with a shared loop rather than having multiple requestAnimationFrame calls scattered throughout the code. A centralized approach minimizes redundant calls and makes it easier to add FPS control.

The following AnimationManager class allows us to register and unregister animation tasks while controlling the target FPS. By default, we aim for 60 FPS, but this can be adjusted for performance needs.

class AnimationManager {
  private tasks: Set<FrameRequestCallback> = new Set();
  private fps: number = 60; // Target FPS
  private lastFrameTime: number = performance.now();
  private animationId: number | null = null; // Store the animation frame ID

  private run = (currentTime: number) => {
    const deltaTime = currentTime - this.lastFrameTime;

    // Ensure the tasks only run if enough time has passed to meet the target FPS
    if (deltaTime > 1000 / this.fps) {
      this.tasks.forEach((task) => task(currentTime));
      this.lastFrameTime = currentTime;
    }

    this.animationId = requestAnimationFrame(this.run);
  };

  public registerTask(task: FrameRequestCallback) {
    this.tasks.add(task);
    if (this.tasks.size === 1) {
      this.animationId = requestAnimationFrame(this.run); // Start the loop if this is the first task
    }
  }

  public unregisterTask(task: FrameRequestCallback) {
    this.tasks.delete(task);
    if (this.tasks.size === 0 && this.animationId !== null) {
      cancelAnimationFrame(this.animationId); // Stop the loop if no tasks remain
      this.animationId = null; // Reset the ID
    }
  }
}

export const animationManager = new AnimationManager();

In this setup, we calculate the deltaTime between frames to determine if enough time has passed for the next update based on the target FPS. This allows us to throttle the frequency of updates to ensure the browser’s main thread isn’t overloaded.

Practical Example: Animating Multiple Elements with Different Properties

Let’s create an example where we animate three boxes, each with a different animation: one scales, another changes color, and the third rotates.

Here’s the HTML:

<div id="animate-box-1" class="animated-box"></div>
<div id="animate-box-2" class="animated-box"></div>
<div id="animate-box-3" class="animated-box"></div>

Here’s the CSS:

.animated-box {
  width: 100px;
  height: 100px;
  background-color: #3498db;
  transition: transform 0.1s ease;
}

Now, we’ll add JavaScript to animate each box with a different property. One will scale, another will change its color, and the third will rotate.

Step 1: Adding Linear Interpolation (lerp)

Linear interpolation (lerp) is a common technique used in animations to smoothly transition between two values. It helps create a gradual and smooth progression, making it ideal for scaling, moving, or changing properties over time. The function takes three parameters: a starting value, an ending value, and a normalized time (t), which determines how far along the transition is.

function lerp(start: number, end: number, t: number): number {
  return start + (end - start) * t;
}

Step 2: Scaling Animation

We start by creating a function to animate the scaling of the first box:

function animateScale(
  scaleBox: HTMLDivElement,
  startScale: number,
  endScale: number,
  speed: number
) {
  let scaleT = 0;

  function scale() {
    scaleT += speed;
    if (scaleT > 1) scaleT = 1;

    const currentScale = lerp(startScale, endScale, scaleT);
    scaleBox.style.transform = `scale(${currentScale})`;

    if (scaleT === 1) {
      animationManager.unregisterTask(scale);
    }
  }

  animationManager.registerTask(scale);
}

Step 3: Color Animation

Next, we animate the color change of the second box:

function animateColor(
  colorBox: HTMLDivElement,
  startColor: number,
  endColor: number,
  speed: number
) {
  let colorT = 0;

  function color() {
    colorT += speed;
    if (colorT > 1) colorT = 1;

    const currentColor = Math.floor(lerp(startColor, endColor, colorT));
    colorBox.style.backgroundColor = `rgb(${currentColor}, 100, 100)`;

    if (colorT === 1) {
      animationManager.unregisterTask(color);
    }
  }

  animationManager.registerTask(color);
}

Step 4: Rotation Animation

Finally, we create the function to rotate the third box:

function animateRotation(
  rotateBox: HTMLDivElement,
  startRotation: number,
  endRotation: number,
  speed: number
) {
  let rotationT = 0;

  function rotate() {
    rotationT += speed; // Increment progress
    if (rotationT > 1) rotationT = 1;

    const currentRotation = lerp(startRotation, endRotation, rotationT);
    rotateBox.style.transform = `rotate(${currentRotation}deg)`;

    // Unregister task once the animation completes
    if (rotationT === 1) {
      animationManager.unregisterTask(rotate);
    }
  }

  animationManager.registerTask(rotate);
}

Step 5: Starting the Animations

Finally, we can start the animations for all three boxes:

// Selecting the elements
const scaleBox = document.querySelector("#animate-box-1") as HTMLDivElement;
const colorBox = document.querySelector("#animate-box-2") as HTMLDivElement;
const rotateBox = document.querySelector("#animate-box-3") as HTMLDivElement;

// Starting the animations
animateScale(scaleBox, 1, 1.5, 0.02); // Scaling animation
animateColor(colorBox, 0, 255, 0.01); // Color change animation
animateRotation(rotateBox, 360, 1, 0.005); // Rotation animation

Note on the Main Thread

When using requestAnimationFrame, it’s essential to keep in mind that animations run on the browser’s main thread. Overloading the main thread with too many tasks can cause the browser to miss animation frames, resulting in stuttering. This is why optimizing your animations with tools like a centralized animation manager and FPS control can help maintain smoothness, even with multiple animations.

Conclusion

Managing animations efficiently in JavaScript requires more than just using requestAnimationFrame. By centralizing animations and controlling the FPS, you can ensure smoother, more performant animations while keeping the main thread responsive. In this example, we showed how to handle multiple animations with a single AnimationManager, demonstrating how to optimize for both performance and usability. While we focused on maintaining a consistent FPS for simplicity, this approach can be expanded to handle different FPS values for various animations, though that was beyond the scope of this article.

Github Repo: https://github.com/JBassx/rAF-optimization
StackBlitz: https://www.stackblitz.com/~/github.com/JBassx/rAF-optimization

LinkedIn: https://www.linkedin.com/in/josephciullo/

DEV Community: Giuseppe Ciullo

The Day AI Argued With MDN (And Lost)

The Real Problem Isn't Hallucination

Mozilla Decided to Test It

The Web Serial API Example

Why It Happens

Enter MCP

What Does the MDN MCP Server Provide?

Mozilla Ran the Tests Again

It Was Faster Too

Practical Examples

Compatible Clients

The Bigger Story

Final Thoughts

Orchestrating Scalable Frontends: The Power of the Composition Root

Revisiting the Structure

The Risk of the "Cannibal Feature" (God Feature)

The Illusion of Simplicity

Pages as a Composition Root

The Director and the Actors

Hierarchy of Responsibilities

Substitutability and Maturity

The Core Principle

Next Step: Toward the Page-Level Store

Feature-Driven Architecture: Designing Scalable Applications

Introduction

Scalability is not just performance

What a feature really is

Feature-Driven Architecture: the key principle

Example: the cart feature

Example index.ts:

⚠️ Important rules for exposing feature parts

Combining Atomic Design and Feature-Driven Architecture

Features and reusability: a mindset shift

Scaling the team, not just the code

When it makes sense to adopt this approach

Conclusion

[Boost]

Atomic Design: From UI Composition to Real-World Applications

Giuseppe Ciullo ・ Jan 15

Atomic Design: From UI Composition to Real-World Applications

Atomic Design is a composition pattern, not an architecture

The real-world short circuit

Organisms that turn into mini applications

The false Molecule vs Organism problem

The problem is not Atomic Design

A proposal: separate UI and application architecture

Atomic Design as a UI library (with a key rule)

UI state vs Business state

Dependency Rule (non-negotiable)

Features as the primary architectural unit

Testing strategy: an often underestimated benefit

UI (Atomic Design)

Features (Application Architecture)

Why this approach works

Conclusion

Still splitting text with .split(" ")? Intl.Segmenter is the native way to handle words, sentences, and characters — correctly, across languages. No regex. No hacks. Just smart, locale-aware segmentation.

Stop Splitting Strings the Wrong Way: Discover Intl.Segmenter

Giuseppe Ciullo ・ Nov 11

Stop Splitting Strings the Wrong Way: Discover Intl.Segmenter

What Is Intl.Segmenter?

Understanding Granularity

Example: One Sentence, Three Languages

Example: Word Segmentation (English)

Example: Grapheme Segmentation

Example: Sentence Segmentation

Example: Real-world Use — Word Counter

Conclusion

[Boost]

Your .join(", ") Is Lying to You: Meet Intl.ListFormat

Giuseppe Ciullo ・ Sep 29

Your .join(", ") Is Lying to You: Meet Intl.ListFormat

What Is Intl.ListFormat?

Styles and Types: Beyond .join()

Punctuation Matters: Automatic Commas and Localization

Examples

Real-World Use Cases

Conclusion

Simplify Currency Formatting in React: A Zero-Dependency Solution with Intl API

What is Intl.NumberFormat?

Example: the `cart` feature

Example `index.ts`:

What Is `Intl.Segmenter`?

What Is `Intl.ListFormat`?

Styles and Types: Beyond `.join()`

What is `Intl.NumberFormat`?

How `Intl.NumberFormat` Works

How to Use `Intl.NumberFormat`

Creating the `CurrencyFormatter` Component

Introduction to Native `Intl` APIs

Description of `Intl.DateTimeFormat`

Basic Examples: Getting Started with `Intl.DateTimeFormat`

Advanced Examples: Unlocking the Full Potential of `Intl.DateTimeFormat`

TypeScript and `Intl.DateTimeFormat`

Why Consider `Intl.DateTimeFormat`?