What makes Rails stand out is the focus on convention-over-configuration as a guiding principle in the ecosystem which results in a lot less code (have you seen these relatively thin models and controllers?), as well as established dependencies and the lack of tendency to bikeshed in libraries (geocoder or devise for example have been mostly stable over close to a decade, with few popping up to replace it)

> What makes Rails stand out is the focus on convention-over-configuration as a guiding principle in the ecosystem which results in a lot less code

Convention over configuration and less code is fine, but unfortunately Rails is not a great example of it IMO. The "rails" are not strong enough; it's just too loosey goosey and it doesn't give you much confidence that you're doing it "the right way". The docs don't help much either, partly because of the history of breaking changes over releases. And the Ruby language also doesn't help because of the prolific globals/overrides and implicitness which makes for "magic".

So you're encouraged/forced to write exhausting tests for the same (normally dumb CRUD) code patterns over and over and over again. Effectively testing the framework moreso than your own "business logic", because most of the time there barely is any extra logic to test.

So I'm also surprised it gained the reputation is has.

Do you have a recommendation for a better incarnation of the principle?

Phoenix with Elixir is for sure "a better Rails".

Although that's really selling it short - it's so much more than that! But in the context of this conversation, it's a good place to look.

Django is similar but done better IMO.

The prevailing sentiment is that once you hit scaling issues with frameworks like Rails or Django you should have enough resources to simply throw money at the problem either in the form of more hardware, cloud computing, or better software engineers that can identify bottlenecks and optimize them.

Since most websites will never scale past the limitations of these frameworks, the productivity gains usually make this the right bet to make.

If Shopify or Github can handle scale with Rails, maybe it’s not a framework problem.

Github can be horribly slow sometimes (tested from different machines and through different ISPs) and difficult to tell if that is down to the framework used to render the pages or any other parts of the system.

A few years ago it started a transition to react. It has been less snappy ever since to me.

Agree, the new code viewer is horrid. Also breaks right-click navigation between files for no reason. Not once have I triggered the interactive editor mode on purpose, but happens all the time accidentally, trying to select / hightlight a line. So frustrating…

Hard disagree on this. I went with this sentiment and deeply regret it. With LLM assisted coding it's very fast and easy to write a Go or even a Rust server. They have less bugs and can actually do things like threads that you end up working around in python/ruby.

Giving an existing Rails codebase to an LLM and effectively asking it to rewrite it in Go is going to result in a shitstorm of epic proportions.

At least it’ll make for an interesting post mortem blog post.

I am not sure why people are comparing a web framework with writing your own code in another programming language.

How many CVEs have you had reported yet against your custom code for probably the middleware you wrote to get a request with params available to use them (the params) in an SQL query?

Of course if you are good at this and have a lot of experience than even using an LMM I am sure your code is more than fine. But on average I think it is safe to say that any middleware or library code to deal with HTTP requests and make the information available for business logic generated by an LLM has probably a lot of bugs (some subtle some very visible).

For me the power of Rails is that if you do CRUD web apps it is battle tested and has a long history of giving you what you need for fast building business logic for that CRUD app. Is it the knowledge that is put into designing a web framework that works for 90% of the operations you need to write your custom business logic.

Rails has ActiveRecord, which has an extremely elegant REPL. It's a delight to use.

ActiveRecord may be both the best and worst part of Rails. Currently the largest scaling problem that I'm facing is with all the before_* and after_* callbacks which run per model record rather than a batch of changed records. This is an N+1 query landmine field for which ActiveRecord offers no solutions.

I agree that ActiveRecord isn't particularly opinionated about how to deal with updates to batches of records, but there are multiple ways of approaching this and AR won't get in your way.

upsert_all[1] is available to update a batch of records in a single write that does not invoke model callbacks.

activerecord-import[2] is also very nice gem that provides a great api for working with batches of records.

It can be as simple as extracting your callback logic and a method (def self.batch_update) and running your callback logic after the upsert.

[1] https://api.rubyonrails.org/classes/ActiveRecord/Relation.ht... [2] https://github.com/zdennis/activerecord-import

By upsert_all not invoking model callbacks, it's admitting that the ActiveRecord approach doesn't scale.

"It can be as simple as extracting your callback..." Isn't this the kind of repetitive thing a framework should be doing on your behalf?

To be fair, ActiveRecord isn't a fault Rails invented. Apparently it's from one of Martin Fowler's many writings where each model instance manages its own storage. Even Fowler seems to say that the DataMapper approach is better to separate concerns in complex scenarios.

TBF no framework will do everything perfectly, and having clean escape hatches is pretty good in itself.

Even outside of batch processing, there will usually be a few queries that absolutely benefit from being rewritten in a lower layer of the ORM or even plain SQL. It's just a fact of life.

AR is the worst thing about Rails - it's anti-pattern central. The Ruby REPL is amazing, however.

ActiveRecord or how to badly couple your storage with your objetcs.

Before rails, a lot of people were either using PHP or Java with JSPs/Servlets. If you were 'cool' you used Spring/Hibernate with a mountain of XML configurations.

Ruby/Rails was a breath of fresh air. Translate: Not a PITA.

What “severe scaling issues” have you encountered?

They honestly really haven’t though. I’d’ve thought they would’ve by now, but I still find bringing up a backend with something like Go to be annoyingly tedious and feature-incomplete in comparison.

Like yeah, I know you can do it. But it was much more effort to do things like writing robust migrations or frontend templates. I’d love to find something in Go or Typescript that made me feel quite as productive as Rails did.

Preach. I found the whole "just use stdlib" culture in Go so annoying. I love the language (both Go and Ruby actually), but Go's ecosystem and tooling is eons behind.

Maybe I am comparing apples and oranges, not sure.