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.
There is also WebCL, an effort underway to put OpenCL in the browser, and River Trail, an experiment to execute subset of JavaScript using OpenCL as a backend. I don't know how difficult it is to write a CPU compute device driver, so I don't know if WebCL will become a viable general stategy for multicore execution in a browser though.
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.
Javascript supports web workers which are effectively threads with the exception they don't share the application memory, but communicate over postMessage().
This makes possible share the calculations across the cores, but since postMessage() serializes each transferred object the effectiveness of this might not be that good.
