Why Ruby on Rails still matters

Before this Digg, before that Slashdot.

What else am I missing?

Every time I share a project I provide two links, one for my vps and another one for GitHub pages. Usually my projects run on the client, so I have never experienced the hug of death myself.

I absolutely love this comment <3

My first company website was served of a 120MHz Pentium that also served as the login server where 5 of us ran our X clients (with the X servers on 486's with 16MB RAM)...

And it wasn't static: We because peoples connections were mostly so slow, we used a CGI that shelled out to ping to estimate connection speed, and return either a static image (if you were on a dialup) or a fancy animated gif if you were on anything faster.

(the ping-test was obviously not reliable - if you were visiting from somewhere with high latency, you'd get the low bandwidth version too, no matter how high your throughput was - but that was rare enough; it worked surprisingly well)

I used to host 3,000 active daily users from a 33mhz 486 with a 56k modem.

Thousands and thousands of lines of quality conversation, interaction, humanity.

To be honest, I kind of miss those days.

I love to think that the web of the future is just going to be everyones' mac Mini or whatever.

Big Data™ has always irked me, frankly.

I took a startup from zero to 100k MRR as of last month over the last 5 years. I can tell you that cloud billing is the least of your concerns if you pay even the cursory attention to writing good queries and adding indexes in the right places. The real issue is the number of developers who never bother to learn how to structure data in a database for their use case. properly done, you can easily support thousands of paying users on a single write server.

Yeah, the mac minis can have up to 64GB of ram which would support some usable models. However, I accidentally got one with 24gb of ram, and my apps already use 12gbs. So, perhaps I'll get a second box just for LLMs!

Get NUC, or one of those refurbished Dell or HP mini PCs. They have plenty of CPU power, consume very little idle power, and friendly to Linux.

Glad it resonated with you!

If you're considering k8s, take a look at Kamal (also from DHH): https://kamal-deploy.org/

I think it makes more sense for small clusters.

Nobody's actually doing work because serving web pages is cheap.

It does look like the main article isn't actually cached by Cloudflare. But most of the assets are. So it is definitely helping but not taking the entire load.

Yeah, but there's Plausible Analytics self-hosted on the mac mini that's getting more of the load right now.

Cloudflare Tunnel provides you a publicly routable address for free. With wireguard you would still need a VM somewhere, and if you are hosting your own VM, then whats the point?

Why the assumption that an API endpoint should be a 1:1 mapping to a database table? There is no reason we need to force that constraint. It's perfectly legitimate to consider your resource to encompass the business logic for that use case. For example, updating a user profile can involve a single API call that updates multiple data objects - Profile, Address, Email, Phone. The UI should be concerned with "Update Profile" and let the API controller orchestrate all the underlying data relationships and updates.

I have actually had a different experience. I feel like I've run into "we can't just see/edit the thing" more often than "we want another thing here" with users. Naming a report is the kiss of death. "Business Report" ends up having half the data you need, rather than just a filterable list of "transactions" for example.

However, I'm biased. A lot of my jobs have been writing "backoffice" apps, so there's usually models with a really clear identity associated to them, and usually connected to a real piece of paper like a shipment form (logistics), a financial aid application (edtech), or a kitchen ticket (restaurant POS).

Those sorts of applications I find break down with too many "Your school at a glance" sort of pages. Users just want "all the applications so I can filter to just the ones who aren't submitted yet and pester those students".

And like many sibling comments mention, Rails has some good answers for combining rest entities onto the same view in a way that still makes them distinct.

Turbo frames solves a lot of this. https://turbo.hotwired.dev/

Multiple models managed on a single page, each with their own controllers and isolated views.

> you end up making a dozen or more API calls just to show everything

This is fine!

> I've fought the urge to use graphql for years

Keep fighting the urge. Or give into it and learn the hard way? Either way you'll end up in the same place.

The UI can make multiple calls to the backend. It's fine.

Or you can make the REST calls return some relations. Also fine.

What you can't do is let the client make arbitrary queries into your database. Because somebody will eventually come along and abuse those APIs. And then you're stuck whitelisting very specific queries... which look exactly like REST.

This is a very common pattern and one that’s been solved in Rails by building specialized controllers applying the CRUD interface to multiple models.

Like the Read for a dashboard could have a controller for each dashboard component to load its data or it could have one controller for the full dashboard querying multiple models - still CRUD.

The tight coupling is one of many approaches and common enough to be made default.

The Rails support for multi-model, nested form updates is superb.

Separate entities on the backend - a unified update view if that’s what’s desired.

No need for any outside dependencies.

You can separate the view and the backend storage without going graphql. You can build your API around things that make sense on a higher level, like "get latest N posts in my timeline" and let the API endpoint figure out how to serve that

It's seemingly more work than graphql as you need to actually intentionally build your API, but it gets you fewer, more thought-out usage patterns on the backend that are easier to scale.

You should checkout phoenix liveview. you can maintain a stateful process on the server that pushes state changes to the frontend. its a gamechanger if you're building a webapp.

https://www.youtube.com/watch?v=aOk67eT3fpg&ab_channel=Theo-...

As someone who co-founded one of the most successful Ruby on Rails consultancies in the world: building CRUD apps is a _fantastic_ business.

There are two types of complexity: essential and incidental. Sometimes, a straightforward CRUD app won't work because the product's essential complexity demands it. But at least as often, apps (and architectures, and engineering orgs, and businesses) are really just CRUD apps with a bunch of incidental complexity cluttering up the joint and making everything confusing, painful, and expensive.

I've served dozens of clients over my career, and I can count on one hand the number of times I've found a company whose problem couldn't more or less be solved with "CRUD app plus zero-to-one interesting features." No technologist wants to think they're just building a series of straightforward CRUD apps, so they find ways to complicate it. No businessperson wants to believe their company isn't a unique snowflake, so they find ways to complicate it. No investor wants to pour their money into yet another CRUD app, so they invent a story to complicate it.

IME, >=90% of application developers working today are either building CRUD apps or would be better off if they realized they were building CRUD apps. To a certain extent, we're all just putting spreadsheets on the Internet. I think this—more than anything else—explains Rails' staying power. I remember giving this interview on Changelog ( https://changelog.com/podcast/521 ) and the host Adam asking about the threat Next.js posed to Rails, and—maybe I'd just seen this movie too many times since 2005—it didn't even register as a possible contender.

Any framework that doesn't absolutely nail a batteries-included CRUD feature-set as THE primary concern will inevitably see each app hobbled with so much baggage trying to roundaboutly back into CRUD that it'll fall over on itself.

I actually believe that most of useful real-world software is “one step away from Excel”, and that’s fine

Yes now at doctors offices you have the option to sign an agreement for the doctor to wear a microphone to record the conversation and then AI tool automatically creates a report for the doctor. AI and all aspects of medicine seem to be merging.

ankane to the rescue, as normal

The real problem is programmers that understand how a computer works end-to-end is becoming increasingly rare, and possibly accelerated by the adoption of LLMs.

A lot of them prefer to write Ruby because it is simply the most beautiful language they know of. Technical details are merely a formality expressed in code that borders art.

I was under the impression the industry was collectively moving in that direction, but then bootcamps ushered in a new era of midwit frontend developers hell bent on reinventing the wheel from scratch (poorly).

This has been my experience as well. Hotwire is actually a more pleasant experience than React.

React is a good choice if you’ve got a huge dev team that can split things into components and independently work on things but otherwise React is so full of footguns that it’s almost comical that people choose it for anything other than bloated VC projects.

I wonder how it compares to Svelte for people. I weighed both but Svelte didn’t require me to learn Ruby (as much as I’m sure I’d enjoy it).

then you have to rewrite your whole app to use asyncio keywords and colored ORM methods. A gevent monkey patch, or eventually nogil concurrency makes a lot more practical sense.

And the switch is rather easy. I've been writing elixir for nearly 10 years, rails before that, and have overseen the "conversion" of several engineers from one to the other.

Generally I'd say any senior rails dev, given the right task, can write decent elixir code on their first day. There are a lot fewer foot guns in elixir and Phoenix, and so other than language ergonomics (a simple rule that doesn't stretch far but works at the beginning is use pipe instead of dot), there's minimal barriers

Normally "switch languages" isn't great advice, but in this case I think it's worth considering. I have heard people coming from Django and Rails background describe Elixir as "a love child between python and ruby". Personally I love it

And if you want to make the move, I know a great resource: http://PhoenixOnRails.com

</shamelessselfplug>

I personally think Elixir is a great language, but the jump from ruby to functional programming is big enough that I'm not sure it's useful general advice.

Do you mean Ruby lacks syntactic support for adding type annotations inline in your programs?

I am one of the authors of RDL (https://github.com/tupl-tufts/rdl) a research project that looked at type systems for Ruby before it became mainstream. We went for strings that looked nice, but were parsed into a type signature. Sorbet, on the other hand, uses Ruby values in a DSL to define types. We were of the impression that many of our core ideas were absorbed by other projects and Sorbet and RBS has pretty much mainstream. What is missing to get usable gradual types in Ruby?

I for one really like RBS being external files, it keeps the Ruby side of things uncluttered.

When I do need types inline I believe it is the editor's job to show them dynamically, e.g via facilities like tooltips, autocompletion, or vim inlay hints and virtual text, which can apply to much more than just signatures near method definitions. Types are much more useful where the code is used than where it is defined.

I follow a 1:1 lib/.rb - sig/.rbs convention and have projection+ files to jump from one to the other instantly.

And since the syntax of RBS is so close to Ruby I found myself accidentally writing things type-first then using that as a template to write the actual code.

Of note, if you crawl soutaro's repo (author of steep) you'll find a prototype of inline RBS.

+ used by vim projectionist and vscode projection extension

now that was a crazy rabbit hole

> At this point you can find tools that can make demos easier to build or get you further in a hackathon.

I don't understand this at all. ruby on rails is probably peak technology for getting something up an running fast at a hackathon. its a very streamlined experince with a ton of drop in plugins for getting to the product part of the mvp. Maintaining a ruby app is a nightmare overtime. At least it was 5 years ago the last time I worked fulltime in a startup using ruby on rails.

These days I use elixir. its higher performance and reasonably fast to write in but I woudln't say its as productive as ruby on rails if you're competing in a hackathon.

> What do you mean "left behind"? Are you saying people will actually get "left behind" or just that people will _feel_ like they're left behind?

Feel.

> maybe us engineers

I’ve started qualifying such statements… “you mean a real engineer or just a software developer?

I don't really know if I would agree on saying that RoR failed, from recent my experiences, it's still a sought after tool for startups.

I do share your opinion on the untyped part, it's a bit of a bummer but there are gems to Ruby that helps with that.

Regarding the monkey patches, it's a concern many have and because of that, there is now a cleaner way of doing it! It's called a refinement. It's like monkey patching but in a more controlled way where you don't affect the global namespace.

https://docs.ruby-lang.org/en/master/syntax/refinements_rdoc...

Failed or not, but at least for 2020 Y-Combinator Ruby-based startups valuation was more than other programming languages based startups combined.

https://charliereese.ca/y-combinator-top-50-software-startup...

Or if you want more Next.JS like, but still fullstack framework there is https://leptos.dev/ and https://dioxuslabs.com/. Maybe dioxus being much more ambitious in its scope (not just web).

If you're willing to go the meta programming route, Rust is pretty flexible too. You can literally run python inline using macros.[1]

In my experience as someone that has been using Rust for a few years (and enjoys writing Rust) the biggest issue regarding adoption is that async Rust just isn't there yet when it comes to user experience.[2]

It works fine if you don't deviate from the simple stuff, but once you need to start writing your own Futures or custom locks it gets to a point that you REALLY need to understand Rust and its challenging type system.

[1] - https://github.com/m-ou-se/inline-python

[2] - https://blog.rust-lang.org/images/2024-02-rust-survey-2023/w... | (Full Survey: https://blog.rust-lang.org/2024/02/19/2023-Rust-Annual-Surve...)

I seem to observe that people drawn to rust are into systems programming and people drawn to rust are into minimal services programming and any attempts at building a batteries-included CRUD framework are so against the grain of the community’s common interest that it never goes anywhere.

Ruby, meanwhile, optimizes for programmer happiness and Rails optimizes for programmer productivity. What other language-framework ecosystem has the same values alignment?

I think types can help, but I don't think they're "strong" enough to overrule training data.

I just ran into an example of this trying to get it (Windsurf + Claude) to "rewrite this Objective C into Rust using the objc2 crate". It turns out objc2 made some changes and deprecated a bunch of stuff.

It's not figuring stuff out from base principles and reading the types to write this code, it's just going off of all the examples it was trained on that used the old APIs, so there's lots of errors and incorrect types being passed around. Hopefully it'll keep getting better.

Interesting! What sort of stuff goes in the scaffold repo? Like examples of common patterns?

Definitely agree I think Ruby's closeness to natural language is a big win, especially with the culture of naming methods in self-explanatory ways. Maybe even moreso than in most other languages. Swift and Objective C come to mind as maybe also being very good for LLMs, with their very long method names.

Hooray, I can replace accurate auto-complete with imaginary LLM suggestions! I use copilot and static types. Both are useful for auto-complete - traditional auto-complete gives accurate results with documentation popups; copilot gives higher level suggestions that are frequently nonsense (but right enough to be useful still).

In any case static types have many advantages, not just auto-complete. There's:

* refactoring

* finding references

* go to definition

* documentation

* bug prevention

LLMs are a million miles from being able to do any of that stuff automatically.

> Is the remaining 10% of “formal correctness” worth the extra volume of characters on the screen?

Yes, if only just for the ease of large-scale refactorings. And "extra volume of characters" is very limited if you use a modern language. In Haskell you could even not write a single type annotation in all of your code, although that's not recommended.

I doubt most people who like static types only do so because of autocomplete.

The last time I tried this it created idiomatic code from scratch. I prompted it in phases though, and I suspect if I had asked it for more at once it might've used a generator.

I haven't seen it run into a ton of issues like this when it can see all of the files, but I did hit issues where it would make guesses about how e.g. the Stripe gem's API worked and they'd be wrong.

Overall with Rails though, testing has always been pretty important partly because of the lack of types. I have noticed Windsurf is pretty good at taking a controller or model and writing tests for it though!

What in particular? Never tried Rails so I want to know what I'm missing.

What is missing from Django in your opinion?

im not aware of the generator supporting all that

here's what I get

`Possible values: importmap, bun, webpack, esbuild, rollup`

inertia, I think, avoids writing an api to bridge rails/react