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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.