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.

Ever since the commercialisation of the Graphical User Interface pioneered by systems like the Xerox Star and popularised by the original Apple Macintosh, software has relied heavily on point-and-click interactions. If you wanted to book a trip, buy a pair of shoes, or research a health symptom, you were expected to navigate a labyrinth of user interfaces. You click menus, adjust range sliders, fill out multi-step forms, deal with cookie pop-ups, and open dozens of browser tabs just to cross-reference basic information. We have become accustomed to spending more time managing the software rather than actually achieving our goals.

That contract is officially changing. Driven by advances in artificial intelligence and large language models, a new generation of web tools is pioneering a radical philosophy: Intent-Driven Design. Rather than expecting our users to learn complex menus and click through elaborate sales funnels, these platforms operate by capturing high-level human goals and silently executing the grunt work in the background.

This vision builds on long-standing HCI concepts like Golden Krishna’s “The Best Interface Is No Interface” and Don Norman’s principles of human-centered design.

The ultimate goal of modern web design is no longer to build prettier buttons or flashy animations; it is to eliminate the interface entirely.

Well, at least what we understand based on our current experience.

It is essential for UX designers to understand the changes we’re witnessing and even re-evaluate our role, shifting our focus from designing visible interfaces to guiding transparent, intent-driven AI experiences.

The Death Of The “10-click” Process

To understand where web design is going, we first have to look at the friction we have accepted as “normal” for decades.

Consider the traditional workflow of buying a flight online. The user experience is intentionally hyper-interactive:

1. Navigate to a travel aggregator or airline website.
2. Select “Round Trip” from a dropdown menu.
3. Type the origin city and wait for auto-complete.
4. Type the destination city and wait for auto-complete.
5. Click a calendar modal, toggle through months, and select departure and return dates.
6. Choose the number of passengers and cabin class.
7. Click “Search” and wait for the results page to load.
8. Filter by price, layover duration, departure time, and airline.
9. Sort the results and scan through dozens of individual options.
10. Click through a three-page checkout funnel dodging upsells for rental cars and travel insurance.

This is a classic point-and-click UI paradigm. The computer acts as a passive container of data, and the human acts as the orchestrator, manually inputting parameters, interpreting raw outputs, and executing each micro-step along the way.

Intent-driven design flips this dynamic entirely. Instead of forcing you to navigate the mechanical steps of how to find a flight, the interface asks a simple question: What are you trying to accomplish?

When you express a goal, such as “Find me a non-stop flight to Chicago next weekend under $300 that arrives before 5 PM”, the software reads your intent, executes the multi-step search query behind the scenes, compares the options, and presents a single actionable resolution. The ten clicks dissolve into one clear intent outcome.

Three Web Platform Examples Replacing Buttons With Intent

This shift isn’t a theoretical vision of the distant future. Some of the world’s most accessible websites allow you to experience intent-capturing systems already.

1. Perplexity AI: Search Without The Open Tabs

Traditional search engines like Google were built as directories. You typed a keyword, and the interface rewarded you with ten blue links. The actual work of opening five tabs, skimming long articles, dodging ads, and manually assembling an answer was left to you. Although this is now changing, with AI content appearing first when you search on Google.

Perplexity AI allows anyone to perform instant intent-based searches. Instead of forcing you to click into multiple tabs, the interface synthesises the perfect result for your context.

• The interaction: You ask a complex question in plain English: “Compare the top three budget laptops for a computer science student, focusing on battery life and keyboard quality.”
• The invisible work: In under two seconds, the platform searches the web, reads dozens of articles, evaluates hardware specifications, and cross-references user reviews.

• The result: (See screen above) Instead of throwing web pages at you, Perplexity dynamically generates a single custom answer complete with formatted comparison tables, pros and cons lists, and concise inline citations. You get the outcome of thirty clicks in just one.

2. Vercel v0: Web Design Without Dragging And Dropping

For years, creating a website meant using visual builders like Figma or drag-and-drop web editors. As designers, we spent hours manually drawing rectangles, picking hexadecimal colour codes, adjusting padding values, and sometimes writing CSS code.

Vercel v0 lets anyone test its generative interface builder right from the home page without signing in.

• The Interaction: A user types a descriptive goal into the input prompt: “Create a modern dark-mode dashboard for a subscription SaaS app showing monthly revenue, active users, and a customer churn chart.”
• The invisible work: The underlying AI understands layout principles, accessibility guidelines, UI component libraries, and responsiveness. It writes clean HTML, Tailwind CSS, and React code in real time.
• The result: Rather than spending an afternoon manipulating elements, the user receives a fully functional, pixel-perfect user interface in seconds! The traditional visual design tool disappears, replaced by raw human intent.

3. Goblin.tools: Breaking Down Overwhelming Tasks

Many traditional productivity tools require you to manually construct task lists, drag items across Kanban boards, and assign micro-deadlines. Goblin.tools is a free, single-page suite of single-task AI tools designed specifically for neurodivergent users or anyone feeling overwhelmed, requiring zero sign-ups or configuration.

• The interaction: You enter a vague, intimidating goal into the Magic Todo tool, such as “Prepare for a job interview”.
• The invisible work: Instead of forcing you to plan every step, the system analyses the cognitive load of the goal and automatically breaks it down into small, actionable sub-tasks adjusted to your preferred level of detail.
• The result: The interface eliminates the stressful task-planning phase and presents a clean checklist tailored to your exact goal.

The Core Pillars Of Intent-driven Web Design

When you remove traditional menus, sidebars, and forms, how do you keep a website usable? Designers pioneering this space rely on three core pillars:

1. High-level Goals

An invisible interface doesn’t always wait for you to type a command — it leverages context to anticipate user needs. Guided by industry standards like Apple’s Human Interface Guidelines on Contextual & Ambient Design, modern systems read environmental metadata, such as device state, location, and past interaction patterns, to trigger proactive actions.

For example:

