Feature-Based Structure for Frontend Development

One thing I’ve learned while building my app: Good structure doesn’t matter at the beginning… but it matters a lot as your project grows. On the backend, I naturally structured things like this: → routes → schemas → services Each layer had a clear responsibility. Easy to scale. Easy to maintain. But on the frontend, I went with: → components → hooks → lib It felt clean at first. Until the app started growing (boards, pins, collaborators…). Working on a single feature meant jumping across multiple folders: components → hooks → lib Same feature… different places. That’s when I realized: I was structuring my backend by feature logic, but my frontend by file type. And that difference becomes very obvious at scale. So I’m now moving toward a more feature-based structure on the frontend: → grouping everything related to a feature in one place Not a full refactor yet, but the direction is clear. Key takeaway: You don’t really understand structure when starting a project, you understand it when the project starts growing. Curious how others approach this ….do you prefer feature-based or layer-based structure? #softwareengineering #webdevelopment #reactjs #nextjs #buildinpublic

  • No alternative text description for this image

I think neither is correct, the files should be collated in relation to their parent, if you have a unique button used in a component, it should be in a sub folder of that component folder, unless its shared, then it lives in a shared directory, this means that your file tree is a readable representation of your dom, and you dont have to jump everywhere to see scoped hooks and functions.

Like
Reply
See more comments

To view or add a comment, sign in

Explore content categories