[HN Gopher] The Rails Doctrine
___________________________________________________________________
The Rails Doctrine
Author : thunderbong
Score : 123 points
Date : 2023-05-13 13:36 UTC (9 hours ago)
(HTM) web link (rubyonrails.org)
(TXT) w3m dump (rubyonrails.org)
| fallingmeat wrote:
| Why do similar articles or headlines seem to come up at the same
| time on front page? e.g. there is another article on Rails that
| happens to be front page right now that is seemingly otherwise
| unrelated (the other article is called The Rails Cheat Sheet).
| revskill wrote:
| Because people love Opinionated Monothlic to "flexible,
| unopinionated, microservice, cloud native architecture"
| nowadays.
| sodapopcan wrote:
| I used to love Opinionated Monothlic. I still do but I used
| to too.
|
| I've since moved on to Elixir's Phoenix. Not quite as
| opinionated as Rails but many of the low stakes decisions
| have been made.
| dceddia wrote:
| I've noticed this too sometimes and I think it's like a "meta"
| conversation on HN. It happens pretty often and I think people
| see an article about X, which reminds them of some other good
| article about X, and then they both end up on the front page
| because "hey we're talking about X today!"
| [deleted]
| makotech221 wrote:
| The thing about building an opinionated framework is that
| sometimes your opinions suck. I hate using RoR at my job, I curse
| it every day. How in the hells do you think allowing gems to run
| their own code without being called is a good thing?
| strzibny wrote:
| I like what Rails offers. I like it to the point that I am now
| creating a SaaS template[0] that packs all of Rails has to offer.
|
| That includes using frameworks like Active Storage, features like
| CurrentAttributes or defaults like Minitest.
|
| Some of it is controversial or not favoured by community. Not
| many people experience Rails with the core value it's designed
| around which is a shame!
|
| It's great you can replace certain parts, but should you?
|
| [0] https://businessclasskit.com/
| clairity wrote:
| yes! i'm doing something similar on a personal project, trying
| to leverage the rails conventions as much as i can, and so far,
| it's been a real net gain in productivity from something like
| rails 5.2/6. i'm using the bleeding edge rails 7.1.alpha, which
| has a number of niceties like built-in password challenges,
| template locals, common table expressions in AR, and default
| dockerfiles (which i don't use), pluse better support for
| encrypted attributes and (postgres) enums. i'm also using some
| new-ish ruby features like endless methods, which is
| surprisingly useful for thinking about how to make methods more
| atomic and modular.
| absoluteunit1 wrote:
| Hacker news today:
|
| 6. Rails Cheatsheet
|
| 7. The Rails Doctrine
|
| Interesting coincidence. Right on top of each other too.
| k099 wrote:
| This happens routinely on HN. People read one thing, which
| causes them to remember or discover something else on the same
| topic, and submit that. People likely to upvote one will likely
| upvote the other. Frequently, that second submission started as
| a top HN comment in the first submission.
| yawboakye wrote:
| revisionism is a dangerous endeavor. react is vastly more popular
| than rails but doesn't exalt any of these so-called bedrock of
| rails' popularity and longevity. rails appeared at the right time
| and commented itself as the go-to framework for web development.
| it enjoyed a monopoly of the worse-is-better crowd's time and
| energy. it had a curious coincidence with agile manifesto and the
| surge for software-as-a-service business. in my opinion, it
| cemented its place. it's losing now, to both rails-esque and
| anti-rails framework but it will be a while until it isn't among
| first 3 recommended frameworks for building web/API-based
| software. the doctrine is largely nonsense.
| tinco wrote:
| It cemented itself amidst a whole bunch of web frameworks that
| didn't achieve its success. If you don't believe that's because
| of its doctrine you're fooling yourself. When Rails gained not
| just popularity but great success (as measured in successful
| businesses launched on it) the back end web development
| framework market wasn't some uncontested market ripe for the
| taking. PHP was still picking up speed, Java frameworks were
| released every semester, Microsoft was packing features into
| .Net at a steady clip, I think even Django was already well
| loved in the Python community.
|
| That a framework built on a programming language no one even
| knew existed would become the most effective web development
| platform for the better part of the next 5 years was beyond
| anyone's expectations. It's because Rails was built on
| consistently good or great decisions, and the only way to be
| that consistently good is to have a doctrine guiding you.
|
| From the outside it might look quirky, but having a strong
| opinion on how things should be done specifically for developer
| productivity and happiness has been a corner stone of the Ruby
| community since its inception.
| davetron5000 wrote:
| These almost entirely boil down to DHH's personal preferences--
| which is fair enough as it's his framework--but I don't really
| see these helping in any general way to understand Rails beyond
| "whatever DHH wants is his framework".
|
| If you want to understand the core values of Rails they are:
|
| * Implicit behavior through conventions regarding core features
| like databases and routing * The framework has a reasonable
| built-in for anything you'd need to make a web app * Major new
| features or changes usually originate from DHH and 37 Signals
|
| The stated values are mostly useless:
|
| * Programmer happiness - completely subjective as to who is being
| made happy. Lots of Rails things make lots of people unhappy just
| as much as the opposite.
|
| * Convention over Configuration - this is the only clearly stated
| value and it is basically the core ethos of Rails, even though it
| really means "as compared to J2EE". Rails has a TON of
| configuration you still need to do on any project.
|
| * The menu is omakase - the text explains better, but the point
| is that everyone should use the selected tools and yet a good
| chunk of Rails developers deviate from stuff like minitest,
| fixtures, etc. That the defaults can be swapped out was never a
| goal of DHH's and I think they exist only because of the merge
| with Merb way back when.
|
| * No one paradigm - this is just a retcon for how different parts
| of rails are different from no really good reason. Why are
| helpers a big blob of global functions? Why does a controller
| expose data to the view via instance variables? Why do schema
| migrations default to nullable fields and no foreign key
| constraints? Why do you define instance methods on mailers but
| invoke them as class methods? There's no rhyme or reason to this.
| It's not bad, but it's also not the result of deeply thinking
| about the best way to approach these problems.
|
| * Exalt Beautiful code - DHH sets the standard of beauty. This is
| possibly the worst part of the doctrine because when others adopt
| this it leads to constant infighting about style and other
| pointless things. If you've ever seen any of Basecamp's code
| online, I would not personally call it beautiful. As a doctrine
| for an open-source project this is useless.
|
| * Provide sharp knives - this is a curious one both in text and
| analogy. What he's saying is that "dangerous" features should be
| OK because people should be trusted to use them. Fine, I guess,
| but if you do any home cooking, sharp knives are far more safe
| than dull knives. And any language feature can be abused. What is
| very frustrating about Rails is these "sharp knives" tend to be
| unobservable so it's hard to know what is happening and why.
|
| * Value integrated systems - this is where it is either DHH's
| lack of experience or just flat out delusion, because Rails
| provides exactly nothing to help scale a monolithic system to
| hundreds or thousands of developers and tons of performance
| requirements. It can be done - look at Shopify and GitHub - but
| nothing about Rails gives you a leg up on what is required to
| build a monolithic system. THAT SAID, like configuration over
| convention, this does demonstrate Rails value in a roundabout way
| - you get mostly what you need in one package and, unlike the JS
| ecosystem, don't have to piece it together on your with starter
| packs and boilerplates
|
| * Progress over stability - Maybe initially this rang true, but
| Rails has been extremely stable for a long time, and that's a
| good thing. The team does a great job of deprecating things and
| providing an upgrade path, and Rails happy path features very
| rarely break between versions. But what progress has Rails made
| at a high level? It still works more or less as it did when it
| came out. This is totally fine and should be heavily promoted as
| an alternative to the constant change, rot, and churn in the JS
| ecosystem.
|
| * Push up a big tent - this is almost entirely untrue. DHH does
| not value this. Maybe he did when this was written, but he does
| not value diversity on any real level, at least not based on his
| written words and public actions. This includes "diversity of
| thought" as well as "diversity of people".
|
| The Doctrine is a nice idea, but I don't see how it helps anyone
| really understand Rails beyond "DHH's framework". And again,
| that's fine. It's his framework. He doesn't have to explain
| himself and, to be honest, I kinda wish he wouldn't.
| AugustoCAS wrote:
| I stopped at the first point out of sadness. I've worked on the
| JVM space for 19 years. For the last 1.5 years, I've been working
| in an org that uses Spring Boot and the code, configuration, and
| general designing of the applications feels horrendous. I know
| spring boot was the 2nd (or 3rd?) attempt of Spring to get a
| quick development framework simiar to Rails (Spring Roo was the
| first I think) but my gosh it has soo much magic, and it's so
| slow. Starting up a app can easily take 20+ seconds, and the full
| start/stop cycle can take 60+ seconds. On production we often
| have apps taking longer than 2 minutes to boot up and the only
| thing they do is open a few connections to the database and to a
| messaging broker (both which are very fast). The component
| scanning "feature" is a disaster.
|
| I love ruby and find it and I know Rails also has some magic, but
| I love my types. I'm glad I'm going back to do something sensible
| in a few months. Probably Kotlin + http4k.
| throaway23432 wrote:
| As an ex-Rails developer, It's unlikey I'd return.
|
| Rust/Go/Elixir/Gleam/Kotlin/Clojure/Crystal/TypeScript are all
| infinitely better, in my experience.
|
| There are so many options now, you just need to explore them and
| go outside your comfort zone.
|
| If I ever did use Ruby again, I would use Jets over Rails.
| ekvintroj wrote:
| I used Rails for over 5 years, and both Rails and Ruby were
| elements that I never had to struggle with to get things done.
| However, they did have their secrets, and mastering such complex
| tools can be challenging. I always appreciated DHH's critical
| attitude, and although I don't like many of Rails' design
| decisions (such as the use of AR vs. Repositories), I think it
| solves many typical web development problems out of the box.
| However, with JavaScript, Kotlin, or Python (to name a few), you
| have to do all of that manually or they don't measure up.
| yuppiepuppie wrote:
| As someone who doesn't use rails at all, I found this refreshing.
| In my day to day, I'm exhausted by the endless arguments that
| arise from using an unopinionated framework, the likes of fast
| api or flask. I'm not sure that these argument provide any value
| to the users we build for. I wish more frameworks would layout
| their values like this and let the developers who use them stop
| talking about these "invaluable" points.
| philwelch wrote:
| There's a lot of value in having decisions made for you ahead
| of time. Nonetheless, decision fatigue is one of the things
| that annoyed me most about Rails after working in it for the
| first few years of my career; the flexibility and
| "expressiveness" of Ruby syntax makes it so writing code is a
| series of pointless decisions. Do I use parentheses in my
| function call? Do I use do/end or braces? Array indices or
| helper methods like .third? I've grown to question the value of
| this sort of thing. Rubyists used to say that various Ruby
| frameworks were DSL's (DHH here restrains himself to saying it
| "looks like" a DSL) but frankly, leaving the parens off of
| method invocations isn't a very convincing magic trick once you
| know how it works, and it's not worth having to second guess
| whether to use parens every time you want to call a method.
| LapsangGuzzler wrote:
| ...or you can use a standard formatter like standardrb and
| end that conversation entirely.
|
| You're right, it's easy to bikeshed on which syntax
| constructs are more elegant, but the Ruby ecosystem provides
| tools to eliminate the need for that conversation.
| philwelch wrote:
| > ...or you can use a standard formatter like standardrb
| and end that conversation entirely.
|
| This is the solution I've gravitated to in other languages
| (e.g. Black, gofmt), but that was after my time in the Ruby
| ecosystem.
| hakunin wrote:
| While those decisions are completely meaningless as far as
| performance or correctness of your program goes, they do have
| value for readability. One way to deal with them is of course
| to install something like standardrb and never think about
| it. The other way is to read the code you just wrote, and see
| what reads clearer/better in a specific case.
| philwelch wrote:
| > The other way is to read the code you just wrote, and see
| what reads clearer/better in a specific case.
|
| Yes, that's the extra decision step in my main workflow
| loop that I'd like to cut out whenever possible.
| hakunin wrote:
| I think in general it's almost impossible to cut out
| human consideration and still get auto-clarity. With an
| auto-formatter you gain a little speed and lose a little
| readability. I think most people are really arguing about
| whether this trade off is worth it. Some are arguing that
| any readability gains are minimal (and debatable), but
| then it's like arguing that there's no point to being a
| better writer, and information can just be auto-formatted
| for human consumption with a set of standard heuristics.
| I guess we might actually get this world once everything
| is written by ChatGPT to maximize consistency. But then,
| how can we both claim to like complete and total
| mechanical consistency in code, and dislike it in any
| other form of writing? If code can be written more than
| one way, shouldn't we optimize it the same way for fellow
| devs as good writers would for their readers?
| andrewmutz wrote:
| That's interesting. I've had the opposite reaction to those
| many little decisions: it doesn't matter. Do whichever you
| like. All of the options are sufficiently readable.
| sodapopcan wrote:
| It matters somewhat. I had a coworker who used to avoid
| parens any time it was possible which I found incredibly
| annoying: "foo bar" .split(" ")
| .map(&:capitalize) .join " "
|
| There is really no advantage to not putting parens for the
| `join` call. Meanwhile, it makes modification a pain as
| well as makes for some ugly diffs.
|
| But as a sibling comment mentioned: just use a linter.
| weaksauce wrote:
| the convention that i think most rubyists gravitate
| toward is to always include parens for method calls when
| calling something that takes a parameter. omit if there
| are no parameters.
| sodapopcan wrote:
| It is, and it's how I do it when I write Ruby. I was just
| responding to "it doesn't matter" part of the parent
| comment. If you decide not to use parens, then you get
| situations like the one I illustrated where you have to
| use parens for chaining then you're left with a decision
| about what to do with the last one.
| andrewmutz wrote:
| Why are the parens important in this example?
| sodapopcan wrote:
| You can't chain without parens. # Does
| not work "foo bar" .split " " .join
| " "
|
| There was a proposal to introduce a "pipe" operator at
| one point which was shot down [0]. It wasn't actually a
| pipe operator at all and really just an operator that
| would have made the previous syntax possible (|>, instead
| of .)
|
| [0] https://dev.to/baweaver/ruby-2-7-the-pipeline-
| operator-1b2d
| epidemian wrote:
| Yes, definitely omit parentheses when calling a method
| without arguments.
|
| For calls with some non-block arguments, it's not so
| clear-cut as "always include parentheses".
|
| Some methods are so prevalent that they almost become
| part of the language "syntax", even though there's
| nothing syntactically special about them. For example,
| you rarely see parentheses used on calls to
| `attr_accessor` or `private`: class Cat
| attr_accessor :fluffiness private def
| plan_world_domination # TODO end
| end
|
| I think parentheses around `private(def some_method ...
| end)` would be especially non-idiomatic. Even though
| passing the result of the `def` expression to the
| `private` method is exactly what's happening.
|
| Another place where it's usual to omit method call
| parentheses is on embedded DSLs. For example, in RSpec
| it's uncommon to include parentheses on calls to
| `describe` or `it`. describe "RSpec DSL"
| do it "looks neater without parentheses" do
| # ... end end
| weaksauce wrote:
| yeah there will always be edge cases but those are few
| and why i hedged with gravitate toward. private feels
| like a part of the language actually like an if statement
| instead of a method though.
| solatic wrote:
| "Programmer happiness" is such a provocative point.
|
| Anyone who is giving Rails a serious look, should take the time
| to read Eloquent Ruby. When Rails prioritizes programmer
| happiness, what Rails is really doing is prioritizing the
| happiness of the lone rockstar developer who is the sole writer,
| owner, and operator of that codebase. You can build some code
| that is, yes, quite eloquent. It will be a complete work of art
| (and yes, Eloquent Ruby was quite illuminating at how Ruby
| uniquely helps you to write code as art). It will read like
| English. Your productivity will be phenomenal. You will feel like
| you can cure cancer by yourself. But all that flies out the
| window once you need to share that code with someone else, or
| inherit a codebase from someone who thought of himself as Da
| Vinci and his codebase as a modern Sistine Chapel. Then it
| becomes a _colossal pain_. Because while the codebase itself
| might be art, the shared context for how to work within that art
| is nowhere to be found.
| hakunin wrote:
| You're right that if your goal is to write English-like code,
| then clarity may suffer. The same is true if your goal is to
| write consistent strict mechanical code. The only goal I think
| that makes sense, is to go for clear code based on shared
| context with your team. That said, I don't see how the rails
| doctrine inhibits one's ability to write clear code.
| JeremyNT wrote:
| This is so far divorced from my experience, like we're not even
| thinking about the same software.
|
| Rails is very opinionated, and when I've encountered new rails
| code bases they are easily legible to me and can readily be
| understood.
|
| Even outside of rails, the largest real pitfalls of clever ruby
| I've seen are related to gratuitous use of metaprogramming,
| which one can sometimes encounter if you need to maintain or
| find a bug in a gem you aren't familiar with.
|
| Maybe your problems weren't with rails, but with the
| programmers of the code bases you were looking at? I believe
| it's possible to write unmaintainable code in any language.
| weaksauce wrote:
| Eloquent Ruby is a simply fantastic book that should be
| required reading for everyone. and yeah inheriting someone
| else's codebase that has a gem that installs some new dsl that
| you have no idea where it came from can be a nightmare.
| danmaz74 wrote:
| I've been using Rails for over a decade and worked on lots of
| different Rails code bases. Contrary to what you're saying, my
| experience is that the philosophy of "convention over
| configuration" usually makes it very easy to delve into a Rails
| project you don't know, as long as the developers didn't decide
| to go off the rails with experimentation.
|
| Then of course you can find badly written code in any language,
| and if a quirky would-be rockstar creates a project thinking
| about art instead of readability and maintainability, they can
| definitely create an unmaintainable mess with Ruby on Rails -
| there is nothing preventing you from doing that.
| seattle_spring wrote:
| Oh boy does this comment resonate with my experience. Several
| times now I've had incoming Rails enthusiasts insist that RoR
| is the absolute best solution to all problems. Inevitably, once
| the project has more than 3 engineers, it becomes a disjoint,
| indecipherable mess that eventually gets re-written entirely.
|
| I've said it once and I'll say it again: Rails is the least-
| scalable framework ever _when it comes to # of engineers._
| Someone is surely going to respond "you can just add more
| instances!" Not what I'm talking about, though it's bad in that
| department too.
| TenJack wrote:
| I'm curious, what do you think the most scalable backend
| framework is (engineer wise)?
| eviluncle wrote:
| what kind of codebases were you working on? I've had the
| pleasure of working on 2 big companies using rails, each with
| well over 50 engineers and the code base was so relatively
| easy to jump into. The beauty of rails is that if you follow
| its guidelines, anybody can jump right in.
|
| what alternatives do you find are better when scaling up with
| more engineers?
___________________________________________________________________
(page generated 2023-05-13 23:01 UTC)