No, and that's the point of the article. What you are calling parallel w/r/t IO should be called concurrency (conceptually happening at the same time by virtue of being able to interrupt and resume units of work). The reason IO APIs like you've described is concurrent but not necessqrily parallel is because there is no guarantee in the API that they both happen literally simultaneously; I could build a JS runtime that "works" for all the code written against XMLHTTPRequest (ignoring side-effects) but which under the hood only ever makes one HTTP request at a time. And because I can do that, that means JS code is living in a concurrency-only world, even though as an implementation detail most runtimes support parallel execution of those concurrent operations.