Ruby on Rails: The Documentary [video]

if you open up any Rails application, it looks basically the same in structure whether it is the biggest Rails app there is or a new one.

I used to love this, untill I started to hate it. I am convinced this is amajorcontributor to why so many Rails apps turn into an unmaintainable mess over years.

Who measures onboarding in hours? It's fine if it takes a day or two to understand the domain. And the framework. And how they tie together.

Talking about the domain: Rails puts "the plumbing" up front. Its how it achieves this consistency. My app is never about "models" or "http" or "databases". My app is about medicine-journals. Or loan-request-management. Or CRM. Rails makes itself important, at the cost of my domain.

Rails' opinionatedness makes it so that this is hewn in stone. Its MVC is a given - and that's fine - major architectures should probably be dictated by the framework. But it's ORM - ActiveRecord also is a given. And that's not fine because AR (as an architecture and as how Rails implements it) is very unfit for a large category of applications. It's virtually impossible to swap AR out for anything else. Same with templates/views, JS, Caching, and many more: you can -in theory- replace them with a drop-in alternative. But you cannot -not even in theory- replace them with something that has an entirely different architecture or concept. This makes Rails not Omakase, but actually McDonalds: wherever in the world you come, you know exeactly what to expect, but it also makes boring and bland: no-one eats 7days/week McD.

This makes all Rails apps look alike. Despite the fact that not one of the apps that "we" are building is alike another. Domain. Team. Project Planning. Combine any of them and the projects demand different things, but with Rails you are out of luck. Regardless if you build the next fintech platform with a team of 120 senior devs over 6 years, or you hack your "marketplace for coffeelovers" over the weekends alone: you get The Rails Way. One of those might be a perfect fit. But it's impossible they all are. Each team gets the same "menu". And in many cases it simply won't fit.

You're building CRUD apps. The conventions work and are extensible for teams of 1, 10, 100 and 1000s. You are not special and neither is your product. Companies making millions or billions of dollars have used this framework successfully.

This level of bike-shedding is what makes conventions necessary especially when dealing with the typical hyper-pedantic software developer. Just the thought of having to debate where to put every file in a project or having to invent a new folder structure for every app we build fills me with a bizarre mixture of boredom and rage.

As with everything in life the people that whine about the medicine the most are the ones that make it necessary.

Your model of companies using Rails with 1000s of engineers is almost comically naive. Look at what Shopify and Github have to do to make Rails work for them. Also look at the non Ruby code engineers there are writing and ask yourself why they might be doing it. Rails is not a religion. It can be good at what it does without having to go on a crusade when people point out its substantial limitations.

you're seriously convinced they would have had no problems if they chose something else? every codebase that lasts that long and is used that much is going to face very hard challenges as it scales and meets new landmarks.

the maintainable codebase from day 1 to day 5000 is (mostly) a myth. yeah maybe some other stack could have faced different tradeoffs.

I'm also curious about YOUR choice of stack at this point.

I never said that some other stack wouldn't have problems. My point was that Rails is great at some problems and awful at others. No idea how this can be controversial at all. My impression seems to be that there is a group of fanboys that are not able to have any intelligent conversation on what their favorite tool is good for and what it's not good for.

In my day job I use mostly Rails. My team is starting to rewrite some of the services we own in Golang because Rails is no longer a good fit for the problems and scale we use it for. Rails was great to get started fast.

Nothing wrong with using a press instead of a hammer at some point, they are just tools.

My team is starting to rewrite some of the services we own in Golang because Rails is no longer a good fit for the problems and scale we use it for.

What sort of web app do you have that is CPU bound?

It's an API gateway converting single digit MB-sized blobs of JSON into similarly sized blobs of JSON with a different structure.

The Rails app I scaled posted half a meg of JSON on every save-request every 10-15 seconds. In Rails, we parsed it, converted some parts into HTML nodes in Nokogiri, sanitized it, and saved it to both mysql and cassandra.

It wasn't a problem other than that a better initial design (nothing to do with rails) could have made passing all that data not needed, which was better for mobile. We had about 600,000 customers.

How many requests per second are you talking about roughly? One major problem we face is that downstream services also have performance problems and have multi second response times. While waiting for the response, a whole rails worker is sitting idle, taking up hundreds of megabytes of memory for seconds.

Is there any comparably complete framework that does not need any significant adjustments even when it's used by 1000s of developers building the same app?

Probably ASP.NET is as close as it gets.

Or its Java counterpart, Spring.

I think that's a bit unkind to ASP.NET ;-)

But yes, Spring and the various Java equivalents probably also fit the bill.

This, it is also on the other end of performance spectrum.

If your reverse your comment you could say “only when your reach 100s of developers will you need to start changing things a bit.”

Sounds good to me. Most companies never reach that scale and if they do, I think investing into some extras will be well worth it.

Tobi looks pretty chill about it in the documentary.

Totally, Rails is a great tool. So is my gunsmith hammer. I can like it for what it does without arguing it's the best thing in the world for cutting wood or joining two pieces of metal together.

Can confirm. Nothing worse than figuring out what sort of "magic" is affecting a route in a huge Rails app. Oh look, a before_filter in a super class 4 levels up that is defined in an include helper. But wait, why isn't it affecting all calls and only some? Ah there's another chain of filters that you only can know about if you are familiar with the older Rails version API.

Rails is the "goto:" label of web frameworks. It's unbelievable how much it encourages spaghetti code and misdirection directly via its conventions.

You're building CRUD apps.

No. "we" are not.

Domain. Team. Project Planning. Combine any of them and the projects demand different things, but with Rails you are out of luck

hmm, sounds like this rails app that one might have not heard bout. You should check it out. Think it's called Basecamp

help I’ve just witnessed a murder

on the off chance someone doesn't understand the subtext here.

BaseCamp is DHH's company's product. DHH is the creator of Ruby on Rails. He literally create RoR to build BaseCamp, which is exactly the type of software the other poster is claiming is problematic for RoR.

DHH is on record as having said RoR was evolved organically from the early code of BaseCamp.

which is exactly the type of software the other poster is claiming is problematic for RoR.

I wasn't. I specifically did not mention any concrete examples. I presume parent misread it as "for project management rails is unsuited" which, indeed it's not: specifically because PM is very much CRUD and has relatively little and/or relatively simple business logic (It's not for nothing that the hello-world of nearly all frameworks around CRUD are "TODO lists", the simplest form of PM).

What I tried to say, is that your domain, your team, your timing, your specific planning and your kind of project and any combination thereof has different needs. A setup, architecture, framework, fits one or a few of these perfect. But never all of the combinations of them. Nor over time (today you are a one-man-shop, tomorrow a team of 6. Today you build a full-stack web, tomorrow you need APIs for integration. Today you build a CRUD app for some medication journal, tomorrow it pivots into a complex tool for medical research.)

then you worded it badly.

Domain. Team. Project Planning. Combine any of them and the projects demand different things, but with Rails you are out of luck

There's no reasonable interpretation of that in which BaseCamp doesn't fall into the list of things that you feel RoR is poor at.

This is part of the problem with your claim - many of us arenotbuilding CRUD apps, we are building complex enterprise software and thereareunique challenges to solve.

Then I think the focus should be on the API. At enterprise level, the API becomes the language, and the frameworks (and even departments to an extent) become the functions/methods.

Business = program

Company = class (business can be a conglomerate)

Department = method

frameworks = implementation details

At the end of the day, all programming is CRUD at various levels of abstraction. You read some data, and then create/update/delete various forms of related data in various locations, like your DBMS or maybe a file or your GPU's VRAM

Rails provides a way to approach CRUD via MVC. Controllers are your API. Models are the connection to the Database. Views are what the controllers render.

If your app doesn't do these 3 things - API, Database, and representation of your API - you don't need rails (I bet you do those three things). Other than that, you're free to layer on whatever architecture via ruby that you want on top of these basic rails constructs. If you don't like it, again don't use rails. It's opinionated for a reason

I don't think it's necessarily bike shedding, and actually a lot of the sentiments resonated with me. Rails is a tool that does a tool's job. It's nice to know a hammer does hammer things when you're expecting it. If you need a level, maybe use a different tool. I think the main issue is everyone expecting it to be "one-size fits all." It was never meant to be that, really

I couldn't agree more. There is also a technology aspect to it. Rails is objectively veeeeeery slow. Concurrency support is nonexistent. This is not a good fit for all problems. It also to some degree prevents you from breaking out the parts that would benefit from a different language into their own services (Rails needs to call them, but it's really not good at IO).

