[flebron]

You may be speaking of a particular implementation or engine. JS, the language, has no such concept of a "thread". The standard describes execution of a valid program as linear. Libraries may add functions such as event listeners or threading or sockets, but these are not part of the language.

And yes, to be pedantic, by JS I'm refering to ECMAScript, or ECMA-262. If by JS you mean JavaScript the implementation by Mozilla, then Node doesn't use that anyway :p

[joshuacc]

Well, there are Web Workers, which are basically threads. http://www.html5rocks.com/en/tutorials/workers/basics/

But it appears that it's part of the WHATWG HTML spec rather than ECMAScript, which is a bit weird.

[jerf]

Web Workers are closer to "processes" in the Erlang sense of the term. They're walled off fairly extensively from the rest of the JS runtime that spawned them because that is pretty much the only good way to backport threading onto a language that wasn't designed with it in mind from the beginning.

Languages like C which had them bodged on years later, well, I'd call that a bad way to do it. It worked for the time but there's a reason why we are all fleeing that implementation of threading and it still stains the entire idea of "multithreading" decades later.

If JS is ever going to get threading, the best case scenario is for it to look like Perl or PHP's efforts... years and years of implementation work to get to something that pretty much everybody recommends you still just stay away from. And Perl and PHP were trying to integrate threading into just one runtime each, and without a browser connected at the hip with its own ideas about threading embedded into decades of code. I would not hold your breath for "true" JS threads anytime soon.

[pfraze]

That's because it's a Web platform API, not a language feature.

[pan69]

Timers are sort of threads..

[pan69]

Let me know if you disagree... Don't just hide behind a down vote...