Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: