Live data from Hacker News

Bullet Train – Rails-based SaaS framework

bullettrain.co

21–30 of 148 posts

Re: Bullet Train – Rails-based SaaS framework

#26
post #9

I evaluated Bullet Train last year when building an MVP for a client. Ended up using Jump Start Rails instead. Main reasons: 1. The hybrid approach to iOS and Android apps with JSR were better than what BT had to offer 2. There was a lot less to learn about the mental model of how JSR was built via Bullet Train. It was basically pay, pull down, configure, and get going with JSR. BT has things like SuperScaffolding, a…

Did you end up using tailwind with jump start rails? Any way around it? I like the idea of jump start rails but would like to stay away from tailwindcss.

Why?

Note, Bullet Train also uses tailwind.

Re: Bullet Train – Rails-based SaaS framework

#27
post #23

Earlier quoted context omitted.

genuine question -- as opposed to what when it comes to wanting to launch something quickly from zero

The only one that I could see competing is Django, but IMO it isn't as fast as rails.

Fast in what sense? Dev speed, performance, or something else?

Re: Bullet Train – Rails-based SaaS framework

#28
post #4

Earlier quoted context omitted.

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

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

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.

Re: Bullet Train – Rails-based SaaS framework

#29

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.

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.

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

Post reply on HN