我发现自己总是在讨论串中发表评论，但又忘记回去查看。HN没有内置的通知功能，所以我很好奇大家是如何跟踪自己参与的讨论的。<p>你们发现的最佳工作流程是什么，以便在不遗漏回复的情况下跟进活跃的对话？
返回首页
一周热榜
嗨，HN，我们是Jamie和Dan，正在开发JSX Tool（[https://jsxtool.com](https://jsxtool.com)），这是一款新的检查器/开发面板IDE，允许您通过点击和命令点击轻松导航到React项目的任何JSX行，并探索您的渲染堆栈。
<p>演示视频：[https://www.youtube.com/watch?v=JIIXvN7vhrs](https://www.youtube.com/watch?v=JIIXvN7vhrs)</p>
我已经写了近十年的React代码。自从我第一次在Babel和Redux时代看到源映射以来，我一直希望能够从源映射中编辑我的代码。我也一直想像处理HTML那样检查我的JSX。
<p>去年，我发现我第一次真正使用AI的场景是，在Chrome元素检查器中进行临时的CSS更改，然后将其粘贴到ChatGPT中，询问在Tailwind中的等效写法。接着，我将这些更改粘贴到我的React TSX文件中。</p>
我想简化这个过程，但得出的结论是，为此我需要构建一个JSX检查器。我不得不编写一个自定义AST解析器，以创建JSX与HTML之间的映射。因此，我花了几个月时间开发了一个检查器，使JSX与DOM双向连接。
<p>下一个功能是添加一个CSS编辑器，类似于浏览器检查器中的那个，但用于JSX。与处理HTML的样式不同，我决定对React fiber的任何内存样式编辑都应全局应用，就像您在代码库中调整了那行代码一样。</p>
最终，我能够添加我真正想要的两个AI功能：（1）在我进行像素调整时提示内存样式，以及（2）将这些临时更改保存回我正在使用的代码库中。
<p>为了实现从Chrome扩展与文件系统的交互，我构建了一个小型本地服务器，从您的项目根目录挂载，允许扩展将文件系统命令发送回项目根目录。我们将其命名为“开发服务器”。（注意：您可以在没有安装此服务器的情况下完全使用我们作为JSX检查器。）</p>
经过这一切，我发现要将自己转变为用户，我需要一个功能相对完善的IDE。我需要vim绑定、类型检查器、自动补全、代码检查器、代码搜索和一个合适的文件浏览器。幸运的是，我们能够利用我们偶然发现的开发服务器架构，添加LSP服务器和Rip Grep。经过几个月的使用，我几乎在所有网站编辑中都使用JSX Tool。
<p>我们在移动端仍然有些粗糙，但我们正在努力改进。</p>
所有不涉及AI的IDE功能都是免费的，并且在没有AI的情况下也能正常工作。我们让您免费体验提示功能，但会施加一些使用限制。
<p>扩展本身不是开源的，但带有LSP的开发服务器是开源的。如果您想构建任何类型的浏览器内IDE，这是一个很好的基础，并且几乎与React无关。构建开发服务器是一项重大工程，因此我希望看到有人分叉它并从中找到价值。</p>
未来，我们希望开始添加一些我们能够利用的功能，比如让AI为运行时异常提供代码建议或处理网络日志。我们认为，在开发面板中拥有IDE的便利性使我们在便利性和工作流程上下文中占据了优势。
<p>无论您对AI编码的看法如何，我都希望制作出一个无论有无AI都能有用的工具。我们希望您能试用一下，并愿意分享关于产品技术方面的任何您可能感兴趣的信息。</p>
我已经在浏览器中断断续续地重现了原版的MacPaint几年了。虽然目前仍处于测试阶段，但我终于准备好更广泛地分享它。
我的目标是实现像素级的准确性，因此我花了很多时间研究Atkinson的原始QuickDraw源代码、模拟器，以及我的iBook G3，以确保字体渲染和形状工具等细节完全正确。
一些技术说明：
- 字体渲染出乎意料地棘手；理解原始流程的独特之处需要大量实验，而避免画布平滑/抗锯齿则需要仔细处理。
- 使用React进行声明式编写；通过缓冲池和写时复制语义保持合理的性能。
- 你可以通过用户界面分享作品链接。
例如：<a href="https://zenpaint.org/#p=KQumBQ5x" rel="nofollow">https://zenpaint.org/#p=KQumBQ5x</a>
- 这里没有考虑移动设备支持（显而易见的原因）。在较大的手机或平板上可能仍然可以使用，但我并没有对此进行测试。
在MacPaint的限制下创作艺术作品有一种神奇的感觉：1位图形、有限的分辨率，以及一套奇特的工具，依然让人感到意外的表现力。
虽然仍有一些粗糙的地方和缺失的功能，但我非常希望能听到任何记得原版的人给出的反馈。
500级错误发生在太平洋标准时间下午4:10，并于下午4:16结束。
无法当前推送，内部服务器错误。
我一直在开发 Fast LiteLLM——一个用于流行的 LiteLLM 库的 Rust 加速层，并且我有一些有趣的经验，可能会引起其他开发者的共鸣，他们也在努力从现有系统中挤出性能。
我的假设是，作为一个 Python 库，LiteLLM 会有很多优化的低垂果实。因此，我开始使用 PyO3 创建一个 Rust 层，以加速性能关键部分：令牌计数、路由、速率限制和连接池。
**方法**
- 使用 tiktoken-rs 构建令牌计数的 Rust 实现
- 添加无锁数据结构 DashMap 以支持并发操作
- 实现异步友好的速率限制
- 创建猴子补丁 shim 以透明地替换 Python 函数
- 添加全面的功能标志以实现安全、渐进的发布
- 开发性能监控以实时跟踪改进
在构建完所有 Rust 加速后，我进行了全面的基准测试，比较了基线 LiteLLM 和经过 shim 处理的版本：
| 功能 | 基线时间 | Shimmed 时间 | 加速比 | 改进 | 状态 |
|---------------------|----------------|------------------|------------|--------------|------------|
| token_counter | 0.000035s | 0.000036s | 0.99x | -0.6% | |
| count_tokens_batch | 0.000001s | 0.000001s | 1.10x | +9.1% | |
| router | 0.001309s | 0.001299s | 1.01x | +0.7% | |
| rate_limiter | 0.000000s | 0.000000s | 1.85x | +45.9% | |
| connection_pool | 0.000000s | 0.000000s | 1.63x | +38.7% | |
结果表明，LiteLLM 已经相当优化！核心的令牌计数几乎没有变化（慢了 0.6%，可能在测量噪声范围内），而最显著的提升来自于更复杂的操作，如速率限制和连接池，Rust 的并发原语在这些方面确实产生了实质性的差异。
**关键收获**
1. 不要假设现有库是低效的——维护者通常对他们的领域非常了解。
2. 关注算法改进而非重新实现——有时候，更好的方法胜过更快的语言。
3. 微基准测试可能会产生误导——现实世界的性能影响差异显著。
4. 最大的收益往往来自复杂部分，而非简单操作。
5. 即使是“适度”的改进在规模上也可能很重要——在高吞吐量应用中，速率限制的 45% 改进是有意义的。
虽然核心的令牌计数几乎没有改善，但速率限制和连接池的提升仍然为高流量用例提供了价值。我构建的基础设施（功能标志、性能监控、安全回退）为未来的优化奠定了坚实的基础。
该项目继续在 GitHub 上以 Fast LiteLLM 的名义进行，欢迎对 Rust-Python 集成模式感兴趣的朋友参与，尽管性能提升让人谦卑。
编辑：为了澄清——token_counter 的负性能可能在测量的噪声范围内，这表明 LiteLLM 的令牌计数已经相当优化。而在速率限制和连接池方面超过 45% 的提升仍然为高吞吐量应用提供了价值。
寻找一些在圣诞假期期间阅读的书籍灵感。
抱歉，我无法直接访问或翻译链接内容。如果您能提供链接中的具体文本，我将很乐意为您翻译。
我一直在考虑这个问题，我认为屏幕时间、点击次数等对我来说并不相关。<p>我想到的更像是对对话的分类，比如用户在结束时是否感到满意，用户是否感到沮丧等等。<p>目前你们是如何进行这些工作的呢？
新的数据显示，三年的二手车平均价格仅比全新车低约10%。在这个微小的差距下，过去“购买二手车可以省大钱”的逻辑正在崩溃。
一家媒体正在对此进行深入报道。如果您在过去一年内购车，我们希望听听您的故事：
您是否因为二手车在经济上不划算而最终选择了新车？
或者您购买了二手车，却觉得自己花了过多的钱？
您在二手车市场上看到的最令人震惊的价格是多少？
（请注意，如果我们决定引用您的故事，可能会请求您的姓名和地点）