Dude, stop splitting hairs here. For all means and purposes in real life, concurrency and parallelism are synonyms. Ask 100 programmers what the difference is and 99 of them will tell you they are identical. And JS is definitly not parallel. JS even managed to deceive people into thinking that it is multi-threaded because they deliberately use the term "asynchronous" everywhere. I call that false advertising.
They might be synonyms for some people but it's important to understand the fundamental differences. There's no false advertising here, if people misunderstand the terminology it's not a JS fault. JS is not parallel, that's absolutely true. It's concurrent. Concurrency is a design decision, it doesn't have anything to do with multitasking, parallel execution, threads etc. It's just small blocking callbacks on steroids if you wish. Everything is put into a callback and a supervising scheduler (a part of the same program, not the OS) chooses which one to execute.
If some people want to believe in something that's not there, it's a sect, cargo cult, religion, you name it. I'd like to dig deeper and know the underlying truth instead of marketing bs or things pretending to be what they're not.
Further reading, if you're interested: actor model, greenlets, coroutines (boost::asio or goroutines are good examples). There are different approaches to concurrency while parallelism isn't that diverse — it's just code that runs on different threads and managed by the OS. The context switching is also quite expensive, that's why concurrency is this popular, you can achieve almost-multitasking for almost no cost.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.