@CLMan 这中文还是我提交的翻译，当时有意（偷懒）保留了翻译腔，这居然被原原本本的复制了（

还记得古代 3dfx 吗，它是怎么死的，就是因为捏死专利不开放图形 api （不允许其他厂商支持它的专有 api ），然后被 nvidia 一个 geforce 玩死了
现在 nvidia 的状态也是类似，捏死 cuda ，不让第三方实现（ cuda 确实好用）
只可惜以目前现金流状态 nvidia 短时间死不了（

长文件名支持需要应用程序自己适配（
如果写死一个 wchar_t path[MAX_PATH]那神仙也救不了（

就好像英语用大写一样，看着会高级很多（

vscode 之前有个更新就说支持这个编码了（
笑死还是微软最快

迷惑回复之 yuv vs uv
这俩玩意都不是一个东西啊，texture 里的 uv ，就是指纹理坐标系里的坐标啊（你把 u 看成 x ，v 看成 y 不就好了），用 uv 这俩只是为了防止名字冲突
https://en.wikipedia.org/wiki/UV_mapping

@sillydaddy 阿里系的确认收货都是支付宝做的，实际上担保服务就是支付宝提供的，第一方就是支付宝。而闲鱼，淘宝，1688 这些都是不提供担保交易服务，这么说反而闲鱼 app 内做确认才是“第三方确认收货”。。。

有没有可能高温下硬件会提前损坏？而且坏了肯定没保修了，即使 cpu 本体能承受得住，cpu 周围的部件也不一定能用，比如有些风扇甚至会在高温下提前损坏，这样更压不住温度了

@jifengg @pursuer 实际上那 b 是 binarystring ，是在没有 typedarray （ uint8array, arraybuffer ）时代的二进制 blob 替代品，你看上去是一个文本，它实际上可以存 0-255 所有的字符，不是仅限于 ascii ，也可以包含 utf-16 禁止的字符序列（反过来你即使 atob 把 utf-16 的中文 base64 结果转换为这个 binarystring 也是不能得到正确中文的）。
可以说是非常之奇妙，这玩意的构造方法就是用 String.fromCharCode ，古代的主流用法是 String.fromCharCode.apply(undefined, [1,2,3]) 来从数组里构造一整串 binarystring （用这个方法弄出来的字符串保证是 binarystring ，在一些优化过的引擎里不会用两倍空间存储）
因为过于魔法而难以进一步优化（比如一不小心就会退化成普通 string ，占用两份空间），所以 arraybuffer 才会被发明以取代 binarystring
（然后因为 arraybuffer 不能轻易扩展长度，最近又在搞 resizable arraybuffer ）

arc 并不是灵丹妙药，而且性能不一定比得上 gc 和手动内存管理，还有额外的空间占用（所有被跟踪的对象，总得有个地方来记录引用计数吧），也没“彻底”解决内存问题（比如手动 weak 可能会炸，但不写可能会漏）
性能问题举例一个最简单的地方，因为没有额外标注，arc 必然得保证线程安全性，也就是说，即使你只在一个线程中使用，也需要通过线程同步的手段去做，虽然锁的粒度很小，但是由此带来的 happens-before 的语义也会导致很多优化失效

这篇钓鱼文还真有人翻译也是笑死（
看看原文发布时间

@GeruzoniAnsasu 最后那点其实不太对（
既然都 fp 了，还用啥 this 啊🤔️，没有 this 那用啥都差不多
还不是主要为了少打几个字（

显然通过拼接 html 的形式思路就不对（
你可以考虑把数据库里的数据提取成一个数组，然后 map 成单独的组件（就像列表渲染那样
啊🤔️实际上就是列表渲染吧，只是每个元素可以是异构的而已

还不是因为主流的事件处理方式（浏览器提供的，不是你想改就能改的），要求提供一个函数做回调，这种情况下，写一个函数名意味着函数声明的位置和使用的位置就有一定距离，原地写 function 也有太长的问题
还有就是，箭头函数不会有 this 的问题，不需要外面设置一个 var self = this 这样的写法（虽然现在大家都不用 class 了，不存在 this 的问题）
虽然我觉得还是视角的问题，把回调看作延续就会比较自然了

u 盘还有非固态的吗？以前好像有那种给相机用的磁盘，挺小只的（成本极高，还容易坏，不会有人复古仿制了）
不过 u 盘主要的问题是用次品颗粒（

一般来说是一起改代码（
所以如果都是 js 的话就很合理了（
还有就是用类似 json 动态生成表单的方式，缺点是自由度比较低，但是基本上只要改后端就可以了，放在后端比较合适
剩下的我能想到的就是所谓的低代码方案，其实就相当于把前面的两个方案结合起来，动态生成，但可以容易定制
（这个容易定制当然也是有限定范围和代价的）

以前的前端开发 ide 如 frontpage 就有提供类似功能，把一个页面的一部分定义为公共组件，一改就一起改不确定底层方案是怎么实现的，我猜可能是同时修改多个文件（

说起来 bat 也是有编码问题的（
记事本默认 utf8 的话，只要系统没开实验性 utf8 ，默认保存出来的 bat 也是会炸的（有 ascii 范围外字符的情况下），反过来也是一样，开了实验性 utf8 ，那网上一大堆 bat 就用不了了
结论：不要用 bat （

主要现代前端框架不是解决怎么把页面做出来的问题，而是解决怎么在需求复杂而且经常变化的环境下，把代码的复杂性控制到一个合理的水平的问题
如果只是做出页面，并再也不需要动，那自然不需要发展这么多所谓的框架，香草 js 肯定可以解决所有问题。
问题在于，一旦需求发生了变化，比如要加一个功能，怎样才能让复杂性以低于线性的速度增长，而不是 O(n!)复杂度。