@ns20 #33 百度百科：
科学家（ scientist ），是指对自然、生命、环境、现象及其性质进行重现与认识、探索与实践，并作出突出贡献、具有杰出成就的科学工作者。 [2]
如：英国物理学家牛顿、波兰化学家玛丽·居里、美籍物理学家爱因斯坦、中国空气动力学家钱学森。

当代科学家可还行？他这相当于写论文不注明关键引用文献，也能当此重任吗？

@GrayXu #56 没人说他不厉害啊，那个知乎的回答里还特地提到了他文转理呢，能在这么短的时间里跑通你说的’pipeline‘，谁都没资格去踩他一脚。
所以那个回答的核心也不是要黑什么东西，而是关注在一个点上：PO 主纯粹就是拿开源工具和代码跑通了流程，确通篇都在说自己'实现了 xxx'。

没看懂你说的啥意思，我理解了你的设计意图，我的意思是佩服你选择了一个这样的设计，实现了一个“一定要避开 vue 和 react 的设计”的设计。
我的牢骚其实只有第一句，就是看得人头疼。代码框架没必要从设计的“优雅性”“独特性”上做文章，简单易用的话方便传播，性能优秀的话也可以获得大众的青睐。你提供的这个设计让人看不到从使用者角度的角度来说的优点。
你好像有点看不上 react 使用了 jsx 语法，react 本身是否优秀不谈，但是 react 正是靠这个简单易懂的语法才让大众更容易接受的，如果它不推广 jsx 语法，让大家伙都套一堆 creeateElement ，估计 vue 早一统天下了。
vue 就更别说了，要不是他让大家直接写 html 和 css ，在国内是不可能获得巨大支持的。

当然你这看起来是个实验性质的项目，讨论上面那些没什么意义，但是我觉得既然是讨论也可以说出来。
那么认真说这里我觉得最大的问题真的还是需要让人易书写易理解。
比如 attr/prop 的实现你可能觉得很取巧很优秀，但是我其实之前评论的时候有写但是删掉了，就是觉得因为这种写法不存在归属感，会让阅读代码的人非常消耗精力。这个其实有一点点像 hooks ，使用起来省事，但是在复杂情形下阅读非常消耗精力。

这个文档整的这么好看，不开源岂不是浪费了？

这个 demo 看的我脑子嗡嗡的，我觉得最大的问题是不具有统一性，没办法一眼就看出来如果我自己要实现一个东西应该怎么写。
你这个如果把 tag() 方法实现成参数是 object 其实就是 vue ，比如 tag({ setup });
如果实现成正常传参就是 react, 比如 tag(props, { });
你刚好卡在缝里选择了传入一个方法，在下佩服。

哦，没看到第二页已经有人推荐好汉两个半了

@Dvel #38 感觉编剧脑力快要用完了，剧情水准开始略有下降，但是前面四季非常棒。

大部分朋友推荐的剧都挺新的，推荐一个上面好像都没有提到的稍微老一点的剧：
好汉两个半 - Two and a half man
没换主角之前的搞笑水准非常高

李跳跳+一指禅，开屏广告两个抢着帮我关

这不是无底线吧，只是放弃 web 了，虽然也很👎 就是了。
另外我现在都不骂产品经理了，毕竟都是为了完成老板给指的 kpi ，上班根本不用带脑子的。

1.未来女主拉胯，这是最垃圾的地方，找个和他妈一样好看的女主这么难吗？
2.还是有重大 bug ，这个迁移，明知有大问题，连个基本的防守都不做，或者说做了但是完全等于 0 ，让一个医生轻轻松松关了盾墙，轻轻松松抓了公爵大人，最后敌人都把城给炸了，营里的人才爬起来穿衣服，而且军营传讯居然靠一个人工摇醒？这个纪律性战斗力，还是帝国第二大家族，是不是有点过于不合理了。
3.没交代清楚的东西过多，对没看过书的人简直大爆炸级不友好，基本上看什么都很疑惑。
4.男主的闪念镜头过多，而且每次都有那个贼丑的女主，让人无语。

但是总体上瑕不掩瑜，在知道他是一个超大型的设定之后，也能接受好多东西没交代的问题。如果都能拍出至少是这一部的水准，那就更期待后续的几部了。

举报没问题啊，一般是走劳动仲裁，有时间可以去仲裁处咨询一下或者电话咨询：举报 996 需要提供什么证据。留心保存一下证据，然后再花点时间往返几次只有工作时间上班的仲裁处。方式方法正确，结局往往都比较理想。互联网也并没有那么严格的背调，不用担心再找工作问题。而且从性价比和风险的层面来看，被举报的厂子几乎不可能后续找你茬。