Is there a comparable framework that does what Rails does but is somehow 10x faster? I wouldn't use Rails for everything but the fact that plenty of companies like Shopify are serving millions of requests per second with it shows that it's probably acceptably fast for mega scale apps.

and gitlab, github :)

These two have lots of backend code that's not Ruby. Rails is great at what it does and it's not optimal for many other use cases.

I'm sure things have changed post-acquisition, but for a very long time Github's back-end languages were just Ruby and C.

Turns out C is better at some problems than Ruby after all? This was my point.

Agreed on that. My point was just that even at massive scale, the vast majority of the backend was written in Ruby.

Rails does everything. You can build a stateless API gateway with it. Is it great for that particular use case? No. Your question about frameworks with similar capabilities is pointless because my point was that there are use cases where the capabilities of Rails are not a good fit.

You said it's objectively very slow. My question is relevant because your point begs the question: Slow compared to what?

If you want to give an honest apples to apples comparison then, okay fine, what framework that does everything that rails does is considerably faster?

Is a Ferarri faster than a dump truck? Sure, but they have different uses. Try hauling gravel with a Ferrari. For the class that Rails is in, there isn't anything as feature compatible that is also an order of magnitude faster.

Ruby/Rails is not great for efficiently transforming megabyte sized blocks of JSON into differently structured megabyte sized blocks of JSON, just to give you one example. Golang/Rust/Java is better suited to that. Other use cases are for example any ML-Workloads where Python's ecosystem is much superior to Ruby's.

That being said, you missed my original point, which is that there are problems where you don't really want Rails implemented in a different language because Rails is not a good tool to solve that problem. Think hammer vs saw. You are asking for a different brand of hammer that can cut wood better. Wrong question.

Obviously not every took if right for every job. But your claims that Rails is slow because for what it does there are not many good replacements. Go is a language not a framework.

Phoenix framework on elixir does come close to this. Designed by people with a background in ruby and rails, and has much of the same design philosophy.

That said, there are areas where Phoenix can't match rails, such as having access to a large developer community and a large existing base of libraries.

Except when you look at benchmarks it's actually not that much faster than rails.

https://www.techempower.com/benchmarks/#section=data-r21&hw=...

I don't know how they measure it, but other measurements have shown different results:

https://medium.com/@elviovicosa/phoenix-vs-rails-benchmark-2...

I don't know how they measure it, but other measurements have shown different results

The big difference is the blog post you linked performs a very basic GET request to an endpoint. It mentions it doesn't hit the database or deal with caching. It's basically a non-realistic hello world that is good at isolating performance of a specific library but doesn't show how it fits into the grand scheme of things.

The other link performs multiple database queries as part of the request which goes back to the old saying that for a huge portion of web apps you're I/O bound (AKA waiting for something else such as the database).

Spring, perhaps.

Cumbersome build and deployment, and high level of ceremony alone prevent it from being a sufficiently competitive choice.

Spring and ASP.NET.

compare with what, in what load?

From my day job:

Stateless API gateway making HTTP calls to other services, which have response times in seconds for various reasons. Rails throughput ~20 requests per second. Golang rewrite throughput: 200k requests per second. Same hardware.

I helped write what might be a similar API gateway prototype in rails (made a DB query and decorated downstream requests with auth/role/etc headers). You might have threadpool/process/concurrency tuning to do. Even then, I don't think rails is a good solution for what is essentially an HTTP proxy, and I would've pushed for a different tool if time wasn't an issue. Rails was fast to build, I'll give it that. We ended up getting downstream service to $1M ARR so rails wins out against my "let me write it in XYZ language/framework" again somehow.

This is the point I wanted to make. Rails is great for some problems, not great at others. I can tell you for example that it's not great at transforming 2MB of JSON into a differently structured 2MB of JSON.

What in the world are you talking about?

This reads like someone who doesn't understand how to use a tool so they think it is broken. I've worked on Rails apps that outperformed Spring/Java apps routinely and node apps routinely at very large scale. You're very rarely bottlenecked on CPU in a modern CRUD app, much more often, it is the database.

It sounds naive to call the framework that runs github, that almost everyone in the world pushes their code to "veeeeery slow" and I don't know what you mean by "bad at io" in any context where that is a problem for Rails.

It's possible to make Rails relatively fast.

But Ruby is one of the slowest languages around. And Rails adds a lot of runtime overhead to that. It really is very slow out of the box.

And that matters for virtually no-one¹, because almost no-one is running their rails app at that scale.

That something would outperform Spring is really due to technical choices, the stack, suboptimal use or libraries. Because Java is undeniably multitudes faster than Rails; in everything.

¹ This used to be my strongly held opinion. But I'm shifting around since we're in a the middle of an unprecedented energy/climate crisis and a slow rails app is gobbling up electricity much more than a highly tuned one. Or the same service rewritten in Go or Rust or Java will.

i’m preparing a talk for either railsconf or railsworld that puts this question/concern to the community. two times i have deviated from the standard apps/{models,controllers,views} layout and i have profited massively, especially in terms of conceptual integrity and abstraction. all my code lives in app/lib under domain-specific directories. this includes the models. the only part worth separating is the web router and controllers. i have achieved separation between my app and the web parts that aren’t offered by default by rails. i’m hoping to share my experience, for the community’s consideration.

I've had the pleasure to work on such kinds of Rails apps a few times. It was almost magical, compared to all the other common Rails apps with their ever accumulating fat models, complex controllers, untestable- coupled classes and so on.

One had this what you describe: everything in /lib, and the MVC merely delegating to that. MVC downgraded to what it should be: plumbing that binds together your domain stuff.

The other did something similar but had it in gems (bound as Railties/engines). IT was a bit more cumbersome, as one had to release a new gem before being able to integrate it in the rails app. It forced a very solid separation of concerns.

compared to all the other common Rails apps with their ever accumulating fat models, complex controllers

i interpret fat model as: what can be move to the model, sits better in the model (directory). things that cannot be moved to the model: the request, the response, the session. not set in stone, but usually this works.

what i regret about older Rails code i wrote was the gluing of all biz logic to ActiveRecord ORM models (akin to, yuck, Hibernate entities), that also contain DOAs, form validation and all business logic. now i tend to split these out: form dtos that do validation, repos with queries, simple record classes, etc.

fat signals homogenous big thing, but is actually where most of the application lives. i coudl call it lib as well.

Except that Models are also Records. So by definition they don't separate concerns: for one the separation of concerns between "storing/retrieving stuff" and "all the business logic stuff". This lack or SoC, invites other tight coupling: For example, in Rails we commonly couple our models to our database design. You need a Medicine Adjustment? Better have a "medicine_adjustments" table, eventhough its more an Event than a record. Sure, you can pick and choose pieces of ActiveModel, and build models that aren't backed by database-tables, or by multiple tables. I do that all the time. But its far easier to just tightly model each Model around a Record/db-table. And because it's easier, its what most of us (especially juniors not bitten by it years later) will do: the easy way.

