This is a big question and hard to answer IMHO without more context and constraint. I'll take a stab at laying out some thoughts on the matter. So many apps ca

This is a big question and hard to answer IMHO without more context and constraint. I'll take a stab at laying out some thoughts on the matter. So many apps can fit into the CRUD tent. I mean, Jira and Confluence are basically CRUD apps, right? But so is an ad-hoc internal company app. I'll focus more on apps that are meant to be externally facing as I typically work on larger efforts, and then mostly on backend services and infrastructure automation. I would personally stay away from Python. Not only do I prefer typed languages, but I also appreciate languages with fantastic tooling and language services, mature concurrency primitives, and an active/energetic community. I find Python seriously lacking in those regards, and falling further behind other language choices every year. I personally have no issues with writing prototype/production ready code in less dynamic languages at the same speed; faster usually is my sense for anything more than a few dozen lines. If elixir had focused more on a type system and better language services/tooling(like the F# team) I'd probably be more interested in Phoenix. Ignoring the erlang VM, I find F# much more compelling as a language and am hoping one of the new crop of frameworks will shape into a viable Phoenix alternative. That being said, I could still see myself pushing Phoenix depending on the experience and leanings of the rest of the team. In no particular order: TypeScript+React+ASP.NET: I really like C#; it's not for everyone, but coupled with the CLR it has completely acceptable performance, concurrency primitives, and language services(intellisense, refactor support, etc). Entity framework and linq are a super compelling combo; using this ORM will ruin most other ORMs for many people. Dotnet core has resulted in a lot of extra activity in the OSS community, and the dot.net ecosystem is full of very well engineered, comprehensive projects. F#+React+ASP.NET: For some extra spice try F# full-stack. There are some great backend frameworks shaping up, and Fable makes F# possible for the client. Great language and great concurrency support. F# is my crush language. Fable's creator has been doing excellent work including making it possible to consume TypeScript type definitions; going so far as to reach out to the F# team to include features necessary to support the flexibility of TS. Ability to execute on this would really depend on the starting team as well as current/future hiring practices. TypeScript+React+Node.js(TypeScript): This is one of my favorite "easy-ish-to-sell" stacks. Nodejs has come a long ways, and offers a sufficient concurrency experience with async/await. Node-Chakra-Core has some clutch time-travel debugging abilities.. Javascript programmers at least keeping up with ES6 shouldn't have TOO much trouble adjusting to TS, and as a bonus they can be more effective working full-stack on the backend. This should provide for a very large potentially hiring pool. There are some super compelling TypeScript-first projects cropping up as well like MobX, NestJS, TypeORM, etc. My sense is that TypeScript is attracting more of the "engineery" types to the JS/Node ecosystem. If C# is any indication, this is a welcome addition IMHO. Dart: Dart appears on the surface to be a more first class TypeScript. It looks super compelling, has some great tooling(including a sweet looking profiler), has a great looking VM for server side execution, and a small but very passionate and motivated community.. A few highly visible companies adopted it and swear by it. This is probably the most experimental stack I would consider and can't really explain it... I'm dart-curious. I feel they should ditch the custom eclipse based IDE and focus on the language server protocol and plugins for the popular IDEs with the 2.0 initiative. TypeScript+React+Golang: Sure, why not? I think I'd need a good reason for going golang... Like some serious server-side performance requirements and/or lots of backend services. In the context of a "CRUD" app, I'd be more likely to swap services written in other languages out with golang as the performance requirements became clear. Mini-rant: React is pretty great but I wouldn't mind a TypeScript-first implementation to it's interfaces. DefinitelyTyped group has done an excellent job but keeping everything typed can be a bit gnarly and gross. I'm a huge proponent of MobX over redux until you know you need redux. I haven't personally missed redux since extricated myself from it, however I can imagine circumstances where I'd "see the light" and want it. Take the redux creators advice; you probably don't need it.