Naming is hard. The language we use shapes the way we think about things, but also the conversation we have about it. That’s why we have so much confusion about colors, icons, UI components, features — and that’s why we struggle to name design tokens, HTML classes, and variables.

Sometimes, the names we choose are too generic, so it’s difficult to understand what exactly is meant. And sometimes they are too specific, leaving little room for flexibility and reuse. How do we choose the right names? And which naming conventions work best? Let’s take a closer look.

How To Name Things

If you’re looking for some inspiration for naming HTML classes, CSS properties, or JavaScript functions, Classnames is a wonderful resource jam-packed with ideas that get you thinking outside the box.

The site provides thematically grouped lists of words perfect for naming. You’ll find terms to describe different kinds of behavior, likeness between things, order, grouping, and association, but also themed collections of words that wouldn’t instantly come to one’s mind when it comes to code, among them words from nature, art, theater, music, architecture, fashion, and publishing.

How To Name Colors

How would you choose the right name for a given color? Fortunately, David Aerne maintains a tremendous repository of color names, currently with 30355 unique color names, sourced from various references and 1000s of user contributions.

Of course, the repository comes with a color picker and name search and plenty of other color pickers as well. Tremendous work, which is also a fantastic reference to keep nearby.

How To Name Layers and Groups

What makes a good name? Javier Cuello summarized a set of naming best practices that help you name your layers, groups, and components in a consistent and scalable way.

As Javier points out, a good name has a logical structure, is short, meaningful, known by everyone, and not related to visual properties. He shares do’s and don’ts to illustrate how to achieve that and also takes a closer look at all the fine little details you need to consider when naming sizes, colors, groups, layers, and components.

How To Name Design Tokens

How to build a flexible design token taxonomy that works across different products? That was the challenge that the team at Intuit faced. The parent company of products such as Mailchimp, QuickBooks, TurboTax, and Mint developed a flexible token system that goes beyond the brand theme to serve as the foundational system for a wide array of products.

Nate Baldwin wrote a case study in which he shares valuable insights into the making of Intuit’s design token taxonomy. It dives deeper into the pain points of the old taxonomy system, the criteria they defined for the new system, and how it was created. Lots of takeaways for building your own robust and flexible token taxonomy are guaranteed.

Frequent Names For UI Components

Looking at what other people call similar things is a great way to start when you’re struggling with naming. And what better source could there be than other design systems? Before you end up in the design system rabbit hole, Iain Bean did the research for you and created the Component Gallery.

It’s a collection that includes plenty of examples for more than 50 UI components — from accordion to visually hidden — and also lists other names that the UI components go by. A fantastic resource, and not only with regard to naming.

Bonus: Name That UI, a visual dictionary of common UI components.

How To Name New Features

Features often have low adoption due to poor discoverability. Feature adoption needs time — first the feature must be discovered, then understood, then tried, learned, and eventually built into existing workflow. Erin Gannon has written a helpful practical guide on how to make sure all of it happens.

Good names are driven by user needs and problems. They should signal the value or outcome of a feature (the job-to-be-done), and — most importantly! — tap into the user’s own language. So ask people to explain a feature in their own words and then use the words they use.

How To Name Variables (Taxonomy Map)

A wonderful example of naming guidelines for a complex multi-brand, multi-themed design system comes from the Vodafone UK Design System team. Their Variables Taxonomy Map breaks down the anatomy and categorization of a design token into a well-orchestrated system of collections.

The map illustrates four collections required to support the system and connections between tokens — from brand and primitives to semantics and pages. It builds on top of Nathan Curtis’ work on naming design tokens and enables everyone to gather insight about where a token is used and what it represents, just from its name.

If you want to explore more approaches to naming design tokens, I’ve put together a list of useful Figma kits and resources that are worth checking out.

Design Token Naming Guide + Inventory

Romina Kavcic created a helpful little tool for naming design tokens — from learning how they work and how to name them well to configuring your own naming structure with components, categories, states, and roles.

Bonus: The Design Token Names Inventory spreadsheet, with a simple structure with four levels to give you a bird’s-eye view of all your design tokens. You can easily add rows, themes, and modes without losing track, and filter your tokens.

Naming Products or Services

If you are looking for the right name for your product or service, Onym is a fantastic open-source repository that organizes tools and resources for finding names for brainstorming, vetting, guides, sprints, etymologies — all the way to cautionary tales and agencies that name things, as well as useful books to take a look at.

Useful Bookmarks for Naming Things

A quick-reference list of tools and guides for naming just about… well, anything, in one place:

Wrapping Up

The right name is the one that’s well-understood and used by the team and users. So much time is wasted speaking about the very same thing but in different dialects — the designer’s dialect, the developer’s dialect, the product manager’s dialect, and the user’s dialect. That’s what often causes frustration and confusion.

So if you see low adoption, it might be merely because of the name. And pay attention to potential naming conflicts and put them in a backlog of things to address later. It’s one of those fine little details that can reduce frustration and confusion and help teams work together better.

Meet “Design Patterns For AI Interfaces”

Meet Design Patterns For AI Interfaces, Vitaly’s new video course with practical examples from real-life products — with a live UX training happening soon. Jump to a free preview.

(yk)

The post A Practical Guide To Naming Things appeared first on The NOKIA Blog.

To be completely honest with you, I missed the news when CSS Container Queries first shipped. And when I finally heard about it, my very first thought was, “Why exactly do I need this when media queries already exist?”

I’m not proud of that reaction, knowing what I know now, but it was comforting to know that I wasn’t alone. In fact, there are legions of us out there.

What baffles me is that container queries aren’t a new feature, as it currently sits at around 94% browser support. And yet, very few people are actually using it. According to the State of CSS survey, 86% of developers are aware of container queries, but only 41.4% actually use them. Surveys can be biased and not completely representative of our entire field, but this one is certainly the best indicator we’ve got.

Kevin Powell also talked about this at SmashingConf Amsterdam 2026: Container Queries adoption has been terrible. And that is so strange to me, knowing that the ability for components to adapt to the size of their outer container has been at the top of so many CSS wishlists over the years.

I’m not particularly interested in how many people are using container queries as much as in how they are using them. I can’t account for everyone, but from what I’ve seen — including in my own early attempts — many of us are using them wrong.

The bottom line is that incorrect use comes down to the same impression I had when learning about them: they absolutely look just like media queries at first glance. And since they look similar, it’s easy to assume they serve similar purposes and work the same way.

They don’t.

Note: I should state up front that what I’m focusing on in this article is using container size queries, i.e., a responsive design technique for responding to the size of a particular container. There are also container style queries that respond to a container’s computed styles (and are experimental at the time of this writing). You can catch up on those in Juan Diego’s piece here on Smashing Magazine where he examines their possible use cases.

The viewport is a proxy. It always has been. Media queries are what gave us the illusion that screen width alone is responsible for how responsive apps adapt to their environment.

Ask yourself this: When you write @media, what are you asking the browser?