In the book "Growing Rails Applications"¹ has the -IMO- best practical patterns to solve this, but it goes right against the "you open a rails app and know what's happening": neat patterns, well manageable, and well documented, but very non-railsy.

https://rubyandrails.info/books/growing-rails-applications-i...

IMHO if you're splitting an app into domains you might as well go all the way and split it into an engine or gem.

i doubt. the further down the wedge drives the harder it gets to make the components communicate, and i think when communication gets hard we’ve probably gone too far. that’s not even taking into consideration the mechanisms of managing engines/gems.

Sounds interesting! You might start with a blog post…?

In one of her interviews Sandi Metz mentioned that she separates all her activerecord models under models/ar.

She is big on separating the business logic from the framework.

I don't know what exactly the complaint is here. You don't like that Rails has a common structure?

It's virtually impossible to swap AR out for anything else.

I've used Mongo and a number of other ORM's, why can you not use other ORM's exactly?

This just sounds like you don't like frameworks and want to build things from the ground up, because most of the complaints you make are just not true. Maybe you are just inexperienced with Rails because you can swap out almost anything.

because behavior is an unspoken part of contracts.

I can't reasonably swap out an array with a linked list even if the official contracts are the same.

this is why things like DAL's are created, they give you an opportunity to deal with the differences in behavior.

The issue with frameworks like RoR that use AR throughout is that the queries are sprinkled throughout the codebase, giving no opportunity to fix such behavioral differences.

What happens is every ORM then attempts some sort of "query reuse" and they do so badly because it's not possible to do it well with the contracts they expose. It creates code where you can't ever reason about the query that's actually being generated.

What kinds of queries are sprinkled throughout that are not part of AR, or depend on AR?

Sure, if you are going to swap out AR for another ORM in the middle of an established project you are going to have a bad time, but if one is doing that I have larger questions.

I must be misunderstanding the question because anything that queries in rails uses AR and that's often done in both lib code and controller code rather than behind a dedicated module boundary.

What is it that's not making sense to you?

because anything that queries in rails uses AR and that's often done in both lib code and controller code

How is that different from any other framework ever? You have to query the DB somewhere. Rails makes it incredibly easy to swap out databases. Much more so than any other platform I can think of.

Nothing is making you use AR at all. This is a non issue.

how is a dump truck different from a gocart.

If it needs to be explained you've never seen anything but a gocart.

I wasn't saying that we want to swap it out in the middle of an established project, but that it's impossible to do so in a greenfield project too.

there's MongoID and it's OK-ish, -a brilliant piece of work though!- but not particularly good inside Rails yet the best alternative example there is. Yet with this (naturally) many gems won't work either. Everything in the community simply presumes Rails' AR is always there. Because it practically always is.

ROM-rb, and Sequal all attempted to be "plugin replacements" but the author of the first rage-quitted at some point exacly because Rails (the dev team) refused some compromises or even abstractions that would allow swapping AR out for something that fits SomeProject better, at the start.

since "plumbing" is an essential part of *every* application, I'd rather not focus on it all the time.

I maintained both kinds of framework-heavy and "organic home grown just libraries" apps, and you know what? I totally prefer framework heavy stuff; at least it has battle tested facilities for everything, and I can expect consistency instead of fomo-driven/resume-driven development.

my last homegrown framework was a nasty 60k LoC api that did like 10 operations. total business logic was 3000 lines, including fn declarations and docs. just transaction scripts. the remaining 57k were a gargantuan amount of boilerplate that gave absolutely nothing to the project, and all in "typed python" which is like 0.9x java verbosity. a massive piece of shit.

I'd rather not focus on it all the time.

Me neither. Which is why I want it tucked away and out of sight and out of thought.

My app is about Medicine, or Projects, or Coffee, or Orders. Not about Controllers, Models, HTTP and DatabaseLayers. Hence I don't want to work day in day out in this plumbing but rather in my domain¹.

Also, there's this false dichotomy, where "no framework === diy mess" That's nonsense. It's perfectly possible to create a well architectured, clean, maintainable and scalable system without the constraints of a framework. You don't need to write your own HTTP handling or database layers if you forego a frameworks: it's what libraries are for. Or microframeworks. Or both.

¹ Here Uncle Bob Martin explains that much better than I ever could:https://youtu.be/sn0aFEMVTpA?si=mY8S1r6qqp8LWEVF&t=4517

either you're very lucky or I've been very unlucky with our respective teams, as yes, it is perfectly possible to create a decent application without frameworks, but it's also incredibly unlikely, given that the average coder is incredibly mediocre at best and often does not even know basic engineering practices ~ i.e. see the success of function-signature-stealing-decorator-heavy web frameworks in py; that alone makes impossible to use constructor injection without "advanced" concepts like closures, but who cares, just instance from inside the controller and monkeypatch!!!1oneone

If the team is VERY skilled, VERY small and VERY able to keep the culture going forward indefinitely I'm all in for the homegrown framework; if not, I'd rather have a set of well done facilities that accrued many years of manhours i.e. cli commands out of the box, testing framework already well configured with decent standars like tx-wrapped tests, and so on, decent security, admin panels...

it's not a technical matter, it's a social matter. social matters are more important than technical ones.

    I am convinced this is a major contributor 
    to why so many Rails apps turn into an 
    unmaintainable mess over years.

I have two easy answers to why Rails apps turn into messes.

1. Any non-trivial app in any non-trivial language/framework usually becomes a mess eventually, given enough commits and developers

2. Rails (specifically, ActiveRecord) won't stop you from creating circular dependencies between models. This is easy to avoid, but it doesn't warn you about this or try to prevent it. So 99% of Rails apps have like, a User model that depends on (and is depended on by) most of the other models. This is far from a Rails- or ActiveRecord-specific issue though.

    Who measures onboarding in hours?

You're right of course: that's a one-time cost. It's nice to optimize this but as you say, it's a one-time cost. Assuming a developer will spend multiple months or years working on the app, it would be better to optimize for the rest of that time.

However I think the standardization on MVC pays off here as well. For apps with multiple developer teams you may constantly be "onboarding" as you move between different areas of the app. And you can move forward with less bikeshedding.

    And that's not fine because AR (as an architecture 
    and as how Rails implements it) is very unfit for a 
    large category of applications

I agree, although I also feel strongly that AR is very good at getting out of the way and letting you just use raw SQL when you want.

So IMO/IME it works well for scenarios where some of your data is AR/ORM friendly and some isn't.

     Same with templates/views, JS, Caching, and many 
     more: you can -in theory- replace them with a 
     drop-in alternative

I can't agree. A lot of Rails projects use HAML instead of ERB and while I never set that up myself, I wasn't under the impression that it was a hassle.

Rails' caching backend has been seamless to swap between DB, Redis, in-process, and Memcached backends. As far as the caching "frontend", it's entirely optional, so I can't really imagine there is an obstacle to swapping it for something else? Like, you neverhaveto use `Rails.cache`.

As for the JS side of things, I don't think I totally agree. There aren't drop-in alternatives, but you don't have to use Stimulus, and you can certainly use your own.

    This makes all Rails apps look alike.

This is good in a lot of ways. Less bikeshedding more building. But, also... I have to admit. I am bored to tears with Rails. Happy to be working in another language/framework for the moment and possibly forever.

You're right of course: that's a one-time cost.

I disagree. This presumes that there's some initial "onboarding" process, and that once that's done you just now will know the structure of the app for all future, never spending more effort on it.

That's only true for trivial apps. What actually happens in bigger codebases is after you stop working in some section of the code for a few weeks, it falls back out of your head and you have to figure it out again. Additionally, without conventions other members of your team are constantly inventing new structures and connections between things.

So really this lack of consistent organization is a continuous drag, not a one time cost.

I realize my post was overlong, but I assure you it explicitly agrees with what you just typed.

I need to be more concise.

so many Rails apps turn into an unmaintainable mess over years