• Time and location: A food delivery web app prioritising your saved home address and dinner items automatically at 6:30 PM on a weekday.
• Cross-app history: A calendar application noticing an email about an upcoming appointment and surfacing a one-click “Add to Schedule” card without forcing you to copy and paste event details manually.

2. Generative UI

In traditional web design, every user sees the exact same layout. An e-commerce store shows the same navigation bar whether you are a first-time visitor looking for customer support or a returning customer tracking a package.

As highlighted in the Nielsen Norman Group’s analysis on AI as a new UX paradigm, computing is shifting from command-based interaction to outcome-specification. This enables Generative UI, where interfaces are rendered dynamically on the fly based on what you are trying to do in that exact moment. For example, platforms like Vercel v0 demonstrate how raw intent can instantly render functional code components without manual layout building. If you express a desire to compute complex financial data, the interface generates a dynamic calculator widget on demand, receding once your goal is completed.

3. Execution by AI Agents

Traditional interfaces are obsessed with prevention, constantly peppering users with confirmation pop-ups (“Are you sure you want to delete this file?”).

Intent-driven interfaces adapt Jakob Nielsen’s 10 Usability Heuristics on User Control and Error Recovery by shifting the safety net from prevention to easy reversibility. Because autonomous agents take actions on your behalf, products prioritise frictionless rollback mechanisms. A prominent “Undo” button, simple revision prompts (“Make this summary shorter”), and transparent audit logs replace intrusive warning modals.

The Hidden Risks

While removing interface friction is liberating, stripping away visual controls introduces significant product design challenges. When software acts on inferred intent rather than direct point-and-click commands, designers must navigate critical ethical and technical pitfalls.

The Illusion Of Control

When a website makes decisions for you, it can quickly feel patronising or invasive. As explored by the Stanford Human-Computer Interaction (HCI) Group, automation must maintain clear boundaries to prevent user frustration. Furthermore, ethical frameworks from the Center for Humane Technology emphasise that product designers must guard against manipulative defaults.

Designers must strike a delicate balance: automate routine execution, but explicitly prompt the user for high-stakes confirmations (such as financial transactions, publishing public content, or altering privacy settings).

The Black Box Problem

In a traditional UI, if you get an unexpected result, you can usually diagnose the issue — perhaps you checked the wrong filter box or selected an incorrect date.

With an intent-driven interface, troubleshooting becomes harder. To address this “black box” challenge, the Google PAIR (People + AI Research) Guidebook advocates for transparent feedback loops. The system must explicitly state its interpretation (“Searching for non-stop flights to Chicago under $300…”) so users can calibrate trust and correct misinterpretations instantly.

From A UX Perspective

As a UX designer, always being curious to understand how our design approach is changing in the world of AI, I find it essential that we re-evaluate the foundational elements of our craft.

Rather than designing static buttons and rigid forms, we need to learn to map and present dynamic, generative UI components that adapt on the fly to user intent.

By mastering these evolving patterns, like ambient feedback, inline prompts, and transparent AI status indicators, we can ensure that screenless, agent-driven tools remain intuitive, ethical, and deeply human-centered.

Conclusion

The ultimate goal: The best design is no design.

For decades, the digital industry has evaluated software success through engagement metrics like time spent in app, click-through rates, and page views per session. Websites were deliberately engineered to maximise visual engagement and interaction volume.

The philosophy behind Golden Krishna’s seminal book The Best Interface Is No Interface, aligned with the broader Center for Humane Technology’s Time Well Spent movement, turns these metrics on their head. The ultimate test of a modern digital product is no longer how visually captivating its buttons are, but rather: How effectively did this software solve the problem and get out of the user’s way?,

We are entering an era where web applications will no longer be measured by the beauty of their interfaces, but by their ability to render those complex interfaces completely obsolete. The future of the web isn’t more interaction — it is seamless, invisible completion.

(ah, yk)

The post The Death Of The Button: Why The Best Interface Is No Interface appeared first on The NOKIA Blog.

There are also big differences between hosting providers. Some focus on low-cost shared hosting, while others offer managed WordPress hosting, cloud hosting, or plans built for businesses and agencies. The tools included with each plan can vary just as much. Backups, staging sites, caching, security, migrations, CDN access, and developer tools may be included, limited, or cost extra.

This comparison looks at six popular WordPress hosts: WordPress.com, Bluehost, Pressable, Cloudways, Kinsta, and SiteGround. Each provider has been tested and compared across the areas that matter when running a WordPress website.

The goal isn’t to name one host that works for everyone. A personal blog, WooCommerce store, client website, and busy online publication have very different hosting needs. Instead, the results should make it easier to see where each provider works well, where it falls short, and which type of WordPress website it suits best.

Best WordPress Hosting: Quick Recommendations

Not everyone needs to compare every plan and technical detail. These recommendations offer a quick starting point based on common WordPress projects. Each host has been selected for a different type of user, with performance, management tools, support, pricing, and the overall hosting experience taken into account.

Best Overall WordPress Host: WordPress.com

WordPress.com is our best overall host because it combines managed WordPress hosting with the flexibility and ease of use many websites need. It works well for blogs and business sites, with plans suitable for larger publications and WooCommerce stores.

Much of the technical work is handled for you, including caching, security, updates, SSL, and CDN access. All paid plans now support third-party plugins and custom theme uploads. Business adds daily backups, staging, SFTP, SSH, database access, WP-CLI, and other developer tools.

WordPress.com is run by Automattic, a company with deep ties to the WordPress open-source project and WordPress.org. That experience carries through to its managed hosting and support, which is useful when a problem involves both WordPress and the hosting platform.

There is less server maintenance to handle, while developers can choose Business when they need more advanced access. Those needing full server control may prefer cloud or VPS hosting.

Pricing varies between plans, so always compare promotional rates with the normal renewal price.

Further Information:

WordPress.com Plans & Pricing

