等 Electron 更新就好了

很正常 在多学几门语言就习惯了
比如 Python / JS / Go
然后你大脑就会慢慢习惯这种不停的切换

专门给 Windows 用的那个需要破解（便宜的）
另外一种通用的不用破解

@huijiewei HyperKit 基于原生的 Hypervisor 框架 但是还是虚拟机 稍微轻量一些 但是本质没有改变 所以 @CEBBCAT 说的仍然没有错 只是 Docker for Mac 帮你做好了这些
虚拟机占多少资源 在本地宿主机只会占用更多 而且性能也有不小的损耗
@Achilless 内存和磁盘空间不会比开了动态分配的其他虚拟机少多少 除非你同时开了很多 VM
但是优点是启动速度快和使用灵活 缺点是对 GUI 支持的不好 以及网络设置要更加的复杂

@Vhc 是正式版 但是不是基于 Chromium 内核的新 Edge
老 Edge 是微软自研发的内核 虽然 UI 里面有 WebKit Chrome 和 Safari 但是仅仅是为了兼容性 就像 IE 里面还有 Mozilla

目前新版 Edge 正式版官方还没有正式发布 更没有开始推送 所以你要自己下载安装
这个安装包应该是属于稳定版 偷跑已经好一会儿了
但是应该还没有正式发布 不过功能上应该是一样的 可能将来正式发布的时候小版本号会更新一点

@siknet 看你楼下 你 2 米的 USB-C 线估计是 USB 2.0 充电线吧 长到 3-5 米应该都还可以用
最多是 3.0/3.1 Gen1 5G 的线 一般最多也就 2-3 米
3.1 Gen2 10G 的线一般也不超过 1 米
TB3 的线 20G 无源貌似就半米多的样子 有源带放大器可以再长但是一般就是 10G 的了

@azh7138m 超长 TB 线都是不带电源的 转光纤的 理论上可以做到非常长
当初 Thunderbolt 还是研发原型的时候就叫 Light Peak 本来设计打算直接用光纤的 但是不带电真的很有局限性 加上实用性和兼容性问题 就用 Mini DP 的接口了

我记得没错的话 USB-C 线 不管是 Gen2 还是 TB3 都没办法做太长超过 1 米的

@shaoyaoju 这么麻烦 要等待用 for of + await 就是了 非要用 forEach/map 或者 reduce 干嘛
并行用 Promise.all + array.map 就是

@ChristopherWu “RESP (REdis Serialization Protocol) ”这样写不算是 typo 啦
只是说明一下 RESP 是 “RE”dis “S”erialization “P”rotocol 的缩写
取自 Redis 里面的 RE 加上 Serialization 的 S 和 Protocol 的 P
因为 Redis 里面取了两个字母 所以大写了一下

@maomaomao001 Chrome App 不是已经有了吗 虽然没有移动端支持 但是桌面系统都支持了啊
也可以访问本地文件 可以授权访问任何网址
即有应用商店 也可以手动载入自己写的

主要问题还是安全性
发布的 app 经过审查 加上签名校验 安全性还可以有点保障

否则就算你给用户来选择 不是所有用户都知道这些

更重要的是要防止被黑客利用 通过复杂的手段钻漏洞 彻底攻破系统的安全性

@maomaomao001 首先 PWA，web assembly 以及 文件和网络权限 其实没有什么关联
不同的技术和 API 罢了

PWA 就是可以离线运行和安装的网页版小程序 目的是用户体验看起来像本地程序 同时又不需要应用商店来分发
Web Assembly 是除了 JS 以外一个全新的基于二进制的运行时 一方面运行效率高 同时可以把各种现有的程序直接移植到 Web 平台 又可以支持任何可以编译到 WASM 的语言
文件和网络权限或者 API 这个是浏览器提供的功能罢了
这几个其实没什么相互的联系
至于 WebApp 的开放生态 也就 Google 有兴趣 其他厂商巴不得让所有 App 都建在自己的封闭围墙里面（其实就算是开放的 Web 其实也可以算是 Google 的围墙）每个厂商都有自己的如意算盘 要想让系统或者各大浏览器统一来支持是很困难的事情

