Comment by jroseattle | Hacker News Reader

Comment by jroseattle | Hacker News Reader

Parent Full thread

I read this post as "your mileage may vary", gravitating toward "it doesn't work like we expected". One particular line caught my eye:

"NodeJS’ async everything wont have any affect on a CRUD app. Popular frameworks, provide very good caching and everything that is needed for your app to work fine even synchronously."

There is a lot to this statement that implies how an application is architected. Node.js is async at heart, and one can only build a successful application if you follow the programmatic model as it's designed. It doesn't matter how simple or complex an application may be, if a framework is being bent to work in ways in which it wasn't designed, the application may not work so well.

Reading between the lines, what I'm getting is a picture of a team that has encountered productivity issues with the current stack and is migrating to a more familiar stack to increase productivity. Nothing wrong with that tradeoff, but I always look to what future tradeoffs are being made: "cache everything and gets the work done ASAP" is great until you need finely-grained control of your queries.

I'm sure they thought well about their decision, but if asked to make a wager -- I'd guess that certain problems are being traded from one framework to another.

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.

Reply on news.ycombinator.com