其实挺好.....web 应用优化后能用，内存是硬伤。

@qrobot 哎，无聊

我有个需求适合多线程+共享内存来写，也没现成安全问题，你说这玩意不好。

- - 你是来吵架的吗

@fulvaz 还有别问为什么要用垃圾 react 不直接干 DOM 。一时半会我改不了。

@qrobot 哎呀，你没理解对。

1. 足够复杂的业务构造 fiber 树的计算量不比音视频小。 我骂 js 不支持多线程需求，肯定是因为有需求需要共享内存+并行，上下文切换的开销怎么会没想到呢。
2. performance 查看。你想得太简单了，线上问题没路径你怎么复现？你最多能用 worker 做心跳发现有问题，却不知道哪里有问题。另外心跳的开销要不要考虑？

其他提的问题首先去骂库克，为什么要弄 WKWebview

@youyaang 愿闻其详，哪个？ 我去看看

@lmshl 老哥能说说这图是哪来的吗， 有点好奇想继续深入研究下

甚至飞书都行 - -

黑卡是什么？

广州房贷放松，拖了半年的房贷全部放了，是个信号

然而三四线依旧收紧。

一二线可以买

- - 矫正你的坐姿, 特别是手肘要有承托.

立杆见影, 现在 9-11-5, 基本不疼.

Quick Tab

你需要这个

yysy, 去年上车天河, 5w 出头, 今年很勉强至少到 6

39w 大概是 39/50, 7800 行.

试试飞书文档, 压力测试 2k 行没问题, 能秒开

7800 行我没测过, 技术上应该是没问题的, 打开时间会长一点.

注意通过导入的方法导入文档, 复制粘贴太为难人了.

@murmur 其实只是大家上下文不同就造成了误解

你只需要 jq 撸个页面, 所以用什么语法, 怎么写, 要不要用 react, 都是无所谓的

我可能和几十个前端合作写一个项目, 你轻视的"语法糖"对我们来说其实是救命的.

看需求而定, 相互理解吧~

@murmur 这就很偏见了~

有一说一, filter 写出来的是无副作用代码, 读起来比 for 舒服多了. 现在看到 for 就皱眉. 意味着要理解对外部状态的处理, 还要考虑这几个状态还会被谁给改了.

换银行吧, 建行是申请不下来了,

@GoLand 100w 去年是最后机会, 现在也不多了........

"他对底层的数据极为依赖，往往后端罢工，前端就死了，因此前端的生死取决于后端，因此后端是大爷，前端是奴仆"

也没那么惨.

如果你把统计加上, 会发现前端的打开成功率不到 99.9%的, 即使后端 API 成功率 99.99%.

如果你讨论的是稳定性之类的, 前端前端是有很多工作可以做的, 并不是简单的主仆关系.
- CDN 备份容灾做了吗
- SSR 呢, 至少后端 API 挂了, 用户可以有个友善提示, 而不是白屏.


我们这的前端经常会倒逼后端去改进, 就看你想不想花精力去推了.

-----------------

推进这些事情总是困难重重, 而且是个长期任务, 还需要你有项目管理的能力.
光是多申请几个 CDN 做容灾, 申请几台机器做 SSR 也对你的沟通能力提出了要求.
或者是这个项目本身怎么说服老板给人力?
如果是跨部门沟通的话, 对你的要求就更高了.

我觉得前端也没多简单......说白了就是依赖方太多了, 很多时候要承担技术以外的角色.