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

31–40 of 288 posts

Re: Doing Rails Wrong

#31

Post by b_e_n_t_o_n »

If you're gonna rant about the JS ecosystem at least get it right. You can set up a Vite + React + Tailwind setup with two commands

   npm create vite
   npm i @tailwindcss/vite tailwindcss
If you want automatic code formatting and linting install biome, that's one more command.

You don't need to think about React Refresh or babel or typescript, it's all handled by vite. I've never even seen a .babelrc file. And why does the author add husky?

Like, if you want to criticize JS fine, but chose valid criticisms. This just sounds like the author hasn't actually used modern js.

Re: Doing Rails Wrong

#32

Post by zdragnar »

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.

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.

Re: Doing Rails Wrong

#33

Post by jonhohle »

b_e_n_t_o_n wrote: post #31

If you're gonna rant about the JS ecosystem at least get it right. You can set up a Vite + React + Tailwind setup with two commands npm create vite npm i @tailwindcss/vite tailwindcss If you want automatic code formatting and linting install biome, that's one more command. You don't need to think about React Refresh or babel or typescript, it's all handled by vite. I've never even seen a .babelrc file. And why does t…

Those two commands required earlier commands to install node and npm.

Re: Doing Rails Wrong

#34

Post by hu3 »

b_e_n_t_o_n wrote: post #31

If you're gonna rant about the JS ecosystem at least get it right. You can set up a Vite + React + Tailwind setup with two commands npm create vite npm i @tailwindcss/vite tailwindcss If you want automatic code formatting and linting install biome, that's one more command. You don't need to think about React Refresh or babel or typescript, it's all handled by vite. I've never even seen a .babelrc file. And why does t…

What about the backend? Rails covers that, your solution doesn't.

I guess I should draw the rest of the owl.

Re: Doing Rails Wrong

#35

Post by bguthrie »

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 powerful framework, but the maintainers are generally well-meaning humans who do not possess a crystal ball, and many choices were made that were subsequently discarded. Consequently, my sense is that there are very few vanilla Rails apps in the wild anywhere.

(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. Docker and k8s bring a lot of pain. It's not worse than that was.)

Re: Doing Rails Wrong

#36

Post by barumrho »

zdragnar wrote: post #32
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.

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?

Re: Doing Rails Wrong

#38

Post by languagehacker »

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.

Re: Doing Rails Wrong

#39

Post by baggy_trough »

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.

Re: Doing Rails Wrong

#40

Post by sublinear »

matpin wrote: post #29
sublinear wrote: post #19

Earlier quoted context omitted.

$1M ARR and 10k+ emails? Those are rookie numbers. There's nothing special about a rails app achieving that. You'd be surprised what kind of far worse junk than anything we're talking about can scale the same or better and is ergonomic to another type of dev. This is all just bikeshedding.

Software complexity is bikeshedding? I disagree. I think it's one of the most important things, especially for startups. Of course Hey is still young... But I'm pretty sure you also know that they have Basecamp with 3M+ users. I mentioned Hey because I think it's a great example of sth more than lists/forms.

I think it's even less important for startups.

At some point, the business cannot be just one app or one tech stack. More devs will come aboard that disagree with the chosen tools and for very good reasons. You must work with the devs you have and the expertise they bring. Only the most out of touch CTO would avoid sunsetting legacy apps. There's the business side concerned with functionality, and then there's the hiring side concerned with implementation details. Both are key to getting the best devs and the best results.

Post reply on HN