@media (min-width: 1024px) {
  .card {
    display: flex;
  }

I, like most developers, am asking the browser: How wide is the screen right now? That’s it.

Media queries answer that beautifully, but what happens when this .card component is placed in a grid cell that’s 300px wide on a 1920px desktop screen?

The media query doesn’t care; it does its job. The viewport is still 1920px, so min-width: 1024px fires and the matched query styles are applied, even though the card only has 300px of space to work with. Eventually, everything in the card deforms, overflows, or cramps up.

“Media queries are dumb. Not dumb in terms of the concept, but dumb in that they don’t know very much. In fact, most people assume that they know more than they do.”

— Kevin Powell

It’s common to think of responsive design purely as a system for updating complete page layouts, like going from two columns on a large screen to a single column on a small screen.

Container Queries Look Inward

Container queries are smarter than that. They make responsive layouts more reliant on what’s happening inside a component rather than on the outer context that has no insight into a component’s contents. It is more like: “How much space is available for me in this specific spot, right now?”

Here is the same card code example we looked at in the last section, but with a container query:

.card-wrapper {
  container-name: card;
  container-type: inline-size;
}

@container card (min-width: 450px) {
  .card {
    display: flex;
    flex-direction: row;
  }
}

This changes everything. The card isn’t influenced by the viewport; its only concern is whether the .card component’s parent wrapper has at least 450px of inline (i.e., horizontal in a left-to-right writing mode) space. If that condition is true, the component goes horizontal; if not, it goes to its default block display.

“Macro” Layout Vs. “Micro” Layouts

A very interesting way to distinguish @media and @container queries is the layout type.

Media queries are for the “macro” layout; they look outward. Stuff like page structure, the header that spans the window, footers, main grid layout, system preferences (prefers-color-scheme), device capabilities (touch screens). You know, anything that is majorly true to the entire page structure.

Container queries, I’d say, are for “micro” layouts, i.e., most things that live inside the “macro” layout. We use them when any content needs to responsively fit whatever space it is allocated. Components that come to mind are things like cards, widgets, forms, navigation, and so on.

In other words, think “page layout” vs. “component layout”.

An element shouldn’t magically become “tablet-sized” just because the width exceeds an abstract width threshold like 768px. Instead, it should switch layout when it has enough space to do so, whether that happens on a mobile viewport or inside a desktop sidebar.

In case you’re still not convinced, did you know there are over 2,300 unique viewport sizes on the modern web? Do you think it is possible to account for all of them?

I’m not hating on media queries. It’s that in this era of responsiveness and component re-use, layout logic is closer to the container than the viewport. When we think in terms of containers and components, we’re effectively relying on the content to determine layout, not the viewport.

This is how it should be.

Example: Fluid Typography Inside A Component

Responsive typography is a good example of something many of us have relied on media queries for. The fact that media queries come with their own CSS units — e.g., vw, vh, and so on — that are relative to the viewport size makes media queries look really good for adjusting font size based on the user’s screen size.

.card-title {
  font-size: clamp(100%, 1rem + 2vw, 24px);
}

This works until that same component is moved into a different context, like a sidebar, where the viewport is completely irrelevant. Now, because we tied the responsiveness to the wrong reference point, the scaled typography can get too big or too small.

Container queries come with their very own units — cqi, cqw, cqb, among others — and we can take responsive components further by coupling those units with the CSS clamp() function, using it for fluid typography that scales with the component rather than the viewport:

.card-title {
  font-size: clamp(1rem, .5rem + 3cqi, 2rem);
}

With this in place, the entire code is self-contained to that element’s specific container.

Example: Flexbox Wrap Detection

Interestingly, container queries can, in a way, detect the state of a component’s internal layout. It’s not bulletproof, but it is also something media queries simply cannot do because they only observe the external browser window and are structurally blind to internal layout events like when, for example, flex items wrap onto a new line. Let’s poke at that.

Flexbox is superb at wrapping content (flex-wrap: wrap), allowing flex items to automatically wrap to new lines when the flex container runs out of space to fit them in a single row. But CSS by itself can’t tell when that wrap happens. There isn’t something like a :wrapped pseudo-class or a media query like @media (flex-wrapped: true) that would get us there.

Media queries only observe the browser window, as they can’t see internal changes. That is pretty much what flex wrapping is: a width state change on the item itself.

For example, if you have a horizontal menu that is lined up with flexbox and you want the items to restyle themselves only when wrapped, you’d be in JavaScript territory, using ResizeObserver to get that information. However, when we nest container queries inside flex items, we can come up with a workaround to get what we need without JavaScript, thanks to this technique I learned from Kevin Powell. The core idea is to allow a flex item to flex-grow: 1 when we query the container’s inline size.

The logic works like this:

1. When there’s enough room, both items (.flex-item) sit side-by-side, each exactly half the parent container’s width.
2. When there is limited space, the second item wraps to the next line.
3. Because flex-grow is active on each item, the wrapped items stretch to fill most of the parent’s width.
4. If the item is a container itself, it detects the sudden width expansion and fires.

/* The flex parent */
.flex-layout {
  display: flex;
  flex-wrap: wrap;
}

/* Register a flex item as a container */
.flex-item {
  container-type: inline-size;
  flex: 1 1 390px; /* Grow to fill space, wrap at 390px */
}

/* Default Card Styles (narrow / side-by-side) */
.card {
  display: flex;
  flex-direction: column;
  background: #f4f4f4;
}

/* Once there's enough room for a full row */
@container (min-width: 600px) {
  .card {
    flex-direction: row;
    align-items: center;
    background: #e2f0d9;
  }
}

This works. As the parent size shrinks and the cards wrap to two lines, the card item expands, the container query fires, and applies the necessary styles.

Container Queries Do Have Side Effects

Container queries, like all things, come with some side effects or caveats you will want to watch for before reaching for them.

Container queries need something similar to a parent-child relationship to function as expected. Let’s say we have this markup:

<div class="card">
  <div class="card-content">...</div>
</div>

We can’t actually query the .card component to adjust the .card-content, like this:

/* DOES NOT WORK */
.card {
  container-name: card;
  container-type: inline-size;
}

@container card (min-width: 400px) {
  .card {
    display: flex;
  }
}

This doesn’t work because a container cannot query itself. In that last example, we’re querying a card container and then attempting to adjust that container’s display based on its size. It’s an infinite loop.

Instead, we need an additional wrapper that makes the .card a descendant of the container:

<div class="cards">
  <div class="card">
    <div class="card-content">...</div>
  </div>
</div>

From there, we can query the .cards container and adjust the .card layout accordingly:

.cards {
  container-name: cards;
  container-type: inline-size;
}

@container cards (min-width: 400px) {
  .card {
    display: flex;
  }
}

In media queries, this doesn’t matter as @media does not care which element you style inside the block; its only concern is the viewport, which is always available. So you can just slap a condition on any element and call it a day.

2. Querying A Container’s size Could Collapse Your Layout

This happens when querying the container’s size (i.e., its block, or vertical, size) instead of its inline-size:

/* Collapses to 0px even if it has content inside */
.hero-banner {
  container-type: size;
}

Why? Because the browser calculates the container’s dimensions without looking at its children. If we don’t give the .hero-banner an explicit height (or min-height or aspect-ratio), the browser sets a height of 0px.

For that reason, it’s often better to query a container by its inline-size instead. That is, unless you genuinely need to query the container’s block size.

Media queries aren’t affected by this, as they treat height the same way they treat @media (min-height: ...) does, i.e., ask the viewport and move on.

3. Queries Cannot Accept Custom Properties

Another container query limitation: we can’t query against a custom property value:

:root {
  --breakpoint-lg: 1600px;
}

/* DOES NOT WORK */
@container (min-width: var(--breakpoint-lg)) {
  /* ... */
}

This is because custom properties depend on values that cascade down the DOM tree. There’s the possibility that a container query that relies on a custom property can change that same custom property. And it can quickly get complicated:

:root {
  --breakpoint-lg: 1600px;
}

/* DOES NOT WORK */
@container cards (min-width: var(--breakpoint-lg)) {
  .card {
    --breakpoint-lg: 1000px;
  }
}

I don’t think any project should wholesale use @container instead of @media. Media queries still play an important role in responsive layouts. It’s about understanding the separation of concerns.

I tend to reach for container queries when a component is used in more than one layout context. For example, a .card element could live in a full-width grid or a narrower sidebar. If that’s the case, then we’ll want the component’s content to determine when it adjusts rather than a media query that looks at the outer viewport.

Similarly, I reach for media queries when a component solely exists at the page level. This would be something like a main navigation that always sits at the top of the page. It is directly influenced by the viewport’s size, meaning that the viewport is a reliable reference for when the navigation needs to adjust. Again, it’s all about “macro” layout versus “micro” layouts.

Here’s a diagram for how I reason about which type of query to use:

Conclusion

At the end of the day, the core reason why container queries look incredibly similar to media queries is simply familiarity. They’re not exactly “new”, but they are way less understood and adopted than media queries. But media queries have plenty of their own limitations; otherwise, we wouldn’t need container queries to fill those gaps.

What we have is a more effective feature for detecting when a specific component’s context changes and a means for adjusting styles based on its content, as it should be when that component can exist in multiple contexts.

(gg, yk)

The post Stop Treating CSS Container Queries Like Traditional Media Queries appeared first on The NOKIA Blog.

Part of the challenge is that it’s not always easy to identify accessibility issues. It often requires digging deeper to find and fix them. This is where the right WordPress plugin can be useful.

Some plugins allow users to adjust visual elements like font size and color contrast. Even better, some scan your content and alert you to problems. You might be surprised to find out how many issues can pop up in your theme and other installed plugins. The results may lead you to consider different options.

With that in mind, let’s look at some of the best WordPress accessibility plugins on the market. They won’t fix every issue, but they can help you learn and improve your site.

Accessibility Checker isn’t a band-aid for your site’s shortcomings. However, it will add missing skip links, focus outlines, and form labels upon request. It also scans your site’s content and creates a laundry list of potential issues. It catches common problems, such as ambiguous link text and missing ALT attributes.

Like all automated tools, you may find some false-positive results. As such, a manual inspection is required to verify them. But the plugin offers tips for fixing any issues it finds. The free version scans your site’s pages and posts, while the pro version includes custom post types and other handy features.

Use WP Accessibility to fix common issues, such as missing language/text direction attributes, missing ARIA labels for navigation, and viewports that don’t scale. It will also enforce ALT attributes in the editor and identify media with missing descriptive text.

These are optional and can be activated as needed. The other big feature here is a front-end toolbar that controls page zooming and color contrast. This gives users more control over how they view your site.

We’re starting to see AI used for a variety of purposes, including accessibility improvements. Alt Text AI automatically analyzes uploaded images and generates an ALT description.

The feature can save you a lot of time and effort – just be sure to double-check to ensure the description is accurate. Note that the plugin requires purchasing AI “credits” to work. There’s a free trial for trying the plugin before you buy.

Are you looking to provide visitors with accessibility options? This plugin adds a widget with a variety of optional feature modules. Users can change the font size and contrast. But there are also tools for switching to a dyslexia-friendly font, highlighting titles, and pausing animations.

You’ll also find a feature that helps you create an accessibility statement. Experiment to see which features will benefit your visitors.

Accessibility is about more than fixing issues – it’s also about adding accessible features. SimpleTOC creates a WCAG 2.2-conforming table of contents for your content. It’s a great way to help users navigate longer pages and blog posts. By default, the plugin adds zero CSS or JavaScript to your site.

Instead, it relies on HTML details and summary tags, which work natively in your browser. When it comes to accessibility, simple is always better.

Media embeds, particularly from third-party services, can be difficult to use. Some are bloated with JavaScript and other code that inhibit accessibility. Able Player offers an accessibility-first solution and implements an HTML5 media player via a configurable shortcode.

It works with locally uploaded files and videos from YouTube and Vimeo. The shortcode offers several options impacting the style and functionality of the player.

Leave No User Behind

Accessibility is not a “nice-to-have” feature – it’s an obligation. It’s also an ongoing process that requires your attention. Thankfully, there are tools to help you find potential issues and fix the most common ones. The WordPress plugins above will help you in your quest. Bonus: Some will add accessible elements that benefit everyone.

No singular plugin can make your site fully accessible. But they can make your job easier. We hope you find a solution to do just that.

Website Accessibility Plugins at a Glance

The post 6 Best WordPress Plugins for Improving Website Accessibility in 2026 appeared first on The NOKIA Blog.

Most of us install a dependency once and never look at it again. It does its job, the tests pass, and we move on. But the web platform keeps moving too, and a surprising number of the libraries sitting in your package.json today are now built into the browser.

In a typical mid-sized JavaScript app, you can often find somewhere between 60KB and 90KB (minified and gzipped) of dependencies that the platform can now handle on its own. Date and number formatting, HTTP requests, modals, tooltips, deep cloning, grouping arrays: these were all real gaps a few years ago. A lot of them aren’t gaps anymore.

The reason those libraries stick around isn’t laziness. It’s that most teams don’t re-audit their dependencies on a Baseline cadence, or are simply not aware of how fast browsers are shipping these days. You check npm audit for security, but is this library still doing something the browser can’t? is a question that rarely gets asked. So the libraries stay.

In this article, we’ll run that audit together. Instead of going through dependencies one by one, we’ll work in clusters, because the wins tend to come in groups. We’ll do the bundle math, build a small decision framework you can reuse, and stay honest about the cases where the platform still falls short. By the end, you’ll have a repeatable process you can run on your own package.json.

What “Baseline” Actually Means

Before we start deleting things, let’s quickly recap what Baseline is. Feel free to skip this section if you’re already familiar.

Baseline is a project from the WebDX Community Group that tells you, in plain terms, how safe a web feature is to use across the major browsers (Chrome, Edge, Firefox, and Safari). A feature can be in one of three states:

• Limited availability
  The feature hasn’t shipped in all the major engines yet. Not safe to rely on without a fallback.
• Baseline Newly available
  The feature has just landed in all the major engines. It works for users on up-to-date browsers, but older devices in the wild may not have it yet.
• Baseline Widely available
  The feature has been in all the major engines for 30 months. At this point, you can reach for it without much thought.

That 30-month gap between “Newly” and “Widely” matters a lot for this audit. A feature that’s Widely available is something you can usually drop a library for today. A feature that’s only Newly available is something you can drop a library for if you check your audience first, or if you’re comfortable with a small feature check. We’ll treat those two cases differently throughout.

You can look any feature up on webstatus.dev, on MDN (every reference page shows a Baseline badge near the top), or programmatically with the web-features npm package. We’ll use all three later when we run the audit on a real project.

A Decision Framework Before You Delete Anything

It’s tempting to read “the browser does this now” and start ripping libraries out. Let’s not do that. A swap that looks free on paper can quietly break things for a chunk of your users, or cost you a feature you were relying on without realizing it.

So before dropping any library, ask three questions. We’ll reuse these in every cluster below.

1. Is the replacement Baseline-safe for my audience?

Not “is it Baseline” in the abstract, but “is it safe for the people who actually use my app.” If the native feature is Widely available, this is usually a yes. If it’s only Newly available, check your analytics or your browserslist config and see what share of your users would miss out. A B2B dashboard where everyone’s on the latest browser is a very different situation from a public-facing site with a long tail of old Android devices.

2. What does the swap actually cost?

Dropping a library isn’t always free. Sometimes the native feature isn’t supported widely enough yet, so you’d reach for a polyfill. If that polyfill is heavier than the library you’re removing, you’ve made your bundle bigger, unless you load it conditionally. We’ll see exactly this with Temporal later.

3. Does the platform feature cover my real use case?

Libraries often do more than the platform feature they resemble. axios isn’t just fetch with automatic JSON parsing; it has interceptors, request cancellation, and retries. If you’re using those, a straight swap to fetch will leave you reimplementing them. Check what you actually use before assuming it’s a drop-in replacement.

Keep these three in mind. Every cluster below is really just these questions applied to a different corner of your dependencies.

Cluster 1: Internationalization (The Biggest Drop Today Win)

This is the cluster where you’ll usually find the most KBs sitting on top of features that are already Widely available. The browser ships a whole family of formatting tools under the Intl namespace, and a lot of small, popular libraries became unnecessary.

Here are the usual suspects and what replaces them:

• timeago.js (1 KB gz) → Intl.RelativeTimeFormat
• pluralize (2.3 KB gz) → Intl.PluralRules
• numeral (3.9 KB gz) → Intl.NumberFormat
• humanize-duration (6.6 KB gz) → Intl.DurationFormat
• list-joining helpers → Intl.ListFormat

Let’s walk through some of them.

Relative Time

timeago.js exists to turn a timestamp into “3 hours ago”. Intl.RelativeTimeFormat does the same thing, and it’s Baseline Widely available.

const rtf = new Intl.RelativeTimeFormat("en", { numeric: "auto" });

rtf.format(-1, "day"); // "yesterday"
rtf.format(3, "hour"); // "in 3 hours"
rtf.format(-2, "week"); // "2 weeks ago"

The numeric: "auto" option is the nice touch here: it gives you “yesterday” instead of “1 day ago” where the language has a word for it. You pass a number and a unit, and you get a localized string back.

You may be wondering about the one thing timeago.js does that this snippet doesn’t: it picks the unit for you. Given a date, timeago.js decides whether to say “seconds” or “days.” Intl.RelativeTimeFormat expects you to do that part. It’s a few lines of arithmetic (work out the difference, find the largest unit that fits), and once you’ve written that helper, you don’t need the library anymore.

Numbers, Currency, And Lists

Intl.NumberFormat covers most of what number-formatting libraries do: thousands separators, currency, percentages, and compact notation.

new Intl.NumberFormat("en-US").format(1234567.89);
// "1,234,567.89"

new Intl.NumberFormat("en-US", { style: "currency", currency: "USD" }).format(
  1234.5,
);
// "$1,234.50"

new Intl.NumberFormat("en", { notation: "compact" }).format(1200000);
// "1.2M"

And Intl.ListFormat, Widely available, handles the “join an array into a sentence” problem, including the Oxford comma, which is the kind of thing people write fiddly helper functions for:

const lf = new Intl.ListFormat("en", { style: "long", type: "conjunction" });

lf.format(["Alice", "Bob", "Carol"]);
// "Alice, Bob, and Carol"

The One Caveat: Durations

humanize-duration turns a number of milliseconds into “1 hour, 30 minutes”. The platform equivalent is Intl.DurationFormat:

const df = new Intl.DurationFormat("en", { style: "long" });

df.format({ hours: 1, minutes: 30 });
// "1 hour, 30 minutes"

One thing to keep in mind is that Intl.DurationFormat is Baseline Newly available at the time of writing, not Widely available. It landed in all the major engines in March 2025, and it’s on track to become Widely available in 2027. So this one fails question 1 for broad-audience apps unless you check your traffic first or add a fallback. For an internal tool on modern browsers, it’s fine today. For a public site with old devices, give it another year or guard it with a feature check.

The Math On This Cluster

If your app uses the full set (humanize-duration, timeago.js, pluralize, numeral), that’s roughly 14 KB gzipped of dependencies, most of it replaceable right now with Widely available APIs. The internationalization cluster is usually the easiest win in the whole audit.

Cluster 2: HTTP Clients

This cluster is more nuanced, so it’s a good one to slow down on.

The browser HTTP libraries people reach for are axios (17 KB gz) and superagent (19 KB gz). For most requests, fetch plus AbortController covers what you need, and both are Widely available.

A basic GET looks like this:

// axios
const { data } = await axios.get("/api/users");

// fetch
const res = await fetch("/api/users");
const data = await res.json();

The one extra line (res.json()) is fetch being explicit where axios was implicit. That’s the pattern across this whole cluster: fetch does less for you by default, and you decide whether you want the things it leaves out.

Timeouts

axios has a timeout option. fetch has AbortSignal.timeout():

const res = await fetch("/api/users", {
  signal: AbortSignal.timeout(5000), // abort after 5 seconds
});

Where fetch Doesn’t Replace axios

This is where question 3 does most of the work, so let’s be specific about the gaps:

• fetch doesn’t reject on HTTP errors.
  A 404 or 500 is a resolved promise, not a rejection. You have to check res.ok yourself. axios rejects on any non-2xx status.
• No interceptors.
  If you rely on axios interceptors to attach auth tokens or handle 401s in one place, fetch has no equivalent. You’d wrap fetch in your own function or class to get the same behavior.
• No automatic retries.
  axios (with a plugin) can retry failed requests. With fetch, that’s your code to write.
• No upload progress.
  fetch still can’t report upload progress in a first-class way. If you have a file uploader with a progress bar, that’s a real reason to keep a library.

I personally heavily rely on interceptors in my interactive online courses, such as Learn JavaScript, and I have solved that for years using a custom class on top of fetch. I’ve shipped this to millions of users and have seen lots of success with it.

None of these are hard to rebuild, and most apps only use one or two of them. But this is exactly the kind of cluster where you shouldn’t do a blind find-and-replace. Look at how you actually use your HTTP client first. If it’s plain GETs and POSTs, dropping axios for a thin fetch wrapper saves you about 17 KB gzipped.

Cluster 3: UI Primitives

This cluster has some of the most satisfying swaps, because the platform features don’t just match the libraries, they’re often more accessible than what teams ship by hand.

The libraries here are modal dialogs (something like a11y-dialog, 1.8 KB gz), tooltip and popover libraries (tippy.js, 14 KB gz, which bundles Popper for positioning), focus-trap (6.6 KB gz), and body-scroll-lock (1.3 KB gz). They get replaced by three platform features: the <dialog> element, the Popover API, and CSS anchor positioning.

The <dialog> Element

A huge amount of modal-related code exists to solve accessibility problems: trapping focus inside the modal, closing on Escape, restoring focus to the previous element when the dialog is closed, and rendering above everything else. The <dialog> element, Widely available, does all of that for you.

<dialog id="confirm">
  <form method="dialog">
    <p>Delete this file?</p>
    <button value="cancel">Cancel</button>
    <button value="delete">Delete</button>
  </form>
</dialog>

const dialog = document.querySelector("#confirm");

dialog.showModal(); // focus moves in, background goes inert, Escape closes it

dialog.addEventListener("close", () => {
  console.log(dialog.returnValue); // "cancel" or "delete"
});

Calling showModal() does the work that focus-trap was installed for: focus moves into the dialog, the rest of the page becomes inert so you can’t tab out of it, Escape closes it, and focus returns to the element that opened it. The dialog renders in the browser’s Top layer, so you don’t fight z-index. You also get a ::backdrop pseudo-element to style the overlay.

That single element can replace your modal library and focus-trap. The one piece it doesn’t handle on its own is locking the background from scrolling, which is what body-scroll-lock was for. That’s now one line of CSS:

body:has(dialog:modal) {
  overflow: hidden;
}

If you’re wondering why we’re using dialog:modal instead of dialog[open], it’s because the open attribute is set as soon as you call show(), but the dialog isn’t actually modal so you don’t want to lock scrolling yet. The :modal pseudo-class is only true when the dialog is actually modal, which is the case when you call showModal().

So three libraries collapse into one element and one CSS rule.

Popover API And Anchor Positioning

For things that aren’t full modals (dropdown menus, tooltips, the small floating panels that tippy.js handles), the Popover API gives you light-dismiss behavior, top-layer rendering, and Escape-to-close with no JavaScript at all:

<button popovertarget="menu" id="options">Options</button>

<div id="menu" popover>
  <!-- menu content -->
</div>

Clicking the button toggles the popover. Clicking outside it closes it. It’s Baseline Newly available (since January 2025).

The other half of what a tooltip library does is positioning: keeping the floating element pinned to its trigger and flipping it when it would overflow the viewport. That’s what Popper (bundled inside tippy.js) handles, and it’s now a CSS feature called anchor positioning. Here it pins the same #menu popover directly under its trigger button:

#options {
  anchor-name: --trigger;
}