“为什么缺迟迟不开放网络能力和文件能力”
之所以不给 WebApp 文件和网络权限 是因为安全问题 就算你可以加上权限管理和沙盒 但是总有办法绕过的
你没办法给一个随便可以打开运行的网页随便访问文件系统 以及随便链接其他网络 这样黑客得笑死
本地 App 还好控制一点 可以用签名来做一些保护 另外现在还到搞封闭花园和沙盒什么的

“微软他们为什么不考虑这么搞”
你说的小工具一个 html 就可以了 其实微软早在 IE5/Win98 的时代就有了
就是 HTA 可以用 html/css 写 UI 用 js+vba 访问几乎所有本地系统 API 文件读写访问网络什么都可以
结果并没有什么正经的软件在用 倒是各路病毒木马用的很欢

“谷歌为什么不考虑这么搞”
Google 一直在尝试做安全又实用的文件系统和文件访问 API 给浏览器
最早有 FileReader API 现在也可以用
同时还有 FileSystem API 沙盒的文件系统 但是被标准否决了 同时也很难用 局限性太大
最近又出了了新的 Native File System API 我觉得这个应该就是你想要的吧
但是要推成标准 让 Firefox 和 Safari 支持可就难了
最近 Firefox 疯狂注重安全和隐私 自然不想要这种高风险的 API 而 Safari 东家 Apple 希望 App 强大 并不希望 WebApp 可以强大到取代 Apps

“感觉现在开发跨平台桌面应用太费劲了”
对于跨平台的 UI 你想要保证兼容性问题 你就得自带浏览器引擎 否则就算是相同的浏览器或者相同 web 核心 不同版本也可以弄的你够呛 所以 Electron 这种虽然好几百 MB 但还算不错的选择 只不过应该还可以通过组件化来优化一下体积 不用的功能应该可以丢掉（貌似可以精简到 80-100MB 左右）
如果非常在乎体积 兼容性要求低一些 其实各大系统都有系统自带 web 核心来用 做出来的 app 都可以非常的小 效果也还过得去

用 import 来导入组件 然后用 webpack 之类的打包在一起

@love Web Component 可以基于 JS 来做啊 然后用 css in js 那样把 template 和 css 包进来
好处是组件化标签 组件内部不透明 不会收到外部的干扰

@iwtbauh 我说的底层主要是说操作系统的底层 网络方面应该说是相对于 HTTP 应用层而言是相对底层的
另外我说的网络设备不一定是“中间网际路由器”或者那些工作在 L2/3/4 的设备 现在已经很多网络设备是工作在 L7 的了 所以 payload 不一定是透明的
正是因为目前这些设备已经会去感知 TCP 甚至 HTTP 所以很难去推动他们 他们会去感知 QUIC 那也是之后的事情 那么在这个还没有被感知的阶段里面 Google 就获得了足够的自由去修改
我同意你说这个是“政治问题” 至少对 Google 而言是的 但是同时也是“技术问题” 如果一个技术发展的足够成熟稳定 想要继续突破和改进就只能另辟蹊径

对于性能 我是真去听过 Google 的专门的 QUIC 讲座的（虽然我没有能力亲自去验证 毕竟我不是做网络或者 OS 的）
至少我也是学过操作系统的 另外也了解了一些网络应用在操作系统实现的一些基本概念
之所以说性能更好 是因为减少了系统调用导致的在内核空间和用户空间频繁切换的问题
如果所有功能全部有系统核心来处理当然会比全部由应用层处理快
但是现实是由于 TCP 很多功能是由核心处理的 但是 HTTP 也有很多功能是有应用层实现的
反倒导致处理 HTTP 的时候 需要频繁的做切换 导致了一些性能的瓶颈（所以有了 User-Space TCP Stack 这样的方案 和 QUIC 的想法就很类似）
而 UDP 在这方面就简单很多 系统核心基本上就只管收发 减少了切换的损耗 也获得了更大的改进空间 减少了对系统更新的依赖

@sujin190 没写完不小心发出去了
说 HTTP2/SPDY 是对 HTTP/HTTPS 网络应用层的修改 基本上面目全非
那么 HTTP3/QUIC 是对 TCP + TLS 这层的修改 那么就相当于直接推到从来了
但是 Google 没办法直接大规模改进和 TCP 和 TLS 并且快速推广 你看看要弄个 BBR 有多麻烦就知道
更不要说更底层的东西 比如这个丢包重传的机制等等 基本上不可能从根本上改变
于是 Google 就直接基于 UDP 重新实现一遍类似 TCP 的功能

