Until "web workers" are generally supported by common browsers, there is no way to run more than on bit of Javascript at a time in any given tab. As all the code is running in a single thread it will only use one CPU core (or if the scheduler bounces the browser process between cores it will use at most one core/second worth of CPU resource per second).

Depending on the how much cross talk there would be between the threads, web workers might not be adequate for some algorithms anyway as the message passing (the only way web workers can communicate, there is no "shared memory" access or other such short cuts to communication) could add noticeable latency. Caveat: I've not used them for anything myself so I don't know if any such latency is large enough to be an issue.

You can create multi-threaded code using web workers, but you exclude your app from browsers that don't support them. The major laggard on the desktop is IE, which is due to gain support for them in version 10. As far as I know the only current mobile browser that supports them is Safari under iOS5, apparently they were present in Android's browser but removed/disabled in recent releases.

JS doesn't really support threads so that's probably a big part of it.

Traditionally JS applications have never been very "heavy" so it's never been a problem as you could just use the other cores to run JS for other browser tabs etc.

Of course now both cores and JS usage are increasing so this will have to change.