Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Trailblazer: A new architecture for Rails

github.com

Post reply on HN
Print view View original

21–30 of 53 posts

Re: Trailblazer: A new architecture for Rails

#21

Post by picardo »

jamie_ca wrote: post #19
picardo wrote: post #17

This "architecture" changes so much about Rails that I don't know why it's trying to build on Rails at all. If you don't like the Rails Way, just create another framework.

Because Rails has 10+ years of development on backend tooling that shouldn't be nixed or reinvented on account of a reorganization of files? Yes, it replaces view rendering completely with Cells, but routing, dispatch, request serialization, activerecord, asset pipeline, rails-provided view helpers and more are all used basically as-is.

The view rendering doesn't need to be done by Rails. I've been using React and Webpack to build the clientside of my Rails apps and have been very happy with that approach. There is nothing that this architecture does that a clientside framework like React cannot do better.

Re: Trailblazer: A new architecture for Rails

#22

Post by dominotw »

ebiester wrote: post #7
germanogmn1 wrote: post #3

Architecture Astronaut

Say that again after you have to learn a rails app with 1500 line models built "the rails way." Controller -> model breaks down when you reach a certain size. Or worse, giant controllers and models with no clear distinction.

I thought the original promise of rails was that you could use traditional OO concepts to combat complexity.

Rails doesn't tell you to stuff all your logic into models.

Re: Trailblazer: A new architecture for Rails

#23

Post by KurtMueller »

picardo wrote: post #21
jamie_ca wrote: post #19

Earlier quoted context omitted.

Because Rails has 10+ years of development on backend tooling that shouldn't be nixed or reinvented on account of a reorganization of files? Yes, it replaces view rendering completely with Cells, but routing, dispatch, request serialization, activerecord, asset pipeline, rails-provided view helpers and more are all used basically as-is.

The view rendering doesn't need to be done by Rails. I've been using React and Webpack to build the clientside of my Rails apps and have been very happy with that approach. There is nothing that this architecture does that a clientside framework like React cannot do better.

Do you use Flux as well? Do you use a router system or still let Rails do most of the routing?

Re: Trailblazer: A new architecture for Rails

#24

Post by mjbellantoni »

picardo wrote: post #17

This "architecture" changes so much about Rails that I don't know why it's trying to build on Rails at all. If you don't like the Rails Way, just create another framework.

I think Nick should be applauded for his attempts over the years to find ways to introduce interesting architectural concepts into the Rails world.

Re: Trailblazer: A new architecture for Rails

#25

Post by picardo »

KurtMueller wrote: post #23
picardo wrote: post #21

Earlier quoted context omitted.

The view rendering doesn't need to be done by Rails. I've been using React and Webpack to build the clientside of my Rails apps and have been very happy with that approach. There is nothing that this architecture does that a clientside framework like React cannot do better.

Do you use Flux as well? Do you use a router system or still let Rails do most of the routing?

Yeah, I do use Flux, and I love it. I use a mixture of both Rails and a clientside routers, but Rails does most of the work for sure.

Re: Trailblazer: A new architecture for Rails

#26

Post by mattmcknight »

"Trailblazer is a thin layer on top of Rails. It gently enforces encapsulation, an intuitive code structure and gives you an object-oriented architecture."

Rails already has all three of these things...trying to put another layer on top only makes things more complicated...

Re: Trailblazer: A new architecture for Rails

#27

Post by mrbrowning »

sbov wrote: post #16
christiangenco wrote: post #15

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 p…

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.

Re: Trailblazer: A new architecture for Rails

#28

Post by rafekett »

sbov wrote: post #16
christiangenco wrote: post #15

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 p…

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.

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.

Re: Trailblazer: A new architecture for Rails

#29

Post by rafekett »

picardo wrote: post #17

This "architecture" changes so much about Rails that I don't know why it's trying to build on Rails at all. If you don't like the Rails Way, just create another framework.

as much as I don't want to quote dhh about anything: http://david.heinemeierhansson.com/2012/rails-is-omakase.htm...

in short, since Rails 3 there is no "Rails Way"

Re: Trailblazer: A new architecture for Rails

#30

Post by rafekett »

ebiester wrote: post #7
germanogmn1 wrote: post #3

Architecture Astronaut

Say that again after you have to learn a rails app with 1500 line models built "the rails way." Controller -> model breaks down when you reach a certain size. Or worse, giant controllers and models with no clear distinction.

I think the issue is monorails (monolithic rails apps). If you have a single domain object you're representing that's that complex, you'd done a poor issue of modeling your domain. It doesn't matter if you write the logic in the model or controller, at that point you're just pushing code around -- you need better abstractions.
Post reply on HN