Sorry, but this article is bullshit. First of all, it's a classic appeal to emotion; it uses hyperbole that is propped up with emotions ("You’ll find yourself

Sorry, but this article is bullshit. First of all, it's a classic appeal to emotion; it uses hyperbole that is propped up with emotions ("You’ll find yourself staring at incomprehensible mega-frameworks maintained by developers who are unapologetic about how little they care for writing documentation", etc) and not by concrete facts. It cleverly it uses two fictitious quotes to imply it represents real people's complaints, when it's in fact the author himself making up the supposed complaints. It also works up a strawman argument: That you can criticize Rails on the basis of a collection of frameworks that the OP apparently thinks are required to good apps. The fallacy here is that those frameworks are not needed, and their problems are not Rails' fault. Perhaps there is subculture of engine-loving Rails people out there that promote such frameworks, but I would not listen to them any more than I would listen to PHP devs. Rails is like any other tool: What you get out of it depends on how you use it. Judicious use of gems, libs, frameworks, databases etc. is just as important as managing your own application complexity. Sorry, but complexity is bad whatever language or framework or whatever you use. If Rails is an easy target it's probably because the apparent ease of implementation makes it tempting to grow your app. Here's a suggestion, a constructive suggestion: Try not to stuff you app with everything you can possibly think of. Login and user accounts? Belongs in a separate app. Document storage? Separate app. Image upload and scaling? Separate app. Email and SMS notifications? Separate app. Integration with external systems such that you feed data to, or from? Separate app. Computing scores or ranks or other statistics based on data? Separate app. And so on. Use a service-oriented architecture for everything, and you will reduce the complexity of each component to a bare mimimum. For example, we use Checkpoint [1] to integrate logins (FB, Twitter, Google) through a single system, so that our apps don't need to deal with API keys or OAuth or anything; performing login in an app using Checkpoint is literally a single line of code (a redirect). Instead of using a database, most data fits into Grove [2], a structured, hierarchical, indexed data store on top of a relational database. Instead of reinventing rating and voting systems for every app, we use Kudu [3], and instead of reinventing flagging of spam or illegal content for every app, we use Snitch [4] -- just to mention a few trivial examples. Our stable of mini-apps has much more, a small ecosystem of reusable, composable tools. By using HTTP as interface glue, we put an artificial limit on the ways that components can entangle themselves; for example, since the API deals entirely with basic JSON objects like arrays, strings and hashes, there are no surprises when you try to access the result of a call, since it will never re-enter its source (unlike, say, ActiveRecord associatons). [1] https://github.com/bengler/checkpoint https://github.com/bengler/checkpoint [2] https://github.com/bengler/grove https://github.com/bengler/grove [3] https://github.com/bengler/kudu https://github.com/bengler/kudu [4] https://github.com/bengler/snitch https://github.com/bengler/snitch