• Personal: Supports third-party plugins and themes, custom CSS and code, along with security, support, and migration tools.
• Premium: Includes everything in Personal, with additional design, analytics, SEO, advertising, and monetization tools.
• Business: Adds daily backups, staging, SFTP, SSH, WP-CLI, database access, GitHub deployments, and other developer tools.
• Commerce: Includes the tools available with Business and adds WooCommerce and online selling tools.

All data correct as of August, 2026.

Best WordPress Managed Host: Kinsta

Kinsta is our choice for the best managed WordPress host. It is built for WordPress sites that need strong performance, reliable hosting, and useful management tools without the site owner having to manage the server.

Every WordPress site runs in its own isolated container, with access to Kinsta’s cloud infrastructure and a choice of 30 data center locations. Server caching, edge caching, a Cloudflare-powered CDN, security, daily backups, and performance monitoring are included.

Kinsta also provides a strong set of developer tools, including DevKinsta. SSH and SFTP are included with all WordPress hosting plans, WP-CLI is installed by default, and staging gives developers a separate platform to test changes. MyKinsta also offers database management, logs, analytics, and Kinsta’s APM performance tool.

The main drawback is price. Kinsta costs more than budget WordPress hosting, so it is harder to justify for a small personal site. But for businesses, busy publications, stores, and other sites where performance and support matter, the extra cost makes sense.

Further Information:

Kinsta Plans & Pricing

• Single Site Plans: Built for one WordPress website, with several levels based on traffic or bandwidth. All include CDN, edge caching, daily backups, staging, security, migrations, SSH, SFTP, and WP-CLI.
• Multiple Site Plans: Designed for users who manage several WordPress installations. These plans increase the number of sites and available resources while keeping them under one Kinsta account.
• Agency Plans: Made for agencies that manage larger collections of client sites. They provide higher limits and more capacity while retaining the same managed WordPress platform and development tools.
• Custom Plans: Available for WordPress projects that need more resources than the standard plans provide. These are better suited to very busy sites and projects with unusual hosting requirements.

All data correct as of August, 2026.

Best WordPress Blogger Host: Cloudways

Cloudways is our choice for the best WordPress blogger host, particularly for established blogs and publications that have grown beyond basic shared hosting. It provides managed cloud hosting while still giving site owners more control over server resources than most managed WordPress platforms.

With Cloudways Flexible, WordPress can run on cloud infrastructure from DigitalOcean, Vultr, Linode, AWS, or Google Cloud. You choose the provider, server size, and location, while Cloudways handles much of the server setup and management. Resources can also be increased as traffic grows.

WordPress tools include server caching, staging, cloning, automated backups, SSL, migrations, security tools, SSH, SFTP, Git, and WP-CLI. Multiple WordPress sites can also run on the same server, provided it has enough resources.

This flexibility is why Cloudways works well for established bloggers. A growing publication can increase its hosting resources without moving to another platform. The tradeoff is complexity. There are more server settings to understand than with WordPress.com or Kinsta. But for bloggers comfortable managing WordPress, that extra control can be useful.

Further Information:

Cloudways Plans & Pricing

• DigitalOcean: The most practical starting point for many WordPress blogs. Plans provide dedicated cloud resources, SSD or NVMe storage, vertical scaling, and a choice of server locations.
• Vultr: Offers a broad choice of data center locations and server configurations. It is useful when the main audience is closer to a Vultr location or a different server setup is required.
• Linode: Another option for blogs that want predictable cloud resources and a choice of server locations while keeping Cloudways responsible for much of the server management.
• AWS: Uses Amazon Web Services infrastructure and provides more server configuration choices. It is generally more expensive and is better suited to sites with requirements that justify the added cost.
• Google Cloud: Runs WordPress on Google Compute Engine through the Cloudways dashboard. Like AWS, it provides flexible server resources but usually costs more than the simpler cloud options.

All data correct as of August, 2026.

Best WordPress Developer Host: Pressable

Pressable is our choice for the best WordPress developer host. It is a fully managed WordPress platform from Automattic, the company behind WordPress.com and WooCommerce, and runs on its WP Cloud infrastructure. That WordPress focus is one of the main reasons it works so well for development work.

Developers get staging and sandbox environments for every site, along with SSH, SFTP, WP-CLI, Git, database access, and other tools needed for building and maintaining WordPress sites. DupliKits can also be used to create reusable site templates, which can save time when several projects start with a similar setup.

Pressable handles much of the hosting work in the background. Hourly and daily backups, caching, security monitoring, automatic scaling, a global CDN, and site migrations are included. There is also 24/7 support from a team that works with WordPress every day.

Pricing is higher than budget hosting, but that is not really what Pressable is competing with. The value comes from reducing server maintenance while keeping the development tools needed for regular WordPress work. For freelance developers and teams managing several sites, that balance makes Pressable a strong choice.

Further Information:

Pressable Plans & Pricing

• Signature 1: Supports one WordPress site, 30,000 monthly visits, and 20GB of storage. Suitable for developers managing a single business or client site.
• Signature 2: Supports three WordPress sites, 50,000 monthly visits, and 30GB of storage. Useful for developers who manage a small collection of client sites.
• Signature 3: Supports five WordPress sites, 75,000 monthly visits, and 35GB of storage. Offers more room for freelancers maintaining several active WordPress projects.
• Signature 4: Supports ten WordPress sites, 150,000 monthly visits, and 50GB of storage. Excellent for developers and small teams that manage a larger group of websites.
• Signature 5 and Above: Plans increase from 20 to 100 WordPress installations, with higher traffic and storage limits. They are aimed at larger development teams and agencies with many sites.

All data correct as of August, 2026.

Best WordPress Agency Host: SiteGround

SiteGround is our choice for the best WordPress agency host. It combines managed WordPress hosting with tools for building, testing, managing, and handing client websites once a project is complete and launched. GrowBig and GoGeek also allow multiple websites under one account, which makes them better suited to agency work than the single site StartUp plan.

