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

141–150 of 288 posts

Re: Doing Rails Wrong

#141

Post by hashbig »

poorman wrote: post #30

Stimulus and Hotwire are the "rails way" now. I've read the docs and they still confuse the hell out me. Seems like you're reinveting your own javascript components over and over again. In my opinion Rails 8 + Intertia.js + React so much less "reinventing the wheel" (especially if you use shadcn components).

Most of the reason I've started losing interest in Rails and the DHH cult is their insistence that their homemade JS solutions (Stimulus, Hotwire, JS import maps) should be the default choice instead of industry standards like Intertia and Vite.

I am maintaining a Rails app with Vite + Interia + Vue, and it's many times easier to manage, develop, especially when working with LLMs that haven't been trained on DHH's new frontend experiments du jour.

Re: Doing Rails Wrong

#142

Post by phoehne »

debone wrote: post #134
phoehne wrote: post #133

The one thing I don't miss about Rails is constantly feeling like I'm doing it wrong. I had a 'discussion' at RailsConf when I was told I should stop using C Ruby and switch to JRuby because it's so much better. And that's the right way to do it. But I couldn't get JRuby to package reliably. I'd fix the issues, it would work for a while, and then something would change. Oh... because I wasn't doing it right. I have t…

Had similar experience with Rust. It's a constant stream of invalidation of your problems "you're holding it wrong".

Yeah - I'm doing the rust thing now. And yes, I am doing it wrong.

Re: Doing Rails Wrong

#143

Post by em-bee »

fhd2 wrote: post #68
languagehacker wrote: post #38

Any project that doesn't need 30 or more devs with various specialties working on it all at the same time doesn't need the complexity that frontend/backend separation introduces. I learned this the hard way through years of over-architecting 1-2 person projects as a freelancer. Nowadays, it's just Django with a little bit of Tailwind on top.

I was hiring for a Django dev earlier this year. For the case study, almost all of them built a thin API backend in Django, and a React monster for the frontend (and in some cases, pretty much all the business logic). When asked about their motivations, almost nobody could explain it. We hired one of the very few people that just used SSR.

i can explain it. (ok, i can't explain why someone would create a react monster instead of using a better suited frontend framework, but i can explain why i prefer to separate backend and frontend)

ever since i started using frontend frameworks for websites, the backend has become trivially simple. so simple that i have been able to reuse the same backend for all my websites built since. most websites do not need more than CRUD on the backend. and even for those that do need more backend logic, separating front and backend makes both parts easier to develop. they don't get entangled, and i can make drastic changes in either part without breaking the other.

frontend frameworks allow me to think of the frontend as an independent client application that runs in the browser. instead of having a complex application that displays here but runs over there, i have two simple applications, one that runs on the server and one that runs in the browser.

using a frontend framework makes development feel like writing a desktop application. i don't have to consider network latency, except to load and update data. but that can happen in the background. it doesn't affect the UI. it makes me think about loading data from the server efficiently. it allows me to preload data in the background. it allows me to cache it so that when the user switches between different views, the data doesn't have to be reloaded, yet it can still be updated.

you can do this with a server framework only too. but getting that working smoothly across multiple page loads is a lot more complex than having all views that share data in a single page application.

Re: Doing Rails Wrong

#144

Post by digianarchist »

poorman wrote: post #30

Stimulus and Hotwire are the "rails way" now. I've read the docs and they still confuse the hell out me. Seems like you're reinveting your own javascript components over and over again. In my opinion Rails 8 + Intertia.js + React so much less "reinventing the wheel" (especially if you use shadcn components).

Stimulus is basically a very small event system with HTML hooks that integrates well with the Rails request lifecycle. I'd love to know if anyone has built anything sophisticated with it because I found it difficult to do anything remotely complex.

Re: Doing Rails Wrong

#145

Post by b_e_n_t_o_n »

JodieBenitez wrote: post #130
b_e_n_t_o_n wrote: post #109

Earlier quoted context omitted.

What if you're building a highly interactive front end?

That might be a case where you want a SPA + backend API. But the point is that in many cases you either don't need a highly interactive frontend or the frontend is not that interactive (ie. progressive enhancements work).

Ime progressive enhancements are brittle and hard to maintain. If your site doesn't need any JS it's fine, but as soon as it needs some interactivity beyond the absolute basics you benefit from having reusable components and automatic change detection / data binding.

Re: Doing Rails Wrong

#146

Post by dlisboa »

dakiol wrote: post #128
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…

> Tooling isn't the problem: The complexity is inherent to modern web development > 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. Depends. One can still write production-grade web applications with way less dependencies. You can write a Golang w…

You're not considering how scalable your simplified solution is to a team of 100+ people developing the same codebase.

Most of the problems of software engineering are not technical, they are social. Web development is simple for a team of 1-10. I love the idea of hand-writing CSS and relying on simple scripts for myself and a few teammates. Unfortunately it doesn't scale to large orgs.

It's not that people don't want to learn.

Re: Doing Rails Wrong

#147

Post by status_quo69 »

johnfn wrote: post #110

> (John runs a single command. The app boots instantly, working forms, instant loading times, blazing fast navigation.) Sure it does. If you're not using Vite, how are you bundling? Oh, you're not bundling? I guess that means you're not using TypeScript? Interesting, how do you catch errors? Oh you just let things crash in production? How do other engineers understand the intent behind your code? Oh they don't I see.…

Correct me if I'm wrong but I believe you're interpreting this as if the rails app needs the same amount of is that exists in the described vite solution.

But in reality if you're using hotwire you can get away with almost no JavaScript at all comparatively. That's why stimulus is in vanilla js generally, it's meant for sprinkling behavior onto the dom vs controlling the dom.

So if you don't have a js framework that needs to control the whole Dom and doesn't need a gigantic optimization step or tree shaking or typescript or whatever, you can get away with a whole lot less than it you embraced those frameworks that _do_ want to own the dom wholesale.

Re: Doing Rails Wrong

#148

Post by b_e_n_t_o_n »

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.

I don't know to what extent that's true compared to the npm ecosystem, but the js ecosystem largely rejects the monolith framework approach. It's focused heavily on frontend / browser, and the most popular JS frameworks are really just backends for frontend. Its most common to have a separate backend, perhaps in a different language, and it's an approach I prefer.

Re: Doing Rails Wrong

#149

Post by nickelpro »

the__alchemist wrote: post #98
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…

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.

That's like saying the Unix philosophy adds complexity because it dictates a tool should do one thing well. Composition of tooling (consisting of many individual tools) is the basis for lots of rock-solid stacks.

I don't think the Unix philosophy is universally correct either, but "too many tools" is a complaint without much consequential basis. It's an aesthetic problem not a functional one.

Re: Doing Rails Wrong

#150

Post by bguthrie »

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.

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.

Post reply on HN