Does this happen more often for Rails than for other frameworks?

There are many ways in which a Rails project can get derailed. But they seem not different from regular tech debt and I could imagine equivalent problems in other environments.

AR (as an architecture and as how Rails implements it) is very unfit for a large category of applications

If you plan to build an application belonging to a category where AR is not a good fit, why use Rails?

I wouldn't claim that Rails is a good fit for all problems. Still, I'd say the structure and defaults of Rails are one of its strong benefits.

Or do you mean "application" as in "usage" - i.e. that over time you might notice a problem that's hard to solve with AR? Could you give an example? I'd guess you could use a different approach for a single task, or even move from Rails to a different tool if that becomes a big issue.

Does this happen more often for Rails than for other frameworks?

Yes. But there are many frameworks where this is even worse. Rails, however, is highly opinioated, and does not allow you to pick and choose your parts (this is a design decision). That has lot's of benefits, but the major downside is that it will never fitperfectly(or as close as one may get). Most often an "off the rack suite" is fine, but we all know that a tailor-made suit is just that much better/prettier/comfortable/durable. Same here: Rails will probably fit your project OK, but that's not good enough for many projects.

AR is a another big contributor, as is the way Rails has its MVC set up. Tight coupling, no separation of concerns, etc. etc.

As you say:

If you plan to build an application belonging to a category where AR is not a good fit, why use Rails?

Which is myentirepoint. Yet it happens. Far too often. (I'm a freelance consultant who deals with these failing Rails projects on a monthly base. And occasionally a very pretty one)

Domain. Team. Project Planning. Combine any of them and the projects demand different things, but with Rails you are out of luck.

I mean you could have at least picked some better example. Considering Rails was precisely extracted out from Basecamp which is "Domain. Team and Project Planning".

This wasn't an example.

It's that your domain, your team, your planning, and any combination thereof put demands on the architecture and framework.

You're bike shedding [0].

Rails/DHH took already established design patterns and made strong opinions into a convention on the folder hierarchy of where you store your code. You can change that hierarchy, its not set in stone. It will require a lot of change. I've been on teams and it isn't just on-boarding time, its countless hours trying to find code written by someone no longer there that had their own layout of where files should go. Without conventions, people will run amok with a file structure. Multiply that by the number of developers on the team with attrition and different view points on organizing files and it can be a giant mess after a number of years. Its all a waste of time and has nothing to do with the quality of the code, what domain the application is in or anything really.

If you love Ruby there are other libraries out there like Sinatra [1] that don't have the conventions of Rails.

[0]https://en.wikipedia.org/wiki/Law_of_triviality

[1]https://sinatrarb.com/

The key is to build a Ruby app and then provide HTTP access and persistence using Rails. You can find a lot of articles about this by searching for Rails and hexagonal architecture.

My biggest issue with trying to do this is ActiveRecord. I'd much prefer the repository pattern.

We detached this subthread fromhttps://news.ycombinator.com/item?id=38249134.

I had a lot of fun watching this documentary. The one person framework really comes out in the personal story of Toby from Shopify. "From Hello World to IPO". What I also loved is that he mentioned that if you open up any Rails application, it looks basically the same in structure whether it is the biggest Rails app there is or a new one. Sure that can be true for many apps, but in a world of, for example, APIs and front-end stacks, that isn't always the case.

The latest developments in Rails are making the solid foundation even more solid. There is stuff happening to make infrastructure easier: Kamal sure, but also Solid Cache and Solid Queue and there is a lot happening in the front-end with Turbo (Morphing) and mobile apps with Turbo Native and Strada.

We have upgrade to 7.1 already and have a mobile app in production that is built with Turbo Native. I am also excited to start replacing our Redis cache with Solid Cache to make everything simpler and cached longer.

Great to see the Rails community so alive and see the deep connection the (ex) core team members have to the framework!

if you open up any Rails application, it looks basically the same in structure whether it is the biggest Rails app there is or a new one

I've never worked with Rails, but this sounds amazing. One of the things I really hate about the Node.js ecosystem is that there are no clear conventions, the structure is always different even when the same framework is used. It's a mess. The exception is probably Next.js but it's more frontend-y.

True, nodejs really doesn't have _the_ framework. Python had flask, php is WordPress and RoR.

Why is that? Especially since most of the new frameworks copy the ideas of existing frameworks.

P.S. Perhaps because a JS framework based off the ideas of rails would be called jails! /s

I've wondered about this for years.

Express was the default with Node for some years but it was mostly used for APIs to feed front ends. These days lots of people have switched to Fastify but again mostly for APIs.

There's really nothing fullstack in the JS world that can be compared to Rails, Laravel, or Django.

Current fullstack solutions (Next, Nuxt, SvelteKit, etc) in JS are trying to kludge front end components into the server which IMO is a mistake. And I say this as someone who has been doing mostly front end since the 90s.

There's really nothing fullstack in the JS world that can be compared to Rails, Laravel, or Django.

I would like to introduce you to Adonis.https://adonisjs.com

It's cool. Another similar option is Platformatic by the creator of Fastify.

https://platformatic.dev/

But still... There are no queues or jobs. No HTML over the wire. No colocation of presentation logic. Etc.

All of that stuff can be easily added using 3rd party packages, just like Laravel, Rails, Django, etc all have userland addons.https://packages.adonisjs.com

I didn't know about these packages. But still, nothing really that improves rendering.

https://packages.adonisjs.com/?category=Rendering

And the fact that these aren't official is kind of the point I've been making. In the JS world there isn't a holistic fullstack framework. You have to stitch it all up yourself. In Adonis, Express, Fastify, Next, SvelteKit, etc.

But still, nothing really that improves rendering.

Because most people are content with using Adonis' Edge templating with something like Alpine for sprinkling in interactivity, or using Vue.

In the JS world there isn't a holistic fullstack framework.

This is true for all monolithic frameworks in every other language. Even Rails you have to use 3rd party addons for stuff. It's not feasible to build everything in for every possible use case, so they make it easy to add on stuff.

I think now you're just starting to move the goalposts.

Because most people are content with using Adonis' Edge templating with something like Alpine for sprinkling in interactivity, or using Vue.

I'm not talking about adding client-side interactivity though. Read my comments again.

I think now you're just starting to move the goalposts.

I think you're not really reading my comments.

Obviously no solution will solve everything 100%. That's not even an argument.

to kludge front end components into the server which IMO is

I think you make a good point here, JS is uniquely able to be executed both frontend and backend, hence things such as underscore templates.

Other languages don't have that ability. Therefore I would agree that there is no point in making a 1to1 copy of existing MVC ideas.

Being an ex-rubyist and now doing a lot of NodeJS, I really enjoy moving server code to the client at zero mental cost since it's mostly the same APIs

Sharing code is cool but OTOH the back and front end are two completely different beasts.

Trying to use client patterns to solve the server has been mostly a mistake. OTOH separating server and client and using an API to glue has produced a lot of issues too (SPAs, etc).

I think the future is a hybrid model where 80-90% of the front end is orchestrated from the server (LiveWire, Hotwire, LiveViews, etc) and 10-20% is a pure client side solution.

I totally agree (also originally a Rails dev). And with Typescript and Remix I get type safety and auto complete from the database layer (Prisma) all the way to the React UI. It’s amazing.

Laravel would be a better example for PHP, especially as it borrowed so many ideas from Rails.

I agree. The only frameworks I’ve found about as productive as Rails are Laravel and Phoenix.

Django and Sails.js both seemed like they were a step down in terms of general productivity, though each had a unique advantage of their own (admin out of the box, websockets & realtime features).

I haven’t had a chance to really give RedwoodJS a trial run, but it's the JS-based fullstack framework I'm most curious about.

After a few years, and as my own application has grown, I feel I'm more productive in Symfony than Laravel, because there's less magic, I know where stuff is, and it's more "loosely" coupled components whilst Laravel is "All in or get out". I've been updating my app since Symfony 3.3-ish to now 6.3 and it's been fun! I've had to exchange the auth, the admin section, added new features, killed off features, but I feel with time, that my code has gotten more stable.

Maybe my first update experience with Laravel was a bit of a mess (v4.2 to v5.0 "The recommended method of upgrading is to create a new Laravel 5.0 install and then to copy your 4.2 site's unique application files into the new application. This would include controllers, routes, Eloquent models, Artisan commands, assets, and other code specific to your application."), and I couldn't easily "see" the models' properties and the Facades, that's why I have shy-ed away from it a bit. I have worked with several Laravel applications since then and have gone through the v6 through v10 upgrade cycle and can say it's gotten easier (though I wish they could settle on a release schedule), but my preference is still Symfony.

Plus when I checked out Django, I felt a bit more "at home" (e.g. see Twig templating language and how they used Django templating language as inspiration).

I've worked with Vue.js and AngularJS 1 and Angular 2+, but I'm glad htmx is coming in strong, so I can focus on logic, speed and stability instead of glueing the frontend and backend API together and debugging in the different browsers.

It will probably not be a well-liked comment, but Spring is absolutely there in terms of productivity, and the cool thing about it is that it never leaves your side when it comes to more and more complex requirements. It really has everything and especially Spring Data with JPA is unbeatable.

Correct.

Wouldn't python's _the framework_ be Django?

Yeah for a default rigidness with the ability to tinker in obvious ways the framework for python is imo Django.

Flask is almost completely freeform in what it allows you to do, it just has a few style recommendations and a ton of community convention, but you could technically ignore 90% of it since Flask doesn't really expect any sort of structure.

Yes.

Django is to Rails as Flask is to Sinatra, imo.

Despite what others will say here, it actually is Next.js. People don't agree with parts of the stack (just as C#/Java people didn't agree with what Rails was doing in 2005), or point out projects with the equivalent mindshare of Sinatra/Flask like Nuxt and Svelte, but when you look at what company-level projects are majority building with in 2023, it's Next.js.

