HackerNews 热门故事摘要

最后更新时间: 2025-06-28 14:17 (北京时间)
第 4/10 页,共 10 条

Whitesmiths C compiler: One of the earliest commercial C compilers available

文章摘要

Whitesmiths C编译器是早期的商用C编译器之一,最初于1978年发布,支持与Unix第6版类似的C语言,且完全独立开发。1985年发布的3.0版本开始支持 emerging ANSI C标准。该编译器可为多种处理器生成代码,如DEC PDP-11、Intel 8080/Z80、8086、Motorola 68000、DEC VAX-11、IBM System/370和System/36,常被用作交叉编译器。公司总裁P.J. Plauger在2021年表示支持将编译器免费用于非商业用途。目前,该编译器的多个版本及其文档、源码和二进制文件已被整理并上传至公共存储库,供下载和使用。

评论摘要
主要讨论点:Whitesmith C编译器的历史、技术特点及其在早期编程中的应用 不同观点: • sizzzzlerz:分享了自己早期使用Whitesmith C编译器进行68000系统开发的经历,提到项目成功完成,但具体问题已不记得,只回忆起曾联系过Whitesmith公司解决一些问题,可能与P.J. Plauger直接交流过。 • kragen:称赞Plauger的书籍,并提到BDS C作为CP/M系统上另一个不错的选择,尽管其兼容性不佳。同时,讨论了开放源代码和自由软件的重要性,并希望Whitesmith的许可证问题能解决。还提到了现代硬件如RISC-V可能比8080更适合编程。 • ChrisMarshallNY:表示自己在职业生涯初期使用了Whitesmith的缩进风格,但对其来源不了解,只是习惯性使用。 • Rochus:关注Whitesmith C编译器支持的C语言版本、发布时间及其优化功能,提出了具体的技术问题。 • HocusLocus:提到了Turbo Pascal的编译速度和效率,认为其是早期编程语言中的佼佼者。 • jockm:希望Whitesmith的Unix克隆版Idris的源代码能被公开,认为其具有历史保存价值,并提到Idris可能是最早的Unix克隆。 • vaxman:详细描述了自己从使用FORTRAN、BLISS、MACRO和BASIC到转向C语言的经历,尤其提到在VAXcluster上使用Whitesmith C的挑战及后续转向其他C编译器的过程。 • mzs:提供了遵循Whitesmith缩进风格的代码示例链接,方便他人查看。 • ok123456:指引查看其他包含早期CP/M编程工具的代码库。 • b0a04gl:解释了文件布局作为接口的设计理念,描述了早期通过文件系统结构追踪源代码到二进制文件的流程。 • chubot:分享了来自lobsters网站的评论链接,指引收听关于Whitesmith和IDRIS的播客,提供了更多历史背景信息。 • secondcoming:提到在Windows头文件中见过Plauger的名字,对其人感到好奇。 补充讨论: • 争议焦点:Rochus对Whitesmith C编译器的具体技术细节如支持的C版本和优化功能提出了质疑,但未有明确答案。 • 其他值得注意的讨论点:包括对早期编程语言如Turbo Pascal的评价、对开放源代码和自由软件的讨论,以及对历史编程工具保存的关注。

Slightly better named character reference tokenization than Chrome, Safari, FF

文章摘要

本文介绍了一种针对HTML标记过程中的“命名字符引用状态”的优化数据结构实现。作者在没有参考主流浏览器引擎(如Blink、WebKit、Gecko)的情况下,自行设计了一个数据结构,并发现该实现相比Chrome、Safari和Firefox在效率、数据紧凑性和易用性方面具有优势。作者的方案使用了约60%的Chrome/Firefox数据大小,同时保持了至少相同的处理速度。文章还解释了命名字符引用的特性,它们以“&”开头,包含ASCII字符,区分大小写,通常以“;”结尾,并被转换为一个或两个代码点。由于HTML标准指出命名字符引用列表是固定的,不会再扩展,因此可以优化数据表示。作者最终展示了一种有效的数据结构,并指出仍有进一步优化的潜力。

