# How the View side is organized **URL:** \ **Category:** A May Of WTFs\ **Created:** [May 15, 2020, 6:22pm UTC](https://discuss.rubyonrails.org/t/how-the-view-side-is-organized/75139 "2020-05-15T18:22:25Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![marcandre](https://sea2.discourse-cdn.com/rubyonrails/user_avatar/discuss.rubyonrails.org/marcandre/32/1695_2.png) [@marcandre](https://discuss.rubyonrails.org/u/marcandre)\ **Post date:** [May 15, 2020, 6:22pm UTC](https://discuss.rubyonrails.org/t/how-the-view-side-is-organized/75139/1 "2020-05-15T18:22:25Z")
I’ve always felt that the View side being compartimentalized in `app/views/path/to/view.html.erb`, `app/helpers/path/to/view_helper.rb`, `app/assets/javascripts/path/to/view.js` and `app/assets/stylesheets/path/to/view.css`, with the controller `app/controllers/path/to_controller.rb`. For general site-wide JS and CSS that’s fine (a bit like there’s `lib/` / gems to put general code), but I feel that it is putting closely related things very far from one another in the tree of documents of a Rails app. The fact that some files are in `javascript` and `stylesheets` is also redundant, we know that from the extension anyways. I imagine they are currently organized this way because of how they get delivered, instead of how they are logically related. The fact that all CSS will typically be regrouped in a big file shouldn’t mean that they have to be grouped together to start with. I feel that `view.html.erb`, `view_helper.rb`, `view.js` and `view.css` belong together and I wish that, by default, they would be (or at least could be) in the same folder. The controller could be one level higher too. Thanks ---
**Author:** ![samsaffron](https://sea2.discourse-cdn.com/rubyonrails/user_avatar/discuss.rubyonrails.org/samsaffron/32/596_2.png) [@samsaffron](https://discuss.rubyonrails.org/u/samsaffron)\ **Post date:** [May 15, 2020, 11:54pm UTC](https://discuss.rubyonrails.org/t/how-the-view-side-is-organized/75139/2 "2020-05-15T23:54:28Z")
I think though that this would be at odds with the move away from sprockets and webpack. I wonder if this ties in to [https://discuss.rubyonrails.org/t/interactive-rails-new](https://discuss.rubyonrails.org/t/interactive-rails-new) discussion. If you are building a Rails app with extremely limited amounts of JavaScript this style of organization could work for you. ---
**Author:** ![sdubois](https://avatars.discourse-cdn.com/v4/letter/s/a3d4f5/32.png) [@sdubois](https://discuss.rubyonrails.org/u/sdubois)\ **Post date:** [May 16, 2020, 5:26am UTC](https://discuss.rubyonrails.org/t/how-the-view-side-is-organized/75139/3 "2020-05-16T05:26:42Z")
> [@samsaffron](#): > > the move away from sprockets and webpack @samsaffron could you by any chance elaborate on that? ---
**Author:** ![ferngus](https://sea2.discourse-cdn.com/rubyonrails/user_avatar/discuss.rubyonrails.org/ferngus/32/5127_2.png) [@ferngus](https://discuss.rubyonrails.org/u/ferngus)\ **Post date:** [May 16, 2020, 7:14am UTC](https://discuss.rubyonrails.org/t/how-the-view-side-is-organized/75139/4 "2020-05-16T07:14:34Z")
Think grouping CSS / JS together with the markup would be a leaky structure as CSS and JS inherently have global state. It’d be really easy for CSS / JS in different controllers to clobber each other without any tooling enforcement. ---
**Author:** ![mdh](https://sea2.discourse-cdn.com/rubyonrails/user_avatar/discuss.rubyonrails.org/mdh/32/1254_2.png) [@mdh](https://discuss.rubyonrails.org/u/mdh)\ **Post date:** [May 16, 2020, 9:21am UTC](https://discuss.rubyonrails.org/t/how-the-view-side-is-organized/75139/5 "2020-05-16T09:21:24Z")
I think there is inherently something sensible about the approach you have suggested when designing and developing from a component based point of view. It’s not a coincidence that most front end frameworks have some variation on this which at the end of the day allows you to say “this is a self contained search bar component” for example. Outside of this I don’t see it as any kind of obvious improvement over what Rails offers currently. However, there are ways of achieving this currently as you described. One way I’m currently playing around with is through using native web components where everything I need for a single component is by default grouped together and doesn’t leak CSS or JS outside of itself. I’d recommend playing around with it if you get a chance. I’m curious to hear others opinions on it!