| 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. |