评论摘要
主要讨论点:HTML5 命名字符实体的解析及其技术细节 不同观点: • **masfuerte 的观点**:指出文章中提到的 HTML5 示例有误。具体来说,提到 "¬in" 如果没有分号会被解析为 "¬in",而正确的是 "∉" 才会被解析为 "∉"。他引用了 HTML 规范的相关部分来支持其观点,强调了只有少数命名字符引用可以在没有分号的情况下使用。 • **deepdarkforest 的观点**:对文章作者的努力表示钦佩,认为撰写如此技术性强的内容需要很大的投入,并表示这种专注和承诺令人感到鼓舞。不过该评论没有涉及具体技术细节,更多是表达对文章撰写工作的赞赏。 • **Ndymium 的观点**:感谢文章让其意识到自己的 HTML 实体编解码库不支持省略分号的命名实体,并表示需要在即将到来的假期中进行修正和改进。这表明文章在实际开发中产生了影响,帮助开发者发现问题。 • **o11c 的观点**:从技术角度详细分析了文章内容,指出作者实际上重新发明了正则表达式的概念。o11c 讨论了 DFA(确定性有限自动机)和 DAFSA(有向无环有限状态自动机)之间的区别,强调在运行时没有区别,但在构建时有差异。他还提出了一些性能优化建议,如使用等价类来减少字符处理的开销,以及考虑在解析实体时采用“快速路径”的方法。此外,o11c 对二分查找和 SIMD 技术在优化中的应用也提供了见解。 补充讨论: • 争议焦点在于 HTML 命名实体在没有分号的情况下如何解析。masfuerte 指出了文章中的示例错误,并提供了规范中的依据,而文章原内容则未考虑这一细节。 • o11c 提供了大量关于如何优化 HTML 实体解析的技术建议,包括等价类、二分查找与线性搜索的对比、以及利用 CPU 缓存等方法。这些建议表明在实际应用中还有进一步优化的空间。 • Ndymium 的评论显示出文章对实际开发工作的帮助,指出了技术文章在开发者社区中的实用价值。

The Journey of Bypassing Ubuntu's Unprivileged Namespace Restriction

文章摘要

Ubuntu近期引入了一种新的沙盒机制,旨在通过AppArmor限制非特权命名空间以减少攻击面。尽管初期看似无懈可击,但研究发现该机制存在漏洞,可以被绕过。研究始于内核层分析,发现通过特定方法可以重新获取非特权命名空间的访问权限。尽管最初计划利用该绕过方法参加Pwn2Own 2025,但由于目标变更,Ubuntu被排除在比赛之外。随后,其他研究人员也公开了类似的绕过方法。在通过ZDI报告该问题未果后,直接联系Ubuntu安全团队,确认该问题仅影响特定配置,且已在后续版本中修复。此次合作体验积极,团队反应迅速且友好。

评论摘要
主要讨论点:研究者在披露漏洞信息时的挫折感及与漏洞披露平台(如ZDI)的沟通问题 不同观点: • throw290348190认为,作为研究者,看到各种绕过方法被公开披露,而自己的研究由于已经提交给ZDI无法分享,感到沮丧。他提到ZDI没有及时更新状态,且尝试通过邮件询问撤回提交的可能性。他还指出,security@$COMPANY.DOMAIN的邮箱经常被低质量的安全报告和钓鱼邮件淹没,这种情况随着LLM(大型语言模型)的普及变得更糟。他认为期待快速回应是不现实的,并暗示那些处理邮件的人工作负担很重。 • 0xbadcafebee同样表达了作为研究者在提交漏洞后由于未获得及时反馈而感到的沮丧,但他提到自己的情况因老板Orange Tsai的介入而得到缓解。他的老板帮助他分析了撤回提交的利弊,使他恢复了冷静,最终取消了撤回请求。他还分享了个人经验,建议在情绪化时将邮件放入草稿箱,第二天再查看,通常会进行编辑或删除。 补充讨论: • 争议的焦点在于研究者在漏洞披露过程中遇到的沟通延迟和情绪管理问题。throw290348190强调了平台和公司处理安全报告的效率问题,而0xbadcafebee则关注于个人在等待过程中的情绪调节和决策过程。 • 另一个值得注意的点是,随着LLM的普及,security@$COMPANY.DOMAIN邮箱中的垃圾报告和钓鱼邮件增多,这可能进一步加剧了处理有效安全报告的难度。 • 0xbadcafebee提供的具体建议(将情绪化的邮件放入草稿箱,第二天再查看)被作为一个有效的情绪管理策略提出,可能对其他研究者在类似情况下有所帮助。