.tooltip {
  position-anchor: --trigger;
  position-area: top;
  margin: 0;
}

Anchor positioning is the newest feature in this article. It became Baseline Newly available in January 2026, when Firefox 147 shipped it (Chrome had it since version 125, and Safari since version 26). Because it’s this fresh, it’s squarely a question-1 feature: great for modern audiences, but check your traffic, and note that some of the more advanced parts (like position-try fallbacks) have uneven support across versions. Keep a sensible fallback for older browsers.

Between <dialog>, the Popover API, and anchor positioning, the UI primitives cluster (tooltip library, modal library, focus-trap, body-scroll-lock) adds up to roughly 24 KB gzipped, and you come out the other side with better accessibility defaults than most hand-rolled solutions.

Cluster 4: Lodash Utilities

Lodash is rarely imported whole anymore, but its individual functions show up everywhere, either as the full lodash package (25 KB gz) or as standalone installs like lodash.clonedeep and lodash.groupby. Several of the most common ones now have direct platform equivalents.

Grouping

lodash.groupby reorganizes an array into an object keyed by some property. Object.groupBy does exactly that:

const products = [
  { name: "Apple", category: "fruit" },
  { name: "Carrot", category: "vegetable" },
  { name: "Banana", category: "fruit" },
];

const grouped = Object.groupBy(products, (product) => product.category);
// {
//   fruit: [{ name: "Apple", ... }, { name: "Banana", ... }],
//   vegetable: [{ name: "Carrot", ... }],
// }

There’s also Map.groupBy for when you want a Map instead of a plain object (handy if your keys aren’t strings). Both are Baseline Newly available, since March 2024, and on track to become Widely available in late 2026.

Deep Cloning

lodash.clonedeep makes a deep copy of an object. structuredClone is the platform version, and it’s Widely available:

const original = { user: { name: "Sam", roles: ["admin"] } };

const copy = structuredClone(original);
copy.user.roles.push("editor");

original.user.roles; // ["admin"] (unchanged)

structuredClone handles the tricky cases that trip up JSON.parse(JSON.stringify(...)): it clones Date, Map, Set, ArrayBuffer, and circular references correctly. The limit to know about (question 3 again) is that it can’t clone functions, DOM nodes, or class instances; it throws on functions and drops the prototype on class instances. For plain data, which is what most people deep-clone, it’s a clean replacement.

Set Operations

If you’ve ever pulled in a Lodash helper for union, intersection, or difference, the Set object now has these built in. They’re Baseline Newly available, since June 2024:

const admins = new Set(["sam", "alex", "jo"]);
const editors = new Set(["alex", "kim"]);

admins.intersection(editors); // Set { "alex" }
admins.union(editors); // Set { "sam", "alex", "jo", "kim" }
admins.difference(editors); // Set { "sam", "jo" }

The full set of methods is union, intersection, difference, symmetricDifference, isSubsetOf, isSupersetOf, and isDisjointFrom.

What’s Worth Keeping

Not all of Lodash has moved into the platform. debounce and throttle still have no native equivalent, and they’re genuinely useful, so cherry-picking lodash.debounce is reasonable. The point of this cluster isn’t “delete Lodash,” it’s “stop shipping the parts the browser already has.” Dropping lodash.clonedeep and lodash.groupby alone is about 8 KB gzipped, and if you were importing the full lodash for a handful of functions, replacing the platform-covered ones can let you drop it entirely.

Cluster 5: Temporal, A Case Study In Not Dropping A Library Yet

Every cluster so far has ended in “go ahead, drop it.” This one is the opposite, and that’s why it’s worth including: it shows the framework telling you to wait.

Temporal is the long-awaited replacement for JavaScript’s Date, and it’s a genuinely better API: immutable objects, sane time zone handling, and no more month indexes starting at zero. It reached TC39 Stage 4 in March 2026 and is part of the ES2026 specification. Firefox shipped it in version 139 (in 2025), and Chrome shipped it in version 144 (January 2026). Safari hasn’t shipped it in a stable release yet; it’s in Safari Technology Preview, with stable support expected later in 2026.

If Temporal is news to you, check out the Temporal Cheatsheet for a quick overview of the API and a comparison to Date.

However, Temporal is not Baseline. It’s still in limited availability, because Safari users don’t have it. To use it across all browsers today, you need a polyfill, and this is where the math turns against you.

The official @js-temporal/polyfill is about 44 KB gzipped. There’s a smaller polyfill that internally does not depend on BigInt and it weighs 19 KB gzipped. A lightweight date library like dayjs is about 3 KB gzipped. So if you swap dayjs for Temporal plus its polyfill right now, you’re not saving 3 KB, you’re adding roughly 41 KB to your bundle, unless you are able to load the polyfill conditionally.

Run it through the framework:

• Question 1 (audience): Temporal isn’t Baseline. For a broad audience, that’s a lot of people.
• Question 2 (cost): the polyfill is more than ten times the size of the library you’d remove. The swap makes your bundle bigger.
• Question 3 (feature gap): Temporal actually wins here; it does more than dayjs. But that doesn’t matter while questions 1 and 2 are failing.

The verdict is generally clear: keep dayjs (or date-fns) for now. The moment to revisit is when Safari ships Temporal in a stable release and it reaches Baseline. At that point you can use Temporal natively and conditionally load the polyfill for users on older browsers. This is a feature to write down and check again in a few months, not one to act on today.

How To Run This Audit On Your Own package.json

The clusters above are a starting map, but your dependencies are your own. Here’s a repeatable process you can run this quarter.

Step 1: List Your Production Dependencies

Start by listing what actually ships to users:

npm ls --omit=dev --depth=0

Step 2: Measure What Each One Costs

For a quick per-package number, Bundlephobia gives you the minified and gzipped size of any npm package. For the real picture (what each dependency costs in your actual bundle, after tree-shaking and deduplication), run a bundle analyzer against your build. npx source-map-explorer works on most bundles, and npx vite-bundle-visualizer works for Vite projects.

Step 3: Check The Baseline Status Of Each Replacement

For each candidate, find the platform feature that would replace it and check its Baseline status. The quickest way is webstatus.dev or the Baseline badge on the feature’s MDN page.

Step 4: Run The Three Questions

For each library with a platform replacement, go back to the framework: Is it Baseline-safe for your audience? What does the swap cost? Does the feature cover how you actually use the library? Most of your decisions will fall out of question 1 (check the feature’s status against your browserslist) and question 3 (check your own usage).

Step 5: Swap Behind Progressive Enhancement Where Needed

For Widely available features, swap and move on. For Newly available ones, either confirm your audience is on modern browsers or guard the new code with a quick feature check and keep a fallback:

if (typeof Intl.DurationFormat === "function") {
  // use the platform feature
} else {
  // fall back to the library, or a simpler format
}

That way you ship less code to the users who can run it, without breaking the ones who can’t.

Wrapping Up

Add the clusters up, and the picture is concrete. The internationalization cluster is around 14 KB gzipped, HTTP is around 17 KB, the UI primitives are around 24 KB, and the Lodash utilities are 8 KB or more depending on how much of the library you were shipping. For a typical mid-sized app, that’s somewhere between 60 KB and 90 KB gzipped of dependencies you can hand back to the platform, and more if you were shipping the full lodash or several of these libraries at once. (The uncompressed numbers are two to three times larger, which is what you’ll see in a bundle analyzer before gzip.)

I’ve chosen relatively lean packages for most of these features, but some individual packages could still be heavy. Your dialog package, for instance, could alone weigh as much as 50KB gzipped depending on what you’re using.

A few features are worth keeping an eye on over the next year, because they’ll open up further swaps:

• Temporal going native.
  Once Safari ships it in a stable release and it reaches Baseline, you can drop both your date library and the polyfill, turning today’s regression into a real win.
• CSS anchor positioning maturing.
  It became Baseline Newly available in January 2026. As it ages toward Widely available, dropping tooltip and popover positioning libraries gets safer for broad audiences.
• Object.groupBy and friends crossing into Widely available.
  The 2024 batch (array grouping, Set methods) is on track to become Widely available in late 2026, which moves them from “check your audience” to “just use it.”

None of this is a one-time cleanup. The platform ships new features constantly, and the gap between “you need a library for this” and “the browser does this” keeps closing. The habit worth building is small: once a quarter, run the audit. List your dependencies, check what’s now Baseline, and hand back what you can.

Pick one cluster from this article, open your package.json, and see how much of it the browser already does for you.

(yk)

The post How Baseline Can Help You Ship Less JavaScript appeared first on The NOKIA Blog.

When you move AI agents from prototype to production, the infrastructure challenges multiply. Your agents need to persist state across multi-step workflows that run for hours or days. They need to coordinate with other agents, share context, and sometimes access GPUs for specialized tasks. Amazon Bedrock AgentCore runtime microVMs provide a fully managed environment for invocations that can run for up to 8 hours and support stateful workflows through managed session storage. Some workloads also benefit from dedicated, larger-capacity environments — for example, when agents need to run continuously for multiple days, access GPUs or the underlying OS, or run multiple collaborating agents on the same host.

Today, I’m happy to announce runtime instances, a new complementary compute option in Amazon Bedrock AgentCore Runtime that gives your agents persistent, managed infrastructure purpose-built for complex agent workloads.

What you get
Runtime instances provides AWS-managed EC2 infrastructure where you deploy multiple agents in a single runtime, each with their own dependencies and artifact types. Your agents can collaborate on the same host within shared sessions that persist for up to 14 days. The service supports GPU acceleration for compute-intensive tasks, session stop/restart to save costs during idle periods, and containerized deployments for teams that want to ship independently. For knowledge that needs to survive beyond a session, runtime instances pairs naturally with Amazon Elastic Block Store (Amazon EBS) and AgentCore Memory, which gives your agents long-term recall across sessions and environments.

Before today, if you wanted to keep your agents running for days or they needed GPU access, or multi-agent coordination, you had to build and manage that infrastructure yourself. You provisioned EC2 instances, configured networking, set up session management, handled scaling, and stitched together monitoring. Runtime instances handles all of that for you while integrating with the same AgentCore APIs, identity controls, and observability you already use with AgentCore Runtime microVMs.

A few things that should make agent developers smile: your agents can call each other as tools within a shared session, iterating autonomously until the job is done. You bring any framework (CrewAI, LangGraph, LlamaIndex, Strands) and any model. Packaging is minimal, a @app.entrypoint decorator and a zip file or container image. And if your workflow spans days, hibernate Monday night and resume Wednesday morning with everything intact.

Runtime microVMs and runtime instances are complementary compute options that you can use independently or together through the same AgentCore runtime APIs. A lightweight orchestrator agent on runtime microVM can coordinate and dispatch work to specialized worker agents running on instances. The orchestrator handles API calls, task routing, and result aggregation using runtime microVM’s fast scaling, while workers on Instances perform compute-intensive tasks like code compilation, security scanning, or GUI automation that require persistent state and direct OS access.

Let me show you how it works
I built two agents for this demo: a code writer agent that generates Python code from natural language descriptions, and a code reviewer agent that analyzes the generated code for bugs, security issues, and style improvements. Both agents share the same file system, so the reviewer can read whatever the writer produces without any data transfer or API calls between them.

Here is the code writer (simplified, no error handling):

writer = Agent(
    model="us.anthropic.claude-sonnet-4-5-20250929-v1:0",
    system_prompt=(
        "You are a senior Python engineer. "
        "Given a task, return ONLY a single Python code block — no prose."
    ),
)

@app.entrypoint
def handler(event, context):
    task = event.get("task") or event.get("prompt")
    session_id = getattr(context, "session_id", None) or event.get("session_id")
    session_dir = SHARED_DIR / session_id
    session_dir.mkdir(parents=True, exist_ok=True)

    code = str(writer(task))
    (session_dir / "code.py").write_text(code)

    return {"agent": "writer", "wrote": str(session_dir / "code.py"), "code": code}

Here is the code reviewer agent (simplified, no error handling):

reviewer = Agent(
    model="us.anthropic.claude-sonnet-4-5-20250929-v1:0",
    system_prompt=(
        "You are a strict Python code reviewer. "
        "Given code, return 3 bullet points: bugs, style, suggestions."
    ),
)

@app.entrypoint
def handler(event, context):
    session_id = getattr(context, "session_id", None) or event.get("session_id")
    code_path = SHARED_DIR / session_id / "code.py"
    code = code_path.read_text()
    review = str(reviewer(f"Review this code:nn{code}"))

    return {"agent": "reviewer", "read": str(code_path), "review": review}

Each agent is a Python application using Strands Agents with an @app.entrypoint decorator and a model of its choice. I package each one as a zip file. For this demo, I use the AWS Management Console. You can also use the AgentCore CLI, the AWS Command Line Interface (AWS CLI) or infrastructure as code.

Step 1: Create a capacity provider.

A capacity provider defines the EC2 infrastructure your agents run on. In the AgentCore console, I select Runtime in the left navigation, then select the Capacity providers tab and Create capacity provider.

I give it a Name, select Linux (64-bit ARM) as the Operating system, and choose c7g.2xlarge as the Allowed instance types. This gives me 8 vCPUs and 16 GiB of memory, enough for both agents to run comfortably side by side.

