I’ve been experimenting with different ways of organizing Vue 3 projects over the past few years.
After trying both responsibility-first and feature-first structures, I eventually settled on a hybrid approach:
<ul>
<li>Root organized by responsibility</li>
<li>Feature-specific code grouped by feature</li>
<li>Consistent file naming for better searchability</li>
</ul>
In this article, I explain the reasoning behind the architecture, show examples from a production-inspired project, and discuss the trade-offs that led me to this approach.
I’m curious how other Vue developers structure larger applications.
Do you prefer:
Responsibility-first?
Feature-first?
A hybrid approach?
DevTo: <a href="https://dev.to/lazydoomslayer/how-i-build-vue-3-applications-part-1-why-i-use-a-hybrid-folder-structure-48c2" target="_blank" rel="noopener nofollow">https://dev.to/lazydoomslayer/how-i-build-vue-3-applications-part-1-why-i-use-a-hybrid-folder-structure-48c2</a>
Medium: <a href="https://medium.com/@lazydoomslayer/how-i-build-vue-3-applications-part-1-why-i-use-a-hybrid-folder-structure-4e930f7c7b71" target="_blank" rel="noopener nofollow">https://medium.com/@lazydoomslayer/how-i-build-vue-3-applications-part-1-why-i-use-a-hybrid-folder-structure-4e930f7c7b71</a>

Smiley Face

Luka Jioshvili

A developer shares their hybrid folder structure approach for organizing Vue 3 projects, combining responsibility-first organization at the root level with feature-first grouping for feature-specific code, plus consistent file naming conventions. The post explains the reasoning behind this architecture with production-inspired examples and discusses trade-offs compared to purely responsibility-first or feature-first approaches.

Why I Use a Hybrid Folder Structure

It does not matter how your project is structured, if there is more than one developer and people join and leave someone will screw it anyway. Unless there is a team lead who does review and enforce developers to follow the pattern. Obviously there is an idea at first, but then it will be hybrid stuff anyway.

I prefer some form of hybrid where like in your example user stuff ends up in same folder: userEntity,userControler,useUser,userCache …
the setup where controllers are in controller folder and entities are in entity folder is the worst. Larger projects easily end up with many entities and the user related stuff is all over the place. I have seen a project where I have to scroll 3 pages on my screen to find userController, and then go to repositories fodler to find userRepositore … DTO … etc it was a frikin nightmare.
I have also done this mistake of placing all enttities in entities package in my own projects, and stupid ass auto discovery concept is a kind of process that pushes you in the direction, as It is easier to declare where to look for entities, and then you suffer for the rest of project lifetime.

The easiest time I ever had was in my first project where I had maybe 3 folders 😁
all pages in root, libraries, and assets

The real strength here is the mental model. A folder structure works when developers can predict where code belongs without debating it every time.

The concept of searching a file in the file system is outdated, nowadays most developers just open a command palette and type the name of the folder, it doesn’t matter where is it located.
The reason structure can be important is when you join a project (or reopen a project you havent open for a while), then you can guess by the structure how the project is structured (since nobody reads READMEs anyway). But this too became outdated now that AI is present.
That being said, seasoned developers that are used to having their projects structured will not feel well when a project is messy.
Anyway nice article, I’m new to Vue and I already picked up some good structuring practices. The only difference with your structure is that my services are also structured like composables (e.g. I have a <code>useUsers</code> , <code>useData</code> etc). Vue doesn’t have a defined file type pattern like Angular or Nest, so using the <code>.pinia.ts</code> and <code>.service.ts</code> but in other places <code>useBlabla.ts</code> is a bit jarring.
So yeah, <code>use</code> everywhere (just like <code>vueuse</code> :)