The article doesn't really get into why it considers this structure better.<p>FWIW, I had a discussion a while back with a coworker who was moving away from this type of structure because it was getting untenable - every new feature required adding files into half a dozen folders and stitching them together in similar-but-not-quite-the-same way as previous ones, leading to a lot of boilerplate for the sake of consistency. In addition, it was hard to see what file was related to what. Plus, because the whole thing was locked into a set of idioms, a gradual architectural migration looked extremely daunting.<p>In my experience, there are two major philosophies when it comes to web project structure:<p>- organize by type (the approach suggested in the article) - everything of the same type goes in a top level folder named after the type of things that it contains (`components`, `reducers`, etc)<p>- organize by proximity - things are grouped together based on whether they are used together (e.g. for a splash page, the components, reducers, contexts, etc for that page all live in a folder called `splash`, and so on)<p>I tend to prefer the latter because the former usually involves a lot more folder navigation (both in terms of finding/opening files, as well as specifying paths for import declarations). It's also easier to see what files are generally related, and if one wants to gradually migrate away from some idioms (e.g. phase out redux in favor of graphql or migrate to react hooks, etc), it's easier to keep the impact of changes localized.<p>The "organize by type" approach, however, is good for organizing things that are consumed from multiple places: think theme components (buttons, etc), reusable utilities, data modeling logic, etc.