這是後續問題Is there a point to multithreading？如果它是多線程的話，JavaScript會更好嗎
如果JavaScript是多線程的，它會比現有的系統更好嗎？在不同線程（後臺）中使用一個UI線程和其他任務進行多線程會帶來更高的響應能力和高效的資源使用情況嗎？
爲什麼該語言的設計者決定將粘貼到單線程模型上，儘管在CPU /機器中沒有進步，並且需要同時從不同機制中提取不同的內容和數據。爲什麼當多線程可以提供更高的準確性時，它們仍然可以用JavaScript timers work？
我不是要拖住JavaScript作爲低效率的，而學習多線程如何帶來價值相比，複雜性，引入了編程
Brendan Eich（Mozilla的首席技術官）談到了在「Threads suck」中創建的複雜性。
他的結論是： 「所以我的默認答案的問題，如一個我在去年五月的Ajax體驗了，‘你們什麼時候會添加線程JavaScript的’是‘？！在你的屍體’
Using web workers是替代方案。
如果JavaScript的是多線程的， 將其票價比現有 更好系統？
當你說「現有系統」時，你指的是什麼？您的瀏覽器中嵌入了現有的Javascript嗎？還是獨立的Javascript實現？
我不是要拖住的JavaScript 效率低下
本身語言是沒有效率或低效率的，它的實現是。 :-)
會和一個UI線程 和其他任務在不同的線程 （背景）帶來更大的 響應能力和 資源的有效使用多線程？
犀牛，在Java中的Javascript上JVM可以訪問和使用線程和其他Java庫，所以是的，你可以編寫腳本了在Javascript整個Swing應用程序和它的工作就像在Java中任何其他Swing應用程序進行那裏。
總而言之，與其引入的複雜性相比，多線程如何帶來價值的問題並非特定於任何語言本身。那裏有一些語言提供了一個很好的運行時提供的多線程功能的包裝，所以不要。考慮到我們擁有多核處理器，爲我們日常使用的臺式機提供支持，多線程技術很難但更重要。 :-)
即使現在使用WebWorkers，多線程對JavaScript也沒有什麼影響，我們對大多數JS應用程序並不需要太多。直到現在，JS正在移動服務器端，並且編寫了更大的應用程序，WebWorkers才變得有用，而webworkers在多線程的情況下越來越好，越來越容易。
除了網絡工作者，JS，特別是服務器端JS也傾向於異步處理，進一步緩解了對線性處理的需求。
在過去甚至到今天，用JS編寫的大多數客戶端應用程序根本不需要多線程，因爲JS引擎也越來越好，而且HTML/CSS渲染也被硬件加速所推動。
還有另一件好事，用JS（服務器到客戶端），我們可以很容易地將大量處理移動到客戶端，基本上實現了龐大的計算機網絡來執行所有計算，而無需客戶端安裝花哨程序只是瀏覽器）。