https://insights.stackoverflow.com/trends?tags=next.js%2Cnes...

How do we know it's not Django/React?(not sarcasm; trying to learn) Adding those two to your link shows them on similar "these increase as rails decreases" correlations, with more area under curve:

https://insights.stackoverflow.com/trends?tags=next.js%2Cnes...

Well, for one, stackoverflow trends are not the only criteria I'm using here. Recent GitHub projects, HN who's hiring threads, frequency of features shipped, and more are being factored in, personally.

Next.js is using React, it's a piece of the fullstack framework, like Rails and erb. React is the primary fullstack JS templating system, that's even more featureful as it's a better client side JS interop story than html templates.

By the stackoverflow graph, it's clear that most complex projects have moved onto frontend frameworks like React, instead of templated html, which standard Django is using. Django used in conjunction with a frontend framework, is most often through Django Rest Framework, which fares much less popular on stackoverflow trends:

https://insights.stackoverflow.com/trends?tags=next.js%2Crub...

P.S. Perhaps because a JS framework based off the ideas of rails would be called jails! /s

https://sailsjs.com/

IME many of the earlier new frameworks were somewhat poor attempts at replicating established players from other languages. That resulted in a lot of cargo culting of bad code, then inevitably churn. I think that's one (of several) reason(s) why Express became more ubiquitous early on. Then from there, since Express became the most popular, and it was more of a micro framework, it allowed multiple competing sub frameworks to emerge. I really tried to use some of the other JS frameworks at the time, and having migrated from Python / PHP always felt they were not very usable by comparison.

Moreover, JS really encouraged the use of API driven development + React, at a time when that trend was in general growing. I bet this impacted the ORM development space, as I suspect FE style devs were perhaps more demanding of an ORM while more backend oriented devs were perhaps fine writing SQL. With other frameworks I find the coupling of ORM and template views to be slightly more natural. Maybe this is just me inventing story lines but its how it feels. I think the lack of a quality ORM _really_ hurt the most.

Lastly there was a growing trend towards micro dependencies and assembling from parts, and I think it promised more than it could deliver. I think if Node had shipped a higher quality standard lib, perhaps akin to Go or (maybe) how Deno is trying to do, the story might have looked much different.

This is my take as a consumer, rather than creator / maintainer of these frameworks, so not sure how accurate this is. Just my viewpoint with my dev career growing alongside the early emergence of Node.

I've built Django projects for years and wondered the same thing whenever I had to build something in Javascript land. There are some scaffolding tools that do pretty much what those frameworks do (e.g. create.t3.gg, which I've used recently for a couple of small projects and really liked) but obviously lack that feeling of cohesion that strong opinionated frameworks like Rails or Django come with.

Not sure if that's a plus or a minus, after all there might be devs whose preferred stacks differ by 1 or 2 items (e.g. prisma over drizzle, nextauth over something else) and they'd both benefit from having a standardized template to start with.

EDIT: just remembered I fell in love with Meteor for a while. Then they started shoving React and other external stuff into it to gain more market share and it inevitably lost that opinionanted nature that, IMO, made it so good. Choice isn't always a good thing for the end user (even, and sometimes especially, when that end user is a professional who just wants to get things done).

Not "any" but "most". I've worked for a company whose RoR codebase/structure looked completely different from the usual because they used a Domain Driven Design-inspired architecture.

This is due to a conflict of philosophies within the RoR community. Basically the clean code enthusiasts (which are also more likely to subscribe to DDD) argue that business logic should not be tied to which specific web application framework you use. So it should basically be in a separate codebase, either in the `lib/` directory or literally in a different project and included into your application as a Gem.

This makes sense from an objective perspective on what constitutes clean code, and I used to believe that this is what a really large enterprise Rails codebase should be refactored to eventually (although I never personally did so).

Rails offers an alternative approach to this however, that is less neat from an objective perspective, but actually follows the Rails principles a lot better and it's called Rails engines. Basically you split your Rails app up into multiple mini-rails apps for each domain called Rails engines, each has the same directory structure as a Rails app and you get the full benefits of a regular Rails app inside each. I used to think this was an ugly approach and I never even considered it, but now after over a decade of Rails development I've made a 180 and I believe this is the way to go.

The "clean" way forces you to construct interfaces between your business logic and the Rails app, basically introducing a lot of extra boiler plate. All for the perceived benefit of making your business logic be abstract of the Rails framework. This violates YAGNI of course, and by a huge margin too. I've never seen the business logic of a Rails app be ported to some other framework in 15 years, the most I've seen is reusing code in a Grape API that was mounted inside the Rails app. And what you give up is Rails' convention over configuration and its predictable structure, and the general documentation and knowledge of that structure that people can carry from job to job.

That's very interesting! In Django this "Rails Engines" approach is the default. A Django project will be made out of multiple Django "apps", each having its own routers (called URL-dispatchers), controllers (called views - yes, I know its weird to call them that), models and templates.

I'm struggling / thinking about this myself a lot.

