4 ms·
Shouldn't we be more focused on which is easier to use though? Even if promises are slower, they probably aren't going to be a major performance issue, so I thi
by GhostVII 9y ago
Shouldn't we be more focused on which is easier to use though? Even if promises are slower, they probably aren't going to be a major performance issue, so I think if you find promises easier to use and less bug-prone, they are better regardless of preformance.
- sparrish 9y agoI don't think we should. I chose node over ruby because of performance. Those numbers are showing significant overhead for promises and async/await. That's a problem I don't want to inject into my latency-sensitive application.
- untog 9y ago> Shouldn't we be more focused on which is easier to use though? In JS I think this depends a lot on whether you are writing client-side code or not. Prioritizing developer ease of use over end-user performance is a very bad habit to get into. But it matters less when writing code that'll run in Node. (that said, I'm not at all convinced that the performance difference mentioned in this article matters a whole lot. It's not actually that significant.)
- GhostVII 9y ago> Prioritizing developer ease of use over end-user performance is a very bad habit to get into Why is that? Whenever you use a high level language, you are making development easier at the cost of end-user performance. Or using a foreach loop instead of a regular for loop, is usually a bit slower, but makes development easier and less bug prone. Premature optimisation is the root of all evil and all that. Obviously at some point you have to prioritise end-user performance, when making decisions that will have a big impact on performance, but when making decisions on the level of promises vs callbacks, I don't think end-user performance should be a priority.