"generally" => most cases so you can read it out as "in most cases, performance should never", which means performance should only be a deciding factor in specific situations where the operation is costly in some way, is used frequently, etc.
For example, the palindrome code from the post doesn't have to be optimized for performance but say you were batching a bunch of expensive asynchronous tasks, you could use Promise.all and generators together to do so. The question you should ask before working on this optimization is whether or not maintaining that extra complexity is going to bring any net benefit. For the palindrome example, there's little to no net benefit so going with an idiomatic approach is fine, even if it's slower.
I don't understand why you think that a library author is in no position to determine whether or not a performance compromise is problematic. Making decisions like that is literally the job of a developer. True, consumer's are in no position to resolve such problems, and that's exactly why building healthy communities is important, so consumers come back to you and tell you that something isn't doing the job well (when it comes to libraries, for product consumers, you can use analytics, performance metrics, etc.)
Yes, Empathy should be every developer's guiding principle, and unnecessary performance optimizations have nothing to do with being empathetic. I'm not saying optimizations are unnecessary but optimizing unnecessarily, is unnecessary.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The combination of generally and never seems confused... and the sentiment is troubling...
Especially when developing software libraries,
Empathy should be out guiding principle, both for those inheriting and maintaining the code we write and for those consuming it.
"generally" => most cases so you can read it out as "in most cases, performance should never", which means performance should only be a deciding factor in specific situations where the operation is costly in some way, is used frequently, etc.
For example, the palindrome code from the post doesn't have to be optimized for performance but say you were batching a bunch of expensive asynchronous tasks, you could use Promise.all and generators together to do so. The question you should ask before working on this optimization is whether or not maintaining that extra complexity is going to bring any net benefit. For the palindrome example, there's little to no net benefit so going with an idiomatic approach is fine, even if it's slower.
I don't understand why you think that a library author is in no position to determine whether or not a performance compromise is problematic. Making decisions like that is literally the job of a developer. True, consumer's are in no position to resolve such problems, and that's exactly why building healthy communities is important, so consumers come back to you and tell you that something isn't doing the job well (when it comes to libraries, for product consumers, you can use analytics, performance metrics, etc.)
Yes, Empathy should be every developer's guiding principle, and unnecessary performance optimizations have nothing to do with being empathetic. I'm not saying optimizations are unnecessary but optimizing unnecessarily, is unnecessary.