On the other-hand if you are undertaking a medium to large scale project (and not a micro-service), you probably want Rails. With Rails you have the benefit of a complete package of libraries that work out of the box and are quite extensively tested. I can almost guarantee everything else will cause you more pains, subjectively, if you really dislike the Rails style, it may be worth it.
I also have a minor quibble with the suggestion that multi-level delegation is a good coding pattern - it is a terrible pattern!
Have you ever tried to find the function you need through 3-4-levels of delegation when everything extends 5-10 different concerns? I'd much rather read - `self.parent_objects.children.function_name` in my code than `function_name` and then spend time searching where the later came from.
Also, Rails 5 is not Rails 4 is sure as hell not Rails 2--as the framework has matured, it's gotten less and less accessible to beginning devs, and has developed a jargon and mindset that sheds very little light on how the Web works under the covers and magic.
Starting with Sinatra or similar and building out and up is a much better way to end up with a real understanding of what's going on.
I think you could remove the word "Rails" and say the same about any medium-large scale software project with several developers working on it. Say what you will about Rails, but after working with it for about a decade, it's actually prevented more confusion and stupidity from creeping into the projects I've worked on rather than enabling it.
The first one decided to go "off the rails" and made up their own architecture based on Uncle Bob's SOLID design principles or whatever. We weren't allowed to use ActiveRecord, which is a huge part of how you handle domain logic, validations, relationships, cascading deletes, and data consistency in Rails. Instead of ActiveRecord Models, we had `repository` classes which basically had a bunch of raw SQL queries, we had `interactor` classes to handle all of our domain logic, and our controllers were just called `interactor` methods and returned the result.
The general architectural ideas came from a good place, but going that hard against the "Rails way" made basics tasks extremely difficult. We couldn't use any external Rails gems because our architecture violated the basic assumptions that gem authors made. We had to hand roll all of our validation logic because we couldn't use ActiveRecord. Our DB raised non-NULL exceptions all over the place because people would forget to validate certain fields, or didn't know that certain fields were required because there was no model class to clearly articulate the schema. After just 6 months the code was already a mess.
The other company I worked for embraced the "Rails way" completely. The code base accumulated a ton of technical debt and general jankiness along the way, mostly due to constantly changing business logic and integration with 3rd party services like Salesforce, but the code base was surprisingly easy to work with. The company shuffled people to different teams a lot and it wasn't that hard to onboard new devs into a given project.
What I'm trying to say in a very long-form way is that Rails, when used as it was intended, works pretty well for medium to medium-large projects. You just have to do what the framework wants you to do. It might seem restrictive, magical, or maybe even stupid, but it will prevent a lot of confusion and pain. If you really dislike the Rails ideology, it's better to just avoid the framework entirely.
I haven't bought the Trailblazer book yet but I probably will somewhere in the next couple of weeks.
Of course on the other end these popular large frameworks often have a lot more maintainers (sometimes even more maintainers per line of code) than the smaller libraries frequently only maintained by one or two people. And there are of course synergies (yes I'm using that word unironically) when all the code lives in a single ecosystem rather than being based on a unique combination of purpose-built libraries.
Having used both Django and Flask, and various front-end frameworks and libraries, I can see the appeal of both sides of the argument. In the end I haven't found either argument to be bullet-proof though. Everything is always a trade-off.
Occam's razor is misused in the manifesto. The author indicates that it means "Prefer simple solutions", which it doesn't.
Occam's razor requires a hypothesis, and generally means "Among competing hypotheses, the one with the fewest assumptions should be selected".
For example, Special Relativity is exceedingly complex, especially if I try to explain it to you. Ontologically though (in actual fact), it's the "simplest" solution to explain the real world data that the speed of light is fixed regardless of reference frame. I could come up with other theories to explain the data that might be "simpler" in explanation, but they require more and more assumptions to be made about the real world. For example, I could say that the speed of light is fixed because aliens cause all of our testing apparatus to show the same reading. For sure, that's a much simpler explanation than explaining Special Relativity. But it rests on a whole huge number of assumptions (like aliens existing, that the aliens want to mess with us, that they have the capability of doing so, etc, etc). So here Occam's razor favors the more complex theory because it makes fewer assumptions.
So saying that something is better because it's simpler and then justifying it with Occam's razor is really an abuse of the concept.
... end rant
The author invited comment directly by using a scientific/philosophical principle in his story. If you mention Occam's razor as a reason your argument is correct, and you completely get that wrong, you stand to be corrected.
So if you want to sound smart by using scientific terminology you don't understand, the scientists are going to call you on it, and that's not being pedantic.
I'd explain why, but then I'd be called a "well-actualista".
There's been a lot written on this subject that's hard to do justice here: http://plato.stanford.edu/entries/simplicity/
No magic, just developer clarity. Neither of these items seemed like a primary concern for many different Ruby libraries and Rails itself.
I also suggest trying out data mapper pattern instead of active record. Flask and SQLalchemy are extremely powerful and easy to use. Virtual data fields and all kinds of neat things that really makes working with data easy and customize for complex business requirements.
I'm much happier using Ruby + Sinatra + Sequel/ROM + dry-rb
I do admit that Rails devs develop considerably faster than me. But I get a feeling the majority of them can't make much more than a single machine monolith. Rails has a way of narrowing many people's technical curiosities. But it probably behooves both sides to learn more about each other.
> Rails has a way of narrowing many people's technical
I ended up disappointed. The piece reads in a very partisan manner, makes questionable declamations of common Ruby tools & patterns, and throws in a lot of obnoxious asides about how bad other programmers are.
Examples: "RoR is a good starting point for a young developer." Its usage encompasses just a tad more than that. "MVC is not an architecture." Just factually untrue.
That said, the lower portions of the guide have some good content and the list items describing popular gems are helpful.
I'm looking forward to moving to Elixir and Phoenix which seems to embrace the less magical, more explicit manifesto while also being the accepted solution in that domain.
On some work projects I've gotten a lot of mileage out of breaking with the traditional Rails patterns in favor of stuff like `Operation` objects. Too bad I didn't know about Trailblazer!
I also agree about Rails making excessive use of Ruby magic. Just because it's possible, doesn't mean you should do it.
Regarding non-ActiveRecord models, I use Sequel exclusively at work - in addition to being decidedly less magical, it has wonderful support for most Postgresql specific features.
I'll be consulting this in the future before embarking on new Ruby adventures.
Also, what do you use for authentication?
Sequel is my favourite of the tools I use.
Regarding authentication, my company makes authorization and access control software, so authentication isn't something we just toss a plugin at.
The kind of magic where you're given some functions to call, and some places to put your code, and if you ask why, you are told that you don't want to know, so shut up. In a non-CoC system, a lot of this magic would be exposed to the developer, so even of we didn't exactly know what was going on behind the scenes, we could at least kind of reason about it.
I hate rails because I like to be able to reason about the code that I write, the libraries I use, and what's going on behind the scenes, even if I don't know ALL the details.
Why? Because I assume that at some point, my code will break. And if I can't reason about what my app's doing, I can't fix it. And after running Ubuntu for a few years, I have long run out of patience for problems I can't fix.
Rails is open-source and extensively documented. I honestly cannot understand this take at all.
The documentation for getting a blog built in 15 minutes doesn't explain why you put your code in each place or how it's put together, because that's not the point. Rails is about making default decisions for commonly bikeshedded questions like "how do we name our database tables" so you don't waste mental bandwidth on them when you're trying to build an application. But explanations for how and why all that happens is very readily available.
For better performance I serve up json directly from Postgres.
All these additional abstractions makes it hard to migrate away later to another platform.
..three years later...
"We are upgrading to Rails."
"Put this file in this folder with this name and your app will do x".
"Because 10 years ago this file structure made a lot more sense and some people liked it so we stuck with it".
One of the keys to cheerfulness is valuing your own experience and in seeing the world as it is, faults and all.
My experience has been that a lot of stuff in the Ruby/Rails (and the Node ecosystem, a thousand times worse) ecosystem is due to well-meaning novices cranking out ever-so-slightly different iterations on the same ideas, cluttering up the package managers with not-quite-right solutions.
That, and a pervasive attitude of convention-over-configuration and self-aggrandizing that tends to place an emphasis on popularity over talent, and on talent over restraint.
I remain cheerful because that culture hasn't yet infected the Elixir community.
I am a little confused on editor suggestion, but this is geared to starting devs. I would say SublimeText all the way. Next step, obviously Vim.