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

71–80 of 288 posts

Re: Doing Rails Wrong

#71

Post by timr »

darkwater wrote: post #66
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.

Capistrano lost its meaning when autoscaling went mainstream (which was around 15 years ago now), yet people kept using it in elastic environments with poor results.

The parent wasn’t describing an autoscaling deployment system.

Rails has a container-based deployment if you actually need that level of complexity.

Re: Doing Rails Wrong

#72

Post by jaggederest »

LollipopYakuza wrote: post #50
rubiquity wrote: post #28

Earlier quoted context omitted.

It was real over a decade ago. This is sheer stupidity and selfishness of bringing hobbies into their jobs. If it makes Front-End devs feel better, the "DevOps" world isn't much better.

What would be an comparable example in the DevOps world? (honest question, I am not really familiar with it)

Well, many years ago you could use CFEngine, Puppet, or Chef, or Ansible, or Salt/SaltStack, and then later Terraform, Otter, Pulumi, and now we have Nix, and a Terraform fork as OpenTofu.

Not all of those tools do identical jobs but there's a ton of overlap within them and they all have idiosyncracies.

Re: Doing Rails Wrong

#73

Post by mystifyingpoi »

LollipopYakuza wrote: post #50
rubiquity wrote: post #28

Earlier quoted context omitted.

It was real over a decade ago. This is sheer stupidity and selfishness of bringing hobbies into their jobs. If it makes Front-End devs feel better, the "DevOps" world isn't much better.

What would be an comparable example in the DevOps world? (honest question, I am not really familiar with it)

Imagine you want to deploy some microservices to Kubernetes. You can just create EKS/AKS/GKE cluster from the GUI, `kubectl apply` a few resources and create a load balancer to point your domain there. That will work. But...

You probably want to automate the infra creation (so Terraform, Pulumi, CDK...), you want to automate building (so GitHub Actions, Jenkins, Bitbucket Pipelines, GitLab CI...) and artifact storage (so Nexus, Arti, ECR, GHCR...), you want to automate deployment (so Argo, Flux, Helm, Kustomize...), you want to automate monitoring (so Prom stack, Datadog, many APMs, Splunk, Graylog, ELK... could easily name a dozen more).

Each part of the stack can easily bring a dozen different tools. I work in SRE and I use at least 40-50 tools for a mid-sized project. And this is "normal" :)

Re: Doing Rails Wrong

#74

Post by bdcravens »

jamesu wrote: post #51
Zanfa wrote: post #17

I sorely miss the sheer amount of utility that you can get from Rails out of the box for free compared to anything in the JS universe. Most JS devs don’t have the faintest idea how much they’re missing out on. Then again reinventing wheels is the JS way of life.

I find you get a lot of utility, but long-term you need to keep updating your codebase and follow whatever trend rails is currently on.

It's useful, but not necessary. Plenty of 10+ year old Rails apps in the wild. Github was running Rails 2.3 until 2018 while the entire software world that depended on it didn't fall apart. Even if you follow best advice and update your dependencies for security sake, you can effectively run the same code using the old "trends" (aside from things like safe parameters, etc).

Re: Doing Rails Wrong

#75

Post by asplake »

timr wrote: post #46
bguthrie wrote: post #35

I've been writing Rails code since 2007. There's a reason the stack has gotten more complicated with time, and virtually no team has ever done it right by this definition. The trouble with an omakase framework is not just that you have to agree to the initial set of choices but that you have to agree with every subsequent choice that's made, and you have to pull your entire dev team along for the ride. It's a very po…

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

Or there was “git push heroku main” or whatever it was back in the day. Had quite a moment when I first did that from a train – we take such things for granted now of course...

Re: Doing Rails Wrong

#76

Post by mkhalil »

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 completely different application architecture than a traditional Rails monolith. So the list of tools (Vite, React, Prettier, etc..) is almost for a completely different problem (again, unless you use Rails for FE; if you want to use Rails for Frontend, use Rails for Frontend; not a fan of the mash-up at all.)

The real issue is learning methodology: A lot of developers today start their careers with frameworks (point 4) before learning the fundamentals of the web (points 1-3).