Parameterized types in C using the new tag compatibility rule

文章摘要

C23引入了一个新规则,允许在不同翻译单元(TU)中定义的具有相同标签的`struct`、`union`和`enum`类型相互兼容。这一变化使得使用宏进行类型参数化成为可能。以前,每个定义在同一TU内的结构体被视为不同的类型,无法直接兼容。 新规则允许在函数内部定义与外部同名的结构体,并且它们现在被视为兼容类型。这为动态数组等数据结构的实现提供了新的可能性。例如,可以使用宏`Slice(T)`定义包含不同类型的切片结构体,而无需提前声明具体类型。 这种技术类似于C++模板,但仅限于类型参数化,不包括函数的参数化。例如,可以定义操作不同元素类型的切片函数,但无法轻松定义通用地图(Map)类型。此外,宏参数必须是标识符,限制了其便利性。 新规则还允许利用C23的其他特性,如`typeof`,以克服某些限制,如内存对齐问题。然而,这种方法也有局限性,不能直接定义包含复杂嵌套类型的结构体。

评论摘要
主要讨论点:C语言中泛型的实现及相关问题 不同观点: • [wsve] 认为C语言使用宏来模拟泛型不如直接在标准中加入模板特性,并建议如果C代码写得像C++,那不如直接使用C++,没有必要感到羞耻。 • [fuhsnn] 支持通过最近的#def #enddef提案来消除定义可读宏时反斜杠的需求,期待该特性被纳入C2Y标准。 • [JonChesterfield] 对宏的“hack”不感兴趣,但指出struct foo{}多次定义同一字段现在被视为同一事物而非未定义行为(UB),认为这是一个好的修正。 • [IAmLiterallyAB] 支持使用C++,认为可以写类似C风格的C++代码,并仅使用所需的功能,而不必完全转向C++。 • [Arnavion] 提到Zig语言的泛型实现方式,通过类型构造函数定义泛型类型,并给出具体例子,认为这是一种 neat 的方法。 • [uecker] 分享了一个实验性库和一些godbolt链接,以尝试实现泛型类型。 • [rwmj] 提出一个具体的技术问题,询问为何在cap和len类型中使用ptrdiff_t而不是size_t。 • [unwind] 认为这是一个有趣的变化,尽管作为多年C语言使用者,目前看不到太多使用场景,但相信这些特性是有价值的。 • [o11c] 关注的是C语言中`_Generic`的实现是否会有改进,认为手动进行一些模板操作并不是大问题,但`_Generic`的不完善导致项目失败。 • [tialaramex] 担心新的类型范式在C23中无法实现,尤其是当两个仅名字不同的类型被视为同一类型时,可能会导致逻辑问题。 • [Surac] 担心这一变化会让不严谨的代码更容易通过编译。 补充讨论: • 评论中涉及了对C语言引入泛型或模板特性的多种看法,一些人建议直接转向C++,而另一些人则在寻找C语言自身的改进方案。 • 对具体技术提案的讨论(如#def #enddef和struct定义修正)显示出社区对C标准未来发展的关注。 • 争议的焦点之一是C语言是否需要像C++那样的模板特性,以及现有`_Generic`特性的不足之处。 • 另一个值得注意的讨论点是泛型的具体实现方式,包括Zig语言的类型构造函数和实验性库的实现。

Alternative Layout System

文章摘要

本文介绍了几种用于排版和文字处理的脚本功能: 1. **Same Sizer**:使每个单词占用相同的水平空间,类似等宽字体效果。 2. **Wiggle Out**:旋转过长单词到页边距,并可调整曲线。 3. **Fill the Space**:填充行末到文本块末尾的空间,使用笔画、重复字母等。 4. **Hyphen Out**:合并连字符单词,将第二部分移到文本框外。 5. **Hyphenator**:通过缩小末尾字母避免单词断开。 6. **Last is First**:预览下一行首词,常见于希伯来手稿。 7. **Ext. Word & Letter**:扩展最后一个字母或单词,常用于圣经抄写。 8. **Variable Gradient**:在文本块中创建渐变效果,可按单词或字形应用。 这些脚本旨在提升排版的美观性和功能性。