协议变得复杂 这个在所难免 关键在于是否值得
对于终端用户而言 他们只需要把浏览器或者客户端更新就好
对于服务的提供商而言 可以增强用户体验 以及有可能节省一些网络开销
而且这些都是公开的标准 而且也有开源的实现
只有在中间的网络提供商没有从中获益 相反可能有不利 这个也是推广最大的风险所在

另外 HTTP 1.1/2/3 之间不一定是一个互相取代的关系 就像现在 USB 2.0 / 3.0 / 3.1 / 3.2 / 4 标准一样 要支持高版本 不一定要抛弃对低版本的支持 高版本功能和性能更好但是更复杂 对于键盘鼠标等低速设备 2.0 足够了 那么对于某些场景 HTTP 1.1 就足够了 但是要求高的场景自然需要更好的版本
那么 HTTP 用 TCP 还是 UDP 其实也应该只是一个选择 上层的应用接口可以是一样的 一般情况下除非有不可修复的安全因素或者实在太过时 不太可能直接淘汰掉现有版本

回到丢包的问题 Google 也和你一样 基于网络条件越来越好的前提下 觉得重传应用层去做就可以了 没必要 TCP 那样那么底层来保证 TCP 的有序分包传输和重传阻碍 对于多路复用是个不小的障碍

但是对于 Google 和网络开发者而言 HTTP3 用 UDP 一个巨大的优势就是 很多 TCP 由网络底层的实现的功能被搬到了应用层
那么修改和改进起来就不需要经过等待操作系统以及网络设备的的更新来实现（也就不需要通过操作系统开发商和网络运营商的准许） 获得了更大的自由度和控制力 以及将来更大的改进空间

@sujin190 先不说丢包的问题了 对于你的观点说是 “http3 完全是为了未来更复杂应用更复杂交互设计的”
其实 Google 仅仅是想从各个方面改进 HTTPS 这个他赖以生存的技术 并且作为这个标准的主要制定者
说 HTTP2/SPDY 是对 HTTP/HTTPS 网络应用层的修改 基本上面目全非
那么 HTTP3/QUIC

@sujin190 丢包自然要重传 但是 TCP 是在底层实现的 而且只要丢包 再收到重传之前 后面所有的包都会被阻塞
而 HTTP3/QUIC 基于 UDP 就没有这个问题 丢包重传那个包 不会影响已经收到的或者还未收到的后面的包
这一点在 HTTP2 场景下尤为重要 因为管道复用 丢包严重的话 还不如 HTTP 1.1 多个 TCP 一起去拿了

HTTP3 完全不是只为了未来来设计的 现在就有这个需求 但是前提下是不对 UDP 进行劣化
尤其是当下的移动场景 TCP 一旦网络 IP 有变 就不得不断掉重来握手 UDP 没有这个问题

除此之外 TCP 大部分的功能是在系统底层以及网络设备硬件来实现和保证的 这一方面改进起来十分困难（比如你不能指望网络上面的路由器全部更新到新版本的 TCP 这种事情）
另一方面对系统网络核心的实现依赖大（比如搞个 BBR 算法改进还要等 Linux Kernal 更新） 而且系统调用切换频繁 HTTP3/QUIC 把很多本来依赖系统底层内核空间实现的功能 放到用户空间应用层来实现 性能上和灵活性都会好很多
比如更新一个 HTTP3/QUIC 的功能 只要浏览器自己或者服务器本身更新就可以做到 不用等系统或者网络硬件来实现
这样一来实现就很大程度上脱离了对底层系统的依赖

这些改进 对于一个技术快速迭代的时代尤为重要 Google 作为 HTTP 网络 Web 应用的最主要的内容提供者和受益者 自然要竭尽所能改进它所依赖的这些技术
所以对于 Google 来说 开发和推广 HTTP2/3 就是 “ 改善用户体验，加强开发实力，节省网络开支，掌控技术标准”

@sujin190 TCP 丢包会阻碍后面所有的包 QUIC 丢包没这么大的影响 更何况 HTTP2 是管道复用 自然会影响后面的请求
本来 HTTPS 是 TCP 握手+TLS 握手 现在省了

用戴森吸估计效果应该也可以