如果 JavaScript 是多线程的，它会表现得更好吗？
这是多线程有意义的后续问题吗？
如果 JavaScript 是多线程的，它会比现有系统更好吗？具有一个 UI 线程和不同线程（后台）中的其他任务的多线程会带来更高的响应能力和资源的有效利用吗？
为什么该语言的设计者决定坚持使用单线程模型，尽管 CPU/机器数量有所进步并且需要从不同的机制同时提取不同的内容和数据。当多线程可以提供时，为什么他们仍然接受 JavaScript 计时器的工作方式准确度更高？
我并不是想将 JavaScript 定性为低效，而是了解多线程如何与其给编程带来的复杂性相比带来价值
This is a follow up question to Is there a point to multithreading?
If JavaScript were multithreaded, would it fare better than the existing system? Would multithreading with one UI thread and other tasks in different threads (background) bring in greater responsiveness and efficient usage of resources?
Why did the designers of the language decide to stick on to the single threaded model despite the advancements in no of CPUs/machine and the need to simultaneously pull different content and data from different mechanisms. Why are they still ok with the way JavaScript timers work when multithreading can offer far greater accuracy?
I am not trying to pin down JavaScript as inefficient, rather learn how multithreading brings in value in comparison to complexity it introduces to programming
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
Brendan Eich（Mozilla 首席技术官）在“线程很糟糕”。
他的结论是：
“因此，对于诸如去年 5 月的 Ajax 体验中遇到的问题“您何时向 JavaScript 添加线程？”等问题，我的默认答案是：“在您的尸体上！”
使用 Web Workers 是另一种选择。
Brendan Eich (Mozilla's chief technical officer) talked about the complexity this would create in "Threads suck".
His conclusion:
"So my default answer to questions such as the one I got at last May's Ajax Experience, "When will you add threads to JavaScript?" is: "over your dead body!"
Using web workers is the alternative.
当你说“现有系统”时，你到底指的是什么？您的浏览器中嵌入了现有的 Javascript？或者独立的 Javascript 实现？
一种语言本身并不高效或低效，而是它的实现。 :-)
Rhino，Java 中 JVM 上的 Javascript 可以访问和使用线程和任何其他 Java 库，因此，是的，您可以使用 Javascript 编写整个 Swing 应用程序的脚本，并且它会像 Java 中的任何其他 Swing 应用程序一样工作。
无论如何，与它引入的复杂性相比，多线程如何带来价值的问题并不特定于任何语言本身。有一些语言为运行时提供的多线程功能提供了一个非常好的包装器，所以不要这样做。多线程很困难，但如今更加重要，因为我们有多核处理器为我们日常使用的台式机提供动力。 :-)
What are you exactly referring to when you say "the existing system"? The exiting Javascript embedded in your browser? Or standalone Javascript implementations?
A language by itself isn't efficient or inefficient, it's implementation is. :-)
Rhino, the Javascript on JVM in Java can access and use threads and any other Java library, so yes, you can script up an entire Swing application in Javascript and it would work like any other Swing application in Java out there.
Anyways, the question of how multithreading brings value in comparison to the complexity it introduces is not specific to any language as such. There are some languages out there which provide a pretty good wrapper around the multithreading capabilities offered by the runtime, so don't. Multithreading is difficult but more so important these days given that we have multicore processors powering our everyday use desktop machines. :-)
多线程不会对 JavaScript 产生任何影响，即使现在有了 WebWorkers，对于大多数 JS 应用程序来说，我们也不太需要它。直到现在 JS 正在向服务器端移动，并且编写了更大的应用程序，WebWorkers 才变得有用，并且 WebWorkers 比多线程更好、更容易。
除了webworkers之外，JS，尤其是服务器端JS也倾向于异步处理，进一步减轻了线性处理的需要。
在过去乃至今天，大多数用 JS 编写的客户端应用程序根本不需要多线程，因为 JS 引擎也变得越来越好、越来越快，HTML/CSS 渲染也通过硬件加速得到增强。
还有另一件好事，使用 JS（服务器到客户端），我们可以轻松地将大量处理转移到客户端，基本上获得一个巨大的计算机网络来完成所有计算，而无需客户端安装花哨的程序（只需浏览器） 。
Multithreading would not have made a difference to JavaScript, even now with WebWorkers, we don't need it much for most JS applications. Only now that JS is moving server side and bigger applications are written that are WebWorkers becomming useful and webworkers is infinatly better and easier then multithreading.
Next to webworkers, JS, server side JS in particular is also leaning towards asynchronous processing, further alleviating the need for linear processing.
In the past and even to this day, a majority of client side applications written in JS simply do not need multithreading as JS engines are also getting better and faster with HTML/CSS rendering being boosted by hardware acceleration as well.
And there's another nice thing, with JS (server to client) we can easily move a lot of processing to the client side, basically attaining a huge network of computers to do all the computing without clients needing to install fancy programs (just the browser).