Further down, I configure the VPC, subnets, and security groups for network access. Under Storage configuration, I keep the default gp3 volume. Under Service access, I select Create a new service role and let the console create the infrastructure role that manages EC2 instances on my behalf.

I select Create capacity provider and wait a few seconds. The status moves to Active.

Note the capacity provider configuration summary: operating system, instance type, subnets, security group, instance profile, and infrastructure role. Once created, only the description can be edited, so verify your settings before you proceed.

Step 2: Create a runtime and deploy the first agent.

Back on the Runtime page, I select Create runtime. I give it a Name, select Instances as the Compute type, and choose the Capacity provider I created in the previous step.

Under Agent source, I select S3 Source, then Upload to S3. I choose my agent zip file (ACIDemoWriter.zip), set the Language runtime to Python 3.13, and specify agent.py as the Agent entry point. This is the file that contains my @app.entrypoint decorated function. Under Permissions, I select Create default role to let the console provision the IAM role my agent needs.

I select Create runtime and wait for the status to become Ready.

I repeat the same process for my code reviewer agent. I create a second runtime, select the same capacity provider, upload my reviewer agent zip file, and wait for it to become Ready. Both agents now share the same underlying EC2 infrastructure.

The console shows me a View invocation code section with ready-to-use Python, TypeScript, and JavaScript snippets to invoke my agent programmatically. But for this demo, I use the built-in test feature. I select Test on the writer agent’s page.

Step 3: Invoke agents and observe collaboration.

The Runtime playground opens. At the top, I see three fields: Runtime agent, Endpoint, and Session ID. The console generates a session ID automatically. I take note of it because I will reuse it with the reviewer agent.

In the Input field, I type a JSON payload asking the writer agent to generate code:

{"prompt": "write a fibonacci suite"}

I select Run. After a few seconds, the Output panel shows the agent’s response. The writer agent generated a Python module with two implementations of a Fibonacci sequence (a list-based function and a generator) and wrote it to /tmp/agentcore-session/ca5ec24d-07f5-4eeb-add1-5ba416bf9eb2/code.py. Notice the session ID in the file path. That directory is the shared file system for this session.

Step 4: Invoke the reviewer agent in the same session.

Now I switch the Runtime agent dropdown to ACIDemoReviewer. The important part: I paste the same session ID (ca5ec24d-07f5-4eeb-add1-5ba416bf9eb2) in the Session ID field. This is what connects the two agents.

I type a simple prompt:

{"prompt": "review the code"}

I select Run. The reviewer agent reads the file the writer produced from the shared session directory and returns a detailed code review. It finds no critical bugs but suggests adding type hints, input validation, and simplifying the edge case handling.

The two agents never exchanged messages or called each other’s APIs. They collaborated through the shared file system that runtime instances provide within a session. You can extend this pattern to any number of agents: a test agent that runs the code, a documentation agent that generates README files, a security agent that scans for vulnerabilities, all sharing the same working directory.

Key details
Here are a few things to know as you get started:

• Supported OS: Linux (ARM64 and x86_64) at launch.
• Session persistence: Sessions persist for up to 14 days.
• Runtimes: Python 3.11-14 with native code support. Container images also supported.
• GPU: Support for GPU-accelerated instance types.
• Integration: Uses the same AgentCore APIs, identity, observability, and policy controls as AgentCore Runtime.
• Pricing: Standard EC2 pricing plus a management fee for AgentCore orchestration.
• Regions: US East (Ohio, N. Virginia), US West (Oregon), Asia Pacific (Mumbai, Singapore, Sydney, Tokyo), and Europe (Frankfurt, Ireland)

To get started, visit the runtime instance in Amazon Bedrock AgentCore documentation and create your first capacity provider.

— seb

The post Runtime instances: persistent compute for production AI agents on Amazon Bedrock AgentCore appeared first on The NOKIA Blog.

Perhaps it’s because these features are still incredibly convenient. Smart usage creates a pleasing aesthetic and can save space. And better coding practices lessen those previous concerns. This doesn’t mean a slider or carousel is always appropriate. However, there are still plenty of use cases when they make sense.

Even better, there are so many options, particularly for WordPress websites. You’ll find plugins that offer everything from basic image movement to full-on dynamic content presentations. Odds are, there’s a slider or carousel plugin that will match your needs.

With that in mind, we’ve rounded up a collection of the best free responsive slider and carousel plugins for WordPress. Let’s go!

portfolios or to spotlight sponsors. GS Logo Slider was designed specifically for this niche, giving you a quick way to create a logo presentation.

You’ll find multiple layout options, drag-and-drop ordering, tooltips, hover controls, and the ability to display images in grayscale. You can display your slider via a custom shortcode or by using the included Gutenberg block.

MetaSlider offers a simple workflow for creating responsive slideshows. Drag your images onto the canvas and set captions, links, and SEO data. There are also settings to help you optimize sliders for mobile devices. Also included are multiple themes, transition/animation effects, and accessibility options.

Create stunning sliders in no time with Smart Slider 3’s slide library feature. The plugin offers premade slides ready for your custom content. The included slider templates will also come in handy for integrating popular styles with minimal effort.

Want to showcase your content? There’s also a dynamic slide feature that will fetch your site’s latest posts. It’s a good choice for those who want great looks without the extra work.

There’s a lot to like about fetching reviews from third-party websites like Google. New reviews are added automatically, and there’s no manual labor involved. WP Google Review Slider will download your company’s reviews and serve them locally – great for performance.

The plugin integrates with the Google Places API to grab new reviews daily. There’s also an option to display reviews in a static grid format – no slider necessary.

The beauty of Carousel Slider Block is that it’s a block-first solution. It supports all Gutenberg blocks, meaning you can add any type of content imaginable into a carousel.

This design also means you can preview your creations directly in the Block Editor. You’ll also find plenty of controls to personalize your presentation.

Accessibility shouldn’t be an afterthought when building a slider or carousel. Accessible Carousel outputs keyboard-navigable and screen reader-friendly presentations. It also features a graceful fallback when JavaScript isn’t enabled.

The plugin includes a hero carousel, card scroller, and premade block patterns. You can also turn off autoplay to put users in control.

Depicter helps you build interactive sliders and beyond. The included template library will get your project off to a fast start, while an array of visual effects will grab user attention. You also get tools to build carousels, notification bars, and popups. The plugin is a jack-of-all-trades for interactivity.

Here’s a plugin that lets you create compelling sliders without weighing you down. Super Block Slider uses a 5KB JavaScript file to power your slideshows – great for even slow connections. Sliders are responsive and allow you to set different backgrounds for mobile devices.

There are also settings for custom overlays, parallax effects, animations, and navigation styles.

Slideshows can be a great way to show off your WooCommerce products. Woo Product Slider offers a quick setup via templates and the ability to display new and featured products. No worries if your store has hidden products, as you can choose to add them to your slider.

There are also options for displaying product details and an add-to-cart button.

Sticking with e-commerce, Product Gallery Slider for WooCommerce adds interactivity to your product pages. It improves on the standard Woo product gallery with a responsive slider that can handle all your product images.

It’s perfect for displaying product variations, such as colors or styles. Other features include a lightbox, caption, and image zoom toggles.

WordPress Slider Plugins at a Glance

Slide On In

This collection of free responsive WordPress slider plugins covers just about every use case. Whether you’re looking to showcase your site’s content, social media uploads, or enhance your e-commerce shop, you’ll find a tool that can help you achieve your goals.

here. He recently started a writing service for WordPress products: WP Product Writeup. He also has an opinion on just about every subject. You can follow his rants on Bluesky @karks.com.

Read more articles by Eric Karkovack

The post 10 Best Free Responsive Slider & Carousel WordPress Plugins appeared first on The NOKIA Blog.

React Server Components don’t send HTML to your browser. They don’t send JSON either. When a server component renders, what actually travels over the wire is a custom streaming protocol called Flight. It’s a line-delimited format with its own type system, its own reference resolution, and its own rules for reconstructing executable behavior on the client.

Most React developers have never opened the Network tab and actually looked at a Flight payload. It looks like a mix of JSON fragments, dollar-sign-prefixed references, and module pointers that the React runtime silently reassembles into a live component tree. The framework handles it, so nobody questions it.

I’m not sure most teams have thought carefully about what that trust actually implies.

I started pulling apart the Flight protocol after CVE-2025-55182 dropped in December 2025. The security community called it React2Shell, and for good reason. It was a CVSS 10.0, unauthenticated remote code execution vulnerability sitting in the Flight deserialization layer. One crafted HTTP request to a Server Function endpoint, and an attacker had shell access. No credentials needed.

The federal Cybersecurity & Infrastructure Agency (CISA) added it to the Known Exploited Vulnerabilities catalog. Sysdig tied in-the-wild exploitation to North Korean state-sponsored actors deploying file-less implants through the Ethereum blockchain. That’s the kind of CVE that gets your attention.

After spending time in the source (mostly getOutlinedModel and getChunk, which is where the resolution logic that matters actually lives), I realized React2Shell wasn’t a one-off parsing bug. It was a symptom. Flight reconstructs executable references, lazy-loaded components, server RPC endpoints, and async state from a stream of text. That’s a deserialization system.

The attack surface extends well beyond a single missing hasOwnProperty check. This article covers how Flight works on the wire, where the deserialization sinks are, what attackers have already weaponized, and what’s still exposed.

This leads to a ranked, practical set of defenses for your own Server Components: schema validation on every Server Action, the server-only package, cross-site request forgery (CSRF) hardening beyond framework defaults, and an assessment of what the Taint API and Web Application Firewalls (WAFs) provide.

Table of Contents

Flight On The Wire

Open your browser’s Network tab on any Next.js App Router page and look for requests returning Content-Type: text/x-component. That’s Flight. It’s not a single JSON blob. It’s a streaming, line-delimited format where each line is a self-contained “row” that the client-side React runtime processes as it arrives over the connection.

Here’s what a simple Flight payload looks like in practice:

1:I["./src/components/ClientComponent.js",["chunks/main.js"],"default"]
2:J["$","article",null,{"children":"$1"}]
0:D{"name":"RootLayout","env":"Server"}

Row 1 is an import directive. It tells the client to load ClientComponent.js from the bundler’s chunk map. Row 2 is a JSON tree that constructs an <article> HTML element, and the "$1" inside children is a reference back to chunk 1 (the imported component). Row 0 defines the server execution context, marking this as a RootLayout running in the Server environment. Even in this tiny example, you can see the mix of structural data, module references, and cross-chunk pointers that makes Flight different from plain JSON.

The Row Format

Every row follows the same syntax: <ROW_ID>:<ROW_TAG><PAYLOAD>n. The row ID is a numeric identifier that other rows can reference. The tag is a single character (or short string) that tells the parser what kind of data follows. The payload is the actual content.

Here are the row tags I found while reading through the source:

So far, this might look like a benign structured data format with some custom tags, but the real complexity and attack surface live in the prefix system.

The $ Prefix System

This is where I started paying closer attention.

When the client-side parser encounters a string value starting with $, it doesn’t treat it as literal text. It intercepts the string, checks the prefix, and routes it through a type-specific resolution path. The parseModelString function in ReactFlightClient.js is where this happens. It’s essentially a big switch statement on the character after $.

Every other prefix resolves a chunk and gives you the parsed result. $@ hands you the raw internal Chunk object instead, the wrapper React uses to track resolution state, pending callbacks, and internal metadata (which is why it’s used for Promises and why exploits use it to get a mutable handle). Exposing framework plumbing through the protocol looks like a design mistake to me, though I’d be interested to hear the rationale if there is one.

And $: (property access) is the other critical prefix. It lets the protocol specify a path like $1:user:name, which tells the parser to resolve chunk 1, then access .user, then access .name on the result. That’s arbitrary property traversal driven by data in the stream. If you’ve spent any time auditing JavaScript for prototype pollution, that pattern should feel familiar.

This Is Not Just A Data Format

Flight is not JSON with extra steps. JSON gives you data. Flight gives you behavior. It reconstructs module references that trigger client-side code loading, creates server action endpoints the client can invoke as RPC calls, sets up Promise chains that the React runtime will await, and builds lazy-loaded component boundaries that execute on demand.

Whether React developers think of it that way or not, the mechanics look very similar to deserialization systems that have historically caused problems. The stream doesn’t just describe what the UI looks like. It instructs the client runtime on what code to load, what functions to call, and what to trust.

If you want to read the implementation yourself, fair warning: the chunk resolution path is miserable to follow. State transitions bounce between helper functions, and the naming obscures what the code is actually doing. I gave up on static reading and just set breakpoints. The key files are react-client/src/ReactFlightClient.js for the client-side parser (look for parseModelString, getChunk, reviveModel, and getOutlinedModel) and react-server/src/ReactFlightServer.js for the serialization side. The reply handler for Server Actions lives in react-server/src/ReactFlightReplyServer.js.

Why Flight Is A Deserialization Sink

The deserialization pattern is familiar: Java’s ObjectInputStream gave us ysoserial, Python’s pickle executes code on load(), PHP’s unserialize chains __wakeup and __destruct methods, and .NET’s BinaryFormatter was deprecated entirely.

The pattern: deserialize attacker-controlled input → invoke behavior during reconstruction → lose control of execution.

So JavaScript should be immune to this, right? JSON.parse() only produces plain data objects. No constructors fire. No magic methods run. You get back exactly what the JSON string describes, nothing more.

That’s true for raw JSON.parse(). But it stops being true the moment a framework wraps custom deserialization logic around it. And that’s exactly what Flight does.

Prototype Pollution

JavaScript uses prototype-based inheritance. Every object has a __proto__ link to its prototype, and property lookups walk up this chain. If an attacker injects __proto__ or constructor.prototype as a key during reconstruction, they modify the shared base prototypes that all objects inherit from. Downstream code reads attacker-controlled values without knowing.

Flight’s $: prefix performs property traversal on deserialized objects. The getOutlinedModel function walks colon-separated paths like $1:user:name by iterating through each segment and accessing it on the parent object. If those path segments include __proto__ or constructor, the traversal walks straight up the prototype chain. That’s not a theoretical risk. It’s exactly how React2Shell worked.

Duck Typing and Thenables

The V8 engine (and the JavaScript spec) treats any object with a .then property as a Thenable. When you await something, the runtime checks for .then and calls it if it exists. No class check. No internal slot verification. If .then is callable, it gets invoked.

Flight resolves chunks asynchronously. If an attacker constructs an object with a manipulated .then property and gets it into the chunk resolution pipeline, the runtime calls the attacker’s function during normal await behavior. The language semantics do the work.