评论摘要
主要讨论点:对"Same Sizer"及其他文字排版方式的看法和讨论 不同观点: • Demetrius认为"Same Sizer"的拉伸方式使每行的宽度不同,导致看起来不美观。他以越南书法为例,说明了在保持字符宽度一致的情况下进行排版的可能。 • Nick238指出在非字母语言(如英语)中,"Last is First"等方法会带来阅读困难,因为需要回溯理解字母在不同单词中的发音。 • Cjcenizal以一种反讽的语气表达了对"Same Sizer"的欣赏,认为这是一种“美丽的愚蠢”,给他带来了乐趣。 • Donatj分享了自己因眼疾问题,发现"Same Sizer"比标准文本更容易阅读,甚至认为这可以作为一种无障碍模式。 • Eddythompson80对"Hyphenator"布局提出建议,希望增加文本并缩小字体,以模仿手写笔记的方式。 补充讨论: • Philsnow将"Last is First"与格里高利圣咏中的custos符号进行类比,指出它们在视觉引导上的相似性。 • NackerHughes提到网页每几秒就重新加载的问题,认为非常烦人。 • Rsanek提到对boustrophedon书写的兴趣,认为这是一种优雅的解决长行文字排版问题的方法。 • RattlesnakeJake以一种矛盾的方式表达了对"Same Sizer"的喜爱,认为它既糟糕又迷人。 • Shreyarajpal提到在Devnagri文字中,文字是顶部对齐的,并建议可以尝试将罗马字母进行类似的处理。 • Gualdrapo推荐了"Imager"工具,并提供了链接。 • Groxx认为"Same Sizer"的排版方式与两端对齐的文本类似。 • B0a04gl从技术角度分析了这些排版方式如何打破字距规则,导致排版引擎需要处理非原生逻辑,从而影响排版效果。 • Gtr32x对作者频繁提到希伯来文的原因提出疑问,是否历史上的希伯来文本当中使用过这些方法。 • Igrom以简洁的方式指出这种设计风格与瑞士设计有关(暗示其简洁、功能性强的特点)。 争议焦点: • "Same Sizer"的美观性和可读性存在争议。一些人认为其拉伸方式不美观且不易读,而另一些人则认为它有趣、易读,甚至可以作为无障碍模式。 • 不同文字排版方式在不同语言和文字系统中的适用性,以及它们对阅读体验的影响。 其他值得注意的讨论点: • 对历史和文化中的其他排版方式(如越南书法、boustrophedon书写、希伯来文本)的提及和比较。 • 技术层面上,排版方式对字距和排版引擎的影响。 • 对网页技术问题的反馈和建议。

Glass nanostructures reflect nearly all visible light, challenging assumptions

文章摘要

新加坡科技设计大学(SUTD)的研究团队通过3D打印技术制造出具有近完美反射性的纳米玻璃结构,颠覆了传统光子学中对低折射率材料的认知。他们开发了一种名为Glass-Nano的光固化树脂,通过双光子光刻技术打印出纳米级精度的结构,并在加热过程中均匀收缩转化为清晰的玻璃。该团队成功制造出具有高度均匀性的钻石型光子晶体,在可见光谱范围内实现了接近100%的反射率,挑战了传统高折射率材料的主导地位。这一突破为玻璃在纳米光子学中的应用开辟了新途径,包括可穿戴光学设备、集成显示器和传感器等领域。研究结果与理论模拟高度吻合,展示了低折射率材料在光学应用中的巨大潜力。

评论摘要
主要讨论点:关于光子晶体技术及其创新应用的评论,以及对新闻来源可信度的质疑。 不同观点: • [xeonmc] 认为这篇新闻的核心技术是光子晶体,其基本原理是通过创造多个界面来增加光的反射机会,从而实现光的控制。他指出,新闻中的创新点在于使用前驱化学品和光刻技术来制造中空玻璃结构,使得界面成为玻璃与真空的对比,而不是玻璃与其他对比度较低的材料。这一技术类似于使太阳镜具有光泽的原理。 • [passwordoops] 对新闻来源表示怀疑,指出该文章是由“新加坡科技设计大学”撰写的,并质疑这是否属于付费公关内容。他认为这种做法可能比雇佣人员撰写低质量摘要更好,但仍然对其可信度表示担忧,同时提到这可能不如AI生成的总结那么糟糕。 补充讨论: • [xeonmc] 关注技术本身的原理和创新,强调了光子晶体技术在界面设计上的突破,并通过实际例子(太阳镜的反射)来支持其观点。 • [passwordoops] 则更关注新闻背后的动机和可信度,提出了对学术机构参与公关宣传的质疑,这涉及科学新闻的独立性和客观性问题。 争议焦点: • 焦点之一是对技术创新的理解和评价,一方关注技术本身及其应用潜力,另一方则质疑新闻来源的可靠性和动机。 • 另一个潜在的争议点在于学术机构是否应该参与付费公关宣传,这可能会影响科学新闻的中立性和质量。

