I think this "nature based" code organisation is not so good. Each feature gets distributed over several folders and each folder becomes a huge dumping ground. It's awkward to deal with and not scaleable. I think it's much better to organise code according to feature, subfeature etc. where code for a feature is organised together. It's kinda like how Vue and React switched from lifecycle methods to hooks... it became much easier to deal with these frameworks when code is organised isomorphically rather than being distributed according to implementation details of the framework. Wouldn't it be weird if say, you put all your Python classes in a folder called classes, your functions in a folder called functions, your type annotations in a folder called types etc.? I don't understand why, when it comes to react projects, it's become semi-prevalent. Angular code standards advise against this (not that Angular is very good).
My personal term is "clothing code". All the shirts go in this drawer, the socks in this drawer, etc. The strategy works for clothing because the goal is to mix-and-match, but for code usually a set of files always belong together.
I have created quite sizable applications like this and didn’t find it hard to navigate. Also, most logical features I create is in the backend or in a utils folder if it is really needed in the frontend.
But I am still unsure on what you mean with your comment maybe you can show one of your own repos to display what you mean?
Really depends what "quite sizable applications" means.
The biggest frontend side projects that I worked on were 232k and 110k lines of code and if you're not organise code according to features then this will be mess and hard to maintain and understand what's going on.
There is not perfect project structure that will fill each project.
There's hundreds of articles advocating this same method of organisation and almost none advocating for the system typically used by so many people starting out with web frameworks.
I think it's objectively better, in my contracting career almost every large or experienced team I've worked with have organised by feature. Those that didn't soon moved to feature based organisation when the size of the project got to the point that the flaws of nature-based organisation became particularly self-evident.
Do you also migrate towards a monorepo then? Or do you keep it feature based like in the example you showed. It is definitely interesting but I haven’t seen a frontend repo like this. So, it is hard to wrap my head around it.
I've used monorepos sometimes, but I think this method of code organisation is not really related to whether you decide to use a monorepo or not. It's about how you organise any package, whether that package is it's own repo or within a monorepo.
A good tip is to think about your features in advance, you should have some idea of what many of the top level feature folders are gonna be before you start your project, but of course you can add new features as you discover their need. Also, don't fear nesting one or more subfeatures inside of a feature when it feels right.
I think this "nature based" code organisation is not so good. Each feature gets distributed over several folders and each folder becomes a huge dumping ground. It's awkward to deal with and not scaleable. I think it's much better to organise code according to feature, subfeature etc. where code for a feature is organised together. It's kinda like how Vue and React switched from lifecycle methods to hooks... it became much easier to deal with these frameworks when code is organised isomorphically rather than being distributed according to implementation details of the framework. Wouldn't it be weird if say, you put all your Python classes in a folder called classes, your functions in a folder called functions, your type annotations in a folder called types etc.? I don't understand why, when it comes to react projects, it's become semi-prevalent. Angular code standards advise against this (not that Angular is very good).
My personal term is "clothing code". All the shirts go in this drawer, the socks in this drawer, etc. The strategy works for clothing because the goal is to mix-and-match, but for code usually a set of files always belong together.
Helix design principles are worth looking at too helix.sitecore.com/introduction/wh.... I use some of those ideas in my FE projects.
I have created quite sizable applications like this and didn’t find it hard to navigate. Also, most logical features I create is in the backend or in a utils folder if it is really needed in the frontend.
But I am still unsure on what you mean with your comment maybe you can show one of your own repos to display what you mean?
Really depends what "quite sizable applications" means.
The biggest frontend side projects that I worked on were 232k and 110k lines of code and if you're not organise code according to features then this will be mess and hard to maintain and understand what's going on.
There is not perfect project structure that will fill each project.
codeopinion.com/organizing-code-by...
There's hundreds of articles advocating this same method of organisation and almost none advocating for the system typically used by so many people starting out with web frameworks.
I think it's objectively better, in my contracting career almost every large or experienced team I've worked with have organised by feature. Those that didn't soon moved to feature based organisation when the size of the project got to the point that the flaws of nature-based organisation became particularly self-evident.
Do you also migrate towards a monorepo then? Or do you keep it feature based like in the example you showed. It is definitely interesting but I haven’t seen a frontend repo like this. So, it is hard to wrap my head around it.
I will try it for my next project, any tips?
I've used monorepos sometimes, but I think this method of code organisation is not really related to whether you decide to use a monorepo or not. It's about how you organise any package, whether that package is it's own repo or within a monorepo.
A good tip is to think about your features in advance, you should have some idea of what many of the top level feature folders are gonna be before you start your project, but of course you can add new features as you discover their need. Also, don't fear nesting one or more subfeatures inside of a feature when it feels right.
Totally agree.
The keyword here as I know is vertical folder structure vs horizontal folder structure or package by feature vs package by layer.
As the project grows, I think package by feature would be better, you know where the code should supposed be found when you are searching for it.
Sometimes, we do create a
sharedorcommonfolder (the same level with other features) to serve common codes.