4 ms·

> it's inevitably where you're going to end up If the project's successful. The chance that most of what we're building with Rails hits the required escape vel

> it's inevitably where you're going to end up If the project's successful. The chance that most of what we're building with Rails hits the required escape velocity to require something other than Rails is a "Nice Problem". For the vast majority of things people are building for the web, "CRUD+Auth+Billing" is all that's needed, maybe with a few API hooks into something more novel running on different infra. If you then need it, then you can just build out a few more services with a few more API hooks, and then transition to a non-Rails stack as required. It's great if you have unlimited resources to spend the time setting up the perfect tech base for a project for if it does eventually require scaling above what, Basecamp for example, can handle - but that seems like wasted resources for a great deal of orgs that don't have that level of backing. Of course, if you truly need something novel, then it's a moot point, if you can't achieve what you need to with a stack, then just don't use it.

lmm 8y ago
> If the project's successful. The chance that most of what we're building with Rails hits the required escape velocity to require something other than Rails is a "Nice Problem". > For the vast majority of things people are building for the web, "CRUD+Auth+Billing" is all that's needed, maybe with a few API hooks into something more novel running on different infra. > If you then need it, then you can just build out a few more services with a few more API hooks, and then transition to a non-Rails stack as required. True as far as it goes. But if we're just talking about a prototype for validating product/market fit, with the intent to transition to a more maintainable stack as and when that becomes necessary, what's the problem with "list of 30 random npm packages" as a starting point?
- smw 8y ago
  > what's the problem with "list of 30 random npm packages" as a starting point? The dude starting with rails will probably be done with the MVP before you decide _which_ 30 random npm packages to use.
  - lmm 8y ago
    I'd probably just copy/paste from my current project TBH, which takes all of 5 seconds.
- wastedhours 8y ago
  Rails can take you much further than MVP though, as evidenced by all of the companies that reach breaking point with it. Basecamp, Github, Shopify - all reached proper business status on Rails (arguably Twitter too, although business is a bit of a stretch...). We can argue it from both ends, but I see Rails as the middle ground, and allows you to go from MVP to $XXm ARR on the same stack. A hacky MVP with 30 npm packages doesn't have a clear path up the tree to grow without serious changes, and a custom architecture is useless if you don't get any users.
  - lmm 8y ago
    > A hacky MVP with 30 npm packages doesn't have a clear path up the tree to grow without serious changes I see it as the opposite: it's clear which functions are the responsibility of which library, and it's easy to replace the ones that are becoming blockers and leave the ones that aren't. Whereas with Rails if you keep it monolithic then upgrades always become a huge pain point, but if you try to cut out pieces of it you're going against the grain. (I used to love TurboGears nearly a decade ago, because you could use it like a monolithic framework to start with but it was explicitly a collection of standalone libraries underneath, and so once you started needing to do different things to individual pieces it was easy to. The modern web ecosystem could do with something like that, IMO (though personally I'm sticking to ScalaJS for the type safety))

lmm 8y ago

> If the project's successful. The chance that most of what we're building with Rails hits the required escape velocity to require something other than Rails is a "Nice Problem". > For the vast majority of things people are building for the web, "CRUD+Auth+Billing" is all that's needed, maybe with a few API hooks into something more novel running on different infra. > If you then need it, then you can just build out a few more services with a few more API hooks, and then transition to a non-Rails stack as required. True as far as it goes. But if we're just talking about a prototype for validating product/market fit, with the intent to transition to a more maintainable stack as and when that becomes necessary, what's the problem with "list of 30 random npm packages" as a starting point?

smw 8y ago
> what's the problem with "list of 30 random npm packages" as a starting point? The dude starting with rails will probably be done with the MVP before you decide _which_ 30 random npm packages to use.
- lmm 8y ago
  I'd probably just copy/paste from my current project TBH, which takes all of 5 seconds.
wastedhours 8y ago
Rails can take you much further than MVP though, as evidenced by all of the companies that reach breaking point with it. Basecamp, Github, Shopify - all reached proper business status on Rails (arguably Twitter too, although business is a bit of a stretch...). We can argue it from both ends, but I see Rails as the middle ground, and allows you to go from MVP to $XXm ARR on the same stack. A hacky MVP with 30 npm packages doesn't have a clear path up the tree to grow without serious changes, and a custom architecture is useless if you don't get any users.
- lmm 8y ago
  > A hacky MVP with 30 npm packages doesn't have a clear path up the tree to grow without serious changes I see it as the opposite: it's clear which functions are the responsibility of which library, and it's easy to replace the ones that are becoming blockers and leave the ones that aren't. Whereas with Rails if you keep it monolithic then upgrades always become a huge pain point, but if you try to cut out pieces of it you're going against the grain. (I used to love TurboGears nearly a decade ago, because you could use it like a monolithic framework to start with but it was explicitly a collection of standalone libraries underneath, and so once you started needing to do different things to individual pieces it was easy to. The modern web ecosystem could do with something like that, IMO (though personally I'm sticking to ScalaJS for the type safety))