@egen 12 代 i9 单核性能也差不多 现在 CPU 单核性能已经瓶颈好多年了
现在 Intel AMD 还是 Apple Qualcomm 都是在堆核心

这个早就有了啊

没啦

@3dwelcome wasm 目前设计的目的是可以直接把现有的软件编译到浏览器里面运行 而且主要就是算法部分
或者借助 wasm 把 js 里面有性能瓶颈的部分 更加高效的执行
另外 wasm 和 js 可以无缝集成 这样 wasm 就可以借助 js 来操作 dom js 也可以借助 wasm 来提升核心算法的效率

@3dwelcome 我记得本来 JS 是想加类型的 你可以看下 ECMAScript 4 https://evertpot.com/ecmascript-4-the-missing-version/
但是失败了

然后有了 TypeScript Dart Flow 基本上都是为了给 JS 加静态类型
结果就是 TS 成功了 Dart 在靠 Flutter 续命 Flow 死了

当初 ES4 失败 我记得是因为大部分 JS 的开发者并不想要类型 觉得太麻烦了 太复杂
而且就是给网页写点 script 方便好用才更重要 灵活性更重要

但是随着 webapp 越来越大 需要团队协作的越来越多
所以静态类型的重要性就越来越大

我个人认为 现在 JS 根本不打算再尝试加入类型：
1 是有之前的失败
2 已经有了很成熟的 TS 和 Dart 有需要的人为啥不用
3 现在 JS 核心人员有不少就是不喜欢 TS 和静态类型的 就是不想要和 TS 这些一样 你看下最近出的 private field/method 就知道了

@creanme 既然是静态类型 肯定会越来越复杂的呀 毕竟有大型工程的需要

----

@3dwelcome 另外我猜你可能是希望通过引入静态类型来提高 JIT 性能 可能你不是特别在意静态类型本身
这样其实各大浏览器开发商已经在往这个方面努力了
之前有 asm.js 其实就是给 简化的 JS 加上基本类型的静态类型 这样就可以直接编译成本地代码执行
然后 asm.js 进化成了 wasm
所以 JS 本身就没有必要为了性能去添加静态类型的复杂度
想要性能 可以用支持静态类型的语言之间编译成 wasm
想要灵活性 就用 ES 或者编译到 es5 就是

@3dwelcome 现在给 JS 加类型 语法就 2 种 要么学 TS 类型写在变量后面 a: string
要么学 Java 写在前面 String a 基本上就是 Dart 的做法
说要用变量名来表示类型的就是扯淡 string_a 这个根本没办法统一 而且之前也有这么做过的 问题多的要命

“我不想用 TS 啊，就想用原生 JS 那个熟悉的味道”
加上类型后就不是 原生 JS 的味道了啊
而且现在 TS 已经很成熟 JS 直接改个名 然后加几个 any 就可以跑了 具体的类型验证 后面再加也行
唯一就是用一些第三方库 需要找 typing 或者写 def 有一点点麻烦

那不就是 TypeScript 吗
不是所有人都喜欢类型的呀

为啥你不喜欢 TS 又想要类型？

TS 本来就可以兼容绝大部分的 JS
你不想要类型 TS 你定义成 any 基本上就和 JS 差不多了

另外 Google 有 Dart 呀
推过 但是失败了 现在靠 Flutter 来用 而且最终编译成 JS

@Rocketer 未来我觉得还是要看 Wasm
不管是 JS 还是 TS 还是 Rust/C++ 甚至 Java/C# 都编译成 Wasm 就可以了

我觉得 对于一个自己深度制定的 Windows/Linux + Android + 质量合格的硬件 整体的体验肯定会比 Apple 全家桶好 而且自由的多

但是大部分人都没办法 "自己深度制定" 这样一来 Apple 自带的功能就可以很好的工作
比如 还没出的 Universal Control 其实 Windows/Linux Android 早就有软件可以实现

苹果生态的好处就是事情比较少 而去软件质量相对比较高 并且问题也少

其实很简单 如果你没用过 macOS 也没有非用不可的理由 就完全不需要 Mac
Mac 再香都不需要 更不要说现在 Mac 还不是 x86 的了

从 Windows 转到 Mac 的代价非常大的 而且很多常用的软件不一样 或者需要从新购买
我觉得比从 Android 转到 iOS 难度要大

确实要看软件和网络
我一般 13pro 一晚上也就掉 5%以内
但是有一次装了几个 app 后 一个晚上直接从 50%掉到关机
估计是有 app 一直在后台做什么

@ytll21 不是哦 首先 docker 不是只用来部署线上服务的 很多时候也用来开发测试 或者本地搭建环境和脚手架
如果线上用了容器 这样本地环境和线上环境比较相似 可以避免一些麻烦

另外 现在越来越多全栈 其中 devops 也是很重要的一个技能 你的的代码你要自己部署上线 就是可能有运维帮忙 对于全栈 负责任的人还是自己

就算有专业的运维 如果线上用容器 也应该和开发一起讨论容器的一些细节和兼容问题 比如那个 Linux 发行版 以及某些库的版本
另外如果线上出问题 那么肯定也要跑到容器里面 或者拉下来一个容器来测试复现之类的 那么基本的容器的操作还是要会的

总之 现在除非真的在一个地方养老 如果是做线上系统的 还是一定要学一下容器的

这个和国内的百度比还是好点的了
所以国内这种情况更严重 互联网割裂更严重
每个 App 都希望把用户圈在自己的生态里面

macOS 12.3 移除了自带的 python2
肯定是你的 zshrc 或者 bashrc 里面用了 python 了 如果不需要移除就是
如果需要 homebrew 自己安装一个就好

zstd 不适合 web zstd 主要的优势是快而不是压缩率
br 的速度肯定没办法和 zstd 比 但是压缩速度对 web 而言没那么重要 尤其是静态资源
br 就是专门为 web 优化的算法

@duke807 br 是压缩慢但是解压缩还是比较快的而且不太占资源
xz 如果是高压缩率的话 压缩和解压都太慢 而且太占资源了 不太适合浏览器

只有那些比较简单封装的 webapp 可以从 Electron 转而使用 webview2
或者有人出一个和 Electron 一样 API 的东西但是用 webview2 + node 作为内核

@okampfer 很难 除非 webview2 支持能够支持 NodeJS 但是可以说是不可能的
只有那些比较简单封装的 webapp 可以转而使用 Electron
或者有人出一个和 Electron 一样 API 的东西但是用 webview2
但是像 vscode 这样这么多功能又要跨平台 又非常依赖 Node 的 app 肯定还是会用 electron 的

另外 webview2 是和系统的 Edge 绑定的 不受 App 的控制
如果有人就是不升级 Edge 或者 App 太老 Edge 又太新 就会出现兼容性问题
除非 App 自带一套 webview2 那么这样就和 Electron 一样重了

@dcsuibian windows 出了 webview2 也是基于 Edge / Chromium 的
那么大部分 Electron App 在 Windows 下其实可以不用带整个 Chromium ，当然 如果要用到 Node 的部分就没办法了

@LxExExl 就是 HiDPI 的 不是整数倍的缩放 字体就是不够清晰
尤其是 Dark Mode 下 看久了眼睛不舒服

@LxExExl 4k 缩放到 1440 不是刚好 2x 感觉字很模糊 看久了后感觉眼睛都花了

@hello2090 我戴眼镜 2-3 年前也觉得 4k 1080p 内容太少 5k 很合适
但是用了 5 年 5k 后 现在觉得看着太累了 屏幕要放到更近才舒服 但是这样就更伤眼睛了
现在换成 4k 反而觉得刚刚好