SiteGround handles many routine hosting jobs, including WordPress updates, daily backups, caching, CDN access, SSL, security, and server maintenance. GrowBig and GoGeek also include WordPress staging, while developers have access to SSH, SFTP, WP-CLI, databases, and other common development tools.

The agency tools are the main reason for choosing SiteGround here. Team members can be added as collaborators without sharing the main account login. Finished websites can also be transferred to clients while the agency remains attached as a collaborator. GoGeek adds white label client access, so clients using Site Tools do not see SiteGround branding.

The main drawback is renewal pricing. SiteGround offers large discounts for the first year, but regular rates are much higher. Agencies should use those renewal prices when calculating the long-term cost of hosting client websites.

Further Information:

SiteGround Plans & Pricing

• StartUp: Supports one website, around 10,000 monthly visits, and 10GB of storage. It includes managed WordPress tools, daily backups, caching, CDN access, SSL, and email. The single site limit makes it less useful for agency hosting.
• GrowBig: Supports unlimited websites within its resource limits, around 100,000 monthly visits, and 50GB of storage. It adds more server resources, WordPress staging, on-demand backups, and collaboration tools. This is a good starting point for smaller agencies.
• GoGeek: Supports unlimited websites within its resource limits, around 400,000 monthly visits, and 100GB of storage. It provides more server resources and adds white-label client access, making it the strongest shared hosting plan for agencies managing client websites.

All data correct as of August, 2026.

WordPress.com is our choice for the best WooCommerce host. WooCommerce can now be installed on any paid WordPress.com plan, giving store owners more choice over how much hosting and how many store tools they actually need.

The close connection with WooCommerce is a major advantage. WordPress.com and WooCommerce are both part of Automattic, so the hosting platform is built and supported by people with a deep understanding of WordPress and WooCommerce. This becomes useful when a problem involves the store, WordPress, and the hosting environment.

For larger stores, the Commerce plan includes everything in Business, along with WooCommerce and additional selling tools. This includes real-time backups, staging, SFTP, SSH, database access, payment tools, shipping integrations, automated taxes, product recommendations, and other WooCommerce extensions.

WordPress.com also handles much of the hosting work, including caching, security, updates, SSL, and server management. Store owners can concentrate on products, orders, customers, and sales rather than maintaining the server. It may cost more than basic WooCommerce hosting, but the managed setup makes more sense as a store becomes busier.

Further Information:

WordPress.com Commerce Plans & Pricing

• Personal: WooCommerce can be installed alongside third-party plugins and themes. It provides a low-cost starting point for a very small store, but it does not include the advanced backups, staging, and developer tools available on higher plans.
• Premium: Includes everything in Personal, along with additional design, analytics, SEO, advertising, and monetization tools. WooCommerce can be installed, although growing stores may benefit from the stronger hosting tools available with Business.
• Business: Adds real-time backups, staging, SFTP, SSH, database access, WP-CLI, and other developer tools. WooCommerce can be installed normally, making Business a good choice for store owners who want to build their own WooCommerce setup.
• Commerce: Includes everything in Business and adds WooCommerce with a collection of store tools and extensions. It supports unlimited products and orders, payments, shipping integrations, automated taxes, product recommendations, abandoned cart emails, and other selling tools.

All data correct as of August, 2026.

Best Budget WordPress Host: Bluehost

Bluehost is our choice for the best budget WordPress host. Its lower-priced plans provide the tools needed to run a blog, portfolio, small business site, or other WordPress project without paying the higher monthly cost of premium managed hosting.

WordPress hosting includes managed updates, SSL, CDN access, malware scanning, backups, migration tools, and a domain for the first year. Bluehost also provides a 99.99% uptime SLA and several server locations. WordPress setup and site management are handled through a dashboard aimed at users who may not have much hosting experience.

Starter is the obvious choice for smaller sites, while Business provides more storage, supports more websites, and adds further security and backup tools. Higher performance plans are available when a site needs more resources, so there is room to move beyond the entry-level packages.

The main issue is renewal pricing. Bluehost offers large discounts for the initial term, but the regular price is considerably higher. That needs to be included when comparing it with other budget hosts. For a smaller WordPress site where keeping the initial cost low matters, Bluehost still provides a strong set of hosting tools for the money.

Further Information:

Bluehost Plans & Pricing

• Starter: Supports up to ten websites with 10GB of NVMe storage. It includes managed WordPress updates, CDN access, SSL, malware scanning, weekly backups, migration tools, and a domain for the first year. It is the best fit for blogs and smaller WordPress sites.
• Business: Supports up to 50 websites with 50GB of NVMe storage. It provides more room for growing sites and is better suited to users managing several WordPress installations or a busier business website.

All data correct as of August, 2026.

Most WordPress hosts include more than just server space. Backups, staging sites, caching, CDN access, SSL, security, and migration tools reduce the amount of work needed to maintain a site. A host may advertise backups but run them only weekly, or offer staging only on its more expensive plans.

There is also a difference between a tool being included and it being well connected to the hosting platform. The right setup depends on whether the project needs simple management or greater control.

Developer requirements can be very different from those of someone running a single blog. Staging sites, SSH, SFTP, WP-CLI, Git, database access, logs, and local development tools will save a lot of time. They are also useful when testing updates or tracking down a problem without making changes directly on a live site.

Cloudways provides the greatest server control of the hosts compared here, while Kinsta and Pressable combine strong development tools with a more managed setup. WordPress.com also provides many common development tools on suitable plans. SiteGround covers most everyday development needs, while Bluehost provides enough access for many smaller projects.

The main question is how much control is actually required. More server access is useful for some developers, but it also means taking responsibility for more of the hosting setup.

AI tools are starting to appear in WordPress hosting platforms. Many providers now use it to help monitor websites, detect security threats, improve performance, and simplify routine management tasks. Some platforms also include AI assistants that can answer questions, troubleshoot common issues, or help configure hosting settings.

While these tools can save time, they shouldn’t be the main reason for choosing a host. Performance, reliability, support, and security still matter more. AI is best viewed as a useful addition rather than a replacement for a well-managed hosting platform.

