[rtheunissen]

A framework is no good if it requires that the engineers working with it are excellent in order to not create a mess. A great framework or language _should_ empower participants with average ability and experience to produce good results.

[dasil003]

What's an example of a framework that meets this bar? In my experience, the messiness is generally a function of scope, team size and technical ability. Some languages / frameworks give you better or worse tools for managing that scalability, but context matters (right tool for the job) and none can guarantee a good result if the team is weak. What really matters is the technical leadership, who must have both the experience, and sufficient influence, to avoid going down a path of crippling technical debt that eventually strangles the system.

As far as Rails goes, for all it's shortcomings, people forget what web development was like in 2003. The dominant paradigms were overwrought XML-powered J2EE with incredibly low power-to-weight ratio for web development, or unstructured PHP wild west stuff. These days every language has a framework that was heavily influenced (directly or indirectly) by Rails. Sure I wouldn't use Rails everywhere (1000+ engineer team: java, lots of concurrency: elixir/erlang, lower-level large systems: go/rust, etc), but it still has a great sweet spot from the prototype to moderate sized web app / API. Things that become weaknesses as you scale (eg. ActiveRecord pattern) are based on contextual tradeoffs that need to be made thoughtfully versus declaring them table stakes for all web frameworks.

[joshmn]

I think the problem is a little more subtle.

With Rails, you can call `relation.map(&:id)` and `relation.pluck(:id)` and get the same thing — an array of `id`. But using map is 50x slower because it loads the entire model into memory (ActiveModel is very expensive) before enumerating; pluck fires a query and hits the result set from ActiveRecord — very inexpensive!

Average ability participants then fall for this foot gun (and others like it) and end up designing things poorly. One overlook quickly turns into accelerant at scale. This isn't unique to Rails, but Ruby — the delight that it is — makes it almost too trivial to do.

I've seen this happen at Rails shops many of us have an account on, where I wouldn't consider the people I worked with average ability participants either.

[Sivart13]

But if you’re going to render those `relation` records in a paginated list anyway, pulling them into memory is superior so you don’t hit another DB round trip delay.

Which is to say, there’s a lot of ways to do things, and trade offs between the different ways, but isn’t that the case with any library or framework?

[joshmn]

> But if you’re going to render

Sure – if – that's fine and optimal! In larger apps, where there's more complexity, there are so many paths that aren't that trivial and that's where the trouble begins.

[gls2ro]

I dont understand how come a framework will help you avoid that.

You can do a similar performance issue with anything: here is a raw example: give to anyone a non-ORM framework and the chances of someone hitting multiple times the DB to query the same records increases with team size and app scope. I am not sure there is a framework that can protect your colleagues from doing select * and then count the in memory objects instead of doing a count on DB.