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

111–120 of 288 posts

Re: Doing Rails Wrong

#111

Post by mylons »

skinnymuch wrote: post #80
mylons wrote: post #24

Earlier quoted context omitted.

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…

are you dabbling at all in the “no build js” stuff that Rails 8 supports? i did it for that corporate project and their deploy time went from 30 minutes to 5 minutes. it’s also such a headache reliever but removing most of the confusing aspects of the JS ecosystem for me.

Re: Doing Rails Wrong

#113

Post by hahahacorn »

padseeker wrote: post #90
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).

this ^^^ I've used turbo/stimulus/hotwire. It's best suited for STATELESS interactions withe the browser/web page. The problem is not all desired user experiences and use cases are stateless. And the ecosystem for hotwire is a minuscule fraction of all the other popular js frameworks. If you're searching for inventory available its perfect. However if you want to update one thing based on the most recently touched in…

I think the fundamental misunderstanding (for the majority of devs who dont "get hotwire") is that you can very often delegate the statefulness of a given interaction to A: The Server via the database or B: The Browser via localstorage.

If your page can be written with it's state being "reasonably" delegated to one of these two, hotwire is _all you need_. (To be clear, it's more common that you're just doing a bunch of work to duplicate state that already exists in the database/on the server, or handled natively by the browser, and by "delegate" I mean don't-duplicate-for-no-good-reason.)

There are many (but fewer than those who "don't get" hotwire believe) cases where it's more of a headache to delegate state to A or B. In which case you should absolutely pull in react/vue//etc. My go-to is: https://github.com/skryukov/turbo-mount + react because it minimizes it's footprint on the "omakase-ness" of your rails app.

Re: Doing Rails Wrong

#116

Post by kelvinjps10 »

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

I think the point of the article it's that these tools are redundant since rails a full stack framework, already has the features to help you make a web app

Re: Doing Rails Wrong

#117

Post by andix »

I just use most of the tools that are mentioned. They just work, if you pick the right bundler (Vite is a good pick). It's like Linux, it requires hundreds of packages/tools to run, and nobody complains about that.

Re: Doing Rails Wrong

#118

Post by kenhwang »

tra3 wrote: post #61
mystifyingpoi wrote: post #49

Earlier quoted context omitted.

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

The primary benefit of containerization is isolation. Before docker, you'd drop all your code on a shared host so you had to manage your dependencies carefully. Specifically I remember having to fight with mysql gem a lot to make sure that there no conflicts between installed versions. With docker, you build your image, test it and ship it.

We had vm-per-app before docker, so it was still build the image, test, and ship, but it actually had everything it needed inside the vm.

Docker helps with the portability due to it's ubiquitous it is now, but it's not like the vm requirement went away, the docker image still generally runs in a vm in any serious environment, and a lot more attention has to be paid to the vm:docker pairing than the previous hypervisor:vm pairing.

Re: Doing Rails Wrong

#119

Post by mvdtnz »

bdcravens wrote: post #74
jamesu wrote: post #51

Earlier quoted context omitted.

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

Large rails apps tend to be on older versions not because they're so very stable but because Rails upgrades are a nightmare at scale. Even point versions have lots of undocumented breaking changes. There was a lot I didn't like during my 4 years as a rails developer but upgrades were the very worst of it.

Re: Doing Rails Wrong

#120

Post by nonethewiser »

I get the spirit of the dialogue. And feel quite similar. But I have some quips over things that are blatantly misconstrued:

- you wouldnt use vite then also add next or remix

- if you're using vite, next.js, etc. you're not going to need to add nor configure babel

- vite, next.js, etc. starters come with pretty much all of these separate things he mentions included. typescript, prettier, eslint, tailwind, react etc. You know, like a batteries included framework.

Post reply on HN