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

Doing Rails Wrong

bananacurvingmachine.com

Post reply on HN
Print view View original

161–170 of 288 posts

Re: Doing Rails Wrong

#161

Post by aldousd666 »

torben-friis wrote: post #157
mkhalil wrote: post #76

This article has been re-written for over a decade. The so-called "complexity" is just a list of tools that each solve a specific problem. Tooling isn't the problem: The complexity is inherent to modern web development. You see similar "hidden" complexity in other frameworks like ASP.NET, and GUI desktop frameworks as well. If you're using Rails as an API backend with React handling the frontend, it's almost a comple…

As someone who’s kind of a newbie in rails, but with 10 years of experience in other languages… It sounds ok to adapt tools if needed (won’t get into whether tools are actually needed, let’s assume they are). But Rails is supposed to be a giant, everything and the kitchen sink framework bringing everything from an ORM through its own console to scaffolding code generation. If adding tools to the setup is needed, isn’…

'vanilla rails' is really a bunch of other tech bundled together. including much of it that is rendered using other technologies. hotwire? javascript and websockets. The thing that always gets me about Rails (and I am a decades long fan of it,) is that when they upgrade major versions, all of the tooling that comes bundled in the box changes. Sure rails 1.0 didn't have websockets bundled in but it did indeed come built on Prototype.js, which if you still have in a rails 8 project probably gets a lot of laughs. There's a lot more to 'staying current' in a long lived rails app than just upgrading the gems.

Re: Doing Rails Wrong

#162

Post by butlike »

nucleogenesis wrote: post #41
barumrho wrote: post #36

Earlier quoted context omitted.

What was the reason?

I’d guess that it’s because React came around and it was from Facebook so it got a lot of adoption? Maybe there’s some other reason, the comment you responded to seems to imply something anyway

Javascript ajax was getting out of hand. Everyone wanted SPAs but managing the state of each button was becoming extremely unwieldy. Thousands of jQuery/js lines, the submit button wouldn't toggle to enabled once disabled...stuff like that. React came along and had prop state per element on a page (as they rebranded it, components), which helped immensely in this department.

Edit: and yes, as you said, it came from Facebook, so it wasn't just a solo developer's grad project; it had a large amount of support right out of the gate.

Re: Doing Rails Wrong

#163

Post by 0xblinq »

dismalaf wrote: post #91
0xblinq wrote: post #59

Earlier quoted context omitted.

That's the only good reason to use Hotwire. Being a JS hater.

You know Stimulus is for writing JS, right?

Yes. It's also recommended to not use much of it and do almost everything else with turbo drive, or turbo frames, or with turbo streams, or with whichever convoluted magic you can do to avoid it until you can't anymore. Then you use Stimulus. Yes, I know it.

The fact people can't escape JavaScript doesn't stop people from being JS haters.

Re: Doing Rails Wrong

#164

Post by steve_gh »

abtinf wrote: post #81
Jolter wrote: post #43

Earlier quoted context omitted.

It’s also the case that tried and true technologies work best for LLMs, since they have much more training on them.

Rails “convention over configuration” approach is probably also more LLM friendly. Convention can be trained into the model itself, whereas configuration takes up precious context.

I have definitely found this. A few months ago I tested Claude coding a web task in Rails vs Flask. Claude did much better with Rails - I think the opinionated Rails conventions helped the AI. However, Claude didn't complete the ask in Rails. A couple of weeks ago I revisited a similar task with one of the latest AIs. It sailed through it in Rails (didn't try Flask).

Re: Doing Rails Wrong

#165

Post by butlike »

Zanfa wrote: post #127
b_e_n_t_o_n wrote: post #107

Earlier quoted context omitted.

JS has multiple full stack frameworks similar to Rails. There is even a framework called Sails... The problems people solve with JS are different from the ones solved with Rails. Which is why the frameworks look different.

> JS has multiple full stack frameworks similar to Rails. There is even a framework called Sails... But it doesn’t. Rails is not just a full-stack framework. It’s the entire ecosystem of gems that magically just work together. What JS has is like the Temu version of Rails.

Haha that comparison made me chuckle out loud. It's true though.

Re: Doing Rails Wrong

#166

Post by timr »

bguthrie wrote: post #150
timr wrote: post #46

Earlier quoted context omitted.

> I'm old enough to remember what it was like to deploy a Rails application pre-Docker: rsyncing or dropping a tarball into a fleet of instances and then `touch`ing the requisite file to get the app server to reset. If this is what you remember, then you remember a very broken setup. Even an “ancient” Capistrano deployment system is better than that.

My recollection is that this is what many Capistrano setups were doing under the covers. Capistrano was just an orchestration framework for executing commands across multiple machines. More than that, I worked for many enterprises that were using Rails but had their own infrastructure conventions and requirements, and were unable or unwilling to explore tools like Capistrano or (later) Heroku.

> More than that, I worked for many enterprises that were using Rails but had their own infrastructure conventions and requirements, and were unable or unwilling to explore tools like Capistrano or (later) Heroku.

Well, OK, so you remember a bad setup that was bad for whatever reason. My point is that there's nothing about your remembered system that was inherent to Rails, and there were (and are) tons of ways to deploy that didn't do that (just like any other framework).

