
Layered vs Feature-Sliced: Two Ways to Cut the Same App
Every frontend architecture is really just a decision about which axis you slice the app along — by technical kind, or by feature. Both are correct. Both eventually hurt. The question worth asking isn't which one is better, it's which one is cheaper to be wrong about later.

What FSD Actually Fixed (and What It Didn't)
Feature-Sliced Design got popular because frontend spent years being treated as the part of the codebase that didn't need real architecture. It fixed that perception. It did not fix cohesion, and pretending it did is how you end up with a button smeared across ten folders.

The Direction of the Arrows: Dependencies Are Your Real Architecture
You can draw whatever folder diagram you like. The honest picture of your app is which module imports which — the direction of the arrows. Get that wrong and no folder structure will save you.

The shared/ Folder Is Not a Place, It's a Promise
Every codebase grows a shared/ folder, and given enough time every shared/ folder becomes a junk drawer. Not because the team got lazy — because the folder was never given a rule. Here's why it rots, and how to keep it boring.

The Smeared Component: When Architecture Scatters What Should Stay Together
FSD is one of the best frontend methodologies out there. Used without thinking, it turns a complex component into a scavenger hunt across eight folders. Here's what I learned.

Code Structure in React: The FSD Version I Actually Use
Flat folders are fine until every feature starts touching routes, queries, forms, permissions, and UI state. Here's the React structure I use when a TanStack app grows past the simple stage without turning FSD into folder theater.