I think the point wasn't that "asynchronous is hard", it's that "asynchronous is just incidental complexity". CRUD apps don't need to be asynchronous, and node.js has a relatively impoverished ecosystem for such apps.
There are undoubtedly tradeoffs no matter what you use, but this seems like an eminently practical decision.
I'm not so sure about that (the async-is-hard part.) If one is making a decision of architecture change due in part to CRUD capacities within a framework, I'd guess the asynchronous programming model in Node.js is a little more than just incidental complexity.
CRUD operations within R/R might be just a few lines of code, but it's not that much more to accomplish the same with Node, Express/Railway, and any one of a bunch of template schemes.
The change certainly sounds appropriate for the team, but the basis of CRUD as a reason to change an entire architecture leads me to question how the team approached their solution with Node.
Unless you're taking the sunk cost of the node.js development into account, I don't understand your point.
If the core programming model for node.js doesn't help them in any way, and the ecosystem is less mature, then it kind of misses the point to say that everything is doable in node.js. Whether something can be accomplished is not a good metric for whether a platform is productive.
> If the core programming model for node.js doesn't help them in any way, and the ecosystem is less mature, then it kind of misses the point to say that everything is doable in node.js. Whether something can be accomplished is not a good metric for whether a platform is productive.
Hmmm, don't recall saying everything is doable in Node.js. I was speaking of CRUD operations.
I've had experience with many teams who have made similar architectural decisions based on broad, abstract data points, i.e. programming model, ecosystem maturity, etc. Frankly, making these types of decisions on those over-arching points rarely leads to good decision making. Most often, problems of one type are simply exchanged for problems of another, and it's usually caused by lack of real evaluation of system/architecture needs.
I'm not arguing this team shouldn't make this switch, just that the stated reasons don't pass the sniff test. I think the team prefers to programmatic model of R/R to Node, and feel they would be more successful going forward. But I would be hard-pressed to believe this transition is being made for most any reason beyond comfort and familiarity, as opposed to significant system limitation.
There are undoubtedly tradeoffs no matter what you use, but this seems like an eminently practical decision.