PJ5 TTL CPU

文章摘要

文章主要描述了一个显示项目的进展和遇到的问题。作者成功在显示器上运行了生命游戏和Mandelbrot生成器两个程序,但发现当数据传输速度超过500KHz时会出现随机乱码和内存损坏问题,可能与长排线有关。为减少内存损坏,计算在2MIPS速度下进行,而写入显示器时则切换到较慢的500KIPS。作者还制作了第二套主板,并计划添加更多外围设备如操纵杆接口、声卡和真随机数生成器。 此外,作者提到因工作繁忙和芯片短缺,项目进度有所放缓。Jon改进了模拟器,提升了速度并增加了调试功能。作者个人正致力于64x64 256色显示器,并成功显示了一幅图像,尽管由于线路和面包板问题仍需改进。最后,作者完成了时钟板的修改,除一个需要时钟脉冲同步复位的功能外,其他均测试正常。

评论摘要
主要讨论点:选择使用CMOS还是TTL逻辑系列来构建CPU的优缺点 不同观点: • Kragen认为应该使用CMOS(如74HC和74AHCT系列)而不是TTL来构建CPU。他指出CMOS具有无限的扇出(fanout)、较小的地弹(ground bounce)、对称的驱动强度(symmetric drive strength)、低功耗以及对电源电压变化不敏感等优点。此外,CMOS更容易获得且多为表面贴装封装。他还提到,TTL兼容系列(如74AHCT)牺牲了CMOS的噪声容限优势,以换取与早已过时的TTL逻辑兼容性。 • 另一方(隐含的博客或其他人)可能建议使用TTL或TTL兼容系列,比如提到将HC系列替换为AHCT系列。Kragen对此提出了反对意见,认为TTL已经过时,且在现代项目中使用并不实际。 补充讨论: • Kragen提供了Digi-Key上的数据,显示目前仍有280个TTL离散门SKU在售,但许多旧的TTL部件(如74LS86)虽然有库存,却早已过时。与之对比,CMOS的SKU数量更多且更受欢迎,比如74LVC1G08。 • Kragen建议,如果要构建CPU,可以先从RTL仿真、FPGA或CPLD开始,逐步推进到离散逻辑设计,这样可以避免同时调试汇编器、RTL、时序和信号完整性等问题,使项目更具可管理性。 争议焦点:是否应该在现代项目中继续使用TTL逻辑以及TTL兼容系列(如74AHCT)的实际应用价值。Kragen明确表示TTL已经过时,CMOS在各方面都更具优势。

Show HN: Sink – Sync any directory with any device on your local network

文章摘要

Sink 是一个用于在本地网络上的两台 Windows 电脑之间同步目录的工具,无需云存储或外部设备。它能够自动发现网络中运行 Sink 的其他设备,并允许用户选择信任的设备进行连接。Sink 支持近实时同步文件变更,并在处理冲突时保存两份文件副本以防止数据丢失,这些副本存于 `.sink_conflicts` 文件夹中。用户可以通过创建 `.sinkignore` 文件来指定不希望同步的文件或文件夹,该文件的格式类似于 `.gitignore`。当前版本功能较为基础,未来计划增加用户界面、自定义路径、多设备支持等功能。使用时需安装依赖并运行 `main.py`,同步将发生在名为 `sync` 的文件夹中。