I initially focused on $F because forging Server Action references seemed like the obvious attack surface. After tracing the resolution path, $: property traversal looked much more interesting. I also spent a few hours examining chunk status transitions (pending, blocked, resolved, errored) to see if you could force a chunk into an unexpected state, though that approach didn’t yield any results.

The Core Problem

These two risks converge in Flight because the protocol doesn’t just deserialize data. It deserializes behavior. The $ prefix system dictates which execution path the parser takes: $F creates a callable server endpoint, $L sets up lazy code loading, $B triggers a blob handler, $@ exposes internal framework state. The parser’s control flow is driven entirely by what’s in the stream.

If an attacker can influence the stream’s content, they control which functions the parser calls, which objects it constructs, and which internal state it exposes.

The Mechanics Of React2Shell

This is the CVE that proved the theory. CVE-2025-55182, nicknamed React2Shell, is a CVSS 10.0 unauthenticated remote code execution vulnerability in the Flight deserialization layer. One HTTP request, no login required, full shell access.

I want to walk through the entire gadget chain because understanding it reveals how much power the Flight protocol hands to an attacker who can control the stream.

The Root Cause

The vulnerability sits in getOutlinedModel, a function responsible for resolving deep property paths from the $: reference system. The instance used in the exploit chain lives in the server-side reply handling code (ReactFlightReplyServer.js). When the parser encounters a reference like $1:user:name, it splits on the colons and walks the path segment by segment. Here’s the vulnerable loop:

for (key = 1; key < reference.length; key++)
    parentObject = parentObject[reference[key]];

Two lines. No hasOwnProperty check. No validation that the property exists on the object itself rather than somewhere up the prototype chain. Just parentObject[reference[key]] and move on.

So an attacker supplies $1:__proto__:constructor:constructor, and the loop traverses from a plain JSON object up through Object.prototype to the Object constructor to the Function constructor. Function in JavaScript behaves like eval(). Function("arbitrary code")() executes.

No allowlist on property names. No check for __proto__. I searched reviveModel and the chunk initialization path for any filtering. Nothing.

The Gadget Chain

Getting from “I can reach the Function constructor” to “I have RCE” requires chaining several Flight protocol features together. The Resecurity write-up covers the full chain in detail; here’s the high-level sequence:

• Step 1: Prototype walk to Function.
  The $: path __proto__:constructor:constructor walks from any plain object to Object.prototype, then to the Object constructor, then to Function — JavaScript’s built-in eval() equivalent.
• Step 2: Raw chunk self-reference.
  $@0 returns the raw internal Chunk wrapper instead of its resolved value, giving the attacker a mutable handle on React’s internal state machine.
• Step 3: Thenable hijack.
  The attacker sets the chunk’s .then to Chunk.prototype.then, so React’s resolution pipeline treats the manipulated chunk as a legitimate Promise-like object and awaits it.
• Step 4: Context confusion.
  During the second deserialization pass, the payload overwrites _response._formData.get to point to the hijacked Function constructor and places the attacker’s shell command into _response._prefix.
• Step 5: Trigger via blob handler.
  $B0 invokes the blob handler, which internally calls response._formData.get(response._prefix + blobId) — now equivalent to Function("attacker_shell_command")(). That’s arbitrary code execution with whatever privileges the Node.js process has.

Each step uses a legitimate Flight protocol feature in a way the designers didn’t anticipate. There’s no single “broken” feature. The vulnerability emerges from how these features compose when an attacker controls the input.

Impact

The numbers on this one are stark:

• CVSS 10.0. The maximum possible score.
• Unauthenticated and pre-auth. No credentials needed — and the deserialization happens before any application-level auth checks run, so even endpoints behind login walls are exposed.
• Single HTTP request. One POST to a Server Function endpoint.
• Affected React 19.0.0, 19.1.0, 19.1.1, and 19.2.0, across react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack.
• CISA added it to the Known Exploited Vulnerabilities catalog within days.

What Happened In The Wild

Exploitation was immediate. Sysdig published research linking EtherRAT deployments to North Korean state-sponsored actors who weaponized the vulnerability within hours of disclosure. EtherRAT is a file-less implant that uses the Ethereum blockchain for command-and-control communication — a technique researchers call “EtherHiding” — making takedown nearly impossible because you can’t seize a blockchain.

Separately, Palo Alto’s Unit 42 documented a backdoor called KSwapDoor that masquerades as [kswapd1] on infected Linux systems, blending into process lists alongside the legitimate kswapd0 kernel swap daemon; their analysis confirms KSwapDoor uses RC4 encryption to protect its internal strings and configuration data, while C2 communications run over AES-256-CFB with Diffie-Hellman key exchange across a P2P mesh network. The speed and sophistication of these campaigns — state-sponsored actors deploying novel implants through a single unauthenticated HTTP request — underscores why a CVSS 10.0 in a deserialization layer demands immediate patching, not triage.

The Fix

The React team’s patch is clean and targeted. The core change caches the genuine hasOwnProperty method at module load time:

var hasOwnProperty = Object.prototype.hasOwnProperty;

Then every property check in the deserialization path uses .call() to invoke the cached reference:

hasOwnProperty.call(value, i);

Even if an attacker shadows hasOwnProperty on a malicious object, the check uses the original prototype method. The prototype chain traversal that powered the gadget chain is blocked. This fix shipped in React 19.0.1, 19.1.2, and 19.2.1.

The fix is correct. But reading through the patches, I noticed the React team hardened ownership checks while leaving the property traversal model intact. The $: prefix still walks colon-separated paths; it just validates each step now. I think exposing arbitrary property traversal through a network protocol was a design mistake, and the patch treats the symptom. If future bugs emerge, they’ll likely come from this same area.

The framework patch closes the known gadget chain, but it doesn’t change the fundamental dynamic: the Flight protocol still reconstructs behavior — executable references, module imports, RPC endpoints, async state — from a stream of text. That reconstruction happens before your application code runs, before your validation logic fires, before your auth middleware even sees the request. Relying solely on the framework to protect your Server Components means trusting that every edge case in a complex deserialization parser has been found and fixed. The defenses that follow are the practical steps you can take to limit the blast radius on your own.

Defenses, Ranked By Impact

Some of these close real attack paths. Others mostly make you feel safer than you are. I’ve ranked these from most-to-least impactful based on what I’ve seen in the vulnerability research. If you only have time for one change, start at the top.

1. Input Validation On Server Actions (Zod, Valibot)

This is the single most impactful thing you can do at the application level. The Flight deserializer processes raw, unvalidated network input before your code takes control. Strict schema validation is your primary defense against whatever the protocol reconstructs.

Put a schema validation call at the very top of every Server Action, before any business logic runs — and I mean before anything, including logging. If you log an argument before validating it, and that argument triggers the stringification bug from CVE-2025-55183, you’ve leaked source code before your validation even had a chance to run.

Zod and Valibot both work well for this. Validate types, shapes, string lengths, numeric bounds, and enumerated values. Reject anything that doesn’t match. Use .safeParse(), not .parse() — the throwing variant can surface internal error details in the response if you’re not careful with your error boundaries.

"use server"
import { z } from "zod"

const UpdateProfileSchema = z.object({
  name: z.string().min(1).max(100),
  email: z.string().email(),
  role: z.enum(["user", "editor"]),
})

export async function updateProfile(formData: FormData) {
  const parsed = UpdateProfileSchema.safeParse({
    name: formData.get("name"),
    email: formData.get("email"),
    role: formData.get("role"),
  })
  if (!parsed.success) return { error: "Invalid input" }
  // proceed with parsed.data, this is now the only shape
  // your business logic ever sees
}

One important nuance: If your Server Action accepts a plain object argument (not FormData), validate the whole argument — don’t destructure first and validate fields individually. Destructuring before validation means you’re already accessing properties on the unvalidated input, which is exactly the kind of operation the Flight deserializer can exploit.

"use server"
import { z } from "zod"

const CommentSchema = z.object({
  postId: z.string().uuid(),
  body: z.string().min(1).max(5000),
})

// Good: validate the raw argument first
export async function addComment(data: unknown) {
  const parsed = CommentSchema.safeParse(data)
  if (!parsed.success) return { error: "Invalid input" }
  await db.comments.create(parsed.data)
}

// Bad: destructuring before validation
export async function addCommentUnsafe(
  { postId, body }: { postId: string; body: string }
) {
  // by the time this runs, you've already accessed properties
  // on the deserialized input
  const parsed = CommentSchema.safeParse({ postId, body })
  // ...
}

If your Server Action doesn’t start with a schema parse, it’s a vulnerability waiting to happen. I’d argue this should be a lint rule — and if you’re running eslint-plugin-react, consider writing a custom rule that flags any "use server" export without a validation call in its first statement.

2. The server-only Package

The server-only package is straightforward and effective.

Import server-only at the top of any file that contains database credentials, raw API calls, internal business logic, or anything else that should never cross the server-client boundary. If a Client Component tries to import that file (directly or transitively), the build fails with a clear error.

import "server-only"
import { db } from "./database"

export async function getUser(id: string) {
  return db.query("SELECT * FROM users WHERE id = $1", [id])
}

The failure mode to watch for is barrel files. If you re-export a server-only function through an index.ts that also exports client-safe utilities, any Client Component importing from that barrel will pull in the server-only module transitively and break the build — or worse, if the barrel doesn’t include the server-only import itself, it may silently let server code through. Keep server-only modules in separate files with their own import paths.

// Don't do this: barrel re-export mixes boundaries
// src/utils/index.ts
export { getUser } from "./users"     // has "server-only"
export { formatDate } from "./dates"  // client-safe

// Do this: separate import paths
// Client Component imports from "src/utils/dates" directly
// Server Component imports from "src/utils/users" directly

It also won’t protect you from data leaking through return values. If a Server Component calls getUser() and passes the full user object (including passwordHash or internalRole) as props to a Client Component, that data rides the Flight stream to the browser. The server-only guard prevents the code from crossing the boundary, not the data the code returns. You must explicitly filter your return shapes.

3. CSRF Protections

After CVE-2026-27978, relying solely on Next.js’s built-in Origin vs. Host header check isn’t enough. The Origin: null bypass showed that framework-level CSRF protection has edge cases.

For state-changing Server Actions (anything that writes data, deletes records, or modifies permissions), layer your own protections on top of the framework’s defaults.

Cookie configuration.
Set SameSite=Strict or SameSite=Lax on session cookies. If you’re using next-auth or a custom session library, verify this is set explicitly — don’t rely on browser defaults, which vary.

// next.config.js or your auth configuration
cookies: {
  sessionToken: {
    name: "__session",
    options: {
      httpOnly: true,
      sameSite: "strict",
      secure: process.env.NODE_ENV === "production",
      path: "/",
    },
  },
}

Explicit CSRF tokens.
For high-value operations (password changes, role assignments, payment actions), generate a per-session CSRF token on the server, embed it in a hidden form field or custom header, and validate it in the Server Action before proceeding.

"use server"
import { cookies } from "next/headers"
import { validateCsrfToken } from "@/lib/csrf"

export async function deleteAccount(formData: FormData) {
  const token = formData.get("csrf_token") as string
  const sessionToken = (await cookies()).get("csrf_secret")?.value
  if (!validateCsrfToken(token, sessionToken)) {
    return { error: "Invalid request" }
  }
  // proceed with deletion
}

The allowedOrigins gotcha.
Never, under any circumstances, add 'null' to experimental.serverActions.allowedOrigins in your Next.js config (even if the officially advisory is more nuanced, saying “unless intentionally required and additionally protected”). That string literal matches Origin: null — the exact header that sandboxed iframes send — and it reopens the CVE-2026-27978 bypass. If you’re seeing CSRF failures from legitimate requests, the fix is to configure your reverse proxy to set the correct Origin and Host headers, not to weaken the validation.

// Never do this
module.exports = {
  experimental: {
    serverActions: {
      allowedOrigins: ["null"],  // reopens CSRF bypass
    },
  },
}

4. The hasOwnProperty Patch

I covered this in detail in the React2Shell section. The fix is correct, and it completely neutralizes the known gadget chain. It shipped fast, which I respect.

The action item here is to verify you’re actually running a patched version. The RCE fix landed in React 19.0.1, 19.1.2, and 19.2.1. Check your lockfile:

# npm
npm ls react react-dom react-server-dom-webpack

# pnpm
pnpm ls react react-dom react-server-dom-webpack

# yarn
yarn why react-server-dom-webpack

If you see 19.0.0, 19.1.0–19.1.1, or 19.2.0, you’re vulnerable to the RCE. Update immediately. And don’t stop there: the DoS fixes (CVE-2025-55184, CVE-2025-67779, CVE-2026-23864) require 19.0.4+, 19.1.5+, or 19.2.4+. If you updated after React2Shell and then stopped paying attention, you may still be running a version vulnerable to the DoS variants.

It’s a reactive patch, not a structural redesign.

Note: More on that in Where This Goes Next.

5. The Taint API

React’s taintObjectReference and taintUniqueValue functions register objects or strings with the runtime. If tainted data tries to pass through the Flight serializer, it throws an error. The idea is to prevent sensitive data — user records, API keys, tokens — from accidentally leaking into the client.

Here’s how it looks in practice:

import {
  experimental_taintObjectReference as taintObjectReference
} from "react"
import "server-only"

export async function getUserRecord(id: string) {
  const user = await db.users.findUnique({ where: { id } })
  taintObjectReference(
    "Do not pass the full user object to Client Components. " +
    "Select only the fields you need.",
    user
  )
  return user
}

If a Server Component passes the tainted user object as props to a Client Component, React throws it at serialization time with your custom error message. That’s genuinely useful as a development-time guardrail.

The catch — and it’s a significant one — is that taint tracks object references, not data content. Any derivation breaks the tracking:

const user = await getUserRecord(id)

// taint is lost. Spread creates a new object.
<ClientProfile user={{ ...user }} />

// taint is lost. Individual properties aren't tracked.
<ClientProfile token={user.apiToken} />

// taint is lost. Serialization round-trip creates new refs.
<ClientProfile user={JSON.parse(JSON.stringify(user))} />

// taint fires. Same object reference.
<ClientProfile user={user} />

taintUniqueValue works on specific strings (like API keys), but it’s also reference-based. If the same key value appears in a different variable, the taint doesn’t follow.

Think of taint as a development guardrail, not a security boundary. It catches honest mistakes: a developer accidentally passing a full user object to the client. It won’t stop an attacker who can influence what gets serialized, and it won’t survive routine data transformations that your own code performs. It’s a useful defense-in-depth layer, but shouldn’t be your primary boundary.

6. WAFs

