DEV Community: Artclick

How the JavaScript Runtime Schedules Callbacks: A Look at the Event Loop

Artclick — Mon, 24 Aug 2026 11:00:22 +0000

Why doesn't your tab freeze when you call an API?

Here's a question that trips up a lot of people, even after they've been writing JavaScript for a while: if JS can only run one line of code at a time, what actually happens while a fetch() request is out there waiting for a response? Does the browser just sit there, frozen, unable to scroll or click or repaint the screen, until the response comes back?

It doesn't. And once you understand why, a whole pile of confusing behavior in JavaScript stops feeling random and starts feeling predictable. This is that explanation, minus the hand-waving.

The one-thread rule

JavaScript runs on a single thread. One thread means one call stack, and one call stack means the engine can only execute one function at a time. There's no built-in way for your JS code to spin up a second thread and run two functions simultaneously, not the way you might in a language with native threading.

If that were the whole story, any slow operation (a network call, a big file read, a multi-second timer) would lock up everything else. No animations, no clicks registering, no scrolling. Anyone who's accidentally written a giant synchronous loop has felt this firsthand. The tab genuinely freezes, because the one thread is busy and nothing else gets a turn until it's done.

So how does fetch() avoid doing that? It doesn't run on your JS thread at all. The browser hands it off.

Handing work off to the browser

The JavaScript engine itself (V8 in Chrome, SpiderMonkey in Firefox, whichever one your browser uses) is genuinely single threaded. But your JS code isn't running in a vacuum. It's running inside a browser, and the browser gives you a bunch of APIs that live outside that single thread: timers, the DOM, fetch, geolocation, and so on. These are usually called the Web APIs, and they're implemented by the browser itself, often backed by their own threads or OS-level mechanisms.

So when you call setTimeout(fn, 3000), here's what's actually happening:

Your code calls setTimeout. The JS engine registers this call, hands the timer off to the browser, and immediately moves on to the next line. It does not pause and wait three seconds.
The browser starts a countdown somewhere outside your JS thread.
Your script keeps running, the page stays responsive, clicks still register.
Three seconds later, the browser is done timing. It doesn't just barge into your JS thread and run the callback whenever it feels like it. Instead, it places the callback into a queue and waits.
Only once your JS thread is completely free does that callback actually get pulled off the queue and run.

That last step, the constant checking of "is the thread free yet, and if so, what's waiting," is the event loop. It's not a separate clever piece of magic bolted onto JS. It's closer to a simple, boring loop that just keeps asking the same question over and over: anything on the stack right now? No? Then grab the next thing waiting and run it.

Two different queues, not one

This is the part that catches people off guard, because most explanations gloss over it or mention it too late. There isn't just one queue of "stuff waiting to run." There are (at minimum) two, and they get treated very differently.

The macrotask queue (often just called the callback queue or task queue) holds things like setTimeout and setInterval callbacks, DOM events, and I/O completions.

The microtask queue holds Promise callbacks (.then, .catch, .finally), queueMicrotask(), and a few other spec-defined bits like MutationObserver callbacks.

The rule that matters: after each macrotask finishes, and before the engine grabs the next macrotask, it fully drains the microtask queue. Every single microtask, including any new ones that got added while draining, runs before the event loop even glances at the macrotask queue again.

This is why Promises tend to "cut in line" ahead of timers, even when the timer looks like it should win.

Tracing through an actual example

Theory is fine, but this stuff really clicks once you predict an output and then check yourself. Take this:

console.log('start');

setTimeout(() => {
  console.log('timeout');
}, 0);

Promise.resolve().then(() => {
  console.log('promise');
});

console.log('end');

Before reading further, guess the order these four lines print in.

Here's what actually happens, step by step:

console.log('start') runs immediately. It's synchronous, so there's no queue involved at all, it just executes right where it sits. Prints start.
setTimeout(..., 0) gets registered with the browser. Even with a delay of zero, the callback doesn't run now, it goes to the browser's timer system first and its callback lands in the macrotask queue once the (essentially instant) delay is up.
Promise.resolve().then(...) schedules its callback into the microtask queue. Also not immediate.
console.log('end') runs immediately, same as start. Prints end.
Now the call stack is finally empty, and the engine looks for work. It checks the microtask queue first, finds the Promise callback, and runs it. Prints promise.
Only after the microtask queue is completely empty does the engine move to the macrotask queue and run the timeout callback. Prints timeout.

Final output: start, end, promise, timeout.

The takeaway that actually matters for writing and debugging real code: a setTimeout with a delay of 0 does not mean "run this next." It means "run this once the current call stack is clear and every pending microtask has been handled." Those are very different guarantees, and mixing them up is a common source of bugs in code that assumes strict execution order.

Why this matters for callbacks and async/await

Before Promises were standard, this same non-blocking model was handled entirely with callbacks: pass a function in, get it called back later when the work is done. That pattern is still everywhere (event listeners, fs.readFile in Node, older APIs), but it has a well known failure mode once you need several async steps to happen in sequence, each depending on the last one's result. You end up nesting callback inside callback inside callback, each one indented a bit further right than the last. People call this callback hell, or the pyramid of doom, because that's genuinely what it looks like on screen, and it makes error handling and control flow painful to follow.

Promises, and later async/await, don't change anything about the event loop itself. They're built on top of it. async/await is really just syntax that makes microtask-queue based code (Promises under the hood) read like straight-line synchronous code, which is a big part of why it replaced deeply nested callbacks for most sequential async logic.

It's not just a browser thing

Node.js runs on this exact same model. There's no browser tab involved, but the idea is identical: a single JS thread, an event loop, and a set of APIs (this time provided by libuv rather than a browser) that handle the actual I/O work like reading a file or querying a database off the main thread. Every incoming HTTP request, every database call, every file read gets treated as an event that eventually lands in a queue and gets handled once the thread is free.

This is exactly why a single Node process can handle thousands of concurrent connections without falling over. It's not because it's secretly multithreaded. It's because none of those connections are sitting there blocking the one thread while they wait on I/O. The moment a request needs to wait on something slow, it gets handed off, and the thread moves on to the next thing that's actually ready to run.

The short version

JS has one thread and one call stack. Only one thing executes at a time.
Slow operations (timers, network calls, file I/O) get delegated to the browser or to Node's underlying C++ layer, not run on your JS thread.
When that work finishes, its callback doesn't run instantly, it gets placed in a queue.
The event loop's whole job is checking whether the call stack is empty, and if so, pulling the next thing off a queue to run.
There are two queues that matter most: microtasks (Promises) and macrotasks (timers, events, I/O). Microtasks always get fully drained before the next macrotask runs.
setTimeout(fn, 0) means "as soon as possible after everything currently queued," not "immediately."

Once this model is actually in your head, a lot of things that used to feel like arbitrary JavaScript quirks (why your console.log after a fetch() runs before the data arrives, why a zero-delay timeout still runs last, why Node scales the way it does) stop being quirks and start being predictable consequences of a pretty simple system.

We're ArtClick, a web development agency based in Kyoto. We build company websites, WordPress sites, and custom systems — with a focus on sites that are fast, well-designed, and easy to maintain long-term. Learn more at artclickdev.

10 CSS Tips and Tricks for Better Responsive Web Design

Artclick — Thu, 20 Aug 2026 10:38:53 +0000

Modern CSS gives you tools that make most of your old media queries unnecessary. Here are ten practical techniques worth adding to your toolkit in 2026.

Responsive design used to mean picking a handful of breakpoints, 768px, 1024px, maybe 1440px, and writing a media query for each one. That approach still works, but it's not really how modern CSS wants you to think anymore. A lot of the layout and typography work that used to require careful breakpoint math can now just... respond on its own, because the properties themselves understand context: viewport size, container size, even the user's own OS-level preferences.

Here are ten techniques I'd consider close to essential for anyone building responsive interfaces today. Some of these will be familiar, some are newer than you'd expect.

1. Fluid Typography

Fixed font sizes don't hold up well across different screen sizes. Something that reads comfortably on a laptop can feel oversized on a phone, or too small on an ultrawide monitor. Fluid typography lets text scale with the viewport instead of jumping between fixed values at each breakpoint.

rem is relative to the root font size:

h1 {
  font-size: 2rem;
}

If the root size is 16px, that 2rem works out to 32px, consistent, but static. It doesn't know or care how wide the screen is.

