It is critical to create a maintainable folder structure while developing web apps, having the right files in the correct folder helps organize you...
For further actions, you may consider blocking this person and/or reporting abuse
I’ve tried completely flat projects before that’s had some mileage before it got too much, then I added some folders but this subject, it’s not actually important because we have amazing find in files features built into everything, don’t get hung up on it ✌️
I'm actually in complete disagreement with this statement... its only true if you've worked there for years and know the application history. If not, finding via string search in 100k lines of code is often, more often than not, nightmarish.
I use for example ECSS a system that is designed to group css by a 3 letter namespace and that is a point that conventions are often found more in files than folders so identifying patterns and searching are indeed skills that a developer must aim to improve on.
I did state as many have missed that there is a limit read the entire comment
Great system... but rings my point home too... ive been in many a code base developed by 1000 engineers, where css policies are different throughout precisely due to iteration by each developer individually, without a common folder structure, without a standard... this is the common folly of iterative design, it's equivalent to shoot first and ask questions later, which is definitely appropriate in some scenarios. Imagine an app where the login page uses your standard, the home page uses nested Ultra specific css and the dashboard uses bootstrap... worst case scenario... now imagine everything in the same folder, or even just organized by file type. Plan for the future, plan for architecture... there is a big difference to me between Programming and Software Engineering.
No worries man, take care.
That's actually not true. If you're working on a giant codebase where there's no organization behind folder/directory structuring or assigned naming conventions, it'll prolong your onboarding process a great, great deal.
Being organized with this kind of stuff means being cost-effective and empathetic to your coworkers.
you have find in files, your folder structure is irrelevant in this context, that is how as somebody who had no-one to onboard me got around and its battle tested, its true in my context certainly not false.
I have also stated that at a small scale, no structure a flat structure is sufficient at a prototyping phase, adding what you need, when you need it. Im sorry if you disagree but from my experience thats what I have seen.
I think its absolutely okay and valid approach if it's a personal project. Then the only pain you'll receive there will be one of your own doing.😆 But when working with others I wouldn't advise others to "not get hung up on structure". I think that kind of mindset is a gateway to start writing legacy code that nobody wants to touch in the future because messy/sticky/non-comprehensive.
My point is iteration is superior to perfection and organisation that will change countless times in the beginning, why don’t you as an experiment write a todo list in a flat structure with no folders, and then explain where the folders start to be needed, that would be an interesting post no?
Not really following your thread there. Anyway - all I know is that if I had to work with someone who had zero care in the matter, I'd be worried about the impact that developer's code would have as far as maintainability goes. But you do you! I'm honestly not here to argue. I just felt it was important to point out another perspective. Hope you have a nice day!
I promise there is no argument here I’m also presenting the alternative point of view as well 😊 have a lovely day
Absolutely! Which is totally valid as well. Thanks.😊
I really enjoyed this thread, it is insightful. Learnt alot from you guys perspective.
I use well-structured folders so I don’t have to rely on find in files.
Really man, this is old 1980s vim approach. Software architecture is very important, you don't have any of it if all files are flat in a 1000 file application. But even in the vim days we considered architecture. Iteration is actually the least effective method of implementing, short and long term. How would you feel if they built bridges via iteration, why would this be okay for heart monitor software, or even a web-based front-end where personal information can be leaked... there is only one reason, lower upfront cost if you ignore architecture, régulation, new hire onboarding time, comprehension time for when devs modify each other's code, etc, etc.
But when you start a business, actual operating costs far exceeds upfront... so plan for the future and flat file word search ain't it... at least use the IDE click to go feature, faster than typing when tracing and also confirms object is accessible in real time.
Op:
80s eh, I’m not that old and I don’t use vim 😂
I dont understand what this mean, can you write in plain english? Thanks
Bristolian to English translation:
Thanks but I disagree with you on keeping the styles in assets directory.
I like to organize folders per functionality context rather than architecture layer. For instance i can keep only a components and a utile folder, everything else depends on the project. Eg: eg i may have an auth folder for all things related to authentication, or a transformers folder to store all the modules that are used to convert a data type to another or a cart folder for all the modules related to my e-commerce cart logics.
I also like to design my code to minimize the number of call stacks.
Folder by functionality is also a great method of structuring web application, Other devs can easily understand your application features 👍🏾 .
This is the reason I prefer Angular.
Spent 3 years doing angular, 3 years doing react. They are truely about equal, each has its strengths. As I recall in angular the value attribute connects to the controller, in react its really the onchange event more so, I did like than in angular better. Angular separates view and controller explicitly, react combines and encapsulates them by default, but still easy to externalize. I find react hooks are more pleasant to work with than the angular equivalent, forgot the term, been a while. Also the child composition aspect of react is great when used right. Angular development focuses a lot on separating view and controller, classic mvc approach that is solid, many advantages. React on the other hand focuses on separating the view layout logic from the view logic (e.g. submit)... layout is king in react, Controller is king and View is queen in angular. I have a lot more fun in react but it takes a while to really understand it and use it correctly compared to angular. Angular is kinda like php + js to but with a modern templating engine, react changes the paradigm more... for better or worse depends on the property and application.
same here
Seems to me like a good approach initially (means for small sized projects), but very bad on enterprise level projects.
My Point of view is to create a structure more like
modules/featurebased and keep some commonfunctions/classesor whatever in a separate folder such ascommon/core.Yeah not bad, very generic though, not every project needs all these folders, and some projects need more/other folders ... another remark is that oftentimes much of the folder structure tends to be more or less 'dictated' by the framework that you're using.
The distinction between views and pages is pretty vague - views are supposed to be "higher level" than components, but "lower level" than pages?
(funny how I'm in fact contradicting myself because in my latest project I have indeed "components", "views" and "pages", so it seems to fulfill a need, lol)
This is horrendously bad advice. The article is basically recommending organizing by type as the first layer, instead of subject. But this is precisely the reason modern large codebases are so difficult to maintain and are bugy and insecure and cost insaine inappropriate quantities of cash to maintain.
My main advice would be this:
When designing architectural structure one must know what one is building. This is rarely the case in the web world were iteration is king, unfortunately. This is why it is key to refactoring and refactoring often with iterative architectural solutions.
But be warned, you do it like this app suggests, and it's a huge complicated app used by millions, it will be a costly nightmare in the long term.
Thanks for your comment, I really appreciate it. I will use your advice on web projects from now on 👍🏾.
feature folder is good to know
Folders exist to be used. Just like code and tests they should be self explanatory and make understanding discovery and navigation easy. Just at important is naming of the files and co-location of certain logic.
Not one is really more important than the other but folders like layout of your application create a better DX as layout creates a better UX.
It's always interesting to see how others do it, stunt just take everyone's advice, it needs to be a team decision as with most things, but there is some definite and obvious patterns that can be learned through articles such as this.
That is functional domain partitioning. It's very good at creating small apps fast. However if extended it completely breaks down on maintenance. Recomended only for less than 30 un-nested screens.
I prefer problem domain. In all cases even if i have to write more code.
This is basically about React based structure. For everybody else, look elsewhere.
Very Useful!
Great share!
That's in addition a great publish which i really valued learning. It's not every day that people maintain the opportunity to discover something.
I wish i could see whole folder structure.
This has come just in time for me. Was starting on a Nuxt 3 project and the setup command doesn't generate an folders 😅
i'm not sure about styles, but its ok,
What about lib folder?
The lib folder comes in handy when you have dependencies/packages you are to use in your web application, Packages such as Animate On Scroll (AOS), Chart.js, Axios for external API calls. You create individual files for them, import the package and then export the required code for different pages. In general the lib folder is a place to store supporting code for your web application.
thanks for putting this up here i used to ask this question on how it’s structured in my coding bootcamp courses never got an explanation
I'm glad you found some of your questions answered in this post.
atomic design brad frost see example on arc.js.org/
that's cool, but i prefer "move the files around untill it feels right"
interesting, it is what I wanted to know :)
I've been needing this. Thank you!
Unfortunately, it's very bad when you are still using pure JS in a React project. In the real-world, we will work with a lot of developers, and each developer will be responsible for write a user story. You should put all related components into a folder.
To me this seems like a nightmare arcitecture. My experience is that on most projects there are people comming and going, many with limited experience.
By using a more horisontal arctecture projects will quickly become very messy, and if some people dont follow it correct, (which is going to happen), it will create a lot of confusion. As uncle Bob says in one of his talks => you should be able to somehow visualize the app by looking at the folder structure. Vertical/feature based arcitecture pretty much always better in my opinion... As we all need to take some shortcuts once in a while, as long as the shortcut only affect the feature your building, there is no issue because of the encaptulation. For me this description is very much the oposite of encaptulation which one of the main reason why our job as developers can be a nightmare.