HTML for markup.

CSS for styling.

Learning server-side logic (e.g.: can POST and can return a completely different page at the same URL) and databases for dynamic content.

Then, JavaScript for interactivity.

Embrace the tools: Each tool on the list (Vite, Tailwind, etc.) exists for a reason, and they're all necessary for a modern web application. Saying there are "too many" is an amateur take on the reality of the ecosystem.

Re: Doing Rails Wrong

#77

Post by maxlapdev »

mystifyingpoi wrote: post #49
bguthrie wrote: post #35

I've been writing Rails code since 2007. There's a reason the stack has gotten more complicated with time, and virtually no team has ever done it right by this definition. The trouble with an omakase framework is not just that you have to agree to the initial set of choices but that you have to agree with every subsequent choice that's made, and you have to pull your entire dev team along for the ride. It's a very po…

> rsyncing or dropping a tarball into a fleet of instances Could you elaborate? Doesn't sound like a big deal.

It is very funny to me that the sibling comment calls this "a very broken setup" and for you "it doesn't sound like a big deal".

It's all about perspectives, or you really just never had to deal with it.

The happy path ain't a big deal. But think of the unhappy ones:

* What if a server gets rebooted (maybe it crashed) for any reason anywhere in the process. Maybe you lost internet while doing the update. Were you still dropping tarballs? Did the server get it? Did it start with the new version while the other servers are still on the old one?

* What about a broken build (maybe gem problem, maybe migration problem, may other). All your servers are on it, or only one? How do you revert (push an older tarball)

A lot more manual processes. Depends on the tool you had. Good tooling to handle this is more prevalent nowadays.

Re: Doing Rails Wrong

#78

Post by baggy_trough »

skinnymuch wrote: post #67
baggy_trough wrote: post #39

Earlier quoted context omitted.

Personally I'm liking Rails 8 + Tailwind + Stimulus. No node.

Are you familiar and adept with React/Vue/Svelte? I haven’t looked at Stimulus or Hotwire much yet. Just picked Rails up again a few weeks ago. Tailwind and Shadcn (or similar ui) are standard for me now.

No I'm not. I've been happy with a server side rendering approach with a few interactive sprinkles from Stimulus. Tastes great, less filling!

Re: Doing Rails Wrong

#79

Post by sdotdev »

what’s interesting is how every few years we circle back to the same conversation with new names for old problems. the industry keeps rebranding the same complexity as innovation, but it’s mostly the same tension between abstraction and control. every new framework promises to simplify things, but each simplification hides an entire new layer of assumptions that developers eventually have to learn anyway. maybe that’s just the cost of building software at scale now: we’re layering human preferences and historical context into the codebase as much as we are logic. in that sense, modern stacks aren’t complicated because of bad design choices, they’re complicated because they’re living artifacts of collective compromise.

Re: Doing Rails Wrong

#80

Post by skinnymuch »

mylons wrote: post #24
Alifatisk wrote: post #18

I think some people are so fixated with keeping up with the latest tech and prepare their project to scale infinitely that they have forgotten how good barebone setup is, especially with Rails. I get it, it's boring, unentertaining and might be understimulating to some. But it just works, Rails is truly batteries-included. Stop with the overengineering

i came back to rails after a very long hiatus to help a company bring a 10+ year old rails project to Rails 8.x.x from Rails 5. It took a bit to get back in the saddle, but every new project I’ve started since that’s a SaaS/CRUD app of some kind it’s in Rails. I’m finally at the age where productivity is infinitely more important than anything else.

A few weeks ago because there were 2 HN comment sections shitting on NextJS endlessly, I decided to go back to Rails.

I have ported a chunk of my likely last full stack JS project over to Rails with AI vibe coding everything as a reference for me to redo it again with AI but not vibe coding.

Absolutely amazing work. About 40% of that NextJS app was vibe coded and the process of undoing the excessive and verbose code was depressing me.

The Ruby and Rails code is simple and understandable and a fraction of the lines of code.

Last sentence exactly. I am using IntertiaJS for some of the frontend and I finally don’t dislike JS any more. React is amazing when it’s only a view library.

Post reply on HN