DEV Community

Cover image for Everyone uses Flexbox. I stopped, and here is why.
Arnold Daniels
Arnold Daniels

Posted on

Everyone uses Flexbox. I stopped, and here is why.

Mobile-first quietly limits desktop UX

For years, I designed layouts mobile-first and then stretched them to desktop. That approach sounds sensible, but it quietly bakes in an assumption, that the mobile content order is also the right order for larger screens.

Most of the time, it is not.

Flexbox reinforces this assumption without making it explicit. It is excellent at aligning and distributing items, but it ties layout to DOM order. As long as your screen is essentially linear, this works. As soon as a screen has multiple functional zones, it becomes a constraint.

When screens stop being linear

Consider an application screen with real structure. There is primary content, filters, contextual information, an activity stream, and a footer with actions. On mobile, the optimal experience is a simple vertical flow. Content first, then supporting panels, everything scrolls naturally.

With CSS Grid, that layout can be expressed directly:

grid-template-areas:
  "content"
  "filters"
  "context"
  "activity"
  "footer";
Enter fullscreen mode Exit fullscreen mode

Now look at what actually makes sense on desktop. Filters should live permanently on the left. Context should always be visible on the right. Activity belongs near that context, not below the main content. The footer should break out of the flow and span the full width.

grid-template-areas:
  "filters  content   context"
  "filters  content   activity"
  "footer   footer    footer";
Enter fullscreen mode Exit fullscreen mode

Same components. Same DOM. Completely different layout.

Why Flexbox starts to fight you here

At this point, Flexbox technically still works, but only if you are willing to fight it. You introduce wrapper elements that exist only for layout. You add order overrides at multiple breakpoints. You make compromises between semantics, readability, and intent.

The CSS stops describing a layout and starts describing exceptions.

More importantly, your thinking changes. Instead of asking what the best layout is for this screen, you start asking how to bend the existing one without breaking it.

CSS Grid changes the mental model

CSS Grid flips this around. Instead of defining how items flow, you define how the screen is composed. The DOM order stays logical, accessible, and mobile-friendly, while the visual order becomes a deliberate design decision per breakpoint.

Mobile and desktop stop being the same layout at different sizes and become two intentional layouts that share the same content.

This is not just cleaner code. It leads to better UX. On large screens, important context is visible earlier. Secondary panels are placed where they make sense instead of where the flow allows. Horizontal space is actually used, not politely ignored.

From concept to practice: AreaGrid

One reason CSS Grid is underused is that it feels page-level and abstract, while most React code is component-driven. To bridge that gap, I built a tiny wrapper called AreaGrid, a thin abstraction over grid-template-areas.

It lets you define responsive layouts declaratively, while keeping your components and DOM order untouched. No layout JS, no duplicated markup, no styled-components dependency.

You can find it here:
πŸ‘‰ https://github.com/jasny/areagrid

It is intentionally small. The point is not to hide CSS Grid, but to make it ergonomic in a component-based world.

Flexbox is not the enemy

Flexbox is still the right tool inside components. It shines at alignment, spacing, and small-scale layout problems. CSS Grid is not a replacement for Flexbox, it operates at a different level.

Flexbox is about flows.
CSS Grid is about screens.

Once you start designing screens instead of flows, CSS Grid stops feeling complex and starts feeling obvious.

And you may realize you have been sleeping on it.

Top comments (0)