Comment by christiangenco | Hacker News Reader

Comment by christiangenco | Hacker News Reader

Huh, this is interesting. I've been getting more into Meteor[1] lately, and I see a few things here that mirror my experience there:

* Concept-Driven directories (ie: having your model, views, controller, etc. for everything Comment related in the same directory). Meteor still hasn't figured out what directory structure it wants (you could make up your own and things would still work), but I've seen this in several places.

* having an object for each view (I didn't like this about Meteor at first, but it's really just stripping out logic that would have been in the view and putting it somewhere else. It actually makes it a lot easier to debug layout vs. code errors by having the view be as simple as possible)

* I was going to say use of monads, but a) I'm not sure that's what the "call style" and "run style" actually are, and b) Meteor doesn't really use monads, now that I think about it

I'm sure nothing here is unique to meteor either, but it's interesting to read about stuff like this with the added perspective of another framework.

1. https://www.meteor.com/

I've never really understood layer-level grouping. Ideally, the more likely things are going to change together, the closer together you have them.

Given that, it's less likely that you'll change the code for all your models than change the view+controller+model code for a given feature.

That's an ideal scenario, though, that implies that all of your view/controller/model through-lines can be isolated vertically from each other. In fact, controllers often coordinate the actions of multiple models to achieve higher-level objectives, and it's at this point that the relatively greater cohesiveness of layers versus features becomes apparent.

it's useful in practice for denoising file names. unfortunately rails doesn't do this at all, and every controller file is something like `app/controllers/foo_controller.rb`. in Python, if you had a file `app/controllers/foo.py` you'd be able to `from app.controllers import foo`, which is more useful and does an equally good job of declaring the file is a controller without having to write `_controller.rb` every time you do anything with a file.

Or you would just use the class because it's already in the autoload paths. Seeing a lot of opinions from people who don't actually seem to use rails.

au contraire. I have worked on what I suspect is one of the largest Rails apps out there. autoload has been off for a long time (along with many other "convenient" features) for performance reasons.

that's beside the point though, because if you're outside the Rails world you will have to type the whole name of the file if you want to do something with it.

Reply on news.ycombinator.com