vw is relative to the viewport width instead:

h1 {
  font-size: 5vw;
}

This scales smoothly as the browser resizes, but on its own it's risky. On a small phone, 5vw might shrink your heading down to something barely legible. On a huge monitor, the same rule can blow it up to a size that looks absurd.

clamp() is the fix, and it's the one you actually want to reach for in production. It takes a minimum, a flexible preferred value, and a maximum:

h1 {
  font-size: clamp(1.5rem, 4vw, 3rem);
}

Now the heading grows smoothly with the viewport, but it will never shrink below 1.5rem or grow past 3rem. One line replaces what used to take three or four separate media query overrides.

2. Fluid Spacing, Not Just Fluid Type

Once you've got clamp() in your toolkit, don't stop at font sizes. Padding, margins, and gaps benefit from the exact same treatment, and it's an easy thing to overlook since most tutorials only demonstrate clamp() on headlines.

.card {
  padding: clamp(1rem, 3vw, 2.5rem);
}

.section {
  margin-block: clamp(2rem, 6vw, 6rem);
}

Without this, it's common to see a layout where the text scales beautifully but the whitespace around it stays exactly the same at every screen size, which ends up looking cramped on large screens and oddly spacious on small ones. Scaling your spacing alongside your type keeps the overall proportions of a layout feeling consistent, not just the words on the page.

3. Intrinsic Grids That Don't Need Breakpoints At All

A huge chunk of "responsive design" work used to be writing media queries just to change how many columns a card grid has. CSS Grid's auto-fit and minmax() combination removes that need almost entirely:

.grid {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(240px, 1fr));
  gap: 1.5rem;
}

Read that as: fit as many columns as will comfortably hold at least 240px each, and let them share the remaining space evenly. Resize the browser and the grid reflows on its own, four columns, then three, then two, then one, without a single @media block. This is usually called intrinsic or content-aware layout, and once you've built a grid this way, going back to hardcoded breakpoint columns feels like doing more work for a worse result.

4. Container Queries

Media queries respond to the viewport. But a component doesn't always know how much space it actually has, a card might be full-width in one layout and squeezed into a narrow sidebar in another, and a viewport-based media query has no way to tell the difference.

Container queries fix this by letting an element respond to the size of its actual container, not the screen:

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

.card {
  display: flex;
  flex-direction: column;
}

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

Here, the card stacks vertically by default and switches to a horizontal layout once its container, not the viewport, is at least 400px wide. Drop that same card into a wide main content area or a narrow sidebar on the exact same page, and it adapts correctly in both places. This is the piece that finally makes truly reusable, drop-anywhere components possible, which viewport media queries were never really able to deliver.

5. The `aspect-ratio` Property

Responsive images and video embeds used to rely on a padding-percentage hack, wrapping the media in a container with padding-top set to some calculated percentage just to reserve the right amount of space before the media loaded. It worked, but nobody found it intuitive, and it's not something you'd guess how to write from scratch.

.video-embed {
  aspect-ratio: 16 / 9;
  width: 100%;
}

That's the whole thing now. The browser reserves the correct proportional space immediately, which also means no layout shift while an image or iframe is still loading, a detail that matters for Core Web Vitals as much as it does for how polished a page feels while it's rendering.

6. `min()` and `max()` for Flexible Constraints

clamp() gets most of the attention, but its two simpler siblings are worth knowing on their own. min() picks the smallest of the values you give it, max() picks the largest.

A common pattern: let content take up most of the width on small screens, but stop it from stretching too wide on large ones.

.container {
  width: min(90%, 1200px);
}

On a phone, 90% is the smaller value, so the container hugs the screen with a bit of breathing room on either side. On a wide desktop monitor, 1200px becomes the smaller value, so the container caps out there instead of stretching edge to edge. One line, no media query, and it reads almost like plain English once you're used to it.

7. Dynamic Viewport Units: `dvh`, `svh`, `lvh`

If you've ever set height: 100vh on a mobile site and watched content get cut off behind the browser's address bar, this one's for you. The classic vh unit is based on the largest possible viewport, ignoring the fact that mobile browser chrome, the address bar, the bottom toolbar, expands and collapses as someone scrolls, changing how much space is actually visible.

Newer units account for this directly:

.hero {
  min-height: 100dvh;
}