I've learnt a bit of Django's app-centric model (which is similar to rail's "engines")

I work for a company that enforced the data/domain/interface with a plug-in approach to custom code.. and I liked it.

But for my own projects, I get stuck choosing between the two, I see more benefits in the layered approach, but I feel like I'm fighting the tide with every project I start

I really liked the DDD book, but I think that many of the suggestions mostly apply to huge "do it all" enterprise applications, which are also not the best fit for Rails. So I think it's OK if you can't easily apply those patterns to a Rails app - if you actually need to build a single enterprise application to rule them all, you should probably choose a different framework anyway.

It's a huge benefit for agency/consultant work. You can jump into a project you've never seen before and just know where everything is and how it's wired together. You can be immediately productive.

The downside is if you want to do something that cuts "across the grain" so to speak, things can get messy. Combine that with Ruby's high dynamism and someone trying to be too clever can make a mess fast (alias_method_chain anyone?).

Yeah, node has been incredibly successful but I think it's a fair criticism to say it's also a victim of that success in that it just feels like so much arbitrary complexity. And the flavor of the month changes so fast that projects end up this weird mishmash.

Many of the Node projects (typically Express) I've built start out super tiny, one or two files, but once they grow to any production-level complexity, I find myself more or less mirroring the Rails structure.

I'm going to have go push back on this.

I don't like the RoR community, not because they're bad people, but because I think they're insane from a tech perspective.

I only occasionally pick up RoR work because of how off-putting my first experience was. But what makes it worse is that every project I've been on (including one I just started on a few weeks ago) has just been a cluster.

What you're saying here is true in theory, but what you're not telling people is how the community is about as close to the attitude of npm as you can get on the server side. hundreds of gems on your typical application, many of which are used in 1 or 2 places, helping avoid a grand total of less than 5 lines of code.

Then there's the ratwheel you opt into with rails. Every single damned time I find myself having to manually patch libraries to get it working properly. I even once had to track down an old Ubuntu image of a version that had EoL'd 5 years prior and THEN had to manually patch a few C dependencies just to get it to build and run.

Don't even get me started on wkhtmltopdf, fuck that dependency. If you use that in your RoR project, fuck you.

^ that's only partially meant to be humourous.

My experience is that developers suggest RoR then run off into the sunset on their new project, leaving companies not understanding that they're now on a ratwheel of maintenance and upgrades until it's so bad only someone such as myself even has the skillset necessary to pick up the pieces.

Contrast this with asp.net core. Each LTS version is supported for 2 years (which is too short imo), but more importantly, you can install the EOL versions just fine. I would never recommend RoR over asp.net core (asp.net 6+ ... LTS only) because developer productivity isn't worth the maintenance cost.

.NET's LTS releases are supported for 3 years and STS are supported for 18 months. I wish LTS support was 5 years, it seems like ecosystem has matured enough post-going-OSS-wild-ride starting with .NET 6 release and is ready for such a support timeframe. Or at least they could have every other LTS be ELTS?

Also, I do wonder if RoRs perceived productivity is by inertia? I have a hard time believing you can top the productivity of quick scaffolding for back-end you get circa .NET7-8?

On the flip side, within the last few years, upgrading .NET versions has become typically a very easy exercise.

The ASP.NET team tends to churn stuff wayyy more often than I'd like for questionable reasons, which can make keeping more painful than I'd like - but tbh I often just keep using the older ways of doing things in ASP.NET since it's almost always still supported...

I do think .net moves faster than it should (faster than it used to for sure) but I assuage that worry with the fact that you can still install .net framework 1 and it'll work.

you're right, looking closer I got my wires crossed.

non-LTS is 2 years, LTS is 3 years

https://dotnet.microsoft.com/en-us/platform/support/policy/d...

imo, short term RoR will beat the pants off asp.net core in terms of developer productivity. mid to long term asp.net core wins hands down in terms of developer productivity.

I don't think the RoR productivity story is fake, but I do think it's not worth the long term maintenance costs.

I think you have encountered some projects built by undisciplined teams. That is not a reflection on the framework, rather a reflection on the people improperly using it.

The culture encourages a lack of discipline; indeed, high framework coupling is seen as the Rails way.

Framework coupling sure, but that has little to do with adding other random dependencies.

Also why would you be afraid of coupling to the framework? It's not like you're going to be able to change the framework after the project grows, anyway.

while that's true and obviously you can avoid these problems with any framework with enough discipline, my point is that the community in general isn't disciplined.

I've repeatedly seen the same things over a 15+ year timespan.

Perfect storm of dynamic typing, needing to keep up with breaking changes, thought leaders that thought leader too much, and a community that seems to push back on anything that calls into question The True Rails Way.

So if I have an idea for an online service / app. I can go an make it using Ruby on Rails all on my lonesome?

Do I have to deal with JavaScript in any way?

Do I have to deal with JavaScript in any way?

You can use Hotwire (look at turbo frames and turbo streams) and you will write less Javascript code while achieving some very nice interactive UI.

I can go an make it using Ruby on Rails all on my lonesome

Sure can. However I won't pretend it's the only framework you can do this with and be productive. I love Rails and Ruby but it has great competitors these days.

Do I have to deal with JavaScript in any way?

Really depends on what you're doing but probably.

“From Hello World to IPO”

Which specific documentary is it? Google seems to return a few different options.

The linked Youtube video.

Ah yes, around 41 min in… Thanks for the reply.

     it looks basically the same in structure whether it is the 
     biggest Rails app there is or a new one

Totally agree! Developers tend to really undervalue this aspect of RoR.

In addition to easier onboarding, it greatly reduces bikeshedding.

MVC maybe isn't the best paradigm for everything, but it's good enough for most things.

Developers tend to really undervalue this aspect of RoR.

I agree! I think maybe because the consistency only shows its value:

* over years

* in its absence (on other projects which aren't using rails)

Which means it is easy to miss.

I see the same thing with spring. Having constraints helps free you up to solve different kinds of problems. I lived through the "let's define everything from the ground up, picking all our libraries, etc" phase of Java (in the early 2000s; I remember Tapestry and Wicket and Struts and Expresso and XMLC). Would prefer to not do that again.

But coalescing on a particular framework is something that a community has to arrive at together. While I think that JavaScript, for example, would benefit from this, I don't know how to encourage it (other than by leaving comments on HN, maybe :) ).

And don't think that coalescing means there are no other frameworks. Java has a number, and Ruby does too (trailblazer is a rails++ , Hanami is a rethinking of MVC, Sinatra is like flask). But having one big player makes it easier to focus on higher order solutions.

What I also loved is that he mentioned that if you open up any Rails application, it looks basically the same in structure whether it is the biggest Rails app there is or a new one

Which is funny because uncle bob cites this as a major downside to architecting code.

And lots more.

Ruby 3.3 YJIT is 2x faster than Ruby 2.5 in RailsBench.

Work on brining more Ruby Gem from C to Ruby ( easier JIT )

Lots of dev tooling around Ruby and Rails coming.

Hopefully there are more good things to come in Rails 8.0 and Ruby 3.4

The structure of Rails was my first experience of web development (as a job, at least) and it completely ruined me for anything else.

What's funny to me is I have been doing Rails for 15 years, even wrote books on it, and I just thought Tobi was a guy who made a lot of popular Rails stuff. Didn't realize he was the founder and worth 5.5 billion dollars lol

Two figures that inspired me were missing, why the lucky stiff and Ryan Bates from railcasts fame.

Otherwise great docu with DHH "f*uk you" slide which does give an insight into successful open source projects.

Ryan Bates is a legend

Ryan did so much for the rails community and all because of the joy for RoR.

Unfortunately iirc Ryan suffered a burnout and had a lengthy break. I hope all that is better now.

All is better. I still plan to blog about the burnout.

Great to hear and please blog about it - folks need to be aware of the dangers of burnout.

Unfortunately having folks around me that had burnout helped me to avoid one myself.

Indeed. Also, kudos to Chris Oliver for taking up the mantle.https://github.com/excid3

Definitely! Chris's stuff is great.

The Ruby on Rails community struck me as different back in the day in how fun it was.

It's hard to explain but coming from a Java background the community seemed to be full of interesting and engaging characters. Some people don't really appreciate that and prefer things to be very dry but I loved it.

I'd like to shout out to Ryan Bates, Geoffrey Grosenbach, Zed Shaw, _why, Jason Seifer, Gregg Pollack, Sandi Metz, Ezra Zygmuntowicz, Yehuda Katz, Dr Nic, Tenderlove and a whole heap more.

Thanks everyone, you've made it a very entertaining journey.

I think he heard us...

https://news.ycombinator.com/item?id=38253485

I agree with that, I would also have liked to have seen Tenderlove in it.

tenderlove is legend, on both the Ruby and the Ruby on Rails sides

Yes! Tenderlove was brilliant, especially his profile image :)

I'm always here to speak praises for Ryan Bates. His practical videos to build features was a huge insight for me as a junior developer at the time.

Thanks! Glad to help.

Thanks Ryan. You made me love Rails and to be passionate about coding. I’m still working every day in it and still love it every single day. I have a one man SaaS that is providing for me and my family for the last 9 years.

You played a big part in it. Thank you!

I wouldn't expect to be mentioned in the documentary, but thanks for the shout out. :)

I tried to like ruby and rails, but when I tried to grok the language, I found it more difficult to follow than python + js (my daily drivers).

Did anyone else feel the same way? I kind of want to give it another chance bc I have some side projects that I want to try out, but I find django/python and next/react easier to grok. Maybe I should try harder?

FWIW, I also want to pick up good practices when it comes to engineering a back end, and the good ex-rails engineers I know tend to be really good in general.

Interestingly, for me it is the exact opposite, I tried Django/Python and it's more difficult for me to grok. Somehow I just find Rails easier and more straightforward.

I think its bc I just know python better. When I look at ruby code, especially with symbols, I can't really tell what's going on the same way I can with python. I get the impression python is more simple while ruby is more powerful (featurefull) + more object oriented.

Yeah, probably. I just moved from Ruby to Python and I'm not exactlylovingPython. But, I'm quite sure it's just that I'm not used to Python yet.

I think one thing is true -- Ruby gives you lots of different ways to do things. And it can be really terse sometimes, if you want it to be. Some Ruby devs IMO should learn to favor readability over terseness.

Overall though, Ruby is my favorite language and IMO can be very beautiful. I don't think anybody would call Python beautiful. (Lots of great things about it though, nice language and ecosystem... no hate)

I've worked more in Python, but rails was way more intuitive for me than Django. I knew just how I should do everything, and if I needed to alter some functionality, I knew just where to look. I loved its consistency.

I like ruby quite a lot, too.

rails made me very fast.

Honestly, if you only are familiar with Python, it’s gonna be pretty tough to learn anything else. I would recommend spending some time learning literally any other language (Ruby is fine). Otherwise, if you just know Python, I think it will hold you back.

For example, ending an if statement with semicolon and then having the if block indented below is just not the normal way to do things. I’m not knocking Python, I use it all the time and it’s great, but it’s not a language you can carry over to learning other languages. It’s like if you know English, it’s pretty easy to learn Spanish. But if you only know Chinese, it’s going to be tougher to learn an “English-ish” language. Hope that makes sense.

FWIW, I have experience in TS/JS, Python, Java, and Scala. I would say TS/JS is my strongest stack.

Its not the minor syntax differences that I have trouble with, its that ruby does not "fit my brain like a glove."

This was (is) me.

Love Rails, but found it very difficult to learn Ruby. It's very hard for me to read, but that may be because I come from a C# background.

If you're looking for something like Rails, I'd recommend trying out Laravel.

It's on par with Rails as far as features, ease of use, etc. And PHP was a lot easier to learn for me versus Ruby.

When I first started with Rails on a project I took over in 2012 I really disliked it.

Today it’s something I repeatedly try to tell everybody about. It’s just so productive.

Look athttps://dry-rb.org/, some of the patterns there may seem more familiar.

Ruby is much more straightforward than Python or JS IMO. But Ruby devs tend to love metaprogramming a lot more (IMO) which can seem obtuse.

I saw it and I don't think it make it any justice, Ruby on Rails changed the paradigm of creating web applications with routes instead of files (like PHP, JSP and Webforms did) with the MVC pattern that now is present in every respectable web framework and the documentary doesn't tell that. It was enjoyable though.

MVC was already used in frameworks like WebObjects for example (and maybe others) quite a while before Ruby on Rails was born.

Sure but I think the point is Rails popularized it.

It probably made it more available to the masses (as WebObjects was not free and license costs where in the region of a car at some point)

MVC was popular before Rails. Rails certainly introduced MVC to a lot of new people, though.

Struts was a popular Java MVC framework in the early 2000’s and was pre-Rails.

I kind of feel bad mentioning Struts and Rails in the same sentence, though, as Rails did much more than Struts.

MVC dates all the way back to Smalltalk in the early 80s.

I do seem to remember DHH complaining about "XML pushups" when Rails was released, and knowing what he meant from Struts.

Sounds like from the comments that Rails is gaining a little bit more popularity again instead of being known as the boring robust framework

I probably won't use it again in any projects, but I liked the video because of nostalgia. Rails is a memory of a fun and scrappier me, a different time, appropriate in its own light for my path at the time.

Why wouldn't you use it again and what would you use instead?

Governance seems more invested in making ideological changes (dropping Webpacker, TypeScript, breaking changes between versions that add busywork but no value) than building the community and expanding reach. DHH continues to push poor technical decisions and alienate contributors by taking weird political stands.

As someone who’s taken multiple projects to production in Rails and generally loves Ruby, these days I prefer to start new projects in full-stack TypeScript. RedwoodJS has been quite good.

Which of DHH's technical decisions would you consider poor?

After doing lots of Node and Go I've recently come back to Rails and, no joke, it's about 5x faster in development for me. So many niceties. Using Prisma I had a 25 line method (and no real models) and that went down to 3 lines in Rails. It's just a night and day difference. I won't leave Rails again.

Rails really is the premiere framework for web development speed

I couldn't have said it better, its impressive how much you are able to do through Rails in such a short time.

sad to see _why the lucky stiff left out, but I suppose it is what he'd have wanted.

his 'artsyness' was the main reason I avoided learning Ruby for years-- wrongly thinking people who code in Ruby speak like him.

I know this is a possibly unpopular opinion but I don't think one should glorify a sophomoric book as a key Ruby book-- there are others that deserve that title, PickAxe is close, but I'd have liked a book like Whittaker's "C#, Player Guide" for Ruby.

I absolutely loved _why's guide, not the least because it made certain very serious, over the top professional people very uncomfortable. Bullshit in the guise of Very Serious Business Software Engineering is still bullshit, but if you present something like it's a big joke to you, and it still shines, there probably is something to it. I feel a lot of present-day IT wouldn't pass that test.

Well, my opinion is, he took something elegant and sublime and dressed it up in bullshit; there's nothing wrong with being playful and fun--as I mentioned earlier, Whittaker's "C#, Player's Guide" is the ONLY programming book that presented serious stuff in a fun way without clowning.

Perhaps Ruby isn't for you then?

Matz's intent was and has been to bring joy and delight to developers, with the odd combination of PERL, LISP, and Smalltalk as his inspirations. Joy and delight don't necessarily equate with "most practical". But joy and delight are wonderful and healthful qualities to cultivate for a good life!

_why embodied much of the spirit of the (at least earlier) Ruby community. We were software developer immigrants, many coming from prescriptive verbose technologies (I'm looking at you, Java!). We were eager for novel ways of expressing our ideas. Ruby's metaprogramming capabilities are, as far as I know, still all but unmatched beyond perhaps Smalltalk itself (and IO, which AFAIK no one uses seriously). _why's playfulness captured all of this in elegant and sometimes bizarre but often artistic expressions in his projects and code.

I willneverregret or apologize for the Ruby community's appreciation for the Poignant Guide.

And, _why, wherever you are and whoever you are, thanks.

Don't remember _why doing any Rails development -- he was really key in Ruby land, but did his own (super-minimal) web thing called Camping. Anything I'm forgetting that he did with/for Rails?

There was not really a place to put it into the rails doc. But I put a comic strip as a tribute to _why into a related blog post:https://cult.honeypot.io/reads/why-ruby-on-rails-is-not-dead...

One of my biggest mistakes as a dev was not really learning Rails until 2015.

I just didn’t know how much faster building web apps could be.

Yeah me too. I am still sad thinking about the number of hours I spend messing with python environments and versions because I was told it was the “quick and easy” option for solving this or that small problem.*

Also worth mentioning Michael Hart’s intro course, which is a really shockingly well done way to ramp up from absolute zero, even for someone with very little code experience.

* Which, in fairness, it mostly is. But also meh.

Were you using Django?

His book is what got me up to speed in 2015. I was visiting Chiang Mai and binged through the whole thing over a few days and then spent the next week cloning various personal projects I'd written with JS backends.

In under two weeks of opening Michael Hartl’sRails Tutorial, I was already more productive with RoR than with the stack I'd been using professionally for 3+ years.

Same. I spent so long building Django apps and trying to solve problems that StackOverflow told me were inherently difficult, only to find out that Rails has built-in solutions.

This isn’t even a criticism of Django; the things that Django does, it does very well. But there are a lot of things that it doesn’t do that a mature web app will eventually need to handle.

My biggest issue with rails is that the convention it forces you into feels like it's not really a one-size-fits-all solution. I typically build sites that are a one-page or 2-3 page JS app running on an API, as opposed to the more traditional idea of backend paths that return html views. And it seemed like rails wasn't well-suited to that, which was why I didn't stick with it.

Going to have to watch this later today. I've messed with so many frameworks in the past - Laravel, ExpressJS, MeteorJS, Django, Flask, etc. All of them have their benefits and drawbacks and I've been at different knowledge levels when I've tried them all but I've always tried tutorials, done my own thing and given up.

Three days ago I started using rails and I just flew through the weekend to get a MVP setup to show a coworker. Rails just made it easy to focus on what my app needs to do, not how my app needs to be implemented. I can finally see why people love it so much.

I've been a Rails dev for a long time. I've tried a bunch of things and keep coming back to it for the same reasons as you. I'm incredibly productive in it.

For the longest time, my primary complaint has been a lack of documentation/conflicting information when you break from convention. It can be extremely challenging to find/understand the "blessed" way of doing things. Thankfully, ChatGPT is extremely good at providing a starting point for this stuff.

Could you give an example of how ChatGPT helped you specifically with Rails?

The one that I use it the most for is writing ActiveMigrations while integrating with some of Postgres features. There's a lot of settings that get pass-thru to the DB, but aren't clearly documented. I know it's possible, I just can't remember the syntax.

Same thing with some of the more advanced Model relationships. I just don't write _that_ many relationships, so I tend to forget how Rails wants certain things defined. Since a lot of things rely on config, rather than "normal" runtime code, it can be frustrating to debug. ChatGPT just gets me to the right answer.

---

It's also pretty useful at gut checking DB design. There's been a few times where it's suggested a different approach than what I expected and I've preferred it's suggestions.

Wow, thanks. I gotta start checking out how to leverage ChatGPT more.

Dupe:https://news.ycombinator.com/item?id=38222535

played the HN lottery

Yeah, a little frustrating. I think this is the second or third time that I get downvoted for pointing out a dupe of my submission.

I remember fondly when RoR was the hottest thing, so elegant and easy to understand, but I haven't touched it in ages. Is it still good compared to the more up-to-date stuff? Is it still relevant?

Yes. Hotwire is an incredible productivity booster. There can be some lag on waiting for the server to respond in some scenarios but I just drop into Stimulus and perform some manual "optimistic" UI updates -- usually in a just a few lines. I create all my new Rails projects with Tailwind and esbuild and have had no issues whatsoever. The new authentication stuff (generates_token...) is also a huge time saver.

Absolutely! I switched from PHP to Rails in 2008 and I've been able to upgrade all of the relevant projects to modern 7.1. Lots of changes/maturation along the way, but all in the right direction. Still best web framework for fast prototyping in 2023. I use Rails every day. Not the best for high concurrency or system tasks, but great for expressing maintainable business logic and working on web apps in teams.

They was a really good watch. The gentlemen in the video were and are very passionate about Rails.

Early on, these guys had blogs and it was some of the only content you could find on Rails. The documentation was pretty much nonexistent and not very easy to grasp for newcomers. This was before railscasts even hit the scene but these guys, and a very few others, were like disciples spreading the word.

I even remember at around that time there was a fundraiser specifically to hire someone to write better docs. I think it was some third party response to all the forums where people had been lamenting the desire for better docs. This was before go fund me and kickstarter so itself was a little unusual at the time.

I’m a longtime PHP/JS dev who recently decided to give Ruby and Rails a look given its influence on Laravel. The first thing I did was read the Rails Doctrine and, while I appreciated most of it, I thought "The Principle of The Bigger Smile" and DHH’s comments re Ruby's elegance were one self-indulgent-bridge too far. Back to the jaded PHP cave I go...

That was until I learned that in Ruby:

`someObj.some_var = 'hello'`

Is syntactic sugar for:

`someObj.some_var=('hello')`

That made me smile. I have never smiled like that about a programming language. It literally gave mejoy.

I’ll be honest I have some trepidation devoting my time now to something “old”, but on the flip side my career is in PHP so what the hell am I talking about “old” for.

You’re going to love writing tests for Ruby! Nearly everything is a message send, which works insanely well with testing libraries. It’s so damn easy and clean to reach meaningful test coverage in Ruby where it feels like a chore in other languages

Funny they show pictures of Berlin overlayed with "Toronto" at @22:16, I guess they meant to say Tobias moved from Germany->Canada but it made me ???.

And in the shot before that, Chicago!

I worked on a very large production rails app from 2015-2019 and came away loving Rails and hating Ruby. Give me Rails in TS or Go and I couldn't think of any reason to ever use anything else for a web app backend.

The Rails Console has to be one of the greatest productivity enhancers I've ever come across.

I’d love to see a Go REPL that can do nearly as many things as you can do with a Ruby REPL. It’s just not really possible I think. It could be doable with TS with the existing node REPL, but Ruby really is a huge driver behind why Rails console is as useful as it is.

By now I have watched many programming documentaries by Honeypot and I can't recommend them enough. They have documentaries of ue, React, GraphQL, Ember and some more.

There are so many legends from the early rails days that paved the way to how we develop modern web apps. I would go as far to say that in web development there is a time before and after rails emerged.

Great story. I knew a bit about Rails beforehand but it's really nice to see the people involved with its growth.

This was so fun to watch. It’s great to see people find their calling and do great work and change the world for the better along the way.

Haven't touched rails in several years, but now I need to get an idea to get back into it!

Watched it and loved it

Well done. One thing that struck me is how young the framework is in the big scheme of things. When I first got into programming around 10 years ago, people were already writing articles about how Rails was near obsolete so without giving it much thought I assumed it was from… maybe the early 90s?

Hig and low

What I really appreciate about Rails, is the strong vision, and not becoming another bloated framework for building "enterprise grade" applications. This is a 20-year-old framework, which does not afraid to radically change with time, and still being seen as Punk compared to rest

It was so heartwarming to remember my Rails story, its been 20 years ago since I started using it!https://twitter.com/buger/status/1723040883325460818

Honeypot documentaries are really good ! I highly recommend them.

Really amazing documentary! Been using Rails for the last couple of years and it’s just so productive for a small team to build product and follow well established patterns in building business logic.

I’d recommend to those interested in seeing how a real Rails app is structured to look at the Jumpstart codebase as it’s a great resource on how to structure things

https://jumpstartrails.com/

As an alternative Bullet Train is pretty good, even though it adds a lot of bespoke libraries that aren’t the “Rails way”

https://bullettrain.co/