The table below shows how the six hosts in this comparison currently approach AI.

All data correct as of August, 2026.

WordPress.com currently has the most complete AI setup of the hosts compared here. Its AI website builder can create a new WordPress site, while WordPress Agent continues working inside the site after it has been built. It can help with content, layouts, images, pages, and other editing jobs.

The more interesting addition for developers is MCP support. WordPress.com can connect with outside AI agents such as ChatGPT, Claude, Cursor, and other compatible tools. These agents can read site information and, with permission, carry out tasks such as creating posts, managing content, working with media, and changing site settings. MCP is available across paid WordPress.com plans.

Other hosts are using AI in narrower ways, often concentrating on initial site creation, content generation, or hosting support. Those tools can still be useful, but they should not be a major reason to choose a host on their own. Hosting performance, support, backups, security, development tools, and long-term cost still matter much more.

How to Choose a WordPress Host

Choosing a WordPress host is one of the biggest decisions you’ll make for your website. Your hosting provider affects performance, reliability, security, and how easy your site is to manage. The right host will keep your website running smoothly and give you access to support when you need it.

No hosting plan suits every website. A personal blog has different needs than an online store or an agency managing client sites. Knowing what your website requires before comparing providers will help you narrow your options and avoid paying for services you won’t use.

When comparing hosts, look at uptime, page speed, server locations, backups, staging sites, security, support, and renewal pricing. These factors often matter just as much as the monthly cost.

The articles below cover the main topics involved in choosing a WordPress host. Whether you’re building your first website or moving to a new provider, they’ll help you compare your options and make a confident choice.

WordPress Hosting for Different Needs

Choosing a hosting plan that matches your needs can improve performance, make your website easier to manage, and help you avoid paying for resources you won’t use. As your website grows, you can move to a plan with more storage, power, and management tools.

Whether you’re building your first WordPress website, running an online store, or managing client sites, understanding the strengths of each hosting option will make it easier to choose the right provider.

WordPress Performance & Security

A good hosting provider gives your WordPress website a solid foundation, but hosting is only part of the picture. Your website’s setup, the tools you use, and your security practices all affect performance, reliability, and keeping your visitors safe.

Many WordPress hosts include caching, content delivery networks (CDNs), backups, malware scanning, and SSL certificates. Knowing how these features work will help you get more from your hosting plan. Regular maintenance also helps keep your website running well. Updating WordPress, plugins, and themes, monitoring performance, and following good security practices can prevent many common problems.

The articles below cover the tools and techniques that can improve website speed, strengthen security, and simplify day-to-day management.

Managing Your WordPress Hosting

Launching a WordPress website is only the start. Regular maintenance helps keep your website secure, reliable, and running smoothly. Many hosting providers include tools that simplify routine tasks, but it still helps to understand how they work.

Common tasks include migrating websites, installing SSL certificates, updating PHP, managing domains, restoring backups, and monitoring uptime. Learning these skills will help you solve problems more quickly and get more from your hosting provider.

Whether you’re looking after one website or several client projects, a regular maintenance routine can reduce downtime and keep your websites in good shape.

The articles below cover the most common hosting management tasks and show you how to handle them with confidence.

• When Your WordPress Website Has Outgrown its Hosting

  How do you know when a hosting change is needed? Here are a few things to consider.

• Hosting Your Client’s WordPress Website

  Learn how to avoid common hosting mistakes when hosting WordPress sites for clients.

• Understanding Your Web Host

  Your host may not cover all your needs. Take these steps to ensure your website runs smoothly.

• Building a Performant WordPress Website

  Learn how to boost performance with better hosting, lighter themes, and smart optimzation strategies.

• What To Know About Your Client’s WordPress Website

  We cover what to check first, including themes, plugins, custom code, hosting, and unused tools.

• Add an SSL Certificate to Your WordPress Website

  A quick SSL certificate setup can mean big benefits for your site and visitors.

• WordPress Website Email Issues

  Learn how to test sending, check logs, change the from address, set up SMTP, or use a mail delivery service.

Final Verdict: Which WordPress Host Should You Choose?

WordPress.com is our best overall choice because it works for a broad range of WordPress projects while handling much of the hosting management. It is suitable for blogs, business websites, larger publications, and WooCommerce stores, with access to plugins, themes, staging, backups, security, caching, and development tools on suitable plans.

Kinsta is the better choice for users who want premium managed WordPress hosting and are willing to pay more for it. Cloudways suits established bloggers and publications that want greater control over server resources. Pressable is our choice for developers because its managed platform includes a strong set of WordPress development tools.

SiteGround makes sense for agencies managing several client websites, particularly when collaboration and site management tools are needed. And Bluehost remains the budget choice for smaller WordPress sites where keeping the hosting bill low matters more than having advanced management tools.

No host wins every category because WordPress websites have different requirements. The best option is the provider that has enough performance and resources for the site, includes the tools that will actually be used, and remains affordable after introductory pricing ends. For most WordPress users looking for a balance across those areas, WordPress.com gets our overall recommendation.

WordPress Hosting FAQs

WordPress hosting can look more complicated than it needs to be. Hosting companies use different plan names, prices, limits, and technical terms, even when the services are similar. These answers cover some of the most common questions about choosing and using WordPress hosting.

• What is the best hosting for WordPress?
  WordPress.com is our best overall WordPress host because it combines managed hosting with good performance, security, backups, CDN access, and WordPress support. Kinsta is our choice for managed hosting, Cloudways for bloggers, Pressable for developers, SiteGround for agencies, and Bluehost for smaller budgets.
• How much should WordPress hosting cost?
  Basic WordPress hosting can cost only a few dollars per month, while managed hosting may cost $20 to $50 per month or more. Larger sites and stores can cost considerably more. Always check the regular renewal price because introductory rates can make the first term look much cheaper.
