## React vs. Remix：价值观的冲突 Bryan Cantrill 的观点认为，平台分歧源于不同的价值观，而非技术缺陷，这完美地阐述了 React 和 Remix 之间的分歧。最近的会议突显了这一点：React Conf 2025 展示了增量改进——React 19.2，一个强大的编译器——优先考虑 **复杂性即能力**，以最大化用户体验并保持 **稳定性和可组合性**。 相反，Remix Jam 揭示了 Remix 3 的激进转变，转向 **简洁性**，甚至不惜牺牲与 Remix 2 的向后兼容性。这意味着牺牲稳定性以换取显式控制，倾向于一种可追溯的、与 Web 平台对齐的方法，并具有像 `this.update()` 这样的功能来管理状态。 React 拥抱为开发者服务的复杂性，而 Remix 旨在通过开发者消除复杂性，并大量依赖标准的 Web API。这不仅仅是一个技术选择；Remix 将与 Web 平台的对齐视为内在的，而 Cantrill 认为这是一种有意的价值优先级。Remix 团队承认这种破坏——Remix 2 用户没有升级路径——但相信这种牺牲能够解锁一个更易于维护的未来。 最终，这种分歧迫使开发者做出基于价值观的决定：优先选择 React 的强大、复杂的生态系统，还是 Remix 的更简单、更注重 Web 的方法。两者都是有效的，反映了不同的优先级，并承认技术选择从根本上说是关于我们重视的东西。
每日HackerNews RSS
## React 与 Remix：分岔路口
最近 Hacker News 上的一场讨论集中在 React 和 Remix 之间不断演变的关系上，特别是 React Router v7（现在本质上是 Remix）。核心问题在于 Remix 愿意打破向后兼容性以追求新的架构理念，这一举动让一些开发者感到沮丧，这让他们想起了过去在 React Router 和 Angular 中的经历。
许多评论者表达了对持续升级和频繁重写 React Router 造成的的技术债务感到疲惫。他们质疑为什么开发者会选择一个具有破坏性变更历史的框架，尤其是在 TanStack Router、Vue 和 Svelte 等可行的替代方案存在的情况下。
这场争论凸显了一种哲学上的差异：React 旨在在框架*内部*实现复杂性，而 Remix 则将复杂性推到*外部*，提供更明确的控制。一些人认为这是向简化迈出的积极一步，而另一些人则认为它不直观。Shopify 收购 Remix 也在讨论之中，有人猜测这是为了防御 Next.js 不断增长的受欢迎程度。最终，这场对话表明人们渴望稳定性和优先考虑开发者体验而非不断创新的框架。
Durin 是一个用于读取和写入 Dwarf 调试格式的库。
Durin is a library for reading and writing the Dwarf debugging format
16 小时前
Durin 是一个用于读取和写入矮人调试格式的库。它的目标是支持：读取 ELF 和 MachO 目标文件中的 DWARF 5 编码信息。将 DWARF 5 信息写入 ELF 和 MachO 目标文件。将 DWARF 5 信息写入汇编文件。未来它可能支持 DWARF 4 或更新版本的 DWARF 标准。它应该提供：跨平台：durin 对您使用的目标文件类型不做任何假设。提供您自己的缓冲区或使用对象库。延迟：您可以迭代编译单元，而无需解析其内容。仅解析您迭代的调试信息条目 (DIE) 树。durin 还使用 DW_AT_sibling 引用，在可能的情况下避免解析 DIE 的子项以查找其下一个兄弟节点。要将 durin 作为依赖项安装，请运行：并将 durin 添加到您的项目的 dune-project 或 *.opam 文件中。文档在 ocaml.org 上。示例程序在 example 目录中。
## Durin：一个新的DWARF调试格式库
一个名为Durin的新库，使用OCaml编写，旨在读取和写入DWARF调试格式。作者创建它的目的是深入理解DWARF 5，支持OCaml编译器工具，并构建一个定制的OCaml调试器。虽然目前没有专注于性能——预计它会比`gimli-rs`等成熟的库慢——但Durin *完全* 支持DWARF 5，包括`gimli-rs`目前缺乏的`debug_info`部分。
开发正在进行中，当前的工作重点是读取支持、调用帧信息和DWARF表达式求值。作者对现有调试器在这些领域的工具表示不满。
讨论强调了DWARF令人惊讶的图灵完备性以及格式内存在各种求值器。分享的资源包括一本推荐的关于构建调试器的书以及一个关于DWARF格式潜在滥用的演讲。该项目目前正在进行中，尚未发布到OPAM，需要源码编译才能进行测试。
## Ghostty-web：浏览器中的真正VT100终端
Ghostty-web 使用 xterm.js API 为 Web 应用程序带来真正的 VT100 终端体验，不同于 xterm.js 这种 JavaScript 的*近似实现*。它利用相同的、经过实战检验的模拟器，为原生 Ghostty 应用程序提供支持，通过约 400KB 的 WASM 包实现，且没有任何运行时依赖。
最初为 Mux 应用程序开发，Ghostty-web 在 xterm.js 难以处理的方面表现出色——特别是对从右到左的语言、Devanagari 和阿拉伯语等复杂脚本的支持，以及对 XTPUSHSGR/XTPOPSGR 等功能的全面支持。
迁移很简单：将 `@xterm/xterm` 替换为 `ghostty-web`。可通过 `npx @ghostty-web/demo@next` 访问演示服务器。
Ghostty-web 使用 Zig 和 Bun 构建，目前正在修补 Ghostty 的源代码，但未来旨在利用原生 Ghostty WASM 分发版，同时保持与 xterm.js API 的兼容性。
## Ghostty-web：一个基于浏览器的终端模拟器
Kyle Carbs 将 Ghostty 终端模拟器编译为 WebAssembly (WASM)，并兼容 xterm.js API。这使得 Ghostty 能够直接在浏览器中运行，可能成为 xterm.js 的直接替代品。
该项目目前是一个概念验证，未来的目标是性能优化。初步反馈表明，利用 Ghostty 的新 RenderState API 进行增量更新，有可能实现显著的速度提升。
演示地址：[https://ghostty.ondis.co/](https://ghostty.ondis.co/)，源代码在 GitHub 上：[https://github.com/coder/ghostty-web](https://github.com/coder/ghostty-web)。开发者正在探索与 VS Code 等项目的集成，以及用于远程 shell 访问的工具。虽然目标是完全兼容 VT100，但网络演示中一些复杂脚本（如天城文）的问题正在调查中。
## 超越 JSON：为什么 API 要选择 Protocol Buffers (Protobuf)? 数十年以来，JSON 因其人类可读性、灵活性和广泛的工具支持，一直是 API 的主导数据格式。然而，许多开发者，包括作者本人，选择了一种更高效的替代方案：Protocol Buffers (Protobuf)。Protobuf 由 Google 于 2008 年开发，在性能和可维护性方面具有显著优势，尤其是在微服务等现代架构中。 Protobuf 依赖于定义的 `.proto` 文件来建立严格的数据结构契约，消除了 JSON 灵活特性中常见的歧义和潜在错误。该文件会生成各种语言（Dart、TypeScript、Go 等）的强类型代码，从而实现自动化验证并减少解析开销。 至关重要的是，Protobuf 是一种*二进制*格式，导致消息尺寸显著减小——示例中大约小 3 倍——从而实现更快的传输和减少带宽使用。虽然 JSON 易于检查，但 Protobuf 由于其二进制特性，需要专门的工具进行调试。 尽管通常与 gRPC 相关联，但 Protobuf 可以独立于传统的 HTTP API 使用。作者提倡 Protobuf 卓越的性能、健壮性和开发者体验，鼓励其他人考虑将其用于下一个项目。
## 为什么JSON仍然占据主导地位：总结
这次Hacker News讨论围绕一篇质疑JSON为何在Protocol Buffers (protobuf)等替代方案存在的情况下仍然占据主导地位的博文展开。尽管作者提倡protobuf的优势——强类型、效率和契约执行——评论者们强调了JSON持久的优势。
一个关键点是**人类可读性和易用性**。JSON的普遍性、缺乏依赖性和简单结构使其实现和调试快速。Protobuf虽然提供了性能提升，但引入了工具、版本控制和调试方面的复杂性。
许多评论者指出，现代JSON库（如Rust中的Serde或Python中的Pydantic）带有验证功能，解决了许多类型安全问题。其他人建议使用CBOR或更旧的格式如ASN.1等替代方案，但承认JSON的网络效应很难克服。
最终，共识倾向于**选择合适的工具**。Protobuf在高性能、内部系统中表现出色，在这些系统中性能至关重要。然而，对于许多项目，JSON的简单性和广泛支持仍然是更实用的选择，尤其是在考虑开发人员时间和可维护性时。讨论强调，优化“人力成本”通常比优化“机器成本”更重要。
供应链分析师郭明錤预测，苹果可能最早在2027年开始从英特尔采购其低端M系列芯片。这一潜在转变，由英特尔18AP芯片的保密协议和关键PDK套件的待交付情况表明，显著提高了英特尔成为苹果供应商的机会。 此举对两家公司都可能具有战略利益。对于苹果来说，它提供了一个展示对美国制造承诺的机会，可能迎合当前政府的政策。对于英特尔来说，这预示着潜在的转机和对其先进节点技术（如14A节点及更高版本）的需求增加。 然而，2027年的时间表取决于英特尔能否在2026年初成功交付必要的PDK更新，以及交付后顺利集成。这种合作关系可能会重塑苹果的供应链，并巩固英特尔在竞争激烈的芯片制造领域的地位。
## Ruby 是一种“严肃”的语言吗？辩护 关于 Ruby “严肃性”的争论，反映了人们对编程*应该*是什么样子的不同看法。Ruby 有意拒绝了令人愉悦的开发体验等同于缺乏严谨性的观点。它作为对令人望而却步的编码文化的顽皮反叛而出现，优先考虑清晰和乐趣，使编程对初学者和经验丰富的开发者都易于上手。 批评者经常指出像 Twitter 已经超出 Ruby 的能力这样的例子，但作者认为这不是失败——而是*成功*，证明了 Ruby 促进快速增长的能力。许多公司，包括 Shopify、Doximity 和 GitHub，都*使用* Ruby 建立了非常成功的平台，证明了它的能力。 Ruby 的核心优势在于它的文化：吸引重视代码可读性和人道工作环境的开发者。在未来，人工智能日益普及且普遍面临倦怠的情况下，这些价值观——可读性、可维护性和乐趣——将至关重要。最终，作者认为，“严肃性”并不能保证成功；共鸣、清晰和人际连接才能。Ruby 不试图说服任何人，但它为软件开发的未来提供了一个有价值的视角。
## Hacker News 讨论：Ruby 是一种“严肃”的语言吗？
一篇质疑 Ruby 是否“严肃”的文章在 Hacker News 上引发了争论。一些人同意 Ruby 不是他们的首选——引用了过去在依赖管理和扩展方面的问题——但许多人认为它是一种有价值且令人愉悦的语言。
讨论的核心在于如何定义一种“严肃”的语言。一些人认为应该使用客观指标，如代码质量和可扩展性，而另一些人则强调开发者体验和表达能力的重要性。 许多评论者强调 Ruby 专注于人类可读性和编程的乐趣，与优先考虑严格性或性能的语言形成对比。
有人对 Rails 的影响表示担忧，认为它的滥用损害了 Ruby 的声誉。 另一些人指出，Ruby 在特定的领域（如系统自动化）表现出色，但未能跟上更新的工具。 最终，似乎达成共识是 Ruby 的价值取决于项目和开发者——它“严肃”的程度取决于你的需求。 许多人承认它的优点，同时也认识到它在某些环境中的局限性。
就业市场驱动住房需求，但就业类型的变化会影响住房类型。高收入行业——信息、专业服务和金融活动——在大多数主要都市区都在萎缩。这些行业的工人对购买型住房的需求高于租赁型住房的需求。全国范围内，8月份高收入行业的就业人数同比持平，远低于其长期复合年增长率+1.6%。教育和医疗保健行业贡献了大多数都市区新增就业岗位，并且几乎在所有市场中增长速度都高于正常水平。这些工作中的许多平均工资较低，并且通常会产生比购房活动更多的租赁需求。全国范围内，8月份教育和医疗保健行业的就业人数同比增长+3.3%，远高于其长期复合年增长率+2.1%。
## 住房需求降温，高收入就业岗位流失
一则Hacker News讨论指出，住房市场正在降温，这与近期高收入就业岗位的流失有关，尤其是在科技行业。用户报告显示，租金下降（降低100-500美元/月，并有优惠），房屋在市场上停留时间更长，降价现象普遍。然而，人们仍然担心这种趋势是暂时的，原因包括新的涨租算法（如RealPage）以及由于资源向人工智能数据中心转移而导致的住房建设停滞。
这场讨论引发了关于租金控制的争论，一些人认为租金控制会抑制新建设，而另一些人则认为这是对抗算法涨租的必要保护。一个关键点是难以准确评估住房趋势，以及地方法规（如NIMBY主义）对供应的影响。
许多评论员指出了一种“K型”经济，即高端住房仍然强劲，而更实惠的住房则面临困境。还有关于更广泛的经济趋势的讨论，包括潜在的经济衰退指标以及人工智能对就业市场的影响，一些人建议需要采取更谨慎的投资策略。
Runway，一家小型人工智能初创公司，发布了Gen 4.5，这是一款新的文本到视频模型，目前在Video Arena排行榜的独立基准测试中表现优于谷歌的Veo 3和OpenAI的Sora 2 Pro。Gen 4.5擅长根据文本提示生成高清视频，展现了对物理、运动和因果关系的深刻理解。 Runway的首席执行官Cristóbal Valenzuela将他们的成功——与拥有万亿美元规模的公司竞争，而团队只有100人——归功于专注的研究和勤奋。该公司成立于2018年，致力于构建用于视频创作的人工智能模型，估值35.5亿美元。 Gen 4.5，绰号“David”，正在向Runway多元化的客户群（包括媒体、工作室和创意人员）推出，并将通过他们的平台、API和合作伙伴提供访问。Runway计划进一步发布重大版本，旨在将人工智能开发民主化，使其超越少数主导企业。
Runway 发布新的 AI 视频模型，在关键基准测试中超越 Google 和 OpenAI (cnbc.com)
10 分，tiahura 发表于 9 小时前 | 隐藏 | 过去 | 收藏 | 3 条评论
https://runwayml.com/research/introducing-runway-gen-4.5
xnx 发表于 8 小时前 | 下一个 [–]
这是新闻稿垃圾信息。 最好链接到公告：https://runwayml.com/research/introducing-runway-gen-4.5 回复
xnx 发表于 8 小时前 | 上一个 | 下一个 [–]
重复：https://news.ycombinator.com/item?id=46108123 回复
QuercusMax 发表于 8 小时前 | 上一个 [–]
唉，我们需要的正是更好用的假视频。回复
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
## 脾气字体的概要
脾气字体是一种等宽位图字体，提供六种尺寸（5x8 到 32x64），设计灵感源自波德莱尔。它以多种格式分发——BDF、PCF、PSF、OTB、OTF、.dfont 和 FON——以兼容 Linux、macOS、Windows，甚至 DOS。
较大的尺寸（8x16、16x32、32x64）完全支持代码页 437，而所有尺寸（除 5x8 和最初的 6x12 之外）都包含广泛的 Unicode 字符集，如 ISO/IEC 8859-1、拉丁扩展-A、框绘制和盲文。5x8 版本仅限于基本的 ASCII 和盲文。最近的版本在 6x12 尺寸中添加了拉丁-1 补充，并支持 Powerline 符号。
安装方式因操作系统而异，通常涉及字体路径更新和配置。虽然提供 OpenType (OTF) 版本，但在支持的情况下，首选位图版本。脾气字体是开源的（BSD 2 条款许可），值得注意的是，它是 OpenBSD 的默认控制台字体，并已集成到其他项目中，如 FreeBSD、Haiku 和各种嵌入式库。
一个新的位图字体“Spleen Monospaced”已在GitHub上发布，并在Hacker News上讨论。值得注意的是，它是OpenBSD (x86-64)的默认控制台字体。
讨论的重点是该字体不寻常的字符形状——有些人觉得像'C'和'S'这样的字母的矩形形式在较大尺寸下不美观，而另一些人则注意到备用字形的阅读问题。该字体设计的一个关键方面是它受到“throw-up”涂鸦字体的启发，这种风格在盗版社区很流行，甚至在维基百科上以“spleen”一词作为例子。
用户分享了更好的观看技巧，例如调整GitHub等平台上的行距。这次对话突出了字体设计的 субъективность 以及其背后的有趣的文化影响。
印度要求智能手机制造商预装国有的网络安全应用程序。
India orders smartphone makers to preload state-owned cyber safety app
17 小时前
请启用 JavaScript 并禁用任何广告拦截器。