[ElfinTrousers]

Kind of funny that "starting you off with all the features that are the same in every product" is a good description of the original motivation for Rails itself. Which is not criticism, the goalposts have moved quite a bit the past few decades.

[danpalmer]

I see your point but I think this is at a level of abstraction that Rails never set out to solve.

Rails is arguably “technology batteries included”, whereas this is more like “product batteries included”. There are many Rails sites that wouldn’t use these features, however there aren’t many Rails sites that wouldn’t use ActiveRecord or HTML rendering.

[KronisLV]

> Rails is arguably “technology batteries included”, whereas this is more like “product batteries included”.

This seems like a great way to put it! At the lower level of abstraction, there's all of the technical stuff, but at the higher level of abstraction, you think more about the product and the business domain concepts.

[noodle]

I don't think so. This boils down to a set of already installed, pre-configured gems in a starter project. That's always how Rails has worked. When I was consulting, I had exactly this for myself before Bullet Train ever existed - a pre-configured rails repo that I just forked when I started something new.

The thing w/ Bullet Train is that so much work is done for you, that if you don't like an opinion or two that they hold, you really should start from scratch, as tearing things out will just take longer. Its the downside of having so much integration and configuration already done.

[nickelcitymario]

>The thing w/ Bullet Train is that so much work is done for you, that if you don't like an opinion or two that they hold, you really should start from scratch, as tearing things out will just take longer.

Not disagreeing, but wouldn't this be true of Rails itself? It's an opinionated framework. If you like those opinions, it's a great framework to use. If you don't agree with those opinions, you're probably better off using something else.

[noodle]

Yeah, of course. But there's a difference in things like, "I don't want Tailwind, I want Bootstrap" or React vs Vue; instead of things like I don't like Ruby or I don't like convention over configuration. The former set of things ARE decisions you can make within the framework, while the latter are things you can't. You can have this exact same conversation about most frameworks, it doesn't have to be just about Rails. I also had a Symphony repo set up in a similar way when doing consulting many years ago.

Having said that, some of Rails opinions are becoming more optional lately.