• Do I need managed WordPress hosting?
  No. Smaller blogs, portfolios, and business sites can run well on lower-cost hosting. Managed WordPress hosting becomes more useful for busy sites, stores, and businesses that benefit from automatic backups, security, caching, staging, and WordPress-focused support.
• Can I change WordPress hosts later?
  Yes. WordPress sites can be moved between hosting providers. Many hosts provide migration tools or will move the site for you. Keep the old hosting active until the new site has been checked and the domain is pointing to the new server.
• Does better hosting make WordPress faster?
  Better hosting can improve WordPress performance by providing faster servers, more resources, caching, and CDN access. But hosting cannot fix every problem. Large images, heavy themes, slow plugins, external scripts, and database problems can still make a site slow.
• Is WordPress hosting different from regular web hosting?
  WordPress hosting is web hosting set up with WordPress in mind. It may include WordPress updates, caching, backups, security, staging, WP-CLI, and specialist support. WordPress can also run on regular hosting as long as the server meets its requirements.
• Do I need separate hosting for WooCommerce?
  No. WooCommerce runs on WordPress and does not require a separate type of hosting. But stores can need more server resources because carts, checkout pages, customer accounts, orders, and stock changes create more database activity than a typical WordPress site.
• How much traffic can WordPress hosting handle?
  There is no single number. A cached blog and a busy WooCommerce store can use very different resources even with the same number of visitors. Check the host’s traffic, bandwidth, storage, CPU, memory, and other resource limits before choosing a plan.

Read more articles by Paul Andrew

The post The Best WordPress Hosting in 2026 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.

When front-end developers and UX engineers are tasked with building a web interface that feels tactile, bouncy, or destructive, the industry instinct is almost always the same: reach for a physics engine. Frameworks like Matter.js, Cannon.js, or custom WebGL solutions have become the gold standard for creating immersive, gamified websites.

When our team at Isadora Agency set out to build Stress Release, a digital stress-relief squeeze toy designed to let burnt-out creatives smash, stretch, and distort animated UI characters, we initially explored that route. The goal was to build a highly tactile experience where every click yielded a satisfying, squishy reaction.

But as we began prototyping, we realized something crucial: Physics engines produce plausible motion, but in our case, the animators produced intentional motion.

We didn’t need our characters to act like realistic rubber balls bouncing uncontrollably around a canvas. We needed them to react in very specific, highly designed ways. So, we scrapped the physics engine entirely.

In this article, we’ll break down how we built a real-time stress-relief squeeze toy without a single line of WebGL or Matter.js, relying entirely on programmatic Lottie state controls, DOM manipulation, and distance-based math.

The Design Requirements: Intentional Motion

Our core requirement for Stress Release was absolute deterministic control. Our animators had crafted bespoke .json Lottie files that required exact, frame-by-frame sequencing.

For instance, our ‘mega squeeze’ reaction required a precise 181-frame build-up followed by a specific release sequence. To honor this design, we needed an architecture that wouldn’t overwrite the animators’ crafted keyframes with algorithmic approximations.

The tighter the click-feedback loop (click → squish → score), the more you need deterministic frame control. By choosing programmatic state control using Lottie’s native API, we ensured that the interaction layer acted as a flawless trigger for the animation layer.

Creating Tactile Feedback: Mapping DOM Elements To Lottie States

Because our architecture relied on Lottie and the standard DOM, rendering is handled directly by the Lottie runtime, which plays the JSON-based vector animations as SVGs internally. We selected elements directly by ID and CSS class, driving their behavior using a combination of Lottie animation segments, CSS transforms, and click-event math.

To achieve a deeply satisfying “tactile feel” upon hitting a character, we used radial input mapping. The first step was converting the click from page coordinates into the character’s local coordinate space.

Every click was measured against the character’s center point, then translated into score, feedback intensity, and explosion placement:

// Character's center point in its own coordinate space
var x_center = parseFloat($("#playChar").width()  / 2);
var y_center = parseFloat($("#playChar").height() / 2);

// Click position relative to the character's top-left corner
var offset = $("#playChar").offset(); // document-relative position
var X = parseFloat(e.pageX - offset.left);
var Y = parseFloat(e.pageY - offset.top);

// Vector from center to click point
var a = parseFloat(X - x_center);
var b = parseFloat(Y - y_center);

Then we calculate the straight-line distance from the center of the click using the Pythagorean theorem:

var distance = Math.hypot(a, b);

That single number drives everything: the score, the feedback intensity, and where the explosion animation appears:

// Distance zones map to point rewards
if      (distance < 10)  givePts = 100; // bullseye
else if (distance < 40)  givePts = getRndInteger(70, 90);
else if (distance < 70)  givePts = getRndInteger(40, 70);
else if (distance < 100) givePts = getRndInteger(20, 40);
else if (distance < 120) givePts = getRndInteger(10, 20);
else if (distance < 145) givePts = getRndInteger(1,  10);
else givePts = 0; // miss

// Explosion Lottie repositioned to the exact click point
var shiftPosition = window.innerWidth < 1023 ? -20 : 200;
$("#explosionChar").css({
  "margin-left": a + shiftPosition + "px",
  "margin-top":  b + shiftPosition + "px",
});

// Fire the squish animation instantly
explosion.goToAndPlay(0);

The result is a concentric zone system — a perfect circle of scoring rings around the character’s center, similar to a dartboard. The visual complexity of the Lottie SVG is completely irrelevant to hit detection; the hitbox is always a clean circle. Critically, the explosion Lottie animation is repositioned to (a, b) — the same vector used for scoring, so it always appears exactly where the player clicked. This spatial accuracy creates the tactile “I hit that” sensation entirely through math and DOM positioning.

Interaction Handling: Controlling The Narrative

Because the experience used DOM-managed SVG elements, desktop clicks and mobile taps could be handled directly through native event listeners. This avoided extra raycasting or coordinate remapping layers, while keeping the interaction model aligned with how the animations were rendered.

