Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby on Rails: The Documentary [video]

youtube.com

Post reply on HN
Print view View original

221–230 of 248 posts

Re: Ruby on Rails: The Documentary [video]

#221

Post by berkes »

gv83 wrote: post #39
berkes wrote: post #17

> 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 a major contributor 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. An…

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…

> 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

Re: Ruby on Rails: The Documentary [video]

#222

Post by berkes »

merelysounds wrote: post #169
berkes wrote: post #17

> 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 a major contributor 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. An…

> 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 yo…

> 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 fit perfectly (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 my entire point. 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)

Re: Ruby on Rails: The Documentary [video]

#223

Post by berkes »

ksec wrote: post #173
berkes wrote: post #17

> 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 a major contributor 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. An…

>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.

Re: Ruby on Rails: The Documentary [video]

#224

Post by berkes »

LargeWu wrote: post #148
PH95VuimJjqBqy wrote: post #129

Earlier quoted context omitted.

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 beh…

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 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.

Re: Ruby on Rails: The Documentary [video]

#225

Post by berkes »

cies wrote: post #142
berkes wrote: post #51

Earlier quoted context omitted.

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 o…

> 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 O…

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...

Re: Ruby on Rails: The Documentary [video]

#226

Post by gv83 »

berkes wrote: post #221
gv83 wrote: post #39

Earlier quoted context omitted.

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…

> 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…

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.

Re: Ruby on Rails: The Documentary [video]

#227

Post by berkes »

ericb wrote: post #188
jupp0r wrote: post #20

Earlier quoted context omitted.

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).

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 ever…

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.

Re: Ruby on Rails: The Documentary [video]

#229

Post by PH95VuimJjqBqy »

berkes wrote: post #220
PH95VuimJjqBqy wrote: post #125

Earlier quoted context omitted.

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…

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.

Re: Ruby on Rails: The Documentary [video]

#230

Post by pier25 »

joshmanders wrote: post #204
pier25 wrote: post #194

Earlier quoted context omitted.

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…

> 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.

Post reply on HN