Hacker News new | ask | show | jobs
by Aeolun 1771 days ago
Wait. So… you practically need to develop an app to start developing an app?

When someone tells me to ‘invoke these 3 magic incantations’, I can sort of keep track of it. But here it seems like the instructions are to invoke these 300 magic incantations.

3 comments

Yeah, one of the key selling points of Rails was that it was Omakase (Japanese: "I'll leave it up to you", i.e. you take the defaults Rails provides) and "batteries included" (i.e. there's enough provided in the box to get a working application).

Having to jump through all these hoops (I'll note that one of the suggested gems is Devise, which provides a framework for user authentication) suggests either this is very much no longer the case or this is tacking on a lot of stuff Rails was never intended to use, which could be fun to maintain down the line.

The majority of hoops jumped through in the article are entirely of the writer’s own making. They changed the default CSS pipeline and added functionality Rails deliberately does not define.

Devise is common for user authentication (and good choice, in my opinion) but it is extremely opinionated and does not like you departing from the blessed path.

Rails tends to avoid enforcing patterns beyond the base building blocks of MVC. User authentication is out of scope. (Turbo links is strongly opinionated but also very limited and very easy to remove.)

My point about Devise was more “if you’re not using auth, why have you included this?”. I think Rails should probably have a Devise-lite in the box, though.

This sounds like the second of my options i.e. gl;hf when the next major Rails release comes around.

Rails choosing not to provide a standard auth solution is 100% the right call. There are a wide variety of auth scenarios, and Devise is highly opinionated. If you're doing a pretty standard B2C type system where you have individual users, Devise fits well, but when you get to more B2B multi tenant with users spanning tenants, and more complicated workflows with users managing other users, Devise breaks down quickly.
Rails still works just fine out of the box. The bulk of this article is setting up Tailwind JIT, which is not required.
Having just been playing around with Rails and different CSS frameworks for a new project, this is entirely due to Tailwind's dependencies. Adding other CSS frameworks is as easy as yarn add X then importing it into your application.css file.
This setup is deviating quite a bit from a default rails setup: using the beta webpacker, tailwind + plugins, some extra gems.

Also - I noticed the author says "foreman is the best way to develop locally". I encourage the author to give overmind a try - it is a drop in, more featureful replacement for foreman. I love it.

This is due to adding a JavaScript framework. Rails can be up and running immediately.
They are only generators. You don't need to use them but they are there if you choose to use them.