The short answer
Reach for Flexbox when you're lining things up in a single row or column. Reach for Grid when you need to control rows and columns at the same time.
Where Flexbox wins
Nav bars, button groups, anything where the number of items can change and you want them to wrap naturally without extra math.
.nav {
display: flex;
gap: 1rem;
align-items: center;
flex-wrap: wrap;
}
Where Grid wins
Page-level layouts - a sidebar next to a main area, card grids, anything where you actually want to say "this many rows, this many columns" up front.
.page {
display: grid;
grid-template-columns: 240px 1fr;
grid-template-rows: auto 1fr auto;
min-height: 100vh;
}
.card-grid {
display: grid;
grid-template-columns: repeat(auto-fill, minmax(280px, 1fr));
gap: 1.5rem;
}
Nothing wrong with using both
Most real layouts end up mixing the two - Grid for the page skeleton, Flexbox for whatever's arranged inside each card or panel.
A quick way to decide
- One direction only (row or column) → Flexbox
- Both directions matter → Grid
- Content should decide the size → Flexbox
- Layout should decide the size → Grid
Comments
Loading comments...
Related Articles
Taming Slow MongoDB Aggregation Pipelines in Production
An aggregation pipeline that returns instantly on your 500-document local dataset can crawl once it hits a few million real documents. Here's how to actually find and fix the stage that's costing you.
Read ArticleBuilding a Sliding-Window Rate Limiter for Node.js APIs with Redis
Fixed-window rate limiting looks fine in a demo and then lets through double the traffic right at the window boundary. Here's the sliding-window-counter approach that fixes that, built directly on Redis.
Read ArticleMulti-Tenant Data Isolation: Shared Schema vs Separate Databases
Every multi-tenant SaaS eventually has to answer one question honestly: how do you stop one customer from ever seeing another customer's data? Here's how the three common isolation strategies actually compare in practice.
Read Article