## 对 Next.js 15 & React 服务器组件的批评
本文详细描述了一位开发者在使用 Next.js 的 App Router 和 React 服务器组件 (RSC) 时遇到的挫败感，认为它们的基本设计选择存在缺陷，尽管最初很有前景。作者和许多其他 Web 开发人员认为该系统过于复杂且不直观。
RSC 将组件分为“服务器”和“客户端”类型，旨在实现高效的数据获取和渲染。然而，令人困惑的命名约定和限制——例如难以轻松执行乐观更新——导致代码混乱和不必要的复杂性。导航感觉缓慢，因为即使客户端已经拥有数据，每个页面都会重新获取数据。
作者成功地将一个项目从 Next.js 迁移到 TanStack Start，强调了简化的开发体验、改进的性能和更好的类型安全性。他们提倡使用 Astro 或 Fresh 等替代框架来构建静态网站，并使用 TanStack Start 来构建动态 Web 应用程序。虽然称赞了 `next/metadata` 和 `next/og`，但作者最终认为 Next.js 缺乏对开发者的尊重，并鼓励探索 Vite 生态系统中更注重开发者体验的工具。他们总结说，个人将优先考虑重视开发者体验的工具。
每日HackerNews RSS
## 凝视自我的持久魅力 古代生活即使为了最基本的事物也需要投入巨大的时间和精力，这与今天唾手可得的便利形成了鲜明对比。这种投入体现了古代文化所*珍视*的东西。一个引人注目的例子就是镜子——一个看似简单的愿望，却有着令人惊讶的复杂起源。 从公元前7000年安纳托利亚的抛光黑曜石，到青铜，最终到金属背面的玻璃，镜子自文明诞生以来就一直存在。早期的镜子提供的反射是模糊和扭曲的，但人们仍然花费数小时来制作它们，这表明了人类对自我呈现的基本需求。 镜子不仅仅是实用的；它们还具有宗教和文化意义。埃及人将镜子与女神哈托尔联系起来，而中国人则认为它们可以驱邪。然而，以纳西索斯神话闻名的希腊人，真正将镜子视为美丽和地位的象征，用精美的设计装饰它们——有时价格甚至可以达到嫁妆的价值。 尽管技术不完善，但*看到*自己、理解和呈现自己形象的愿望，在整个历史中始终存在，证明了它对创造力和足智多谋的强大推动力。
这段代码片段演示了一个使用Objective-C的基本iOS应用程序设置。`_main`函数通过创建`AppDelegate`类、将其注册到系统并启动`UIApplicationMain`事件循环来初始化应用程序。 `initAppDelegate`函数动态创建`AppDelegate`类，继承自`NSObject`并采纳`UIApplicationDelegate`协议。然后，它添加了`didFinishLaunchingWithOptions`方法，这是应用程序初始化的入口点。 在`didFinishLaunchingWithOptions`内部，代码获取主屏幕，获取其边界，创建一个`UIWindow`和一个`UIViewController`，将窗口的背景颜色设置为黄色，并将视图控制器设置为窗口的根视图控制器。最后，窗口被设置为关键窗口并显示，函数返回`YES`以指示初始化成功。这段代码大量使用了Objective-C消息传递(`_objc_msgSend`)和类/选择器操作。
Harbor的临床试验数据采集应用最初使用标准的React `useState` 和 `Context` 进行状态管理，但在处理代表复杂临床试验数据的深度嵌套组件树时遇到了性能问题。树中的一个状态更新会触发完全重新渲染，影响响应速度。
为了解决这个问题，Harbor采用了使用Jotai库的“原子状态”管理。Jotai允许开发者定义小的、独立的单位状态（“原子”），并且只有当这些特定原子发生变化时，才会重新渲染依赖于这些原子的组件。这与Context形成对比，Context中的更改通常会导致更广泛的重新渲染。
由于Jotai具有类似`useState`的API，因此过渡非常顺利。通过利用受控输入和原子状态，Harbor在显著提高性能的同时，保持了惯用的React代码，避免了完全受控或非受控输入方法的权衡。这使得能够提供响应迅速且性能良好的用户体验，这对于复杂的数据采集应用至关重要。最终，使用Jotai的原子状态在功能丰富性和实际规模性能之间取得了平衡。
使用原子状态来提升 React 在深度嵌套组件树中的性能 (runharbor.com)
10 分，由 18nleung 发表于 1 天前 | 隐藏 | 过去 | 收藏 | 1 条评论
JoeMattie 发表于 22 小时前 [–]
过去几年，我使用了一个非常相似的库 (valtio) 在几个相当大的项目中实现了这一点。实际上，我认为这两个状态管理库都是由同一个人编写的。回复
考虑申请 YC 2026 冬季批次！申请截止日期为 11 月 10 日
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
Example.fi 托管了一个基本的 IRC 服务器，以此致敬这项技术在在线通信领域的先驱作用。IRC 创建于 1988 年，是现代聊天和社交媒体发展的基础，它将人们连接在实时的文本对话中。
这个 IRC 服务器的独特之处在于它的实现方式：它使用 AWK 编写，AWK 是一种文本处理脚本语言，展示了 IRC 协议的适应性。虽然有意限制（大约 60 行代码！），但它既是一个教育工具，也是对 IRC 长期影响的致敬。
连接到 example.fi 的用户应避免使用高级 IRC 功能，并且可能需要使用特定设置（例如 Irssi 中的 `-nocap`），因为其实现经过简化。代码将在稍后公开发布。
## OS/2 Warp PowerPC 版：简短回顾
OS/2 Warp PowerPC 版（OS/2 PPC）于 1995 年 12 月发布，是 IBM 雄心勃勃但最终短暂的基于 PowerPC 的计算尝试。尽管经过多年的期待，但发布仅限于少数 IBM 客户，并且缺乏积极的营销，实际上结束了该平台上的 OS/2 开发。
OS/2 PPC 仅在 IBM 的 Personal Power 系列台式机以及可能的一些 ThinkPad 上运行，其硬件与当时的基于 Intel 的 PC 类似。虽然在技术上令人印象深刻，但该操作系统尚未完成，缺乏网络支持等关键功能，并且设备兼容性有限。
尽管存在缺陷，OS/2 PPC 仍然展示了相对于其 Intel 版本的进步，包括完整的 Unicode 支持、32 位控制台 API 以及令人惊讶的强大多媒体功能。它还基于 PC-DOS 7 提供了一个完整的 DOS 模拟器，并支持 Win-OS/2。然而，可用应用程序的缺乏以及不稳定的环境阻碍了其可用性。
最终，OS/2 PPC 是一个基于新颖微内核架构的有趣实验，但其有限的硬件支持、不完整的功能以及 PowerPC 平台的更广泛的挣扎导致了它的消亡。它仍然是 OS/2 历史中一个独特但很大程度上被遗忘的篇章。
## PowerPC 上的 OS/2 Warp：一段怀旧的回顾
最近 Hacker News 上的一场讨论围绕着 OS/2 Warp，特别是 2011 年的 PowerPC 版本展开。用户们回忆了 OS/2 的优点——稳定性、多任务处理能力以及强大的开发环境——并惋惜 IBM 未能完全支持和推广它。
许多人认为 OS/2 在当时在技术上优于 Windows，但最终还是因为微软在 OEM 销售中的主导地位以及围绕 Windows 构建的蓬勃发展的软件生态系统而失败了。一些人指出 IBM 自身的内部问题，认为他们并未完全致力于 OS/2 的成功，甚至在 90 年代中期更倾向于在自己的 PC 上使用 Windows。
对话还涉及到了那个时代的更广泛的技术格局，包括 RISC 与 CISC 的争论以及像苹果的 MacOS 这样的替代操作系统的潜力。最终，讨论强调了一个“如果……会怎样”的情景——如果 IBM 拥有更好的执行和营销，或者 PowerPC 在对抗英特尔的 x86 架构方面获得了更多进展，会怎么样。它也揭示了迷人的历史细节，例如微软通过演示和内部备忘录积极地诋毁 OS/2。
关于按住版权联系我们创作者广告开发者条款隐私政策和安全性YouTube 工作原理测试新功能© 2025 Google LLC
Hacker News 新闻 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
语音线圈比电机更好吗？[视频] (youtube.com)
11 分，surprisetalk 1 天前 | 隐藏 | 过去 | 收藏 | 1 条评论
hinkley 23 小时前 [–]
但它们比线性执行器更好吗？回复
考虑申请YC冬季2026批次！申请截止至11月10日
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请YC | 联系
搜索：
开发者史蒂夫·马克格拉夫（Steve Markgraf）在“Pico-100BASE-TX”项目中取得了重大进展，成功地在树莓派Pico上仅使用软件和RP2040/RP2350的可编程I/O (PIO)实现了100 Mbit/s快速以太网。该项目建立在先前成功的基础上，例如10 Mbit/s以太网和位敲击USB，利用PIO和DMA以125 MHz的速率进行复杂的编码和扰频。 这个仅发送的概念验证项目通过UDP实现了大约11 MB/s的速度，并通过实时音频和ADC数据流进行了演示。虽然需要隔离（脉冲变压器或开关）且不支持PoE，但该项目展示了将RP2040推向其预期能力之外的潜力。 这为低成本、高速数据采集和流式传输应用打开了大门，例如紧凑的测试仪器和远程传感器，所有这些都不需要专用的以太网PHY芯片。它引发了一个问题：在廉价的微控制器上，软件定义硬件可以被推到什么程度。
## 树莓派 Pico 通过位操作实现 100 Mbit/s 以太网
一个最近的项目展示了树莓派 Pico 的能力，它使用独特的可编程 I/O (PIO) 状态机实现了 100 Mbit/s 的以太网速度——本质上是“位操作”该协议。这突显了计算机历史中的一种反复出现的模式：从基于 CPU 的实现转向专用硬件，随着技术进步又回到 CPU。
这一讨论引发了对硬件优化周期性本质以及 Pico 创新的 PIO 的评论，PIO 允许在无需 FPGA 的情况下实现类似自定义硬件的行为。虽然这不是传统的以太网实现，但这项成就展示了 Pico 的强大功能，并为创建自定义 USB 以太网设备等可能性打开了大门。
用户们争论了鉴于 PIO 的专业性质，这是否符合真正的“位操作”定义，并将其与其他微控制器和 FPGA 设计中的类似方法进行了比较。该项目还引发了关于 Pico 强大 SDK 和示例代码的可用性的讨论，一些用户赞扬了它的文档，而另一些用户则希望有更多完整、可用于生产的周边设备实现。最终，这项成就强调了现代廉价微控制器中包含的令人印象深刻的功能。
## Crunchyroll 字幕质量下降：摘要
自2025年秋季番以来，Crunchyroll的字幕质量大幅下降，影响了第一方（Crunchyroll制作）和第三方字幕。Crunchyroll 过去以高质量排版——屏幕上文字的详细格式和定位——而闻名，现在提供的字幕却非常基础，通常是未翻译的文字堆积在屏幕顶部或底部。
这源于为了适应 Netflix 和 Amazon Prime Video 等通用流媒体服务的有限字幕标准，Crunchyroll 越来越多地将内容转授权给它们。为了符合要求，Crunchyroll 正在转向简化的 TTML 格式，放弃其更优秀的 ASS 系统以及创建该系统的专业人员。
历史上，Crunchyroll 利用粉丝字幕的专业知识和软件（Aegisub）来构建领先的字幕呈现效果。被索尼（Crunchyroll 的所有者）收购的 Funimation 一直提供质量较低的字幕。合并后，Funimation 的做法似乎正在影响 Crunchyroll 的决策。
这种变化是由削减成本和关注标准化驱动的，优先考虑股东价值而非用户体验。专家认为 Crunchyroll 可以通过混合方法来维持质量，但目前的趋势威胁着动漫爱好者的观看体验。
**为此，敦促观众取消订阅，提高认识，并要求 Crunchyroll 公开承诺恢复高质量的排版字幕。** 如果没有压力，这种下降趋势可能会持续。
更改你的显示名称。 这将是你对 kottke.org 发表评论时显示的名称；你的电子邮件不会公开显示。 我鼓励你使用你的真实姓名（或至少你的名字和姓氏首字母），但你也可以选择你在网上社区中使用的昵称。 选择一个持久且相对独特的名称（不要使用“Me”或“anon”）。 请不要频繁更改此名称。 禁止冒充他人。 注意：我允许大家更改显示名称，因为 kottke.org 使用的会员服务会收集全名，我担心有些人可能不希望在这里公开显示他们的姓名。 如果被滥用，我可能会禁用此功能。
黑客新闻新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交登录
太空探索Logo档案 (kottke.org)
21点 由 bookofjoe 1天前 | 隐藏 | 过去 | 收藏 | 3评论
gnabgib 1天前 | 下一个 [–]
原始来源：https://spaceexplorationlogoarchive.webflow.io
replyhealsdata 1天前 | 上一个 | 下一个 [–]
那个加拿大Logo很酷。
replyPanzerschrek 19小时前 | 上一个 [–]
Roskosmos的Logo不见了。
考虑申请YC冬季2026批次！申请截止至11月10日
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请YC | 联系
搜索：