Since the game requires a visual reaction at a specific point, Lottie handles all the squish and bounce feelings internally through its animation curves. Each character has a defined set of animation sections (idle loops, reaction frames, and end states) stored as frame ranges. When a click lands, we jump directly to the exact segment that matches the current game state:

// Animation sections defined as frame ranges per character
const play_segments = [{
  charId: 0,
  sections: {
    idle:     [0,  40],   // looping idle state
    squeeze1: [41, 80],   // light reaction
    squeeze2: [81, 120],  // medium reaction
    squeeze3: [121, 160], // heavy reaction
  },
  playOrder: ["squeeze1", "squeeze2", "squeeze3"],
  endAnimation: [161, 200]
}];

On every click, we advance through the play order and fire the next segment:

function stepAnim() {
  let p         = play_segments[0];
  let i         = p["playOrder"][curr_order_play];
  let playNow   = p["sections"][i];

  playChar.stop();                    // halt current segment immediately
  playChar.loop = false;              // no looping - play once and stop
  playChar.playSegments(playNow, true); // jump to exact frames, force immediately

  curr_order_play++;
  canPlayAnim = 0;                    // lock out further clicks mid-animation

  if (curr_order_play > p["playOrder"].length - 1) {
    curr_order_play = 0;              // cycle back to start of sequence
  }
}

When the segment completes, control returns to the idle loop:

playChar.onComplete = function() {
  canPlayAnim = 1;          // unlock clicks again
  if (!playEnd) playIdleState();
};

function playIdleState() {
  playChar.playSegments([0, 40], true); // return to idle loop
  playChar.loop = true;
}

And for the mega squeeze build-up, the bar loops on a specific frame range until triggered:

// Loop the "ready to release" frames until player activates
indikL.loop = true;
indikL.playSegments([181, 302], true);

// On activation - play the release sequence once
indikL.loop = false;
indikL.playSegments([96, 396], true);
indikL.goToAndStop(0, true); // hard reset after completion

The Responsive Benefit Of DOM Elements

Another major factor in our architectural decision was responsive behavior. Because we built Stress Release in the DOM, we bypassed the complexities of scaling bounding boxes and collision vectors across different devices.

We handled responsive resizing entirely through CSS variables. By recalculating CSS custom properties on every resize, the layout simply reacts to the updated variables, and the Lottie SVGs scale naturally inside their containers without losing their state:

const appHeight = () => {
  const doc = document.documentElement;
  doc.style.setProperty("--doc-height", `${window.innerHeight}px`);
  doc.style.setProperty("--doc-width", `${doc.clientWidth}px`);
};
window.addEventListener("resize", appHeight);
appHeight(); // run immediately on init

Mobile Performance Optimization: The Cost Of Lottie

While this architecture gave us total control over the art direction, it introduced a different challenge: file size.

Lottie JSON files can be heavy. We had 21 different character animations, plus multiple explosion variants that all needed to load. To ensure the experience remained fluid — especially on mobile devices — we implemented a few aggressive optimization strategies:

• Connection monitoring
  We tracked initial asset load time using performance.now() to detect slow connections and flag when load times exceeded 5 seconds.
• Sequential asset loading
  Rather than initialising all 21 character animations simultaneously, we load them in pairs using await, advancing only when each pair completes. This prevents a burst of simultaneous network requests and render work from blocking the browser on low-end devices.
• Aggressive memory management
  Instead of keeping our heavy explosion animations in memory, we destroy and recreate them on the fly. This trades a tiny instantiation cost for a much lower idle memory footprint.
• Dynamic quality reduction
  Quality reduction is a single API call applied immediately after each shelf character loads. The key is applying different quality levels depending on the character’s role in the scene:

// Shelf screen - 21 animations playing simultaneously
shelf = lottie.loadAnimation({
  container: document.getElementById("charShelf" + i),
  renderer: "svg",
  loop: true,
  autoplay: true,
  path: "assets/shelf/" + shelfFolders[i] + "/" + shelfFolders[i] + ".json",
});
lottie.setQuality(0.5); // 50% quality - reduces interpolation calculations
shelf.setSpeed(0.6);    // 60% speed - fewer frame calculations per second

// Play screen - single focused character
playChar = lottie.loadAnimation({
  container: document.getElementById("playChar"),
  renderer: "svg",
  loop: true,
  autoplay: true,
  path: chosenChar.url,
});
lottie.setQuality(1); // full quality - only one animation at a time

Conclusion: Choosing The Right Tech For The Design

When determining the stack for a gamified web experience, it is critical to let the design requirements dictate the technology.

Because our interactions required bespoke, highly controlled visual reactions, we opted for programmatic state control over emergent simulation. This decision empowered the animators to dictate the exact feel of the experience, leaving the code to do what it does best: listen, calculate, and trigger.

By mapping Lottie’s native timeline capabilities to the DOM, you can deliver incredibly rich, tactile user experiences while maintaining absolute control over the art direction.

Further Resources

Want to try implementing this yourself, or see exactly how it feels in the browser? Check out these resources:

• Play with the code.
  We have prepared a simplified demo example on CodePen demonstrating a character reacting to a click using playSegments().
• See the final product.
  Check out the live Stress Release site to see all 21 characters and the optimization strategies in action.
• Read the docs.
  Explore the official Lottie Web documentation to learn more about the player controls we utilized. Specifically, explore loadAnimation(), playSegments(), setSpeed(), and setQuality() — the four methods that power the entire interaction layer described in this article.

(yk)

The post Building Tactile UX: Honoring Intentional Design With Lottie appeared first on The NOKIA Blog.

The WordPress project is slowly but surely inching toward responsive block settings. Version 6.9 introduced the Block Visibility feature, allowing you to temporarily disable a block without deleting it from a post. WordPress 7.0 took it a step further by adding options to hide a block based on device.

Perhaps it’s a niche feature. But it’s also quite handy for targeting mobile or desktop users with specific blocks. And it’s also a gateway to more responsive controls landing in WordPress 7.1.