dvh stands for dynamic viewport height, and it adjusts live as the browser's UI shows or hides. There's also svh (small viewport height, calculated assuming the browser UI is fully expanded) and lvh (large viewport height, assuming it's fully collapsed), for cases where you specifically want one behavior or the other instead of the dynamically adjusting version. For most full-height hero sections and mobile layouts, dvh is the one you want, and switching to it fixes a genuinely common and annoying mobile bug in one word.

8. Logical Properties Instead of Physical Ones

This one's less about screen size and more about a different axis of "responsive", to writing direction and layout context, but it belongs on this list because it prevents a specific category of layout bug that only shows up once you're supporting more than one language or more than one layout direction.

Instead of physical directions like margin-left or padding-right, logical properties describe position relative to the flow of the content:

.card {
  margin-inline-start: 1rem;
  padding-block: 1.5rem;
}

margin-inline-start means "the start edge in the inline direction", which is the left in English, but automatically becomes the right in Arabic or Hebrew, without you writing a single RTL-specific override. padding-block covers top and bottom together as one shorthand. If there's any chance your site ever ships in a right-to-left language, or you just want spacing rules that are correct by construction rather than by accident, this is worth adopting as your default habit rather than something you retrofit later.

9. Responsive Images With `srcset` and `sizes`

CSS handles how big an image displays, but it can't reduce how many bytes get downloaded in the first place. That's what srcset and sizes are for, letting the browser choose the most appropriately sized image file for the current viewport, instead of shipping one large image to every device regardless of screen size:

<img
  src="hero-800.jpg"
  srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1600.jpg 1600w"
  sizes="(max-width: 600px) 100vw, 50vw"
  alt="A wide shot of the product lineup"
/>

srcset lists the available image files along with their actual widths. sizes tells the browser how much space the image will occupy at different viewport widths, and the browser combines that with the device's pixel density to pick the smallest file that will still look sharp. A phone downloads the 400w version instead of the same 1600w file a desktop gets, which is a meaningful difference in load time on a mobile connection, and it's handled declaratively, no JavaScript resizing or lazy-loading library required for this part.

10. Respecting User Preferences, Not Just Screen Size

Responsive design started out being entirely about screen dimensions, but modern CSS can respond to the person on the other end too, not just their device. Two media features are worth building in as defaults rather than afterthoughts.

prefers-color-scheme lets you offer a dark theme automatically, based on the operating system setting the user already chose, rather than making them find a toggle on your site:

:root {
  color-scheme: light dark;
}

body {
  background: #ffffff;
  color: #111827;
}

@media (prefers-color-scheme: dark) {
  body {
    background: #0f172a;
    color: #e5e7eb;
  }
}

prefers-reduced-motion respects a genuinely important accessibility setting for people with vestibular disorders who can get real physical discomfort from large animated motion:

.hero-animation {
  animation: slide-in 0.6s ease-out;
}

@media (prefers-reduced-motion: reduce) {
  .hero-animation {
    animation: none;
  }
}

Neither of these has anything to do with screen width, but both are about the same underlying idea every technique on this list shares: a layout that adapts to the actual conditions it's being viewed under, rather than assuming one fixed context for every visitor.

Putting it together

None of these ten replace each other, and in a real project they mostly stack. A card grid might use auto-fit/minmax() for its columns, clamp() for its internal padding, aspect-ratio on its thumbnail images, and a container query to switch its internal layout once it's dropped into a narrower sidebar, all at the same time, on the same component. That's really the shift modern CSS represents: less time spent enumerating every breakpoint by hand, more time spent describing the actual relationship you want, and letting the browser handle the arithmetic.

Stop Compiling Your Nested CSS. The Browser Does It Now

Artclick — Wed, 19 Aug 2026 08:11:36 +0000

For years, nesting selectors inside each other was one of the main reasons teams reached for Sass in the first place. You'd write .card { .title { ... } }, run it through a compiler, and get flat CSS out the other end. It was one of those "why doesn't the browser just do this" features, and honestly, it's a little wild that it took this long. But native CSS nesting is here now, it's Baseline in 2026, meaning it works across Chrome, Edge, Firefox, and Safari without a build step, and it's worth actually learning properly instead of just copy-pasting Sass habits into it and hoping for the best.

That second part matters more than people expect. Native nesting looks almost identical to Sass nesting on the surface, but the parsing rules underneath are stricter, and a couple of the differences will genuinely trip you up the first time you hit them. This guide walks through the syntax, the & selector, nesting at-rules like @media, and the handful of gotchas worth knowing before you delete your Sass dependency.

Browser support, briefly

Native CSS nesting is supported by Chrome, Edge, Firefox, and Safari as of 2026, and it's considered Baseline Widely Available. The one thing worth knowing is that there were two versions of the spec: an early, stricter one that required the & symbol in more places, and a later "relaxed" version that infers it automatically in most cases. All current browser versions support the relaxed syntax, so unless you specifically need to support an old browser version, you can write nesting the way this guide shows it.

If you do need a safety net for older environments, wrap your nested rules in a feature query:

@supports (selector(&)) {
  /* nested rules go here */
}

Browsers that don't understand nesting will drop the unsupported rules entirely rather than ignoring just the nesting part, so this is worth doing if any real chunk of your audience is on an older browser. For most projects in 2026 though, you probably don't need it.

The basic syntax

Here's the simplest possible example. Instead of writing this the old, flat way:

.card {
  border-radius: 8px;
  padding: 1rem;
}

.card h2 {
  font-size: 1.25rem;
}

.card p {
  color: #4b5563;
}

You write this:

.card {
  border-radius: 8px;
  padding: 1rem;

  h2 {
    font-size: 1.25rem;
  }

  p {
    color: #4b5563;
  }
}

Both compile down to exactly the same thing. The nested h2 rule is understood as .card h2, and the nested p rule as .card p. No ampersand needed for this case, since element selectors like h2 and p are unambiguous, the browser knows you mean "an h2 inside .card," not "a property called h2."

The `&` selector, and when you actually need it

The & symbol represents the parent selector, and while it's optional in a lot of cases under the relaxed syntax, there are specific situations where you still need it.

You need it when combining with the parent to form a compound selector. If you want to target .card itself when it also has a .featured class, you can't just nest .featured on its own, that would mean .card .featured (a descendant), not .card.featured (the same element with both classes). You need the ampersand directly against it:

.card {
  border: 1px solid #e5e7eb;

  &.featured {
    border-color: #6366f1;
  }
}

You need it for pseudo-classes and pseudo-elements, though in practice most people write these with & anyway even where it's technically optional, since it reads more clearly:

.card {
  transition: box-shadow 0.2s ease;

  &:hover {
    box-shadow: 0 4px 12px rgb(0 0 0 / 0.1);
  }

  &::before {
    content: "";
    display: block;
  }
}

You need it, doubled up, for combinators like adjacent siblings. This one surprises people. If you want to select a sibling element that comes right after the current selector, you write the ampersand twice, once to represent the parent, and again as the actual sibling combinator:

.card {
  & + & {
    margin-top: 1rem;
  }
}

That compiles to .card + .card, styling a card that immediately follows another card. It looks strange the first time you see it, but it makes sense once you remember & is just standing in for the literal parent selector text, and + still needs something on both sides of it.

Nesting pseudo-classes without repeating yourself

This is the single most common real-world use case, and it's the one that alone justifies switching. Instead of writing every state of an interactive element as a separate flat rule:

button {
  background: #4338ca;
  color: white;
}

button:hover {
  background: #3730a3;
}

button:focus-visible {
  outline: 2px solid #a5b4fc;
}

button:disabled {
  background: #9ca3af;
  cursor: not-allowed;
}

You keep every state colocated with the base rule it belongs to:

button {
  background: #4338ca;
  color: white;

  &:hover {
    background: #3730a3;
  }

  &:focus-visible {
    outline: 2px solid #a5b4fc;
  }

  &:disabled {
    background: #9ca3af;
    cursor: not-allowed;
  }
}

Functionally identical output. The difference is entirely about where you have to look while editing. When every state a button can be in lives inside one block, you're a lot less likely to update the hover color and forget the focus state sitting three hundred lines further down the file.

Nesting at-rules: media queries, container queries, and more

This is where native nesting pulls ahead of what a lot of people are used to from Sass. You can nest @media, @container, @supports, and @layer directly inside a rule, which keeps responsive and conditional logic sitting right next to the property it actually affects, instead of off in a separate media query block somewhere else in the file:

.sidebar {
  width: 20rem;

  @media (max-width: 768px) {
    width: 100%;
  }

  @container (max-width: 40rem) {
    padding: 0.5rem;
  }
}

Compare that to the traditional approach, where you'd have .sidebar { width: 20rem; } in one place and @media (max-width: 768px) { .sidebar { width: 100%; } } somewhere else entirely, often much further down the stylesheet. Nesting the media query keeps the full story of "what width can this element be" in one spot. For a component with several responsive tweaks, this alone can cut a meaningful amount of back-and-forth scrolling.

Specificity: the good news

Nesting doesn't add any specificity of its own. A nested rule has exactly the same specificity as the equivalent rule written out flat. .card h2 nested inside .card calculates identically to .card h2 written on one line. This is worth knowing because it means nesting is purely a syntax convenience, it doesn't change how the cascade resolves conflicts, and you don't need to relearn specificity rules to use it safely.

That said, nesting makes it very easy to accidentally write something overly specific just by going too many levels deep:

.page {
  .content {
    .card {
      .title {
        color: #111827;
      }
    }
  }
}

That compiles to .page .content .card .title, four selectors deep, which is going to be annoying to override later even though nothing about nesting itself caused the problem, you'd have written an equally gnarly selector by hand if you'd typed it flat. The lesson isn't "nesting is dangerous," it's the same advice that applied before nesting existed: keep selectors as shallow as the actual DOM structure requires, and don't nest just because you can.

The gotcha that catches almost everyone once

Here's the one that's worth reading twice. In the relaxed syntax, a nested rule starting with an identifier that looks like a type selector is fine, h2 { } inside .card is unambiguous. But CSS rules are parsed top to bottom, declarations first, and if a nested selector could be confused with a custom property or declaration, the parser needs the & to disambiguate it.

In practice this mostly comes up with pseudo-elements and certain edge-case selectors, and the safest habit, honestly, is this: when in doubt, just add the &. It's never wrong to include it even where it's technically optional, and a lot of style guides in 2026 recommend always writing it for consistency, precisely so you're not making a judgment call about whether this particular selector needs it every time you write one. I'd rather see & p { } everywhere in a codebase than half the nested rules with & and half without, purely for the sake of not having to think about which category a given selector falls into.

A real component, built with nesting

Here's a small card component pulling everything together, base styles, a modifier, hover and focus states, a sibling gap, and a responsive tweak, all in one block instead of scattered across a stylesheet:

.card {
  display: flex;
  flex-direction: column;
  border: 1px solid #e5e7eb;
  border-radius: 12px;
  padding: 1.25rem;
  background: #ffffff;
  transition: box-shadow 0.2s ease, border-color 0.2s ease;

  &:hover {
    box-shadow: 0 8px 20px rgb(0 0 0 / 0.08);
  }

  &.featured {
    border-color: #6366f1;
  }

  & + & {
    margin-top: 1rem;
  }

  h2 {
    margin: 0 0 0.5rem;
    font-size: 1.15rem;
    color: #111827;
  }

  p {
    margin: 0;
    color: #4b5563;
    line-height: 1.5;
  }

  .tag {
    display: inline-block;
    margin-top: 0.75rem;
    padding: 0.2rem 0.6rem;
    border-radius: 999px;
    background: #eef2ff;
    color: #4338ca;
    font-size: 0.8rem;
    width: fit-content;
  }

  @media (max-width: 480px) {
    padding: 1rem;

    h2 {
      font-size: 1rem;
    }
  }
}

Every rule that has anything to do with .card lives inside that one block. Compare that to how this would've looked as six or seven separate flat rules scattered wherever they happened to get added over the life of the file, and it's easy to see why this feature alone gets people to finally drop a Sass build step they've been carrying around for a decade.

If you're migrating from Sass

The syntax is close enough that most Sass nesting will look almost identical once you drop it into native CSS, but there are a few differences worth checking for before you assume a straight copy-paste will work.

Sass lets you nest selectors that don't start with a combinator or an identifier in ways native CSS doesn't allow, and Sass's & supports some string-concatenation tricks, like &-active to produce .button-active, that native CSS doesn't support at all, the native & only works as a full selector, not as a text fragment you can glue other characters onto. Sass also compiles at build time, so it can be more forgiving about ambiguous-looking rules; the browser parses your CSS live, so it applies the stricter rules described above. Run your migrated stylesheet through the browser and actually check computed styles rather than assuming visual parity, particularly on any BEM-style modifier classes built with string concatenation.

Should you drop your preprocessor?

If your only reason for using Sass was nesting, and you're not relying on its other features, real mixins, functions, math operations that go beyond what calc() and clamp() now handle, you can probably drop it for new projects without losing much. For a big existing codebase, it's less about ripping the preprocessor out immediately and more about not reaching for &-modifier string tricks in new code going forward, so the eventual migration is smaller when you do get to it.

Either way, native nesting is worth learning properly rather than treating it as "Sass, but in the browser." The rules are close enough to bite you exactly when you're not paying attention, and different enough that it's worth the twenty minutes to actually understand where they diverge.

[Boost]

Artclick — Tue, 18 Aug 2026 05:24:35 +0000

Artclick

Aug 18

Styling dropdown menus in CSS got a whole lot better!

#css #frontend #webdev #html

10 min read

Styling dropdown menus in CSS got a whole lot better!

Artclick — Tue, 18 Aug 2026 05:21:29 +0000

For as long as most of us have been writing CSS, the <select> element has been the one form control everyone quietly gave up on. You could change its border, maybe its font, and then you hit a wall. The dropdown panel itself, the arrow icon, the checkmark next to the selected item: all of that lived deep in the browser's operating system layer, completely out of CSS's reach. If you wanted a dropdown that actually matched your design system, the "solution" was to reach for a JavaScript library like Select2 or Choices.js, throw away the real <select>, and rebuild the whole thing out of divs, complete with your own keyboard navigation, focus trapping, and screen reader support.

That's finally changing. A new CSS property called appearance: base-select lets you keep the real, native <select> element (with all its built-in accessibility and keyboard behavior) while styling every single part of it: the button, the dropdown popup, the individual options, the arrow icon, and the selected checkmark. No JavaScript. No rebuilt component. Just CSS doing what it should have been able to do years ago.

In this article we'll build a fully custom dropdown from scratch, starting with a plain <select> and ending with something that looks like it came out of a design system, using nothing but HTML and CSS.

Browser support first, because it matters here

This feature is genuinely new and not yet Baseline. As of writing, it works in Chromium-based browsers (Chrome 135+, Edge, and other Chromium forks), and support in Firefox and Safari is still catching up. Check the current numbers on caniuse.com before shipping this to production.

The good news is that this feature was designed with progressive enhancement built in. If a browser doesn't understand appearance: base-select, it just ignores the declaration and renders a normal, fully functional native <select>. Nothing breaks. Your users on unsupported browsers get the boring-but-reliable dropdown they've always had, and users on supporting browsers get the fully styled version. That's a rare and pleasant kind of "new CSS feature" to work with.

Starting point: a completely ordinary select

Before touching any CSS, here's the markup we're working with. We're building a "favorite language" picker, with a small icon next to each option:

<label for="lang-select">Pick your favorite language:</label>

<select id="lang-select">
  <button>
    <selectedcontent></selectedcontent>
  </button>

  <option value="js">
    <span class="icon">🟨</span>
    <span class="label">JavaScript</span>
  </option>
  <option value="py">
    <span class="icon">🐍</span>
    <span class="label">Python</span>
  </option>
  <option value="rs">
    <span class="icon">🦀</span>
    <span class="label">Rust</span>
  </option>
  <option value="go">
    <span class="icon">🐹</span>
    <span class="label">Go</span>
  </option>
  <option value="ts">
    <span class="icon">🔷</span>
    <span class="label">TypeScript</span>
  </option>
</select>

Two things here look unfamiliar if you haven't seen this feature before:

A <button> as the first child of <select>. This used to be invalid markup. Now, when you include it, it replaces the default closed-state button of the select with your own button element. If you skip it, the browser falls back to its default rendering for the closed state.

A <selectedcontent> element inside that button. This is a new HTML element whose whole job is to mirror whatever option is currently selected. Under the hood the browser clones the selected <option>'s content into it. This is what lets you show an icon and text in the closed select, not just plain text.

Also worth noting: options can now contain real markup. Historically, anything except plain text inside an <option> got silently stripped. Now you can put <span>, images, and other non-interactive inline content in there, and it'll actually render.

If a browser doesn't support any of this, it degrades gracefully: the button/selectedcontent structure is ignored, the option markup collapses down to its text content, and you get a normal select with "JavaScript", "Python", etc. as plain text options.

Step 1: opting in

None of the styling below works until you explicitly opt in, on both the select itself and its dropdown panel:

select,
select::picker(select) {
  appearance: base-select;
}

::picker(select) is a new pseudo-element that represents the popup panel, the part that shows when you click the select. You can opt the <select> in on its own without opting in the picker, but you can't do the reverse: the picker can only go into base-select mode if its parent select has too.

Once both are opted in, the browser strips its OS-level chrome from both pieces and renders the plainest possible version of a select. From here, it behaves like any other element you can put a border, background, or padding on.

Step 2: styling the select button

The select button is the always-visible part, the piece someone clicks to open the dropdown. This is your highest-visibility surface, so it's worth spending the most design effort here.

select {
  display: flex;
  align-items: center;
  justify-content: space-between;
  gap: 0.5rem;
  min-width: 220px;
  padding: 0.6rem 1rem;
  border: 1px solid #d0d5dd;
  border-radius: 10px;
  background: #ffffff;
  font-size: 1rem;
  cursor: pointer;
  transition: border-color 0.2s ease, box-shadow 0.2s ease;
}

select:hover {
  border-color: #98a2b3;
}

select:focus-visible {
  outline: none;
  border-color: #6366f1;
  box-shadow: 0 0 0 3px rgb(99 102 241 / 0.15);
}

Nothing exotic here, it's the same declarations you'd write for any button. That's really the headline of this whole feature: the select button stops being a special case and becomes just another styleable box.

Cleaning up what shows inside the button

Remember the icon spans inside each <option>? Because <selectedcontent> clones the entire selected option's content, the icon comes along for the ride into the closed button too. That's usually not what you want, since it can throw off the button's height and spacing. Target it directly and hide it:

selectedcontent .icon {
  display: none;
}

This only affects how the content looks inside the closed button. The icon still renders normally inside the open dropdown, because that's a separate rendering context.

Step 3: styling the picker icon (the little arrow)

That small down-facing arrow that used to be untouchable OS chrome now has its own pseudo-element: ::picker-icon.

select::picker-icon {
  color: #667085;
  transition: rotate 0.2s ease;
}

select:open::picker-icon {
  rotate: 180deg;
}

The :open pseudo-class targets the select button specifically while its picker is showing, which is exactly what you need to flip the arrow when the dropdown opens. This combination, targeting the icon and reacting to open state, used to require JavaScript toggling a class. Now it's two CSS rules.

Step 4: styling the dropdown picker itself

This is the part that used to be completely off-limits: the popup panel holding all the options. It's addressed with ::picker(select).

select::picker(select) {
  border: 1px solid #d0d5dd;
  border-radius: 10px;
  margin-top: 0.4rem;
  padding: 0.4rem;
  background: #ffffff;
  box-shadow: 0 8px 24px rgb(16 24 40 / 0.12);
}

A detail worth calling out: the picker is a genuine popover under the hood. When it opens, its contents get promoted to the browser's top layer, the same mechanism used by <dialog> and native popovers. That's why it correctly renders above everything else on the page and why it automatically closes other open popovers when it appears, without you writing any z-index hacks or click-outside handlers.

Because it's a popover, you also get transition support for free. If you want the dropdown to fade and scale in instead of just snapping open:

select::picker(select) {
  opacity: 0;
  transform: translateY(-4px) scale(0.98);
  transition: opacity 0.15s ease, transform 0.15s ease, display 0.15s allow-discrete, overlay 0.15s allow-discrete;
}

select:open::picker(select) {
  opacity: 1;
  transform: translateY(0) scale(1);
}

@starting-style {
  select:open::picker(select) {
    opacity: 0;
    transform: translateY(-4px) scale(0.98);
  }
}

The @starting-style block defines what the picker looks like the instant before it transitions in, which is necessary because it's animating from display: none, a state CSS can't normally transition from. allow-discrete is what makes animating display and overlay possible at all. This pairing looks unusual the first time you see it, but it's becoming a standard pattern anywhere popovers, dialogs, or view transitions are involved.

Step 5: styling the options

Each <option> is now a fully flexible container. It comes with display: flex applied by the browser's default base-select styles, which is convenient since our markup already has an icon span and a label span sitting side by side.

option {
  align-items: center;
  gap: 0.6rem;
  padding: 0.55rem 0.7rem;
  border-radius: 6px;
  font-size: 0.95rem;
  cursor: pointer;
}

option:hover,
option:focus {
  background: #f2f4f7;
}

option .icon {
  font-size: 1.1rem;
}

You can reach for the exact same pseudo-classes you already know: :hover, :focus, :first-of-type, :nth-of-type(odd) for zebra striping, and so on. There's no special "option styling API" to learn, it's just CSS applied to an element that finally accepts it.

Step 6: styling the selected option and its checkmark

Two more new selectors round this out. :checked targets whichever option currently matches the select's value, and ::checkmark targets the little indicator next to it inside the open dropdown.

option:checked {
  background: #eef2ff;
  font-weight: 600;
}

option::checkmark {
  order: 1;
  margin-inline-start: auto;
  color: #6366f1;
  content: "✓";
}

Setting order: 1 and pushing the checkmark to the end with an auto margin moves it from its default position at the start of the row to the end, a small flexbox trick that suddenly works here because options are flex containers. You can also replace the checkmark glyph entirely through content, or hide it altogether with display: none if your selected-state background color is enough of a signal on its own.

One accessibility note worth remembering: ::checkmark and ::picker-icon are purely visual. They're excluded from the accessibility tree, so whatever you put in their content won't be read out by screen readers. That's fine, since the underlying <select> still reports the correct selected value through normal accessibility APIs, but don't rely on a checkmark glyph alone to communicate meaning that assistive tech users would otherwise miss.

Putting it all together

Here's the complete, working example:

<label for="lang-select">Pick your favorite language:</label>

<select id="lang-select">
  <button>
    <selectedcontent></selectedcontent>
  </button>

  <option value="js">
    <span class="icon">🟨</span>
    <span class="label">JavaScript</span>
  </option>
  <option value="py">
    <span class="icon">🐍</span>
    <span class="label">Python</span>
  </option>
  <option value="rs">
    <span class="icon">🦀</span>
    <span class="label">Rust</span>
  </option>
  <option value="go">
    <span class="icon">🐹</span>
    <span class="label">Go</span>
  </option>
  <option value="ts">
    <span class="icon">🔷</span>
    <span class="label">TypeScript</span>
  </option>
</select>

select,
select::picker(select) {
  appearance: base-select;
}

select {
  display: flex;
  align-items: center;
  justify-content: space-between;
  gap: 0.5rem;
  min-width: 220px;
  padding: 0.6rem 1rem;
  border: 1px solid #d0d5dd;
  border-radius: 10px;
  background: #ffffff;
  font-size: 1rem;
  cursor: pointer;
  transition: border-color 0.2s ease, box-shadow 0.2s ease;
}

select:hover {
  border-color: #98a2b3;
}

select:focus-visible {
  outline: none;
  border-color: #6366f1;
  box-shadow: 0 0 0 3px rgb(99 102 241 / 0.15);
}

selectedcontent .icon {
  display: none;
}

select::picker-icon {
  color: #667085;
  transition: rotate 0.2s ease;
}

select:open::picker-icon {
  rotate: 180deg;
}

select::picker(select) {
  border: 1px solid #d0d5dd;
  border-radius: 10px;
  margin-top: 0.4rem;
  padding: 0.4rem;
  background: #ffffff;
  box-shadow: 0 8px 24px rgb(16 24 40 / 0.12);
  opacity: 0;
  transform: translateY(-4px) scale(0.98);
  transition: opacity 0.15s ease, transform 0.15s ease, display 0.15s allow-discrete, overlay 0.15s allow-discrete;
}

select:open::picker(select) {
  opacity: 1;
  transform: translateY(0) scale(1);
}

@starting-style {
  select:open::picker(select) {
    opacity: 0;
    transform: translateY(-4px) scale(0.98);
  }
}

option {
  align-items: center;
  gap: 0.6rem;
  padding: 0.55rem 0.7rem;
  border-radius: 6px;
  font-size: 0.95rem;
  cursor: pointer;
}

option:hover,
option:focus {
  background: #f2f4f7;
}

option .icon {
  font-size: 1.1rem;
}

option:checked {
  background: #eef2ff;
  font-weight: 600;
}

option::checkmark {
  order: 1;
  margin-inline-start: auto;
  color: #6366f1;
  content: "✓";
}

Drop that into any Chromium-based browser and you'll get a fully custom dropdown, complete with icons, a rotating arrow, a fading-in panel, and a repositioned checkmark, all without a single line of JavaScript.

Why this is a bigger deal than it sounds

It's easy to read "you can now style a select" and shrug, but the actual shift underneath is significant. Every JS-powered "custom select" library exists because the real <select> couldn't be styled, so teams rebuilt it from scratch using divs and ARIA attributes, and in doing so quietly re-implemented keyboard navigation, focus management, typeahead search, and screen reader semantics. Most of these reimplementations get some part of that wrong, because native form controls are deceptively hard to fully replicate.

appearance: base-select sidesteps the problem entirely by keeping the real element. You still get native keyboard support, native form submission, and native accessibility behavior, for free, because it's still an actual <select>. You're just no longer locked out of its visual layer.

Should you use this today?

Given the current browser support, treat this as progressive enhancement rather than a drop-in replacement for your existing custom dropdown component:

If you're building something new and can tolerate a plainer fallback in non-supporting browsers, this is a great candidate, less JavaScript, smaller bundle, and better baseline accessibility than most hand-rolled dropdowns.
If you already ship a JS-based select component for a production product with broad browser support requirements, keep it for now, but keep an eye on this feature's Baseline status. It's likely to make that component unnecessary within the next couple of years.
Either way, it's worth trying out in a side project now. The mental model (button, picker, picker-icon, checkmark) is small enough to learn in an afternoon, and it'll only become more relevant as support widens.

The <select> element spent decades as the one thing in CSS everyone had to work around. That's no longer true, and it's worth getting familiar with while it's still new.

CSS Can Now Count Siblings on Its Own, No JavaScript Required

Artclick — Mon, 17 Aug 2026 10:43:07 +0000

There's a small category of problems that almost every frontend developer has solved with JavaScript at some point, even though it never really felt like a JavaScript problem. Numbering list items. Staggering an animation across a set of cards. Calculating how far along a stepper someone is. All of it boils down to one simple question: where am I in this list, and how many of us are there?

Browsers have always known the answer. We just never had a way to ask CSS directly, so we reached for JS instead.

The JS workaround we've all written

Something like this probably looks familiar:

const cards = document.querySelectorAll(".card");
cards.forEach((card, index) => {
  card.style.setProperty("--index", index + 1);
  card.style.setProperty("--count", cards.length);
});

It's not hard code. But it's extra JS, extra DOM traversal, and one more thing to keep in sync if the list changes. And the information it's computing, "which position is this, out of how many", was already sitting inside the browser's own layout engine the whole time.

Enter `sibling-index()` and `sibling-count()`

New CSS functions give you that information natively:

sibling-index() returns the current element's position among its siblings
sibling-count() returns the total number of siblings

No traversal, no JS, no manual bookkeeping.

Take a simple list:

<ul>
  <li>HTML</li>
  <li>CSS</li>
  <li>JavaScript</li>
</ul>

li::before {
  content: sibling-index();
}

That renders 1, 2, 3 next to each item, computed entirely by the browser. Pair it with sibling-count() and you can build a "step X of Y" style label with zero script:

li::after {
  content: " / " sibling-count();
}

1 / 3
2 / 3
3 / 3

Why this is more useful than automatic numbering

Numbering list items is a nice party trick, but the real unlock is that CSS now has a sense of scale, it knows not just where an element sits, but how big the whole collection is. That's what makes calculation-based layouts possible.

Staggered animations, without a forEach loop:

.item {
  animation-delay: calc(sibling-index() * 100ms);
}

Every item in the list gets its own delay automatically, no JS assigning animationDelay one element at a time.

Progress and position math, without hardcoded percentages:

.step {
  --progress: calc(sibling-index() / sibling-count());
}

That single line gives you each step's relative position in the sequence, exactly what you'd want for timelines, multi-step onboarding flows, or a progress bar built from a variable number of stages.

Adaptive timelines are a good real-world example:

<div class="timeline">
  <div class="node"></div>
  <div class="node"></div>
  <div class="node"></div>
  <div class="node"></div>
</div>

.node {
  animation-delay: calc(sibling-index() * 150ms);
}

Add or remove a .node and the stagger timing adjusts on its own. Nothing to recalculate in JS.

Why this beats `:nth-child()` for dynamic content

Most of us currently handle this kind of staggering with something like:

.card:nth-child(1) { animation-delay: 100ms; }
.card:nth-child(2) { animation-delay: 200ms; }
.card:nth-child(3) { animation-delay: 300ms; }

It works, right up until someone inserts a new .card in the middle of the list and every delay after it is now describing the wrong element. :nth-child() is fundamentally positional, it targets a slot in the DOM, not a relationship to the group.

sibling-index() is relational instead. It doesn't care how the list was generated or how many items came before your latest change, it just answers "where am I, relative to my siblings" at render time. That distinction matters a lot once your markup is coming from a CMS, an API response, or a mapped React list, exactly the situations where hardcoded :nth-child() rules get fragile fast.

Worth knowing before you reach for it

This is a newer CSS feature and support isn't universal yet, so it's not a safe swap for production logic across the board. Treat it as progressive enhancement for modern browsers for now, and keep a JS or :nth-child() fallback where broad compatibility actually matters. Worth checking current support on caniuse before leaning on it for anything critical.

The bigger pattern here

This fits a trend that's been building for a few years now. CSS picked up :has(), container queries, native nesting, anchor positioning, view transitions, and now sibling-awareness through these two functions. Each one used to be squarely "you need JavaScript for that." One by one, that list is getting shorter.

The useful mental shift isn't "can CSS replace JavaScript here", it's "can the browser do this more efficiently than my JS can". Increasingly, for layout- and DOM-structure-related problems, the answer is yes, the browser already has the information, it was just never exposed to the stylesheet before.

So next time you catch yourself writing JS purely to number items, stagger an animation, or calculate a position within a group, it's worth pausing and asking whether CSS already knows the answer. Chances are, it's starting to.

[Boost]

Artclick — Mon, 17 Aug 2026 09:55:23 +0000

Artclick

Aug 17

Why Good Frontend Developers Still Matter in the Age of AI

#css #webdev #frontend #programming

5 min read

[Boost]

Artclick — Mon, 17 Aug 2026 09:46:39 +0000

Artclick

Aug 17

This Tool Lets You Add Themeable Production-Ready Maps Into Your React App 🔥

#webdev #javascript #programming #opensource

5 min read

Why Good Frontend Developers Still Matter in the Age of AI

Artclick — Mon, 17 Aug 2026 09:46:21 +0000

Ask any AI coding assistant to build a button with Tailwind and it'll nail it in seconds: bg-blue-500 text-white px-4 py-2 rounded-md hover:bg-blue-600. Ask the same tool to fix why your flex container is collapsing on mobile, or why a z-index isn't taking effect, and things get shakier fast.

That gap is a useful lens for a bigger question a lot of frontend developers are quietly asking themselves right now: if AI can write so much of our code, do we still matter? The honest answer is yes, and CSS turns out to be one of the clearest places to see exactly why.

Why Tailwind is a good match for AI

Tailwind's whole design is built around small, predictable, tokenized classes. bg-, p-, flex, items-center — each one maps to a single, well-defined rule, and the naming convention barely changes from project to project.

That predictability is exactly what language models are optimized for. They're pattern-completion engines at heart: show them thousands of examples of p-4 sitting next to flex justify-between, scraped from tutorials, open-source repos, and Stack Overflow answers, and they get remarkably good at reproducing that pattern convincingly. Tailwind's classes are so consistent and so heavily represented in training data that generating them almost becomes a memorization problem, not a reasoning one.

Why plain CSS trips AI up

Classic CSS doesn't have any of that consistency, and that's precisely the point of it, it's meant to be shaped by whoever's writing it. Which is great for developers, and rough for pattern-matching models:

Naming is a free-for-all. One codebase uses .btn-primary, another uses .buttonMain, a third follows BEM (.block__element--modifier), a fourth uses CSS Modules or scoped styles entirely.
Styles can live anywhere — external stylesheets, <style> blocks, inline attributes — with no fixed relationship to the markup they affect.
The connection between a class name and its visual outcome is indirect. An AI model can't actually see your rendered page; it's inferring meaning from text patterns that vary wildly between projects.

On top of that, CSS isn't just syntax, it's a layout system with cascade, specificity, inheritance, stacking contexts, and formatting contexts all interacting at once. Diagnosing a real bug usually means reasoning across several of these layers simultaneously:

Is that z-index failing because of a stacking context created somewhere up the tree?
Is a margin collapsing because of block formatting context rules?
Is a width getting silently overridden by a min-width declared somewhere else entirely?

None of that is a text-completion problem. It's closer to debugging a physics simulation, and that's a different kind of reasoning than "what token comes next," which is fundamentally what an LLM is doing.

The staleness problem nobody talks about

There's a second issue that's less about reasoning and more about timing: most models are trained on a snapshot of the web that's already months, sometimes years, old by the time you're using them. That's a real problem for CSS specifically, because the language has been moving unusually fast lately.

Ask an AI assistant about :has(), container-type, or view-timeline, and you'll often get a confident-sounding answer with no mention of actual browser support, or worse, a subtly wrong explanation presented with total confidence. It won't tell you Chromium shipped a feature months before Firefox did. It won't check caniuse.com before answering. It simply doesn't know what it doesn't know, and it has no built-in way to flag that uncertainty to you.

Meanwhile the platform keeps moving:

Logical properties are reshaping how RTL and internationalized layouts get built
Container queries are quietly replacing a lot of what media queries used to be responsible for
Scroll-driven animations are making JS-based scroll listeners feel like a legacy pattern

If your only source of CSS knowledge is what a chatbot tells you, you're building on a stale foundation without realizing it. The spec, the CSS Working Group drafts, and actual browser support tables are still the ground truth, an AI's confidence level is not.

Why understanding CSS still matters, even if you use Tailwind

AI doesn't do design reasoning. It's good at pattern completion, not at judging whether a layout looks balanced or a component adapts gracefully across breakpoints. It can suggest a plausible flex setup, but it has no sense of why that setup is the right one for your specific design.

Tailwind is still CSS underneath. If you don't actually understand what flex, justify-between, or overflow-hidden do at the CSS level, you're just stacking utility classes and hoping something sticks. Tailwind doesn't remove the need to understand spacing systems, breakpoints, positioning, and the box model, it just asks you to think about those things in smaller, composable pieces. Without that mental model, you can't reason about why your utility stack behaves the way it does when something breaks.

Real bugs still need a human. A hidden scrollbar, a layout shift that only shows up on one device, an overflow caused by a min-width three components away, these are exactly the cases where AI tends to guess rather than diagnose. Inspecting the cascade, spotting an unintended inheritance, checking box-sizing, testing across real devices: this is still fundamentally human work, because it requires actually seeing and interacting with the rendered result, not just reading the code that produced it.

The part AI genuinely can't do

There's a layer of frontend work that's less about correctness and more about feel: nudging padding until a layout stops feeling cramped, adjusting contrast until text is both accessible and pleasant to read, picking a type scale ratio that feels right on mobile, aligning things until a page feels intentional rather than assembled.

None of that comes from a training set. It comes from having actually looked at hundreds of interfaces, built a sense for what "off" looks like, and developed the kind of taste that only comes from experience. AI can generate a technically valid layout. It can't tell you it looks wrong, because it has no eyes and no taste, it only has patterns.

Where this leaves things

AI coding tools maybe useful for scaffolding, for Tailwind-heavy work, and for speeding up the boring parts. But that doesn't make frontend developers less necessary, it just relocates where the value is. Less time typing out predictable class combinations, more time on the things AI structurally can't do: diagnosing real bugs, reasoning across the cascade, and knowing when a layout is technically valid but still wrong.

The developers who understand the cascade, keep up with what's shipping in browsers, and have built an eye for what looks right are exactly the ones who can catch it when the AI's confident answer is quietly mistaken, and fix it when it is. That skill set isn't going away because AI got better at autocomplete. If anything, it's becoming the differentiator.

This Tool Lets You Add Themeable Production-Ready Maps Into Your React App 🔥

Artclick — Mon, 17 Aug 2026 08:15:50 +0000

If you've ever added a map to a React app, you know the drill. Pick a library, wrestle with API keys, fight the wrapper's styling system to make it match your design, then give up and drop down to raw MapLibre or Mapbox anyway. Most map libraries are either too opinionated to customize or too low-level to be a good starting point.

mapcn takes a different approach, and it's the same approach that made shadcn/ui popular for regular components: you don't install a map component as a black-box dependency, you copy the actual source into your project and own it.

What it actually is

mapcn is a collection of accessible, customizable map components for React, built on top of MapLibre GL and styled with Tailwind CSS. It's designed to slot directly into a shadcn/ui project, following the same "copy, don't install" philosophy shadcn made popular.

A few things stood out to me:

No API key required. It ships with free CARTO basemap tiles by default, so you get a working map immediately, with zero signup friction.
Theme aware out of the box. The map tiles automatically switch between light and dark styles based on your app's theme.
You own the code. Since components are copied into your project rather than pulled in as an opaque dependency, you can edit anything, there's no version lock-in, and no fighting an abstraction layer to override one style.
Not locked to one tile provider. Because it stays close to MapLibre's own style spec, you can swap in tiles from OpenStreetMap, MapTiler, Stadia Maps, Thunderforest, or basically any MapLibre-compatible provider whenever you outgrow the free default.
Full TypeScript support, and it drops down to the raw MapLibre instance whenever you need more control than the components expose.

Getting started

If you already have Tailwind CSS and shadcn/ui set up, adding the map component is one command:

pnpm dlx shadcn@latest add @mapcn/map

This installs maplibre-gl and adds the map component into your project, the same way any other shadcn component gets added.

Then it's a normal React component:

import { Map, MapControls } from "@/components/ui/map";
import { Card } from "@/components/ui/card";

export function MyMap() {
  return (
    <Card className="h-[320px] p-0 overflow-hidden">
      <Map center={[-74.006, 40.7128]} zoom={11}>
        <MapControls />
      </Map>
    </Card>
  );
}

That's a rendered, interactive, theme-aware map with zoom controls, no API key, no config file.

One implementation detail worth knowing: MapLibre parses map tiles in a Web Worker, which ships as a separate file. mapcn loads that worker from unpkg by default, pinned to your installed version, so there's no manual setup. If you're running under a strict Content Security Policy, you'll need to allow script-src 'self' https://unpkg.com and worker-src 'self' blob: (plus whatever your basemap host needs). If you'd rather self-host the worker entirely, you can copy the worker files into your public/ folder and point MapLibreGL.setWorkerUrl() at them instead.

Markers, popups, and tooltips

This is where the "composable" part of mapcn's pitch really shows. Instead of one giant marker prop with a dozen config options, you compose small pieces:

import {
  Map,
  MapMarker,
  MarkerContent,
  MarkerPopup,
  MarkerTooltip,
} from "@/components/ui/map";

const locations = [
  { id: 1, name: "Empire State Building", lng: -73.9857, lat: 40.7484 },
  { id: 2, name: "Central Park", lng: -73.9654, lat: 40.7829 },
  { id: 3, name: "Times Square", lng: -73.9855, lat: 40.758 },
];

export function MarkersExample() {
  return (
    <div className="h-[420px] w-full">
      <Map center={[-73.98, 40.76]} zoom={12}>
        {locations.map((location) => (
          <MapMarker key={location.id} longitude={location.lng} latitude={location.lat}>
            <MarkerContent>
              <div className="bg-primary size-4 rounded-full border-2 border-white shadow-lg" />
            </MarkerContent>
            <MarkerTooltip>{location.name}</MarkerTooltip>
            <MarkerPopup>
              <div className="space-y-1">
                <p className="text-foreground font-medium">{location.name}</p>
                <p className="text-muted-foreground text-xs">
                  {location.lat.toFixed(4)}, {location.lng.toFixed(4)}
                </p>
              </div>
            </MarkerPopup>
          </MapMarker>
        ))}
      </Map>
    </div>
  );
}

Because MarkerPopup accepts arbitrary JSX, nothing stops you from building a rich popup with an image, a rating, and action buttons using your existing shadcn Button and Card components. It ends up looking like a genuine part of your app's UI instead of a plugin bolted on top of a map.

Markers can also be made draggable with a single draggable prop plus an onDrag handler, which is handy for location pickers or "confirm your address" style flows.

One thing worth flagging: MapMarker renders actual DOM elements, so it's a great fit for anywhere from a handful up to a few hundred markers. If you're plotting thousands of points, the docs point you toward rendering markers as a GeoJSON layer instead, which is far cheaper for large datasets.

Beyond basic markers

The component set goes further than pins on a map. Looking through the docs, mapcn also ships:

Routes and arcs — for drawing paths and curved connections between points, useful for delivery tracking or "flights between cities" style visualizations.
GeoJSON support — for rendering larger, more complex geographic datasets as map layers rather than individual DOM markers.
Clustering — for grouping nearby points so your map doesn't turn into a wall of overlapping pins when the data gets dense.
Custom controls — the MapControls component in the basic example is itself composable and themeable.

Why this matters if you build client sites

For a lot of client work, whatever map library you reach for immediately becomes the thing that visually doesn't match the rest of the site. Store locators, property listings, delivery tracking, service-area maps, they all tend to need a "location finder" screen at some point, and it usually shows up as a default-blue Google Maps embed sitting awkwardly next to a carefully designed page.

Because mapcn is Tailwind-styled and copy-paste by design, a map built with it can actually inherit your design tokens instead of fighting them. And since there's no required API key, it's a genuinely fast way to prototype a location feature before deciding whether a paid tile provider is worth it for a given project.

Where to look next

mapcn.dev — homepage and live demos
Documentation — installation and philosophy
Component docs — Map, Controls, Markers, Popups, Routes, Arcs, GeoJSON, Clusters
GitHub — source, currently at 11k+ stars

If you're already in the shadcn/ui + Tailwind ecosystem and need a map at some point, this is worth a look before reaching for a heavier, more opinionated library.

[Boost]

Artclick — Thu, 13 Aug 2026 09:37:24 +0000

Artclick

Aug 13

10 Underrated Node.js Tools to Add to Your Developer Toolkit

#programming #node #webdev

5 min read

10 Underrated Node.js Tools to Add to Your Developer Toolkit

Artclick — Thu, 13 Aug 2026 09:37:05 +0000

Most "best Node.js packages" lists just rename Express, Lodash, and Axios in a different order. Fine tools, all three — but they're not the ones that actually saved me time this year. The ones that did are smaller, quieter, and mostly never trend on anything. They just sit in package.json doing their one job well, and I only notice them when they're missing from a new project.

Here are ten of them, what they replace, and where I'd actually reach for each.

1. `execa` — for when `child_process` isn't worth the pain

Node's built-in child_process.exec technically works, but you're back to string-escaping shell commands and manually handling stdout/stderr buffering the moment you do anything beyond "run one command and forget about it."

import { execa } from 'execa';

const { stdout } = await execa('git', ['rev-parse', '--short', 'HEAD']);
console.log(stdout);

Arguments are passed as an array, not concatenated into a shell string, so you stop worrying about escaping. It also throws a real error with the command's actual stderr attached when something fails, instead of leaving you to go dig through a callback.

2. `zx` — for scripts you'd normally reach for bash for

Same author's ecosystem, different problem: zx is for the "this really should just be a bash script, except I want real variables and error handling" situation.

#!/usr/bin/env zx

const branch = await $`git branch --show-current`;
await $`npm run build`;
await $`rsync -av ./dist/ user@server:/var/www/${branch.stdout.trim()}/`;

It's genuinely fun to write deploy scripts in this. The caveat: don't reach for it inside application code — it's a scripting tool, not a library you import into a server. Keep it in your scripts/ folder.

3. `p-limit` — for when `Promise.all` is too eager

Promise.all fires everything at once. That's fine for five requests. It's how you accidentally DDoS your own API, or your own database connection pool, the moment "five" becomes "five thousand."

import pLimit from 'p-limit';

const limit = pLimit(5); // max 5 concurrent

const results = await Promise.all(
  userIds.map(id => limit(() => fetchUserData(id)))
);

This is the fix I reach for every single time I'm processing a batch of anything — API calls, file uploads, database writes. It's about forty lines of source code and it's saved me from rate-limit bans more times than I can count.

4. `nanoid` — for IDs that don't need to be a UUID

uuid works, but a v4 UUID is 36 characters and most of the time you don't actually need RFC-compliant UUIDs — you need a short, unique, URL-safe string.

import { nanoid } from 'nanoid';

const id = nanoid(); // 'V1StGXR8_Z5jdHi6B-myT'
const shortId = nanoid(8); // 'IRFa-VaY'

Smaller output, faster generation, and it's URL-safe by default so you can drop it straight into a route without encoding it. I use this for anything that doesn't need to interoperate with a system that specifically expects UUID format.

5. `pino` — for logging that doesn't slow down production

console.log is fine in development and a genuine performance problem in a high-throughput production service — synchronous, unstructured, and unfiltered by log level.

import pino from 'pino';

const logger = pino();
logger.info({ userId: user.id }, 'user logged in');
logger.error({ err }, 'payment failed');

It outputs structured JSON by default, which sounds like a downside until your logs need to go into something like Datadog or Elasticsearch and you realize structured logs were the whole point. Pipe it through pino-pretty locally if raw JSON in your terminal makes your eyes glaze over — I do, every project.

6. `why-is-node-running` — for the process that won't exit

Every Node developer has had this moment: your script is done, but the process just... sits there. Something's holding an open handle — a socket, a timer, a database connection — and you have no idea which.

import why from 'why-is-node-running';

setTimeout(() => why(), 5000);

It prints exactly what's keeping the event loop alive, with a stack trace pointing at where each handle was created. I've used this to find a forgotten setInterval and an unclosed database pool in two separate "why won't this exit" debugging sessions that would otherwise have eaten an afternoon each.

7. `tsx` — for running TypeScript without a build step

ts-node works, but it's slow to start and its ESM support has been a source of pain for years. tsx is a much faster drop-in for the common case of "I just want to run this TypeScript file right now."

npx tsx script.ts
npx tsx watch server.ts

The watch flag alone replaced a nodemon + ts-node combo in most of my newer projects. It's not trying to be a full build tool — for that you still want tsc or a bundler — but for local scripts and dev servers it's the fastest path from "TypeScript file" to "running code" I've used.

8. `defu` — for merging config objects without losing your mind

Every project ends up needing to merge a default config with user-supplied overrides, and { ...defaults, ...userConfig } breaks the moment either object has nested properties — a shallow spread happily throws away half your defaults.

import { defu } from 'defu';

const config = defu(userConfig, {
  port: 3000,
  server: { host: 'localhost', timeout: 5000 },
  debug: false,
});

defu does a proper recursive merge, only filling in values that are actually missing, at any depth. Small utility, but it quietly prevents a specific class of "why did my nested config option get wiped out" bug.

9. `picocolors` — for terminal colors without the dependency weight

chalk is the household name here, and it's a fine library — but if all you need is basic ANSI colors in CLI output, picocolors does the same job at a fraction of the size, with no dependencies of its own.

import pc from 'picocolors';

console.log(pc.green('✓ Build succeeded'));
console.log(pc.red(pc.bold('✗ Build failed')));

If you're building a CLI tool that other people will install, every dependency you pull in is a dependency they inherit. This is the kind of swap that doesn't change what your code does, only how much it costs the next person to install it.

10. `ora` — for CLI spinners that don't leave you guessing

If your script does anything that takes more than half a second, a silent terminal makes people wonder if it's frozen. ora gives you a spinner with almost no ceremony:

import ora from 'ora';

const spinner = ora('Deploying to production...').start();
await deploy();
spinner.succeed('Deployed successfully');

It's a small thing, but it's the difference between a CLI tool that feels finished and one that feels like a script someone ran once and never polished. Worth the two minutes it takes to wire in.

The pattern across all ten

None of these are exciting on their own. That's kind of the point — the tools that actually save time in practice are usually the ones solving one specific, annoying problem precisely, not the ones with the biggest feature list. Before reaching for a heavier framework or writing something from scratch, it's worth checking whether one of these already exists for exactly the problem in front of you. More often than I expect, one does.

DEV Community: Artclick

How the JavaScript Runtime Schedules Callbacks: A Look at the Event Loop

The one-thread rule

Handing work off to the browser

Two different queues, not one

Tracing through an actual example

Why this matters for callbacks and async/await

It's not just a browser thing

The short version

10 CSS Tips and Tricks for Better Responsive Web Design

Modern CSS gives you tools that make most of your old media queries unnecessary. Here are ten practical techniques worth adding to your toolkit in 2026.

1. Fluid Typography

2. Fluid Spacing, Not Just Fluid Type

3. Intrinsic Grids That Don't Need Breakpoints At All

4. Container Queries

5. The aspect-ratio Property

6. min() and max() for Flexible Constraints

7. Dynamic Viewport Units: dvh, svh, lvh

8. Logical Properties Instead of Physical Ones

9. Responsive Images With srcset and sizes

10. Respecting User Preferences, Not Just Screen Size

Putting it together

Stop Compiling Your Nested CSS. The Browser Does It Now

Browser support, briefly

The basic syntax

The & selector, and when you actually need it

Nesting pseudo-classes without repeating yourself

Nesting at-rules: media queries, container queries, and more

Specificity: the good news

The gotcha that catches almost everyone once

A real component, built with nesting

If you're migrating from Sass

Should you drop your preprocessor?

[Boost]

Styling dropdown menus in CSS got a whole lot better!

Styling dropdown menus in CSS got a whole lot better!

Browser support first, because it matters here

Starting point: a completely ordinary select

Step 1: opting in

Step 2: styling the select button

Cleaning up what shows inside the button

Step 3: styling the picker icon (the little arrow)

Step 4: styling the dropdown picker itself

Step 5: styling the options

Step 6: styling the selected option and its checkmark

Putting it all together

Why this is a bigger deal than it sounds

Should you use this today?

CSS Can Now Count Siblings on Its Own, No JavaScript Required

The JS workaround we've all written

Enter sibling-index() and sibling-count()

Why this is more useful than automatic numbering

Why this beats :nth-child() for dynamic content

Worth knowing before you reach for it

The bigger pattern here

[Boost]

Why Good Frontend Developers Still Matter in the Age of AI

[Boost]

This Tool Lets You Add Themeable Production-Ready Maps Into Your React App 🔥

Why Good Frontend Developers Still Matter in the Age of AI

Why Tailwind is a good match for AI

Why plain CSS trips AI up

The staleness problem nobody talks about

Why understanding CSS still matters, even if you use Tailwind

The part AI genuinely can't do

Where this leaves things

This Tool Lets You Add Themeable Production-Ready Maps Into Your React App 🔥

What it actually is

Getting started

Markers, popups, and tooltips

Beyond basic markers

Why this matters if you build client sites

Where to look next

[Boost]

10 Underrated Node.js Tools to Add to Your Developer Toolkit

10 Underrated Node.js Tools to Add to Your Developer Toolkit

1. execa — for when child_process isn't worth the pain

2. zx — for scripts you'd normally reach for bash for

3. p-limit — for when Promise.all is too eager

4. nanoid — for IDs that don't need to be a UUID

5. The `aspect-ratio` Property

6. `min()` and `max()` for Flexible Constraints

7. Dynamic Viewport Units: `dvh`, `svh`, `lvh`

9. Responsive Images With `srcset` and `sizes`

The `&` selector, and when you actually need it

Enter `sibling-index()` and `sibling-count()`

Why this beats `:nth-child()` for dynamic content

1. `execa` — for when `child_process` isn't worth the pain

2. `zx` — for scripts you'd normally reach for bash for

3. `p-limit` — for when `Promise.all` is too eager

4. `nanoid` — for IDs that don't need to be a UUID

5. `pino` — for logging that doesn't slow down production

6. `why-is-node-running` — for the process that won't exit

7. `tsx` — for running TypeScript without a build step

8. `defu` — for merging config objects without losing your mind

9. `picocolors` — for terminal colors without the dependency weight

10. `ora` — for CLI spinners that don't leave you guessing