webgl 都没用上？那说啥性能啊。。。。。。

"在 Canvas 环境中实现一套 UI 交互界面一直是业内的挑战"
啊？挑战在哪里？做游戏的谁没有自己开发过一套呢，而且我看你的库里好像没几个组件啊？你的文本组件支持多行吗？支持多行多样式吗？怎么代码里还有 if (italic) b.width += fontSize * 0.16 这种 magic number 而且不带解释的？实现了虚拟列表吗？

代码看来其似乎写的挺规整的，但是逻辑很乱，而且完全是过度继承、过度实现了呀。就 canvas 绘图这么个事儿，绝大部分图形一个方法就写好了，这中间也基本没有可以复用和优化的部分，整那么复杂是干啥呢？两个关键项目，几十个包相互引用，会不会有点小题大做？

看这回复一水儿的好评，我都有点忐忑了，是我太菜？

解决方案全都是虚拟列表，没有例外。方案细节基本就是元素复用、列表两端留缓冲区、高度重新计算等。

你觉得不好用是因为这个没有完美的解决方案，比如你说的等高问题，应该是想要考虑保留列表滚动位置，否则根本不必等高。

这些都是一说出来就明白的基础原理，并不是哪个技术方案本身能解决的，桌面端列表大了不虚拟也会卡的爆炸，只是在同一个硬件设施上比网页端能多承受一些而已。

这么烂的天气你为什么穿板鞋，买个雨靴穿上啊

你再放 20 万，北京市的常住人口们也能轻松吃下。。。
你说别的地方是帮帮政府我能理解，北京真不是，我只能说放的太少了。

国内能跑起来种付费课程吗？

我知道 typescript 和 react 分别有几个比较有名的开发者开了课做了专门的网站还挺老贵，vite/vue 相关也有官方的课也有专门的网站也挺老贵，而且似乎都有人真的买单。当然他们的课看着都非常专业、精美，而且背书的开发者也确实是大牛，我觉得可以先试试他们那种模式吧，把气质先提起来，然后再靠免费视频引流呗。

firefox 卡顿，去年一个更新后代理没法用了，这么明显的 bug 把我劝退了，虽然修的算快的，两周左右。

我就拒了一个跟你类似需求的乘客。

首先不想变成专职司机，那不平白多打一份工吗，还没几个钱，图个啥；
其次不想变成司机，每天准点接送啥的，等人，绕路，每天都来那是真的心烦；
再次不想社交，上车唠嗑啥的，并没有这种社交需求。。。；

当然我那个乘客更离谱，人钱都不想付，免费拉了一次对方出门迟到，目的地没有提前沟通好，结果还给我搞迟到了。

@shunia #12 本来吃着早餐刷刷 v2 准备开始干活的，一早上的好心情到这个帖子结束了。

大家都好宽容，我进来一看跟标题没啥关系，翻了好几下鼠标结果看到的居然 public-apis 就已经开始火大了。

噢噢噢噢噢噢噢噢哦哦哦，菊花一紧

全局状态用 context 不就行了？我记得官方文档里就教了大家怎么用 context+useReducer 做一个基础的优化的全局状态管理吧？
zustand 或者 jotai 之类的也就那样，为了实现跨库的特性导致写法很丑，而且心智思维没有 react 本身简单，在没有必要的情况下，不建议引入这些额外的库来做状态管理。尤其是使用 TypeScript 的前提下还要增加额外的成本，简简单单 context 一把梭就足够了。

如果你是在做性能吃紧的产品，那直接别用 react ，原生的 html+class 写起来也不复杂，用起来更是简单。

任何稍微碰瓷马老板的东西，都千万注意法院传票啊！

无理由退换的吧？为啥不买一台回来试试。

主要看 AMD 驱动下的性能能不能满足你要玩的这些模拟器，如果满足那使用体验非常丝滑的，我不是这个 U 但是体验觉得很满意。但是如果性能不够，那确实风扇会忽忽响有点闹心。

@proxytoworld #71 北口那个老头做的，选了钛板才花了 5W 多一点，他比较抠门，给患者省钱一些，但是美化方案比较坚持己见基本不太听病人意见。挺搞笑一个老头，突然忘了名字了。

需要这个玩意的公司，会觉得 400 欧贵吗？

我第一反应是：啊？这么便宜的现成产品，还要啥自行车啊。