Today’s tip will show you how easy it is to show or hide a block based on a user’s device. Here we go!

Sample Project: Simplify a Hero Area for Mobile Users

Here’s a common scenario: Your website has a large hero area, complete with a high-resolution image, text, and a call to action (CTA). It looks great on a desktop device but is clunky on a phone. The image is too big, and there’s too much text for users to digest. What to do?

The responsive Block Visibility controls will make this a piece of cake. We’ll create two hero areas – one for desktop and another optimized for mobile. The result will be a better user experience for everyone.

Step 1: Create Desktop and Mobile Hero Areas

The first step is to create the two hero areas for our page. We’ll grab one from the WordPress Block Pattern library and see what we can do with it.

Our desktop hero area is beautiful on the big screen! It should also work well on tablets, such as an iPad. However, it may be overwhelming for mobile users.

Let’s simplify. We duplicated the desktop hero and made a few changes:

• We replaced the image with a cropped version that is optimized for smaller screens.
• We centered the text and CTA.
• We replaced the three columns of text with one, shorter passage.
• Finally, we tightened up the spacing to reduce scrolling.

The mobile hero offers the same immersive look without the extra bulk.

Step 2: Assign Hero Areas to Their Respective Devices

As of now, our page has two hero areas, each contained within a Group block. The next step is to set one of them to display on desktop/tablet devices, and the other on mobile. We’ll use the Block Visibility feature to make it happen.

Desktop/Tablet Devices:

• Click on the Desktop Hero block we created.
• Click on the Options menu (⋮) and select Hide Block.
• Choose the Hide on Mobile option.
• Click the Apply button and save the page.

Mobile Devices:

• Click on the Mobile Hero block we created.
• Click on the Options menu (⋮) and select Hide Block.
• We’ll choose two options this time: Hide on Desktop, Hide on Tablet
• Click the Apply button and save the page.

You may notice that the mobile hero no longer displays on the Block Editor canvas. That’s the desired result, as it won’t be in the way when working in Desktop preview mode.

Switch to Mobile preview mode, and you’ll see the opposite effect. The desktop hero is hidden, allowing the mobile version to take over. You can edit these blocks when in the appropriate preview mode.

Note that you can also view and edit these blocks using the Document Overview (List View) feature (Shift+Alt+O). Select the block, click on the Options menu (⋮), and select Show from the menu. You can hide it again once you’re finished editing.

Oh, and be sure to test on different devices! It’s not enough to shrink your desktop’s browser window. You can use your browser’s dev tools to emulate a mobile device if you don’t have one handy.

Use Different WordPress Blocks on Different Devices

It’s often the little extras that make the biggest difference. Targeting different devices via the Block Visibility feature is a prime example. Its release didn’t draw much fanfare. However, it makes WordPress more flexible for designers.

Before WordPress 7.0, we’d have to work around this limitation. That could mean installing a specialized plugin or writing custom CSS rules in a theme. Now, we’re only a few clicks away from choosing which blocks display on a given device.

The feature saves us time, improves the user experience, and won’t hog server resources. Most of all, it’s a sign of things to come for WordPress.

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 to Hide WordPress Blocks Based on Device 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.

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.

There is one valuable thing that WordPress blocks left behind, however: code commenting. They’re common when building custom PHP templates and writing CSS. We use them to provide context for what a code snippet does or why it was implemented.

There are times when that extra context is useful in the Block Editor. For example, you might want to share information about a block with clients or colleagues. Perhaps it’s locked or requires a specific setting to display correctly. Sometimes we need to remind ourselves why we did something.

That’s where the WordPress Notes feature comes in handy. Use it to add notes to specific blocks and even keep a threaded conversation. It’s another way to improve your editorial workflow and provide a quick reference for users.

Here’s a look at how the feature works. We’ll show you how to add and retrieve notes to any block on your site. In addition, we’ll share a few tips and hidden gems worth knowing about.

Sample Project: Let’s Collaborate With Blocks

The WordPress Notes feature is part of the larger Gutenberg Collaboration phase. At the very least, it’s a way to add reminders or have an asynchronous discussion with other site users. That second part is what we’ll focus on here.

We’ll simulate a discussion of colleagues regarding a Group block. We promise it will be quick and easy!

Step 1: Choose a Block

The first step is to open a page or post in the Block Editor and select a block. We’ll choose a Group block at the top of the page. We want to discuss its styling with a colleague.

Step 2: Add a Note

Now that we know which block we want to discuss, it’s time to add a note.

1. Click on the Options menu (⋮) and select Add note.
2. A note dialog appears on the right side of the screen. We can add our note in this space.
3. Click the Add note button to save the note.

For reference, we asked if our Group block should have a background color to stand out from the rest of the content.

Next, we’ll wait for our colleague to reply to our note. When they click the block in question, they’ll see a user avatar that indicates a note is available.

Step 3: Our Colleague Replies

Here’s a handy feature: WordPress will send you an email when someone replies to your note (it’s based on the existing comment system). As such, we don’t have to keep checking our page for the latest news.

Our colleague replied to our note and acted on our design suggestion. When we visit the page, we notice that their avatar has also been added to the block’s note notification.

Step 4: Reply and Resolve

We love what our colleague did to dress up the Group block on the page. The last steps are to reply and mark the note as resolved.

To resolve the note, we’ll click the checkmark on the upper right of the dialog. Keep in mind that the note will stay in place unless we manually delete it from the block.

An Easy Way To Collaborate in WordPress

The WordPress Notes feature is a great way to relay information to others or remind yourself of something important. And it will continue to be enhanced as more collaborative features are added to the content management system (CMS).

Even better, you don’t need a plugin to get started – it’s already built into WordPress. That being the case, there are ways to customize the experience. We recommend checking out this guide to tapping into that potential.

Whether you’re part of a team or working solo, give WordPress Notes a try. You may wonder how you lived without it!

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 Quick Tip: How To Use WordPress Block Notes 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.