@iowt #62 好不好用发个帖兄弟。
另外我从来不擦屏幕啥的，没想到还有这么多门道。
要是这个抛光布对普通屏幕也有用，而且大兄弟你用过之后还不错，那我就直接一步到位得了。

@lightjiao #53 这，三点我全都反对。。。
- 服务端即便使用相同的语言重写，改动也一定是巨大的，巨大到等同于完全重写。
- 客户端换了引擎在延用架构和工作流？我也用过不少引擎，没发现有哪两个引擎可以共用甚至是一小部分工作流的。代码照抄是更不可能的，客户端的改动比服务端的改动只大不小。如果如楼上所说更换了同步方案，那前端的核心系统几乎是 100%重写。
- 手游因为资源量的限制，美术资源应该都是重做过的，甚至为了适应移动平台格式都有做优化和调整，内部应该有工具可以做一部分批量操作，减少一部分工作量。

去过一次，玩的啥没印象，但是对吃是真的印象深刻。就去过的好多国内城市来说，算一流梯队。有太阳有云的天气，配合海边城市特有的干净整洁，真的让人心旷神怡。
关于海鲜，我去的那次是租了民宿，去市场买的海鲜和朋友一起下锅烹制的，想去的朋友如果有水煮海鲜的能力，完全可以优先考虑订民宿。
另外我们还特地去吃了一顿野馄饨，不知道算不算当地特色？小串烧烤配馄饨，挺香的，还想吃。

看到上面一堆理中客好来气啊，脏话估计发不出去我先这里自我屏蔽 20 字以上的脏话。

拿快递最零散的淘宝来举例，从快递类型上来说，有包邮的产品，也有需要额外付邮费的产品，也会有本来包邮但是我希望有更好的快递服务从而加价要求顺丰的情况。从成本上来讲每一种情况我都付了快递费。
既然我付了快递费，什么情况下我没权利要求快递上门？什么叫我付的钱不够？商品本身也没有让我选择“快递到快递点”和“快递上门”服务啊？既然没这个选择，那依据法律法规，凭什么我不能默认理解快递应该是送上门的？还特么有说让我塞 20 块钱给快递员的？
理中客怎么不说这钱不是我不愿意给，而是快递公司的压榨，平台没有提供功能，商家自己承担了成本的问题？非要在这儿圣母说不是快递员的问题吗？

关于塞钱不塞钱的问题，拿京东和淘宝的对比举例，绝大部分情况下，京东的商品比淘宝是要贵的，我特么愿意多付钱给京东不就是说明我愿意塞钱来换取更好的服务。咋的在座的谁还没在京东上买过东西吗？所以这“因为你舍不得塞钱”的狗屁理论是哪来的逻辑？

快递员被压榨，当然是个问题，但是这个问题真的需要所有的客户都秉持圣母心态，忍气吞声当做无事发生吗？为什么不应该是，由于客户没有收到快递公司压榨，所以更有意愿发声，从而有“可能”倒逼快递行业调整呢？比如被媒体声讨多次的外卖员群体，难道是因为外卖群体在发声吗？他们身处群体内部，恰恰不敢发声，反而应该是多亏了客户群体的声讨，从而触发了媒体感知，再然后倒逼外卖公司调整的吧？

用过几次 react-query，见过 swr 很多次但是没有使用过。
刚刚去仔细看了一下 swr 的文档，看起来在用法上比 react-query 稍微轻巧一些，比如 react-query 的 {enable} 选项，在 swr 实现的很自然。

但是不知道是不是我的问题，感觉 swr 的中文文档不太好理解，比如：
“条件数据请求”里解释 key 不变会导致即使 token 变化也会返回脏数据，这一部分的解释看的我挺懵的，继续往下看并且结合曾在 react-query 中看到过的解释才理解，原来是因为 hook 的第一个参数整体被当做一个 key，来处理了缓存相关的功能，所以 fetcher 里面的逻辑在 key 不变的情况下可能根本不会被触发。
另外对于“传入参数”这部分文档，我感觉最顶上的“等价”部分反而会导致理解混淆：当我看到等价的时候，下意识的觉得“既然等价那就都可以咯？”，但是其实这部分文档更重要的是说明 hook 第一个参数的整体性。即当你需要可变参数时，不要在 fetcher 方法里直接引用，而是使用 hook 的第一个参数，利用数组进行传参，从而实现当数组数据变化时，引发 key （ swr 概念中的） 变化，进而触发 swr 进行重新计算和验证。这个概念其实就是主流框架本身的概念，还是挺好理解的。但是因为没有解释，不容易触发联想。而且还有最上面的文档来混淆。。。

我个人感觉的话，其实 react-query 的文档也比较让人头大，因为他虽然每个概念解释的很细，但是不太具有关联性，需要自己在使用中串联起来。swr 的文档则是不够细，主体以小例子为主，少见介绍背后的原理或者原因，所以理解起来比较困难。