Live data from Hacker News

Doing Rails Wrong

bananacurvingmachine.com

91–100 of 288 posts

Re: Doing Rails Wrong

#92

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…

This is why I've always had a soft spot for Sinatra

Re: Doing Rails Wrong

#93
post #10

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…

It’s just Basecamp and Hey now right? I liked when they had more than 2 products as a reference for Rails apps. I still feel immense nostalgia for Basecamp 1 and Backpack It.

—-

I love Rails but disagree. Using InertiaJS and React, Vue, or Svelte for some of the front end/views makes too much sense. The new Rails Way should be optionally allowing this.

Re: Doing Rails Wrong

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

Complexity is not inherent to web development. If anything it is now possible to get more done with less.

Hotwire is sort of vanilla rails and it enables you to create very modern experiences with content live updating through web sockets and it is basically a one liner to setup.

The de facto way to deliver JS in rails has also become far simpler through import maps. There is no build step for that. Tailwind support is a flag away when generating a new rails app and is super simple.

Deploying has even become simpler through kamal.

So no, complexity is not inherent to web development and the article is wrong in marking Hotwire as “complexity”. If anything it makes it simpler.

I agree with your point about learning, but learning shouldn’t be about learning more tech. The learning should be how to get more done with less. Anyone can use 20 different programming languages and servers, the skill lies in using 4 of them to do the same and outperform a thousand person team with just 3 devs.

Re: Doing Rails Wrong

#97
Well, I know there are people / apps that need React. I am hoping Bun would replace half if not all of those listed. You just use Bun with Rails.

There were talks on twitter about how the old days of using PHP and Perl with FTP just works.

Re: Doing Rails Wrong

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

Counterpoint: These tools add complexity, and you don't need them. If you step out of the system and look in, you see madness. The problems they solve are created by other tools; they are problem-generating systems.

Re: Doing Rails Wrong

#99

Earlier quoted context omitted.

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…

You are singing the song of my people.

Re: Doing Rails Wrong

#100

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

> Rails apps are rare and getting replaced.

Wait until you find out how many YC startups use Rails...

Or how big Shopify is. Or how many other large companies use it. And how many startups use it but just don't talk about it because it isn't cool anymore.

Post reply on HN