评论摘要
主要讨论点:新推出的文件同步工具与成熟工具Syncthing的对比,及其各自的优缺点 不同观点: • Dewey和Maweki认为Syncthing已经非常成熟,且支持跨互联网同步、具有用户界面,并可在所有包管理器中找到,因此新工具的卖点不明确。 • Poisonborz通过引用《辛普森一家》的片段幽默地暗示该新工具的宣传可能过于夸张。 • Daril提到使用Syncthing结合Cryptomator处理敏感文件,同时推荐了Localsend应用作为替代方案。 • MrGilbert分享了自己使用自托管的Tnxfr.com来快速在设备间发送文件的经验,强调其跨设备兼容性。 • Kinow提到通过Firefox的同步功能来解决设备间发送链接的问题,不再需要手动发送电子邮件。 • Neepi提出了一种完全不同的解决方案,即停止使用所有同步软件,将所有非主设备存放在柜子里,称之为“uninvention”(反发明),强调其简单可靠。 • Bilekas对项目的提交日志表示认同,反映出个人项目的思维流。 • Saaspirant误解了新工具的功能,以为是用于轻松记录想法的工具。 • Kunley和Bbno4直接指出新工具与Syncthing功能类似,甚至有“重新发明轮子”的嫌疑。 • Notpushkin对新工具提出了几点质疑:Linux用户可以轻松自行搭建类似系统、无法真正替代USB驱动器、缺乏盈利模式。 补充讨论: • 讨论中多次提到Syncthing的成熟度和高可用性,反映出用户对已有解决方案的满意度较高。 • 对新工具的盈利模式和市场定位存在一定质疑,特别是其是否能解决实际的连接问题以及是否具备商业可行性。 • 用户提出了多种替代方案和个人工作流,如使用FTP、Cryptomator、自托管服务等,展示了文件同步需求的多样性。 • Neepi的“uninvention”方案虽然极端,但引发了对简单可靠解决方案的思考。

Sailing the fjords like the Vikings yields unexpected insights

文章摘要

实验考古学家、瑞典隆德大学的Greer Jarrett过去三年乘坐着类似维京人的敞篷船,沿已知的维京贸易路线航行了超过5000公里。他通过实践研究,不仅深入了解了这些船只,还发现了挪威沿海的四个可能避风港,这些港口可能属于一个去中心化的网络,在维京时期的贸易和旅行中起到了关键作用。Jarrett使用的是19世纪和20世纪初的挪威传统船只复制品,虽然有同事批评时间跨度太大,但他认为造船技术的延续性使得这种类比是合理的。他的研究填补了维京航行历史中的一些空白,因为关于维京航海的直接史料非常稀少。

评论摘要
主要讨论点:考古学中的实验考古学方法,特别是通过维京式航海进行科学研究和筹资的可行性与意义。 不同观点: • [snowwrestler] 认为,这位考古学家通过筹资让人们支付他进行维京式航海的费用,展示了一种将非商业性学科(如考古学)博士学位商业化的方式。这种做法不仅能探索新的考古发现,还强调了学者需要像企业家一样寻找资金。 • [medstrom] 引用了Jarrett的描述,强调了维京船在海上的实际表现。虽然起初感觉船很脆弱,但在经历多次航行后,发现船在各种海况下都非常稳定,船员们也因此扩大了舒适区,并从中获得了乐趣。 • [kzrdude] 指出,Helge/Anne Ingstad通过类似的维京式航海帮助发现了L'Anse aux Meadows,认为这是类似的先例,应该被提及。 • [mlhpdx] 赞同实地实验的重要性,认为离开书桌去实践能提出不同的问题,并以自己即将驾驶Skerry帆船出航为例。 • [nsavage] 提到了HMS Terror的发现,指出当地因纽特人早已知道该船的位置,质疑官方宣布的发现是否真正具有新意。 • [Liquix] 以幽默方式提到科学家曾用冰冻粪便制作刀具进行实验,尽管结果不成功,但强调了实验考古学中的一些极端实验。 • [divbzero] 提到了NOVA的一集“This Old Pyramid”,通过实际建造金字塔来探索古埃及金字塔的建造方法,认为这是实验考古学的另一种应用。 • [vintermann] 认为,现代的这种维京式航海更像Jekt贸易者而不是真正的维京人,并指出有关Jekt贸易的英文资料很少。 • [zxexz] 讨论了考古学中关于尼安德特人烹饪方法的研究,指出一些被认为是新发现的结论其实在“原始生活”实践中早已为人所知。 补充讨论: • 争议焦点:对考古发现和新颖性的不同看法。例如,nsavage质疑HMS Terror发现的官方声明,认为当地因纽特人早已知道该船位置。 • 实验考古学的实际应用:不同评论提到了实验考古学在不同领域(如维京船航海、金字塔建造、尼安德特人烹饪)的实际应用和其带来的新问题与发现。 • 幽默与轻松评论:如Liquix的幽默评论虽然带有娱乐性质,但也提到了实验考古学中的一些极端实验。 以上总结展示了不同评论者对维京式航海及其在考古学中应用的多种看法和讨论角度。

