>Along came NodeJS and proved to us lost java souls, that with non-blocking I/O, you don't need hundreds of threads to make performant code. In fact, one thread

>Along came NodeJS and proved to us lost java souls, that with non-blocking I/O, you don't need hundreds of threads to make performant code. In fact, one thread is enough, also for driving complex UI. The asynchronous single-thread event loop of Nodejs is helpful for offloading IO-bound tasks but doesn't solve cpu-bound workloads. Therefore, if a programmer wants to develop heavy cpu computations in parallel (rendering, transcoding, image/speech analysis, etc), the "absence of threads" in Nodejs is not relevant to solving those problems. There are many workloads that perform better in a shared-memory multi-thread execution model rather than shared-nothing multi-process (web workers) model. However, that dichotomy doesn't necessarily justify adding shared-memory threads to Javascipt -- it just changes the wording of the question to a higher-level question: Should the Javascript language+runtime evolve to solve heavy cpu-bound workloads? Apparently, enough of the Javscript community said "yes" such that it's been added to ES2017.