> With Rails, you end up in the weeds in the long run, but the alternatives put you in the weeds right off the bat (with the promise of eventual salvation). The

> With Rails, you end up in the weeds in the long run, but the alternatives put you in the weeds right off the bat (with the promise of eventual salvation). The reality of most product development (ymmv) is that the former is highly preferable to the latter. As one of our product managers put it: Often, you want something you can sell well fast enough to buy time to make it good. Overall, in this tool/framework/language debate, I'm growing more and more convinced two things matter the most: - Pick something the weakest 40% of your team are comfortable using. Especially with support, I'd trust myself to figure out enough of Elixir/React/Whatever to be decently productive within a week or two on the go. But that's the thing - that's why I advocate to pick something the weaker team members are fine with. They will struggle, not the stronger team members. - Smash problems with standard solutions. Don't be smart. Pick the right tools, throw hardware at them. A decent combination of load balancing, language+ORM, an SQL persistence layer and possibly a message queue can handle _a lot_ of traffic. And it's easy to hire for and to get new people on board because there are no smart things going on. Note that the language and web framework are not part of this consideration at all. My approach would prefer more established frameworks like rails or something in java though.