The time is right for a DOM templating API

文章摘要

本文提议为Web平台添加声明式模板API。尽管DOM API使网页具有动态和表现力,但缺乏现代开发中重要的模板功能。当前没有简便的方法通过数据创建DOM节点、添加事件监听器、设置属性并防止XSS攻击,且高效更新。声明式模板是现代框架(如React、Vue、Angular等)的核心,因其在 ergonomics、安全性、性能、静态分析和服务器端渲染方面具有优势。 目前,Web应用需依赖外部库实现模板功能,导致应用下载时间长、不安全及开发复杂度增加。开发者需使用npm或CDN,增加入门成本。框架需自行实现模板功能,面临性能和尺寸的权衡。 现在添加模板功能的时机很好,历史上曾有类似提案(如E4X、E4H),但未实现。Web平台应适应开发者需求,像国际化、datetime API一样,加入声明式模板API,提升开发体验和应用性能。

评论摘要
主要讨论点:前端模板、语法及API设计的最佳实践和标准化问题 不同观点: • **taeric**:认为当前的模板语法并不理想,强调好的模板设计应更偏向视觉化工具,如Dreamweaver和Photoshop,而不是符号化的模板语言。同时,批评试图重新创造XSLT类似的方案,并指出处理非良好格式的内容和关联实体的困难。建议减少不必要的复杂布局设计,避免重复造轮子。 • **shermantanktop**:指出API/ABI并非一成不变,应用需求也会不断变化。任何新的模板提案可能只是暂时解决当前问题,但最终会成为需要绕过的旧技术,类似于DOM API和老版本浏览器的问题。建议将熵、扩展和向后兼容性作为主要考虑因素。 • **pier25**:支持原生模板、反应性和数据绑定,认为当前如React等框架浪费了大量CPU和带宽资源,原生支持将更高效。 • **llcooliovice**:认为在反应性领域仍有创新空间,如Ryan Carniato/Solid JS在信号(signals)方面的探索,表明用户空间的探索尚未结束。 • **jlukic**:强调该提案的作者在Web组件和DOM规范方面有丰富经验,增加提案的可信度。 • **vlucas**:建议先构建一些底层API,而不是试图统一模板系统。提出可以通过提供如`element.applyDiff`这样的API来实现高效的DOM diff应用。 • **segphault**:希望采用类似Kotlin的语法来实现通用DSL,而不仅仅是HTML模板,认为这样可以更广泛地应用于其他领域。 • **upghost**:认为声明式模板在复杂SPA中表现不如jQuery,更倾向于命令式控制DOM,因为声明式模板在共享可变状态时容易出问题。 • **notnullorvoid**:认为应聚焦于低层级功能,提供对高层级用户空间 abstractions 的支持,而不是急于标准化高层次特性。 • **aatd86**:质疑为何要在JavaScript上添加另一个DSL,认为函数足够应对需求,不应引入非正交的语言设计。 • **wavemode**:认为前端框架的多样性表明尚未找到最佳的抽象方式,标准化工作应更多关注JavaScript语言本身的改进。 补充讨论: • **llcooliovice** 提到 Records和Tuples提案的停滞与替代方案,以及`setHTML()`在现代浏览器中的实现,指出安全替代方案已存在。 • 讨论中多次提及Web Components的例子,说明其未成为普遍采用的基础技术,表明前端技术标准化的挑战。 争议焦点: • 是否应在浏览器中直接支持原生模板功能,还是应通过用户空间库来实现。 • 声明式模板与命令式DOM操作的优劣比较,特别是在复杂应用中的表现。 • 标准化高层次模板语法与专注低层级API改进的优先级争论。