Web Application Firewalls can add a detection layer for known attack patterns. They can inspect POST requests carrying the Next-Action header, block payloads containing constructor:constructor or __proto__ chains, and flag error responses containing E{"digest" patterns that indicate the server is leaking internal error details.

If you’re running a WAF, here are specific patterns worth adding:

# Block prototype pollution attempts in request bodies
Rule: body contains "__proto__" OR "constructor:constructor"
Action: BLOCK
Scope: POST requests with header "Next-Action"

# Flag potential Flight error leakage in responses
Rule: response body matches /E{"digest":"[^"]+"/
Action: LOG + ALERT
Scope: responses with Content-Type "text/x-component"

# Block excessively large Server Action payloads
Rule: Content-Length > 1MB for POST with "Next-Action" header
Action: BLOCK (mitigates CVE-2026-23864 zipbomb vector)

But attackers know about WAF inspection buffers, and they’re usually around 128KB. Prepend 130KB of padding before the malicious payload, and the WAF inspects the padding, finds nothing, and lets the request through. Chunked Transfer-Encoding tricks accomplish the same thing.

The failure mode is treating WAF coverage as a security boundary rather than a noise-reduction layer. WAFs catch automated scanners and low-effort attacks, and that has real value. But a motivated attacker will bypass them with padding or encoding tricks. The defenses that actually stop sophisticated attacks are the ones earlier in this list: validating input before it reaches your business logic, keeping sensitive code off the wire, and staying on patched versions.

What Came After React2Shell

React2Shell wasn’t the end of it. The security audits that followed the December 2025 disclosure shook out a series of related vulnerabilities in the same deserialization surface. None of them are as severe as the original RCE, but they’re worth tracking because some of them required multiple rounds of patching.

The DoS pair (CVE-2025-55184 and CVE-2025-67779) is a textbook example of why deserialization parsers are hard to patch correctly. The first fix shipped, researchers found edge cases it missed, and a second round was needed. CVE-2026-23864 added a third DoS vector through unbounded memory allocation rather than CPU exhaustion. (See the defenses section above for specific version checks.)

CVE-2025-55183 is the sneaky one. It’s a source code exposure bug that triggers when a Server Function calls JSON.stringify (or any implicit stringification) on one of its arguments. Developers do this constantly for logging, debugging, or error reporting.

The attacker sends a crafted argument that, when stringified, causes the deserialization parser to reflect the function’s own source code back in the response. Business logic, database queries, and any hardcoded secrets sitting in Server Action files become readable by anyone who can send an HTTP request.

CVE-2026-27978 is a different class of bug entirely. It’s a CSRF bypass in Next.js’s Server Action handling. Next.js validates that the Origin header matches the Host header to prevent cross-site request forgery. But when a request comes from a sandboxed <iframe>, the browser sends Origin: null.

The Next.js parser in action-handler.ts treated the string 'null' as a missing origin rather than an explicit cross-origin indicator. So an attacker could embed a form inside a sandboxed iframe, submit it, and invoke Server Actions using the victim’s authenticated session cookies. Fixed in Next.js 16.1.7.

What’s Still Exposed

The CVEs above have patches. But some of the risk is structural, baked into how Flight is designed to work.

Man-In-The-Middle (MITM) On The Flight Stream

If an attacker can sit between server and client (CDN compromise, cache poisoning, rogue proxy), modifying the Flight stream in transit looks feasible. The format is plain text with a predictable structure.

Assuming stream control, an attacker could alter $I (Import) rows to redirect component loading to a different module in the webpack chunk map. They could inject $F (Server Reference) tags to embed hidden RPC triggers in the rendered UI. They could modify D (Data) rows to change component props, and if the target component uses dangerouslySetInnerHTML, that’s a direct XSS vector.

Flight escapes $ prefixes in user-supplied strings to prevent data from being interpreted as protocol instructions. But that only applies to data flowing through the serializer. A MITM attacker writes raw protocol directly into the stream. The escaping doesn’t help.

Server Action Enumeration

Server Action IDs are obfuscated hashes generated at build time. They look random. But server-reference-manifest.json maps every action ID to its source implementation. A public manifest hands an attacker a complete API map. This exposure usually stems from misconfigured hosting, an exposed .next directory, or path traversal.

Known action IDs expose Server Actions to standard IDOR and parameter tampering attacks. An attacker can forge direct requests with manipulated arguments. Developers often trust these inputs blindly because they originate from React’s internal machinery. The architectural consequences of that misplaced trust will be the focus of my next piece.

Encrypted Closure Tampering

When a Server Action captures variables from its surrounding scope (closures), Next.js encrypts them before sending to the client. The key is in NEXT_SERVER_ACTIONS_ENCRYPTION_KEY, AES with a base64-encoded key (16, 24, or 32 bytes). decryptActionBoundArgs handles decryption on each invocation.

By default, this key regenerates every build. But multi-server setups often use a static key. If an attacker gets file read access (path traversal, SSRF), they extract the key, decrypt the closure state, modify it (changing a userId, a role, a query parameter), and re-encrypt. The server accepts the forged closure as legitimate.

Supply Chain Activation via Module IDs

I haven’t demonstrated this end-to-end, but the theory is straightforward.

Flight references client components by module ID, something like ["360","static/chunks/app/page-7f3480.js"]. The bundler assigns these IDs at build time based on the module graph. A compromised npm package sitting in node_modules as a transitive dependency gets bundled into a chunk but never loaded because no component references it. Inert.

But if an attacker injects $I import references into the Flight stream (via MITM, cache poisoning, or server-side injection), the parser should load that dormant module. There may be chunk-level validation I’m not seeing. But if the module ID is valid and present in the manifest, I don’t see what stops it. The attack doesn’t require the package to be imported anywhere in your code. It just needs to exist in the bundle output.

This Has Happened Before

React Flight isn’t the first framework to invent a custom serialization format for server-client communication and then discover it’s an attack surface. And it won’t be the last.

Google Web Toolkit (GWT) used a custom RPC protocol to sync Java objects between browser and server. BishopFox demonstrated that attackers could manipulate the wire format to achieve arbitrary deserialization; GWT eventually disabled binary serialization entirely. It took years.

Java Server Faces (JSF) and ASP.NET both serialized ViewState to the client as a hidden form field. When cryptographic signing was weak or missing, attackers tampered with the serialized state and achieved remote code execution. Microsoft and Oracle patched it repeatedly. The underlying pattern kept resurfacing.

The pattern is always the same: a framework invents a custom wire format to move rich, stateful, sometimes executable data between server and client. The designers assume the server is the sole producer of that data and the client is a trusted consumer. Then someone demonstrates that the wire format can be manipulated in transit, or that the server can be tricked into deserializing attacker-controlled input. React Flight is the latest entry in this pattern. It is not an anomaly.

Where This Goes Next

The React Flight protocol solves a genuinely hard problem: streaming interactive component trees from server to client in a way that enables progressive hydration, async data loading, and server-driven code splitting. It works. I don’t want to lose sight of that.

But it works by serializing executable references, async state, module pointers, and RPC endpoints over a streaming text protocol, and then trusting the structure of that stream on both ends. The React team has patched the known gadgets. The hasOwnProperty fix is correct. The DoS fixes are in place. The source code exposure bug is closed.

I think exposing arbitrary property traversal and executable Thenable reconstruction through a network-facing protocol was a design mistake. $:, $@, and $B are powerful internal primitives that were reachable through a parser that didn’t validate ownership of the properties it traversed. One check was missing, and the result was CVSS 10.0.

As more frameworks adopt server-driven UI patterns, the industry is going to need stronger primitives than “the server is trusted”: cryptographic validation of serialized payloads, signed component trees, and content integrity checks on the Flight stream itself.

Hoping the parser handles every edge case hasn’t worked historically, and I don’t see why it would start working now.

The code is in react-client/src/ReactFlightClient.js. If you ship Server Components, read it. Know what your framework is trusting on your behalf.

(gg, yk)

The post Weaponizing And Defending The React Flight Protocol: Deserialization Sinks In RSCs appeared first on The NOKIA Blog.

We’ve all heard of the sacred rule in modern web development, the rule never to be broken. The rule of “Never block the main thread.”

You almost can’t miss it as a web developer; it’s in almost every performance guide, and to be fair, it is good advice. We all know the browser’s main thread is single-threaded, meaning it can only do one thing at a time.

Plus, as we know, the main thread isn’t ours alone; we share it with the browser’s rendering engine, input handlers, and other critical tasks. As a result, the less time we hold onto the main thread, the more responsive an app feels. That leads us to share tasks with background workers as we’ve convinced ourselves there should be a hard line between the UI and any computation, and that line shouldn’t be crossed.

And that is what a “recommended” architecture looks like.

But I dare say that *sometimes*, moving the data to a worker is slower than just letting the main thread do the work.

I found this out a few months ago while building a Chrome extension with screenshotting features called Fastary. I kept finding a latency of about 2 to 3 seconds in all my testing, even after using an Offscreen Document (a background process in Chrome extensions) to handle the canvas operations. A screenshot task should feel instant without lag, after all.

It is quite ironic that by reflex, we move work away from the main thread to avoid freezing the UI, but sometimes the act of moving that work (e.g., serializing, copying, and deserializing) can also freeze the UI. And sometimes the recommended approach of letting the background do the work can be slower than just doing the work on the main thread.

Let’s talk about that.

The Architecture Of Browser Context Isolation

To put things in perspective, let’s understand why we isolate browser contexts and how they communicate with each other, with emphasis on the communication part.

A browser is more than a single environment. Different environments are running at the same time, each having its own memory space, what it can access, and rules:

• The main thread is what we are most familiar with; this is where JavaScript logic runs, where the DOM lives, where styles get rendered, and where users interact.
• The Web Workers are separate threads that can also execute JavaScript without DOM access. We mostly use this for heavy data tasks.
• The Service Workers are network-related proxies in charge of intercepting network requests and can even run when the page is closed.
• And then there are Chrome extension contexts, where we have background service workers, content scripts, and Offscreen Documents (the relevant ones for this article).

Each one of these is isolated from the others. A web worker or background script lives in a different memory space from the main thread. They cannot just reach and read each other’s variables or logic, and this is known as the “shared-nothing” architecture.

How do these isolated environments communicate? They explicitly message each other back and forth using APIs, like postMessage().

The Structured Clone Algorithm

postMessage() tells the browser to take a piece of data and deliver it to the context that requested it. But to do this, the browser relies on the Structured Clone Algorithm (SCA).

You’re probably familiar with JSON.stringify(). SCA is similar, but much stronger and smarter. In its simplest form, SCA is a deep, recursive copy operation, i.e., cloning. It walks through the entire data structure it is given, clones every single value, serializes it into a transportable format, ships those bytes to the target contexts, and then reconstructs the original object on the receiving side.

SCA is fast, or maybe fast-ish… For a small regular config object like {theme: "dark"}, it is imperceptible; you don’t even notice it. The story changes, however, when dealing with heavy data because the SCA is a synchronous blocking O(n) operation, i.e., the cost increases linearly with the size of your data.

Let’s put that into perspective. A user clicks a button, and internally, an 8MB image payload is sent to a background worker for processing. When you call postMessage(), the main thread must immediately stop what it is doing to run this serialization and copying process.

So, if the time it takes to pack, ship, unpack the data, and go back to the start is longer than the time to just process the data on the main thread, why not do that instead?

What About Transferable Objects?

I’m sure some of you are already thinking, “Why not just use Transferable objects?” And that is a valid point. Let’s talk about that.

Developers who really pursue ultra-high-performance web apps usually use Transferable objects (e.g., ArrayBuffer, ImageBitmap, or MessagePort) to bypass the Structured Clone Algorithm. This is because when you transfer an object, you’re not making a copy (like SCM). Instead, the browser switches ownership of the data from one context to another.

The browser performs a hand-off whereby the sending context loses access to the data instantly, and the receiving context takes full control. It is actually insanely fast. According to Chrome Developers’ benchmark, transferring a massive 32MB ArrayBuffer can take under 7ms, compared to about 300ms when cloning with SCM. That’s a 43x speed boost.

But like all good things, there are downsides. To name a few:

• You lose it once you send it.
  If the UI still needs that data (like to show an image preview), you can’t access it anymore.
• Not all data is transferable.
  A plain JS object is not. A Blob is not. Even a Base64 string is not.
• API limitations.
  In the context of browser extensions, Chrome’s internal messaging (chrome.runtime.sendMessage) traditionally forces everything through JSON serialization.

So, as far as my screenshot extension went, Transferable objects were not an option.

Why We Isolate Contexts Anyway

Why do we even bother isolating contexts at all? Why not just leave it all to the main thread?

Offloading long-running CPU tasks to a background thread is absolutely the right thing to do. The browser needs to paint a new frame every 16.6ms to keep things fluid; that means any task that takes >50ms is generally considered “long”. Offloading to the background is absolutely the right thing to do.

The issue, however, is that we’ve turned this “never block the main thread” into an absolute rule, without asking is this task expensive to process or expensive to move?

I have come to realize now that the rule is less “never block the main thread” than “never block the main thread for too long.”

When The Right Architecture Is The Wrong Architecture

My goal with the Fastary extension was to make it feel like a native app, running as smoothly and instantly as you would expect a native app to.

As you already know, I took the recommended approach to use the Offscreen Document to handle DOM work in the background. But to my surprise, that took a different turn.

The Offscreen Document API is a clear winner. You create a hidden, undisplayed document that runs entirely in the background. It has a DOM and supports Canvas. For example, if I want to crop a screenshot, stitch multiple screenshots together, perform heavy image manipulation, or add a watermark, Offscreen Document was made for that.

Turns out that was not the best approach. This was my architecture:

1. The background Service Worker captures a screenshot with chrome.tabs.captureVisibleTab(), which returns a Base64-encoded data URL string.
2. The background Service Worker uses chrome.runtime.sendMessage() to ship this image payload to the Offscreen Document.
3. The Offscreen Document receives the image, loads it into an <img> element, then draws it onto a canvas before it applies the user’s crop coordinates, encodes the result, and sends the processed image back to the background worker.

But when I tested it, the screenshot didn’t feel instant. As I said earlier, there was a consistent 2–3 second lag.

I figured out that when captureVisibleTab() takes a screenshot, it returns a Base64 URL string, and on a standard 1080p screen, that string could be approximately 1MB or more, depending on how detailed the image is. It gets even more interesting on modern Retina displays (e.g., MacBooks) as they tend to automatically double the image’s size by default.

Keep in mind that since the image payload could be doubled and extension messaging relies on JSON serialization (as of this writing), we potentially deal with massive synchronous communication that costs an entire round trip.

The image string data is JSON-serialized at least twice: once when going into the Offscreen Document and once coming back out with the processed results to the background worker. The actual image processing (cropping) done inside the Offscreen Document was fast, no doubt, but I can’t say the same about the transfer overhead.

The Retina High-DPI Problem

As if the latency itself wasn’t enough, I noticed a rather subtle bug — which, now that I think of it, was more of my ignorance. After a screenshot was taken, the crop result was completely off in a way that either weirdly scaled the image or resulted in incorrect coordinates.

It turns out that when a user selects a region to crop, the content script gets the box coordinates using getBoundingClientRect(), which is measured in CSS pixels; this is what the DOM uses. But when the screenshot is captured natively in Chrome, the browser doesn’t crop it automatically; it instead uses the physical hardware pixels to get the full screen capture. And the browser uses devicePixelRatio (DPR) to know how many physical pixels should represent one CSS pixel. Basically, if a user on a Retinal display (DPR = 2) highlights an area of 400×300 CSS pixels, the actual captured image area is 800×600 physical pixels.

Note: One CSS pixel is equal to 1 physical pixel (DPR of 1) on a standard monitor. On a Mac Retina display or a modern 4K monitor, however, the DPR is usually 2 or 3.

For an accurate crop, I needed to apply these two different measurement systems with the right DPR, i.e., scale the crop coordinates by the DPR. But remember, Offscreen Documents have no physical display. Processing any image would have a default DPR equal to 1. To fix this, I would have to capture the exact devicePixelRatio from the active tab, serialize it, pass it alongside the image payload, and manually do the scaling math inside the Offscreen Document. The complexity starts to compound.

What if I broke the golden rule and did the work on the main thread instead?

Working On The Main Thread

Some developers will argue that UI tasks are the only things that should run on the main thread, but I don’t fully agree with that. Personally, I believe that user explicitly-invoked actions that need immediate results can sometimes get a solid pass to run on the main thread, provided the work is incredibly fast (e.g., 1s).

That’s what I did: scrap out the Offscreen Document and reengineer the logic. Instead of:

Background → [serialize] → Offscreen Document → [serialize] → Background → Content Script

…I decided to run the whole image processing in the active tab:

1. The background Service Worker captures the screen and gets the Base64 string (same as before).
2. The background sends the payload directly to the content script in the active tab using chrome.scripting.executeScript().
3. The content script (running on the main thread) receives the payload, draws it to a canvas, performs the crop using the correct DPR value, and copies the result to the clipboard.

// Background Script
const screenshotUrl = await chrome.tabs.captureVisibleTab(undefined, { format: "png" });

// Inject the processing function into the active tab as a content script
await chrome.scripting.executeScript({
  target: { tabId: activeTab.id },
  func: processAndCopyImage,
  args: [{ base64Image: screenshotUrl, cropData: userSelection }]
});

This approach completely clears out multiple context hops and round trips that JSON serialization requires. The only cross-context transfer involves sending the data URL from the background to the content script.

The Retina DPI issue essentially solved itself, as the content script runs directly inside the real, active browser tab because it knows the monitor’s real devicePixelRatio.

But there’s an elephant in the room that you may have noticed.

Sure, the image is now processed on the main thread, and the background manipulates the canvas in the active tab. I could technically be blocking the main thread. That’s where I amended the “no blocking the main thread” rule to “no blocking the main thread for too long.” In this specific case, at least, blocking the main thread for a task the user requests for approximately one second is justifiable. It works conversely as well: maybe don’t isolate processes if the data transfer cost is greater than the processing cost.

Conclusion: When To Isolate And When Not To

I’ve boiled it down to a mental model that depends on whether the task is:

1. Compute-Heavy Tasks (CPU-Bound)

These are tasks where the primary cost is computation and not the size of the data itself. These are tasks where most of the time is spent on doing calculations or heavy transformations, e.g., image compression, audio profiling, physics simulation, etc.

The transfer cost for these tasks is minuscule compared to the actual work.

2. Data-Heavy Tasks (Data-Bound)

These tasks are the exact opposite. These tasks are only expensive because of the size. The processing time is almost insignificant, but the data is expensive to transport, e.g., image cropping, filtering an array, shallow copy, etc.

In my specific case, offloading the task to the background falls mostly into negative-sum efficiency. If we are talking about moving megabytes of data to perform a 50ms operation, there is no benefit to offloading it to the background.

Perhaps we can think of it like this:

Total Time = Serialization Cost
  + Transit
  + Background Processing Time
  + Deserialization Cost

Looking at this, if the “background processing time” is the most dominant task in your operation, then isolation is the clear winner. But if serialization, plus deserialization, plus transit exceeds that cost, then there’s no need to isolate things.

And if you can’t figure out if the task is CPU-heavy or data-heavy, it certainly doesn’t hurt to measure it, for example, using performance.mark() and performance.measure() around postMessage calls to profile the transfer cost.

(gg, yk)

The post When It Makes Sense To “Block” The Main Thread appeared first on The NOKIA Blog.

For years, WordPress users have relied on traditional page builders to create websites without writing code. While these builders made web design more accessible, many still come with familiar compromises — rigid layouts, reliance on multiple third-party plugins, bloated code, and performance trade-offs that can slow down your site.

Kirki takes a different approach. Instead of building on the conventions of older page builders, it reimagines the website creation experience with a freeform infinite canvas, an integrated CMS, and a comprehensive set of built-in features. The result is a streamlined workflow that gives you greater creative freedom while producing cleaner, faster websites.

Whether you’re a designer seeking pixel-perfect control, a developer looking for cleaner output, or a business owner who simply wants to build a professional website without unnecessary complexity, Kirki aims to remove many of the limitations that have long been associated with WordPress page builders.

In this review, we’ll compare Kirki with traditional WordPress builders across the factors that matter most when choosing a website builder, including:

• Pricing and overall value,
• Impact on website performance,
• Ease of use versus design flexibility,
• Built-in features and functionality,
• Theme compatibility and layout customization.

By the end, you’ll have a clear understanding of where Kirki stands and whether it’s the right choice for your next WordPress project.

A Closer Looks At Kirki

Kirki is a no-code visual website builder for WordPress, designed to bridge the gap where other page builders fall short.

Unlike other page builders, Kirki is an all-in-one solution that aims to provide everything you need to build websites without any third-party dependencies, shifting from the norm in WordPress!

And the best part? It’s all included in your subscription, so you won’t be hit with surprise upgrades.

The Most Feature-Packed Free WordPress Builder

Before anything else, Kirki has a free version, and it’s genuinely powerful.

You can download Kirki for free directly from WordPress.org and start building right away. The free version is not a watered-down teaser. It’s a heavily feature-packed builder that lets you design modern websites on an infinite canvas without spending a cent.

Scale Without Limits With the Pro Plan

For those who want to unlock the full Kirki experience, the Pro plans are surprisingly affordable for the value they deliver.

The Starter plan is just $59/year for one site and includes all premium features. Compare that with Elementor Pro’s Essential plan, which starts at $60/year and still keeps several essentials behind paywalls. With Kirki, what you see is what you get, everything included from day one.

Kirki also offers a Lifetime plan for a one-time payment of $499, giving you unlimited use forever. No renewals, no upcharges, no surprises.

While most page builders upsell critical features or require multiple add-ons to function properly, Kirki keeps it simple. One platform, all features, no hidden costs. Dynamic content, pop-up builder, form builder, submission manager, the entire growing template library — all included from the start across every plan.

Explore Kirki pricing.

Website Performance Comparison

Performance directly impacts user experience, SEO, and conversion rates. So, to get a clear picture of how different page builders impact performance, we put Kirki and Elementor to the test under identical conditions to see how each builder stacks up.

We installed both on a clean WordPress setup using the default Twenty Twenty-Five theme to ensure a fair comparison. Then, we created identical layouts using comparable design elements and ran Lighthouse performance audits to measure load time, responsiveness, and Core Web Vitals.

Test Conditions:

• Clean WordPress installation,
• Same theme: Twenty Twenty-Five,
• Same layout structure and design elements,
• Lighthouse is used for performance scoring.

Sample Layout:

Kirki’s Performance:

Elementor’s Performance:

Kirki’s Code Output:

Elementor’s Code Output:

The difference was immediately clear. Kirki generated a much cleaner DOM with significantly fewer <div>s and no unnecessary wrappers, resulting in faster load times and higher scores across all boards.

Elementor, on the other hand, added heavily nested markup and extra scripts, even on this simple layout, which dragged down its performance.

If clean code, fast loading, and technical efficiency are priorities for you, Kirki clearly comes out ahead.

Exploring The Features

Now that we’ve seen how Kirki outperforms the competition and does so at a highly competitive price, let’s dive into the features to see what makes it such a powerful all-in-one builder.

Freeform Infinite Canvas For True Design Freedom

What makes Kirki different from the existing page builders is its infinite canvas.

With Kirki, you finally get the layout flexibility modern design demands, and no longer need to place elements into rigid structures.

Design on an infinite canvas where you can pan freely, zoom in and out, place elements exactly where you want, overlap sections, layer backgrounds, and build complex interactions, all visually.

Every element’s layout behavior is editable on canvas, giving you pixel-level control without touching code.

The editor supports both light and dark modes for a more comfortable, focused workspace.

If you’ve used Figma or Webflow, you’ll feel instantly at home. If you haven’t, this is the most natural way to design websites you’ve ever tried.

Concurrent Editing Across All Responsive Views

With Kirki’s infinite canvas, all your responsive views, Desktop, Tablet, Landscape, and Mobile, are visible side by side simultaneously. You don’t switch modes. You work across all of them at once, in real time, on the same canvas.

This means you can spot a layout issue on mobile while designing the desktop version, fix it instantly, and move on without ever breaking your flow. No back and forth.

And because Kirki uses a cascading system, changes made at larger breakpoints automatically flow down to smaller ones, so you’re never starting from scratch at every screen size. You only step in where you need to, making adjustments where the design requires it and letting the rest handle itself.

Instant Figma to Kirki Handoff

Talking about Figma, if you have a design ready in Figma, you can instantly import it into Kirki to create a functional website with no need to rebuild from scratch.

Your imported design comes in fully responsive by default, adapting to all screen sizes, including any custom breakpoints you define.

And it supports unlimited breakpoints, too. You can define layout behavior exactly how you want it, and styles will cascade intelligently across smaller screens.

No Third-Party Plugins Needed for Dynamic Content

In traditional WordPress, handling dynamic content means installing the ACF or other third-party plugins.

But with Kirki, all of that is natively integrated. It comes with a powerful Dynamic Content Manager that lets you:

• Create custom content types and fields.
• Use reference and multi-reference relationships.
• Build dynamic templates visually.
• Add dynamic SEO to template pages.
• Apply advanced filtering to Collection elements.

All without writing a single line of code or relying on external plugins.

Reusable Styling With Class-Based Editing

Kirki also has an efficient way to manage design at scale without repetitive work.

It uses a class-based styling system that brings structure and scalability to your design process. When you style an element, those styles are automatically saved as reusable CSS classes.

Here’s what that means for you:

• You can create global classes for common components like buttons, cards, or headings.
• Reuse those styles across pages and projects with consistency.
• Update a class once, and every instance updates instantly.
• You can also create subclasses to make slight variations, like secondary buttons, while still inheriting styles from the parent.

CSS Variables for Global Styling

Kirki takes styling even further with Global Variables, allowing you to define design tokens like colors, fonts, spacing, and sizing that can be reused across your entire site.

You can pair these global variables with your class-based structure to:

• Maintain visual consistency.
• Update values globally with a single change.
• Easily manage themes like switching between light and dark modes with one click.

And while Kirki offers a fully visual experience, it doesn’t limit advanced users. You can write custom CSS for any class or element, and even inject JavaScript at the page or element level when needed.

Build Complex Interactions and Animations Visually

When it comes to modern animations and interactive design, Kirki leaves traditional WordPress page builders far behind.

Its fully visual interaction builder lets you create dynamic, immersive experiences.

You can build scroll-based animations, hover and click effects, interactive sections that respond across devices, and control visibility, motion, and behavior all within a visual interface.

For advanced users, Kirki includes a timeline-based editor where you can:

• Create multi-step animations.
• Fine-tune transitions with precise timing, easing, delays, and sequencing.

Even text animations get special attention.

You can animate text by character, word, or full element. Choose custom triggers (scroll, hover, load, etc.) and select from various transition styles or create your own.

Kirki no-code website builder truly helps you move past generic and create unique animations and complex interactions.

Seamless Integration Management with Kirki Apps

Kirki takes the hassle out of connecting third-party tools with its intuitive Kirki Apps system. You can install and manage essential integrations such as analytics, CRMs, email marketing platforms, support widgets, and more, all from within the Kirki editor itself.

This centralized approach means you never have to leave your workspace. The clean, user-friendly interface guides you through the connection process visually, making setup fast and straightforward even if you’re not a technical expert.

Kirki brings the first real multi-user co-editing experience to WordPress. Multiple team members can work on the same page, at the same time, seeing each other’s changes unfold live on the canvas.

You see your teammates’ cursors moving in real time. You watch edits happen as they happen. Every change is color-coded and attributed, so the entire team stays oriented without ever having to ask.

Your team can also leave comments directly on the canvas, pinned exactly where the change needs to happen. For agencies, freelancers working with clients, and in-house teams juggling multiple contributors, this makes a huge of a difference.

Before you publish your site, Kirki helps ensure your site is technically sound with its built-in Page Audit tool.

It automatically scans your layout for:

• Missing alt text on images,
• Broken links,
• Unassigned or duplicate classes,
• Accessibility issues,
• And more.

So you’re not just building beautiful pages — you’re shipping fast, accessible, SEO-ready websites with confidence.

Theme & Layout Options

Kirki has a growing library of high-quality templates and modular layout options, so you’re never out of options.

Template Kits: Full Website Packs

Kirki’s Template Kits include complete multi-page website designs for every industry. Pick a template, update the content, and you’re ready to launch.

New template kits are added regularly, so you’re always equipped with the latest design trends. And the best part? At no additional cost. You get access to the finest designs without ever paying extra.

Pre-Designed Pages

Need just a landing page or a pricing page? Kirki also offers standalone pre-designed pages you can drop into your project and customize instantly.

Pre-Made Sections

Prefer to build from scratch but don’t want to start with a blank canvas? It also has ready-made sections like hero banners, testimonials, pricing blocks, and FAQs. You can visually assemble your layout in minutes using these.

How Easy Is Kirki To Use?

Kirki has come a long way in terms of accessibility.

The interface has been refined, the workflow is more intuitive, and a growing library of pre-made blocks, sections, pages, and full templates means you’re rarely starting from a blank canvas unless you want to.

That said, if you want something dead simple just to build a basic five-page site fast, there are lighter options out there like Elementor. But they come at the cost of power, performance, design control, and long-term flexibility.

Kirki is built for people who care about what they’re building. If you want pixel-level control, clean code output, truly responsive layouts, dynamic content, advanced interactions, and a site that scales without breaking, Kirki delivers all of that, and it’s more accessible than ever to get there.

To help you get up to speed quickly, Kirki includes:

• A refined, intuitive interface that’s easier to navigate than ever;
• An extensive and growing library of templates, pages, pre-built sections, UI components, and wireframes to kickstart any project instantly;
• Guided onboarding to walk you through the essentials;
• An AI generator that can scaffold entire pages and layouts in seconds.

The bottom line is that Kirki rewards the time you put into learning it. And with everything that’s been added recently, that time is shorter than ever.

What Users Are Saying

For many users, Kirki is more than just a builder. It’s the all-in-one tool WordPress has been waiting for. They are calling it the future of WordPress, a truly great alternative to tools like Framer and Webflow.

Why Kirki Outshines Traditional Website Builders

Building a professional WordPress website shouldn’t mean compromising on speed, flexibility, or performance. Kirki is designed to give designers, developers, and businesses a modern visual building experience that goes beyond the limitations of traditional page builders.

Modern Freeform Visual Builder

Design without being restricted by rigid rows or predefined layouts. Kirki’s intuitive freeform canvas lets you place, arrange, and customize elements exactly where you want them, giving you complete creative freedom.

Real-Time Responsive Editing

Perfect your website for every screen size with side-by-side responsive editing. Instantly preview and fine-tune your desktop, tablet, and mobile layouts simultaneously, eliminating the guesswork from responsive design.

Everything You Need in One Builder

Forget installing multiple add-ons and third-party extensions. Kirki includes the essential tools, widgets, and features you need in a single, integrated platform, reducing complexity while improving reliability.

Performance-Optimized Code Output

Great websites don’t just look good—they load fast. Kirki generates clean, lightweight, and optimized code that helps improve page speed, user experience, and search engine performance.

Seamless Figma to WordPress Workflow

Transform your Figma designs into fully functional WordPress pages with minimal effort. Reduce development time and maintain design accuracy from concept to launch.

Create dynamic websites with data-driven content, engaging animations, sophisticated interactions, and global styling controls that keep your branding consistent across every page.

A Powerful Free Version To Get Your Site Ready

Start building immediately with a feature-rich free version that includes everything you need to create a polished, professional website before deciding to upgrade.

After putting Kirki through its paces, the answer is a clear yes. Kirki not only matches traditional WordPress page builders where it counts, but it surpasses them in nearly every critical area.

From its cleaner, faster code output and outstanding performance to its unparalleled design freedom and powerful built-in features, Kirki solves many of the pain points that users have accepted for years.

Its all-in-one approach eliminates the need for multiple plugins, saving time, money, and technical headaches. If you’re serious about building high-quality, scalable, and visually stunning websites, Kirki isn’t just an alternative; it’s the future of WordPress site building.

Ready to experience the difference yourself? Try Kirki today and start building faster, cleaner, and smarter.

(yk)

The post Meet Kirki: WordPress’s First Visual Builder With An Infinite Canvas appeared first on The NOKIA Blog.

WordPress already includes Custom HTML and Code blocks for these purposes. However, their lack of syntax highlighting makes the code harder to read. Thankfully, there are several options for fixing this issue.

Syntax highlighting plugins help by color-coding and formatting your code snippets. Suddenly, you can tell your PHP from your HTML and JavaScript. It looks similar to what you’d find in popular editing apps like VS Code.

Want to dress up your code on the front and back end of your site? Here are the best syntax highlighter plugins on the market!

custom block to the WordPress editor. Add the block, choose your language, and you’ll get an easy-to-read snippet for your readers.

A settings panel lets you adjust the color scheme and typography. It also works with the Classic Editor, adding <pre></pre> tags to surround your snippets.

If you like the look of the VS Code editor, this is the plugin for you. It uses the same rendering engine as the popular app, while focusing on flexibility and performance.

There are 25+ themes to choose from and support for 150+ programming languages. Other niceties include a max-height block setting (you can scroll to reveal additional code), a copy button, and the ability to convert existing Code blocks.

PrettyCode claims to be the “prettiest syntax highlighting block” for WordPress. It fulfills that promise by offering over 50 themes and a slick title display for its custom block.

The plugin uses the popular CodeMirror library to dress up even the most mundane snippets. And there’s a look to match just about every site.

This syntax highlighter plugin offers plenty of formatting options, from plain to vibrant. It also supports more than 90 languages, making it a good choice for a variety of tutorial types.

Powered by Prism.js, you’ll find options to enable line numbers, a copy button, and a command line interface (CLI). The plugin also enables highlighting in WordPress post excerpts.

Syntax Highlighter Plugins at a Glance

Make Your Code Snippets Beautiful and Accessible

Using a syntax highlighter to share code snippets adds both form and function. Not only will your code look better, but it will also be more accessible for your audience.

Code is often difficult to read, but it can be improved with smart use of color and typography. The plugins on this list are there to help. They provide a wide range of looks and features. Plus, they can evolve along with your site’s design.

Don’t settle for the default styles of the WordPress Code block! Not when any of the above plugins will improve your code presentation in just a few clicks.

The post 6 Best Free Syntax Highlighter WordPress Plugins in 2026 appeared first on The NOKIA Blog.

However, AI also presents opportunities to broaden our horizons. We can use it to do things we haven’t tried before. Even better, we can experiment with ideas that seemed too ambitious a few years earlier. For example, consider projects that had a big learning curve or were time-consuming. Perhaps they don’t seem as daunting in the age of artificial intelligence.

The right tool could be the key to offering new and improved services to your clients. It’s a vehicle for increasing revenue and strengthening customer relationships. What’s not to love?

Let’s look at how AI can help you expand your agency’s service offerings. We’ll cover potential service ideas and considerations before presenting them to clients. You might even find the perfect growth opportunity for your business.

Find Tasks AI Can Do Faster and Better

Time is often the biggest barrier to creating new services. We’re busy enough without having to learn something new or focus on tedious work. More than anything, these are the tasks AI can help us tackle.

If you often find yourself knee-deep in code, you can use AI to lift the burden and increase productivity. Here are a few ideas to get you started.

Performance and Security Audits

Is your client’s website running at peak performance? Is it chock full of vulnerable code? Some plugins can help you find general answers. However, a full audit is often the best way to diagnose and fix issues.

The problem is that it takes significant effort to go through each line of code. You also need to know what to look for during the inspection process. Not everyone has the depth of knowledge in PHP, JavaScript, and other languages found in a WordPress website.

AI tools can save you a ton of time. Even a relatively lengthy code audit can be performed in the background (freeing you to enjoy a cup of coffee or two). Plus, some models are adept at finding security issues and performance bottlenecks.

The big caveat here is that AI can point out issues, but you may not be able to fix every one of them. For example, avoid making changes to WordPress core or third-party plugins. Those changes would be overwritten during a software update. You could, however, alert a plugin author of what you found.

On the other hand, the results can lead you to find better options or use AI to build a custom solution. Regardless, it’s a service you can charge for.

Custom Plugin Development

There are two truths in agency life: No two projects are the same, and no WordPress plugin can cover every niche. That’s what makes custom development an appealing service.

Here again, we face limits on our time and coding abilities. But even an expert developer may not have enough room in their schedule for a complex plugin. Then there’s the future commitment to maintenance. It’s a lot to put on your virtual plate.

AI models make perfect development companions. They can use WordPress documentation to follow best practices and generate plugins with relative ease. Some more advanced apps can also create a logical file structure for you.

This opens multiple possibilities for your agency. You can create one-off plugins to cover client needs. You might also level up by creating more general-purpose plugins for use across multiple sites. A plugin with enough appeal could be sold in the marketplace.

In every case, there’s an opportunity to boost your revenue. Add custom plugin development to your project and maintenance fees.

Content Starters and Analysis

It seems like content is always a sticking point when working with clients. We’re either waiting for clients to deliver it or we’re tasked with cleaning it up. Then there is also the ever-evolving challenge of SEO.

We still don’t recommend using AI to generate production-ready content. It’s simply too generic and won’t reflect branding without human intervention. However, it can help in several areas.

For one, you can use it to create “starter” content. This is text clients can review and edit to match their needs. The final results might be completely different – but that’s not the point. Seeing content on their screen might be the impetus they need to keep the project moving forward. That saves you time and a few headaches.

AI can also analyze content for accessibility and SEO best practices. Use cases include simplifying language, determining keyword density, improving titles, and generating meta summaries. It’s also handy for researching competitors.

Now, these common tasks can be completed in a fraction of the time. Adding them to your service list provides more value to clients. In addition, the SEO analysis could be a source of recurring revenue.

AI Could Be Your Agency’s Growth Engine

Perhaps AI’s value to your business is all about perspective. Sure, you could use it to make less-good versions of what you’re already doing. Generating slop and calling it a day isn’t great for your long-term viability. We won’t argue that some people have chosen this path.

However, AI is also capable of helping you be the best version of yourself. It just requires a more thoughtful approach. Use these tools to tackle the busy work while keeping a close eye on the results. Most importantly, be the decision maker in what you build. In other words, don’t accept AI’s initial output as the final answer.

Treating this technology as a partner is a path to growing your agency. The extra time and mental bandwidth you gain will allow you to identify new revenue opportunities. The ideas above are just the tip of the iceberg.

Ask yourself: What can AI do better and faster? How can it strengthen what I do best? How can I use it to improve client services?

The answers might lead you to something great!

here. He recently started a writing service for WordPress products: WP Product Writeup. He also has an opinion on just about every subject. You can follow his rants on Bluesky @karks.com.

Read more articles by Eric Karkovack

The post How AI Can Help You Expand Your Agency’s Service Offerings appeared first on The NOKIA Blog.

Scrolling is among the most boring necessities of digital design. Or is it? It’s easy for both designers and users to ignore. Yet, we spend much of our days moving up, down, and all around. There’s something to be said for going the extra mile.

Thankfully, there is an opportunity to do more. Scroll effects can add an element of fun to the mix. They’re also great for adding context and drawing attention to important content. Some effects even create a sense of immersion.

Web developers have found all manner of creative use cases. We scoured the CodePen archives to find eight prime examples of how CSS and JavaScript level up the user experience. We were quite impressed with the results.

Below, you’ll find everything from basic elements to jaw-dropping visual presentations. You’re sure to find inspiration for your next project. Let’s get started!

Premium ScrollTrigger Panels

Created by Ashish Ranjan

Here’s a unique way to scroll through the sections of a webpage. This pen creates a “stacking” effect, where each new section is layered on top of the last. The previous section zooms and fades out, allowing you to read the current content distraction-free.

Impressively, scrolling up reverses the effect. The technique uses GSAP scroll trigger and makes a long page seem shorter.

See the Pen PinStack Showcase – Premium ScrollTrigger Panels by Ashish Ranjan

Scrolling Text & Rotating 3D Gallery

Created by Luis Alberto Martinez Riancho

This 3-D gallery turns the classic carousel on its head. It combines scrolling text with a rotating cube that syncs in perfect harmony. Notice the shading and textures used to create a photorealistic feel.

The button-based navigation lets you avoid scrolling altogether, if that’s your thing.

See the Pen Six Faces / Walking The Cow by Luis Alberto Martinez Riancho

Stars Scroll Effect

Created by Aleksa Rakocevic

Scroll effects don’t have to be bold. There are times when subtlety is called for and appreciated by visitors. This starry background features a parallax motif with a hint of sparkles.

The result is a fun, yet classy, trip down the page. Consider it for blogs or other long-form content.

See the Pen Stars scroll effect by Aleksa Rakocevic

Smooth Scroll Behavior

Created by Margarita

Staying with the subtle aesthetic, the on-scroll effects of this pen are a great way to dress up an article. Text gently appears as you make your way down the page.

HTML scroll-behavior is used to ensure a smooth ride and add some flair to static content. This one is appropriate for virtually everyone.

See the Pen It Was Never A Competition — Full Story by Margarita

Infinite Loop Spiral

Created by Toc

Are you looking for a completely twisted take on a photo gallery? This spiral masterpiece will certainly grab attention. Scroll down, and this 3-D ribbon-shaped gallery spins through each image.

Use your mouse or finger to change perspectives. The effect is silky-smooth and will enhance your portfolio projects.

See the Pen Infinite loop spiral by Toc

CSS Scroll-Timeline Word Highlight

Created by Daniel Haim

Here’s a way to list your services and/or accomplishments with style. The text on the left stays put as you scroll, while the right side jumps to the next word or phrase.

It uses the scroll-snap-align and scroll-snap-type CSS properties to keep the presentation tidy. JavaScript sets properties based on user action. The result is an attractive method for making an impact with typography.

See the Pen CSS Scroll-Timeline Word Highlight by Daniel Haim

Springy Section Edges

Created by Tom Miller

Scrolling from one page section to another doesn’t have to be boring. A small effect, like this “springy” animation, adds context and entertainment value to the process. Reach the bottom of a section, and you’re welcomed with a bounce.

Here’s an idea: maybe add some confetti when you reach the end of the page. After all, loyal visitors should be celebrated!

See the Pen Springy Section Edges by Tom Miller

Reverse Scrolling Columns

Created by Ryan Yu

This photo gallery’s multi-column scrolling is reminiscent of a slot machine. The columns are synced, but the middle section moves in the reverse direction. It’s fun and immersive without overwhelming users.

Once again, GSAP scroll trigger serves as the secret sauce to the effect.

See the Pen Reverse scrolling columns by Ryan Yu

Use Scroll Effects To Enhance User Experience

Scrolling doesn’t have to be an afterthought in your design projects. The examples above demonstrate what’s possible with a little code and imagination.

In some cases, these effects can be the star of the show. Consider the photo galleries in our roundup. They become more interesting and interactive when you go beyond the default grid layout. You get high-end form and functionality.

On the other hand, subtlety also has a place when adding scroll effects to more traditional pages. A hint of elegance can transform static content into something more memorable.

The decision is yours to make. Consider your audience and accessibility needs, then choose the effect that makes the most sense.

Want to see even more awesome scroll effects? Check out our CodePen collection!

More CSS Effects Snippets

here. He recently started a writing service for WordPress products: WP Product Writeup. He also has an opinion on just about every subject. You can follow his rants on Bluesky @karks.com.

Read more articles by Eric Karkovack

The post 8 CSS & JavaScript Snippets for Adding Scroll Effects to Your Website appeared first on The NOKIA Blog.