Capistrano can do whatever you want it to do, of course, so maybe someone wrote a deployment script that rsynced a tarball, touched a file, etc., to restart a server, but it's not standard. The plain vanilla Cap deploy script, IIRC, does a git pull from your repo to a versioned directory, runs the asset build, and restarts the webserver via signal.

Re: Doing Rails Wrong

#167

Post by timr »

bguthrie wrote: post #151
timr wrote: post #136

Earlier quoted context omitted.

Yeah, it also wasn’t difficult to do the equivalent without heroku via post-commit hook. Honestly, even setting up autoscaling via AMIs isn’t that hard. Docker is in many ways the DevOps equivalent of the JS front end world: excessive complexity, largely motivated by people who have no idea what the alternatives are.

I was working on Rails apps before AMIs or Heroku.

Me too. I'm not responding specifically to you with the parent comment. That said, "autoscaling", as a concept, didn't really exist prior to AWS AMIs (or Heroku, I guess).

My point is that a lot of devs reach to Docker because they think they need it to do these "hard" things, and they immediately get lost in the complexity of that ecosystem, having never realized that there might be a better way.

Re: Doing Rails Wrong

#168

Post by jrochkind1 »

If you like the "just rails" with no JS or CSS preprocessing at all (including no node dependencies), that's great.

I think that's still pretty ridiculous though.

I find that Rails+vite is a pretty nice sweet spot that really does just work. It's far far better than trying to use Rails with that "webpacker" chain or anything like that. i like that vite can do my CSS and my JS preprocessing needs, so it's just ONE thing, vite, and I'm set.

(Hypothetically you can use some light weight NPM dependencies with "just Rails" (really a weird take on importmaps, not "just rails"), but unless it's ultra simple it gets just ridiculous very quickly. Vite does not. I think the "no need for any real npm dependencies or other preprocesing of your JS, or CSS" dhh take is a weird one. Fortunately everything still works great if you agree with me.

Re: Doing Rails Wrong

#169

Post by torben-friis »

aldousd666 wrote: post #161
torben-friis wrote: post #157

Earlier quoted context omitted.

As someone who’s kind of a newbie in rails, but with 10 years of experience in other languages… It sounds ok to adapt tools if needed (won’t get into whether tools are actually needed, let’s assume they are). But Rails is supposed to be a giant, everything and the kitchen sink framework bringing everything from an ORM through its own console to scaffolding code generation. If adding tools to the setup is needed, isn’…

'vanilla rails' is really a bunch of other tech bundled together. including much of it that is rendered using other technologies. hotwire? javascript and websockets. The thing that always gets me about Rails (and I am a decades long fan of it,) is that when they upgrade major versions, all of the tooling that comes bundled in the box changes. Sure rails 1.0 didn't have websockets bundled in but it did indeed come bui…

>'vanilla rails' is really a bunch of other tech bundled together.

That was roughly my point - unless there's something wrong in my mental model, a Rails user is someone who trusts Rails to get them a sane and consistent bundled pack of tools so they can skip the choice and get to work. If one is going to choose a different set of tooling later on, that seems to defeat the point of using Rails in the first place.

I was not judging the framework itself, for the record. Just saying that if you go for it, going "vanilla" seems like the only sensible choice.

>when they upgrade major versions, all of the tooling that comes bundled in the box changes.

this does sound like a major con indeed.

Re: Doing Rails Wrong

#170

Post by 0xblinq »

matpin wrote: post #10
sublinear wrote: post #2

Meanwhile in real production environments... Rails apps are rare and getting replaced. Most web apps are static builds where the tools listed are not used all at once and largely irrelevant outside the dev environment. > John runs a single command. The app boots instantly, working forms, instant loading times, blazing fast navigation. Same with node? npm run build && npm start

The question I think we should be asking: Why? Why are we replacing everything with React and a bunch of other libs on top of it? The front-end dev space feels like a cacophony of people all blurting out the same over-engineered stack. If your app is a few lists, a chart, and a form... Does it _reaaallly_ need React? 37signals is afterall running multiple successful products with Rails, and one of them is an email cl…

> The front-end dev space feels like a cacophony of people all blurting out the same over-engineered stack. If your app is a few lists, a chart, and a form... Does it _reaaallly_ need React?

If your app is that simple you don't even need Rails.

In my experience, everything starts that simple. But then time passes, team members rotate, and... your PM keeps asking to add more and more features... And that's when the "simplicity of hotwire" becomes a nightmare to maintain. And guess what, the next dev that comes to the project will hate all the hotwire crap, and whoever built it.

It's easier to make a simple list and a form with React/vue/svelte even if it seems overkill at first, because when things get more difficult you already have the big guns. If you start with the tools to build simple, well.... wish your project stays that simple forever, or that you're given enough time to rewrite everything.

> 37signals is afterall running multiple successful products with Rails, and one of them is an email client.

These applications may be a successful product, despite of hotwire, but they're not a good example of anything. They feel like shit to me (using them from Europe). And again, the main problem is not the end result but the maintenance. If there's anything we've got from all of this mess, is that implementing UIs as "components" are the best idea in the last 10 years.

Stop beating the dead horse of variables interpolated in templates. It just doesn't work (unless you work alone).

Post reply on HN