Earlier quoted context omitted.
Why do you think an all-in-one framework is an advantage? As soon as you want to switch something out you end up fighting the framework and the tutorials. Better to start with dedicated libraries that each do one thing - it's inevitably where you're going to end up. (Not that I'd consider an untyped ecosystem in the first place, especially one as fond of "magic" (e.g. monkeypatching) as rails. I have sympathy for jus…
> 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…
> 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?