3 ms·

I have been working with Rails for the last forever. I love Ruby, and I love Rails. Part of the reason why I love Rails so much is in slide 9: "Rails is designe

by joshmn 3y ago

I have been working with Rails for the last forever. I love Ruby, and I love Rails. Part of the reason why I love Rails so much is in slide 9: "Rails is designed to have agnostic interfaces." One of the reasons why I hate Rails is the steep learning curve. It's really easy to get something out the door with Rails. Whether or not it's maintainable long-term is what's up for debate. There are often 10 ways to get the same result: 1-5 are really bad, 6 and 7 are acceptable, 8 is good, 9 is great, 10 is perfect. Not everything has to be 10, or even 9, or even 8; the fewer 1-5s you have the better. The official "Getting Started" guides don't help this at all. Granted, they are indeed marketed correctly: they are for getting started. But it lends to this idea that that all Rails applications have to look that way — the "getting started" way. Many of my applications (and many of the shops I'm brought in to "better") end up shipping with more than what comes out of the box. This might sound normal to folk on HN — engineers are supposed to engineer things, after all — but it's lost on many teams and orgs. ("Many teams and orgs" are largely teams and orgs we have never heard about, and there are plenty of them.) Taking a peak at my usual interface stack includes commands, components, decorators, forms, inputs, queries, presenters, serializers, and services. This is in addition to the default controllers, helpers, mailers, models, views. My ultimate takeaway from seeing over a two dozen "this Rails app is painful to use" situations in the last two years is that the developers hadn't extended past the original patterns that were given to them when they originally spun up the app. This largely results in losing a lot of the Rails magic because developers are (unintentionally wrongfully) forced to do things that goes against Rails' expectations. There are other things besides shipping better abstractions too, obviously. The one that stands out the most is controllers doing too much and becoming God controllers; developers get lazy (or just aren't aware) and simply define routes that are RESTful in the router, but aren't in the actual controller definition. This makes for a tangled mess. There's a way to make Rails as much of a joy to use as it is when you first hit `rails new` — it just takes some experience and diligence. That can be said for every framework. But what can't be said for every other framework is that Rails makes it way too easy to write really bad Ruby code that, ultimately, gets you the "right" result. Avoiding those is the hard part. (I'm currently looking for work in case anyone wants to talk)

rtheunissen 3y ago
Replace Rails with Laravel and you get the same problem: the recommended patterns make it easy to get started but eventually work against you when things start getting big and busy.
- gv83 3y ago
  replace rails and laravel with django and...these frameworks are great, but require great discipline and the ability to factor systems correctly! but TBH, discipline + correct factoring is kinda the baseline to produce decent systems. It's still leagues better with django/rails than with "microframeworks" which are basically a giant spool of rope for anything more than a handful of endpoints
  - cultofmetatron 3y ago
    > require great discipline and the ability to factor systems correctly! is there a framework that doesn't??
1123581321 3y ago
I’ve seen developers, even experienced ones, struggle to grok a Rails app when it’s been extended like that. Once they’re up to speed they appreciate the decisions and contribute to further development. They’re just not used to seeing that, as you describe. Have you found ways to make the extended engineering of Rails easier to understand for those used to limiting themselves to the out-of-box conventions?
- joshmn 3y ago
  > Have you found ways to make the extended engineering of Rails easier to understand for those used to limiting themselves to the out-of-box conventions? Rails comes with a lot of the patterns I implement out of the box. Forms are just ActiveModel objects. Services are just POROs, as are queries. A decorator pattern can be done in 25 lines of code (https://gist.github.com/joshmn/87f14dc7d6b45a72bd4e3f4fb8d82259); https://gist.github.com/joshmn/87f14dc7d6b45a72bd4e3f4fb8d82... Commands are a bit more difficult but anything that can respond to context with flow control handling is easy to grep. There's a fine line between implementing patterns and implementing patterns that behave as Rails expects them to. Thankfully, as mentioned in Eileen's talk, Rails makes it really easy to do this. While the underlying logic may not be documented on the Rails Getting Started guides, peaking under the hood isn't as intimidating as one would think.

by joshmn 3y ago

rtheunissen 3y ago

Replace Rails with Laravel and you get the same problem: the recommended patterns make it easy to get started but eventually work against you when things start getting big and busy.

gv83 3y ago
replace rails and laravel with django and...these frameworks are great, but require great discipline and the ability to factor systems correctly! but TBH, discipline + correct factoring is kinda the baseline to produce decent systems. It's still leagues better with django/rails than with "microframeworks" which are basically a giant spool of rope for anything more than a handful of endpoints
- cultofmetatron 3y ago
  > require great discipline and the ability to factor systems correctly! is there a framework that doesn't??

1123581321 3y ago

I’ve seen developers, even experienced ones, struggle to grok a Rails app when it’s been extended like that. Once they’re up to speed they appreciate the decisions and contribute to further development. They’re just not used to seeing that, as you describe. Have you found ways to make the extended engineering of Rails easier to understand for those used to limiting themselves to the out-of-box conventions?

joshmn 3y ago
> Have you found ways to make the extended engineering of Rails easier to understand for those used to limiting themselves to the out-of-box conventions? Rails comes with a lot of the patterns I implement out of the box. Forms are just ActiveModel objects. Services are just POROs, as are queries. A decorator pattern can be done in 25 lines of code (https://gist.github.com/joshmn/87f14dc7d6b45a72bd4e3f4fb8d82259); https://gist.github.com/joshmn/87f14dc7d6b45a72bd4e3f4fb8d82... Commands are a bit more difficult but anything that can respond to context with flow control handling is easy to grep. There's a fine line between implementing patterns and implementing patterns that behave as Rails expects them to. Thankfully, as mentioned in Eileen's talk, Rails makes it really easy to do this. While the underlying logic may not be documented on the Rails Getting Started guides, peaking under the hood isn't as intimidating as one would think.