当存在同步FileSystem支持时，为什么Web Workers中没有同步WebSocket支持？

Question

我理解为什么浏览器供应商不想帮我阻止他们的UI线程。但是，我不明白为什么会这样：

1. 在Web Workers中没有睡觉（2）
2. 没有同步WebSockets API

有一个synchronous FileSystem API。还有一个synchronous IndexedDB API。对我来说，这似乎是一个矛盾。

Answer 1

WebWorkers没有sleep()功能的原因很简单：您不需要它。 sleep是一个同步函数（它会一直阻塞，直到它返回），这在WebWorkers的异步上下文中是没有意义的。

如果向WebWorker发送消息，则不会阻止等待响应;响应作为消息发送到消息处理程序函数。如果您想在发送回复之前等待一段时间，则不会使用sleep，而是在调用函数时使用setTimeout并关闭消息。

同样，如果您使用WebWorkers进行WebSocket数据传输，您将收到来自主线程的消息，通过websocket异步发送数据包，然后在响应处理程序中将消息发送回主线程。使用同步sleep函数没有合理的位置。

至于为什么没有像文件系统那样的WebSockets同步模式，主要区别在于不能通过网络访问文件系统。 通常，异步API更适合基于网络的功能，所以我想我不认为这是一个矛盾。

IDB是only supported by 3 browsers, none of which have implemented the synchronous API，所以我不认为这是同步API的光辉榜样。事实上，我认为这是人们定义API的矛盾，而不是为实现它而烦恼。

Answer 2

根本不明显：TCP协议也是一种网络协议，对吧？它经常用于同步模式，因为它使应用程序的开发和调试更加简单。

在我看来，当您不希望I / O阻止UI时，异步模式在单线程应用程序的上下文中是显而易见的。如果您打算使用Web worker来处理后台I / O，那么它就不那么容易了。将同步Websocket与Web worker结合使用确实很方便。

最后，假设文件读取调用将很快完成并不是很苛刻。如果IO没有响应，您应该总是超时或接受应用程序将挂起的事实。

Answer 3

对我来说这很明显。

FileSystem API＆amp; IndexedDB API的工作时间为毫秒，因此您可以立即信任您的数据，而不是 WebSockets API必须至少慢100倍，数据必须飞越野外互联网，因此，使它异步是显而易见的。您的回复甚至可以永远回复。

Answer 4

索引数据库不会阻止执行更长时间，很可能它会产生几毫秒的结果，我们不希望在索引数据库中存储数百万条记录。与文件API相同，大多数API将导致更快的执行。

同步API也会导致竞争条件，并且需要多线程同步等，这将增加编程复杂性。相反，基于消息的线程更容易编程，我们没有同步问题。

大多数javascript引擎也很稳定，人们熟悉异步编程方式。写作工人更简单，也更方便。改变这将需要大量重写javascript引擎。引入更多本机API将使工作者编程更加复杂。不同的操作系统和不同的架构或设备wiki介绍更复杂。

Answer 5

从V8 has implemented ES2017 await/async开始，我可以在启用了Promise的库中使用它，而且我不再需要同步API了。