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

61–70 of 288 posts

Re: Doing Rails Wrong

#61

Post by tra3 »

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.

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.

Re: Doing Rails Wrong

#62

Post by cwillu »

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.

Honestly asking, but did you forget to add a “/s”?

Re: Doing Rails Wrong

#63

Post by treis »

This is the fundamental weakness of Rails. You can't just "do Rails" because the UI out of the box isn't usable. You've always had to add something on whether that was Bootstrap 10 years ago or React today. It's always been a bolt on and always has been changing.

Re: Doing Rails Wrong

#64

Post by thinkingtoilet »

LollipopYakuza wrote: post #48
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 second this. In most industries, your clients won't care if the software relies on an ultra scalable architecture split in microservices or a monolith + PostgreSQL.

In every project I ever do, I start with a server and a postgres database. Every addition to that architecture has to be rigorously defended. So often people add complexity for absolutely no reason. Once you actually start scaling then you can worry about the problems that you think you might have.

Re: Doing Rails Wrong

#65

Post by Romario77 »

barumrho wrote: post #36
zdragnar wrote: post #32

Earlier quoted context omitted.

Ember.js was created by big names in the rails community, and made big promises of being a rails like batteries included all in one framework. There's a reason it didn't really get the popularity the other frameworks got.

What was the reason?

I think it adopts some ruby conventions (one I discovered is the name in singular vs plural can mean different things like a collection and an item of a collection). I think there are a lot of conventions like this - you have to know.

I am not a UI developer and just needed to understand/debug something, it was not easy at all.

Re: Doing Rails Wrong

#66

Post by darkwater »

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.

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.

Re: Doing Rails Wrong

#67

Post by skinnymuch »

baggy_trough wrote: post #39
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).

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.

Re: Doing Rails Wrong

#68

Post by fhd2 »

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.

Re: Doing Rails Wrong

#69

Post by rubiquity »

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)

The entire CNCF landscape

Re: Doing Rails Wrong

#70

Post by valevk »

treis wrote: post #63

This is the fundamental weakness of Rails. You can't just "do Rails" because the UI out of the box isn't usable. You've always had to add something on whether that was Bootstrap 10 years ago or React today. It's always been a bolt on and always has been changing.

Which framework is actually just „do X“? Good frameworks should be easily extendable with other technologies.
Post reply on HN