hax.github.com
hax.github.com copied to clipboard
hax
Hax's homepage @ github
常见的给请求加 timeout 的代码： ```ts async function get(url: string, timeout: number) { const timeoutPromise = new Promise((_, reject) => { setTimeout(() => reject(new Error("Timeout")), timeout); }) const fetchPromise = fetch(url) //...
2023年年中了，现在还有那么多 nodejs 版本管理工具： n、nvm、nvs、nodenv、fnm、volta…… 甚至 [pnpm 也内建了版本管理](https://pnpm.io/cli/env)。各位用哪个？ 以下是我个人对这些工具的经验： ### n 本身就是用 nodejs 写的，所以使用之前需要已经安装了 nodejs，另外据说如果把当前的 nodejs 搞坏就切换不了了。 ### nvm 俺很久以前还给 nvm 提过 pr，不过感觉 nvm 实在太慢。 ### nvs 我是很多年前从 nvm 切换到 nvs...
知乎答案链接：https://www.zhihu.com/question/34449620/answer/79028575 其实本答案并不是对工具变化快的直接评价，而是通过预言来间接给出评价：与我预言的即将发生的变革相比，阮老师所描述的变化是小巫见大巫。 我的这个预言或者说判断，在2014年年中即已成形，但我一直憋到2015年年底才来回答——因为在一周前D2的夜场上，我在即兴发言中终于憋不住抛出了我的预言：前端的构建部署即将发生革命性的变化——单独的构建环节将逐渐弱化乃至消失，构建所包含的实质性内容即脚本、样式等资源的编译转译等将云化和实时化。两年后（到2018年时），不要说Grunt/Browserify，Gulp/Webpack等也均将退出主流。 具体来说，我预言明年（2016年）将出现包含JS模块加载、包依赖自动处理、JS自动编译这三项核心功能，并基于HTTP/2的前端资源云服务（可理解为CDN的进化形态）。并且这类服务会在未来两年里快速成长并带动整个前端的大跃进。比如，通过ServiceWorker大幅提升浏览器缓存利用率，加上HTTP/2等协议级优化，Web应用的加载性能将获得划时代的提升；根据UA分发目标平台特定编译版本和自动polyfill，Web应用的浏览器兼容性将获得划时代的提升；提供各种增值服务如方便部署安全特性，安全性监控、灰度部署、包的平稳升级、前端（精确到应用和所依赖的包）的错误监控和分析、前端性能监控和分析等，Web应用的质量将获得划时代的提升，开发效率也将是划时代的提升……由此，前端工程师也会重新把很大一部分精力从构建部署相关的工程问题回归到网站/应用的交互体验本身。（不过应用框架和组件化相关的工程问题届时是否能有比较一致的答案，现在看还很难说。） 以上就是我的预言，立此存照。 BTW，如果2016年9月前我预言的事情还没开始发生，我会亲自动手。 ^_^
富文本编辑器选型
project | repo | star/fork| maintainer | status | deps ----------------------------------------- | -------------- | ---------| ---------- | ------- | ----- [UEditor](http://fex.baidu.com/ueditor/) | [fex-team/ ueditor](https://github.com/fex-team/ueditor) | 2339/1024 | @Phinome (baidu fex)...
感谢 @liusong1111 在 https://github.com/hax/hax.github.com/issues/21 话题讨论中提供facebook的这个slide：[React: CSS in JS](https://speakerdeck.com/vjeux/react-css-in-js)。 slide的前半部分，我没想到facebook能在错误的工程化道路上走那么远（这个可以理解为赞美）。我在前文中“局域化CSS”一节写道：“覆写和扩展class钩子或可类比为某种接口使用，但实际运行时并没有任何约束，我们也很难进行静态检查”。但是facebook居然做到了显式接口和静态分析。这完全来自于f家强大的工程能力，体现了f家前端架构师的牛X。不过可惜的是，即使做到这个地步，这条路仍然是走不通的，他们自己最后也意识到了。BTW，这也基本上可以视作对OOCSS、SMACSS、BEM等方法论宣判的死缓。 后半部分是他们的一个解决方法。 包括： 1. 使用inline style 2. 使用JS表达样式组合，从而利用所有JS的特性（如模块化） 3. 放弃使用selector的specificity机制，而是在插入inline style时使用JS的调用顺序来明确override样式的优先级（在这个点上有极高的灵活性，是完胜传统class钩子的关键点） 老实说，我一点也不意外这样的方案，我甚至惊讶于从Bootstrap流行开始花了这么久才走到这一步。实际上我一直认为“样式为中心”的开发方式最终应该回归到inline style上。 但是，这样的方案是不是胜过了我一直推荐的CSS preprocessor的方案？我认为没有。 此slide列出的CSS的scale问题（即大规模开发时的可维护性问题，或者通称“工程化问题”）如下： 1. Global Namespace 2. Dependencies 3....
```js { // code 1 const [a, b, c, ...d] = test() print(d[0], d[1]) } { // code 2 const [a, b, c, d, e] = test() print(d, e) }...
这次的题目是这样的： ```js 'use strict' var o1 = { f: function () {} } var o2 = { f() {} } ``` 请问 `o1.f` 和 `o2.f` 有哪些差异。
今天发现github pages build失败，原因是github pages换ip地址了，检测到ip没改时，通过这个方式告诉你该更新了。 但是根据https://help.github.com/articles/tips-for-configuring-an-a-record-with-your-dns-provider/ 最好是有alias/aname 记录。不过大多数 dns 不支持（比如坑爹的godaddy）。 于是找一下dns服务商（http://www.datanyze.com/market-share/dns ）  虽然自从我用的everydns挂了以来，dns service的厂商已经很少提供free的服务了，我又不想用dnspod（尽量避免用兲朝厂商），但惊喜发现排名第一的cloudflare的服务是免费的，而且还支持aname（不过是以cname自动flatterning的形式）。更惊喜的发现2011年我就注册了它的服务…… 所以用起来吧。
『偏门』的意思是，这个题目基本没有什么卵用，不建议使用。 例外情形：候选人自称『精通JavaScript』或自评JavaScript水平8分以上（刘鑫老师说，程显峰出过一个面试标准，8分意味着达到标准委员会水平）。 --- JS中一个array（数组）的length属性的最大值是： 【更具有迷惑性的表述是：JS中一个array（数组）可以包含的element（数组元素）最多可以有多少个：】 A. `2**31` B. `2**32 - 1` C. `2**32` D. `2**53 - 1` --- 该题的变形形式（更难一点）： JS中『array index』的最大值是： A. `Number.MAX_VALUE` B. `Infinity` C. 规范没有定义 D. 下表中的 _______...
最近这几年来，浏览器厂商对隐私的注重越来越提升。一些小众浏览器以此为卖点，比如Brave。而随着Chrome一家独大的情况愈演愈烈，有被边缘化趋势的其他浏览器也都着重以隐私为差异化点。比如Safari。 既然以此为差异点，言下之意就是Chrome的隐私保护就比较差一点，那为什么Chrome就差一点？有一种攻讦认为Google是依赖互联网广告的，因此不愿意『过度隐私保护』来削弱第三方广告主的利益。 但是，『过度』隐私保护或许确实达不到目标，比如当初 DNT（Do not track）的纷争。IE10默认打开了DNT，而这是不符合DNT规范的，DNT的一项重要要求是，开启DNT必须是用户主动的选择，而对于广告商的约束也是基于这是用户的主动选择。IE10实际上为了彰显其『保护隐私』而破坏了DNT的基础，最终反而对保护隐私不力，因为广告商会因为DNT并非用户的主动选择而选择忽略之。当然，DNT只是浏览器发了个http头，但本身从来就没有被广告商真正广泛支持（包括微软自己），所以马后炮来看，也很难说IE10在DNT失败上到底要付多大责任，反正最终DNT被证明是一个失败的尝试，而DNT设置自身反而会被作为一种信息用于fingerprinting，因此今年2月，Safari 12.1主动移除了这项功能。 除了认为Google主动『不太重视』隐私保护，另一个点可能是Chrome的功能跑得太快，Chromium的contributor比其他浏览器多一个甚至两个数量级，每天代码变更太多，这当然是Chrome对其他浏览器的极大优势，但也导致根本来不及review所有变更是否对隐私和安全造成了新的影响。据说微软放弃EdgeHTML转投Chromium之后，会着重投入到改善Chromium的隐私能力上。 回来说Safari，Safari对于事关隐私的特性是非常注重，不惜牺牲开发者所需要的功能。比如高精度计时，按照标准可以有5微秒的精度，但Safari只提供了100微秒的精度，比标准差了20倍，就是为了提高时间差分攻击的难度。 我最近在TPAC上听一个Google的人说，Safari的目标号称是要把可以被用作fingerprinting的entropy控制在8个字节bits以内。这是一个非常难以达到的目标。 也因此，Safari做了一些可能比较激进的改动。比如不允许CSS中指定本地字体。因为这可以被用来探测用户安装了哪些字体，并可被用作fingerprinting。对于开发者来说，这意味着除了基本font-family比如serif/sans-serif之外，就只能使用web fonts了，但是对于CJK来说，web fonts的开销还是非常大的。 另一个事情是cache。传统上http cache是共享的，比如大家都用jQuery，就可以从同一个CDN上加载。但是这也存在被利用来探测用户的风险，因此需要被隔离。这意味着每个网站都需要单独加载比如说jQuery，即使之前另一个网站是从同一个CDN以完全一致的URL加载过。Safari已经是这样了，FF和Chrome也打算跟进。（参见 https://github.com/shivanigithub/http-cache-partitioning/ ） 我们还需要注意，这两个事情是有叠加效果的，一方面我们被迫更多使用web fonts，另一方面web fonts也不能跨站共享缓存，结果就是要个性化字体的成本就变得更高了。 本质上，特性和隐私可能是存在矛盾的。比如SharedArrayBuffer也是一个可以被变相用来提供高精度计时的机制。一些对底层硬件能力的暴露也很容易被用来做fingerprinting（比如canvas 2D和3D）。我们要么完全禁用之，要么必须付出一定的性能代价来消除可被利用的entropy，不同的浏览器还可能采取不同的策略。这里也包括一些国内厂商，比如UC等为了一些（不太确定的）理由就阉割掉了WebAssembly能力。 在这个过程中，开发者可能是最被动的。