卡片的配图是不是有点过于牛头不对马嘴了。
做的很棒，兹磁！

[瑞斯拜]

不对，这不是我要上的车！

htmx ，有理论加持，还有出版书，星星多的离谱，肯定倒不了。
语法和用法与目前所有主流框架都不太一样，满足你又先进又不离谱的需求。

solid 没啥好用的，不稳定，现在也不够先进了。

露营意思是睡帐篷吗？话说在高速上吹一整天之后不洗澡不太行吧？

@cr3bit #41 不太懂，zerotrust 和客户端的联系是啥？
浏览器插件在你打开那个弹出面板之后，如果直接切换到其他系统级窗口，浏览器里的弹出面板是不会关闭的。也就是说你如果需要在浏览器和其他窗口之间切换，也并不会受到打扰。

@canxin #36 能理解你讲的例外情况，但是就像我第一点说的，日常要用到客户端登录的情况太少了吧？更何况在国内产品已经几乎 90%都强制手机号或者 QR 扫码登录的前提下。

学英语，找海外啊。rust 在国内还没市场，国外感觉挺容易的呢。好多 terminal 工具都是用它做的。
多多关注 producthunt 、hacker news 这种渠道，好多产品、工具都会在自己的主页招人，hacker news 有规律性的官方管理的招人贴。

这种工具的 PC 端有啥作用？谁能提示一下？
我用的是 bitwarden+vaultwarden ，它新出的那个 PC 端我感觉根本用不上啊。

一是因为日常需要用客户端进行登录的情况少之又少；
二是我浏览器只要开机就打开了，感觉根本没必要多开一个客户端；
三是感觉 PC 端提供不了任何便利啊，比如一些客户端软件如果要登录，PC 端无论如何也做不到自动填充，还得自己复制粘贴，不就一样了么？

@tool2dx #101 怎么又扯到 UI 编程了，write once run everywhere 是 UI 层面的概念吗？它明明依赖的是底层的渲染引擎啊？
html 的名字就说了人家是 text language ，你完全可以在任何平台之上实现一个可以渲染 html 到你想要的效果的引擎。html 本质就是 xml ，哪来的不能 write once run everywhere ？

能不能脚踏一点实地的聊点不假大空的东西！

哥们这么会说废话，应该多少也是个官吧😅

咱们搞技术的能不能整点实诚的，举个具体的例子，浏览器怎么就没能承载你写过的超大的项目？

能不能先定义一下超大，再说明一下无法承载是因为出现了什么问题？

这图都画的这么详细了，一眼看过去就应该知道接下来只能再在外面加一个数据层来进行数据管理啊？毕竟组件和组件之间的关系已经是完备的了。

用 context 确实会限制数据只能在 react 组件之间流转，但是你也没意识到一个问题，当你选择了用 react 去实现一个组件，它就已经不再是一个”通用“组件了，它本身就只能在 react 框架里流转。

如果你能把 Grid 实现为一个独立的组件，那你就必然要为它设计 API 用来向外传递数据，也就意味着你使用 Grid 的地方一定要能捕获 Grid 的输出并且把它集成到你的 App 的数据流里（如果你需要的话），也就意味着你的 App 必须要有一个数据层。此时使用 context 是完全合理的。

如果你还是觉得生理不适，必须要使用一个无依赖的数据层，react 生态里很多这种东西，比如 zustand ，但是我觉得增加的额外心智负担其实不如使用 context 。

最后再说一下那个鼓吹 Angular 的，包括说 service+rxjs 的，其实和 context 是一个性质的东西甚至更为不如。react 好歹数据层的生命周期管理的让人毫无心智负担，rxjs 则难以管理而且还要显式的销毁，否则会引发内存泄漏。service+rxjs 又完全不独立，和代码是紧密关联的，也并不符合 OP 的要求。就试问一下使用 Angular 实现和使用 React 实现，代码路径有什么区别？独立一个状态管理类，所有组件从中直接或者间接进行引用，还能有其他方法？而且早期的 Angular 没有 Inject 注解，甚至要在构造函数里传递 service 实例（至今官方示例代码依然优先采用这种写法），一旦遇到需要继承的情况就构造函数爆炸，蠢的很。而且直到最新的 standalone 组件之前，所有组件和 service 之类的都要显式的声明依赖和引用关系，傻的爆炸。组件编译出来默认 Shadow Dom alike 无法直接外部干涉，还需要每个组件显式声明不采用 Shadow Dom ，无语到让人喊娘。

最最后再提一下，脱藕 html/dom 和脱藕 React 组件不是一码事，不要想着希望自己最终产生的 html/dom 是脱藕的，就期盼着 JS/TS 代码内部也完全脱藕，不存在这种可能性呀，毕竟你的 App 内部总是有关联的，试论哪种解构方式都无法脱离耦合，只是高低的区别而已。

我以为我回到了十多年前

解决了以前要搭一个 React 的全栈项目稍微有点费劲的问题。

比如说有一个叫 T3 还是什么的一个项目就是一套全栈的脚手架，拿了巨多星，主要就是因为一个明星开发者提供了一套开箱可用且全面的全栈模板，算是解决了前端生态稍微有点混乱选择太多配置比较割裂的问题，因为他是明星开发者所以被更多人看到，虽然他的选择有很大的倾向性，但是确实解决了问题。

Next.js 就是一套更加完善，整合的更成功的解决方案。虽然它并不是唯一的选择，但是它有一些先发优势，又得到了 vercel 的大力支持从而和 React 团队搭上了线，从而一跃变成了天选之子。另外它也确实做的很不错，在获得了 React 的原生支持之外，提供了一些未必是原创但是很优秀的解决方案，比如通常比较烦人的 SEO 、图片优化等，另外从开发者角度投入了非常大的精力做优化比如文件路由、文件目录层级优化等。

不过这玩意比 React 激进太多了，从我自己使用的过程和体验来说，感觉 vercel 还是把它当成一个孵化中的项目，并没有真正的稳定下来。

什么概念？之前经手的开发人员都非常的稳重！

@itianjing #88 松的越快就刹的越猛，一般前段猛后段缓。

另外一般都可以在设置里选择，最终停下（速度为 0 ），或者最终缓行（ 5-10km/h ）。
有的车甚至可以设置缓行速度。