[译]web浏览器是否应该坚持成为文档查看器？

原文 Alan Kay 对 Should web browsers have stuck to being document viewers? 的回答 。

web 浏览器是否应该坚持成为文档查看器？

Alan Kay 的回答如下:

恰恰相反，如果 “文档” 意味着模仿旧的静态文本媒介(媒体)（也包括后来的图片、音频和视频记录）。

正因为愿意满足于过份简单的文本格式和格式化方案(“为了方便”), 使得 web 媒介架构开始朝完全错误的方向发展（包括过于简单的参考方案，参见 Doug Engelbart 和 Ted Nelson）。大约在 90 年代初，它具有返祖 hack 的外观和感觉。我预计网景(Netscape)会解决这个问题，而不仅仅是试图主导现有的东西（我期望有一个更好的架构，适用于 “在计算时代思考媒介”，不像 “一个应用程序”，而更像一个操作系统，以处理全球互联网进行中的实际系统要求、需求和规模）。

让人们(尤其是计算机专家)批评 web 和 web 浏览器, 既令人惊讶又令人沮丧, 在今天更是如此。

尽管有一个明显的事实: web 和浏览器所提供的交互媒介， 一直是运行 web 浏览器的个人电脑上的媒介的一个重要的、有质量的子集。

在 WWW 成立之初(90 年代初) 我提出了几个建议，既是对苹果公司(我的研究小组所在的公司)的建议，也是总体上对该领域的建议。这些建议部分是基于互联网开始扩展到的范围和规模:

1. 苹果公司的 Hypercard 是个出色且成功的终端用户创作系统，它的媒介是脚本化的、所见即所得的，而且是 “对称的”（在这个意义上，“读者” 可以反过来以同样的高级术语和形式进行 “创作”）。它应该是接触和处理 web 内容的 “用户体验” 的开始和指南。

2. 浏览器的底层系统不应该是一个 “应用程序”，而应该是一个操作系统，其工作是保护和安全地运行从 web 上获得的封装系统（即 “真实对象”）。web 内容应该始终开放，而不是被束缚在浏览器的功能子集上。

我指出, 与 Macintosh 本身一样，这两项建议，似乎有些不一致，必须加以调和。第一个建议是关于 Macintosh 用户体验的优秀 “指南” 的下一阶段（Chris Espinosa 和其他人从未因这项重要工作而受到应得的赞誉）。这些 “指南” 规定了任何功能的应用程序都要遵循的惯例: 它们是必须相似的部分。

第二个建议是加强这样的想法：在系统中运行的内容必须尽可能不受操作系统工具的影响（因为特殊的需求往往需要特殊的设计等）。一个例子是，如有必要，内容应当能够在必要时生成自己的图形（即使操作系统提供了一些图形工具）。内容越想走自己的路，它向用户的呈现就越必须符合(1)中的标准。就像任何像样的操作系统一样，它必须允许新的想法，同时也要提供安全、高效的资源，并显现出用户体验。

如果我们仔细研究这两方面的一些含义，可以从过去找到一些好的原则。其中的一个真正原则，追溯到贝尔实验室的第一批 Unix 系统。该设计在一定程度上是对 MIT Multics OS 极其复杂的组织的反应。早期 Unix 的一个伟大认识是，操作系统的内核 – 基本上是唯一应该处于 “监督者模式” 的部分，它只管理时间（交错计算的量）和空间（内存分配和级别）以及封装（进程），其他一切都应该在系统的普通进程中表达。操作系统附带的资源可以提供更多功能，但是当需要时，这些资源应该很容易被开发者的进程所取代。

最初的想法是，在不锁定一个大型操作系统的情况下，尽可能多地推动进步，但要保护需要保护的东西，并确保系统完整性和可靠性的阈值。

注：也许 Unix 最好的早期结构和下一阶段设计是 80 年代初 Gerry Popek 和他在加州大学洛杉矶分校的研究人员的 Locus。Locus 允许活的 Unix 进程不仅可以从一台机器迁移到网络上的另一台机器，而且可以迁移到各种类型的机器上。这是通过将中断所需的安全性与每个进程中的多个代码钩子相结合来完成的，因此“中断”可以允许将进程移动到不同的机器并使用不同的（等效）代码恢复。很容易看出，将其与终端用户语言相结合，可以提供一个在整个互联网上兼容运行的网络系统。1984 年到苹果公司后不久，我试图让他们购买 Locus，但当时的 “当权者” 看不到这点。

请注意，当这样一个系统被做成交互式的时候（例如使用来自 ARPA/Parc 研究团体的全面想法），最终用户需要有一个在所有应用程序上尽可能通用的用户界面框架，这可能与新想法(通常也是新功能)所需的自由相冲突。

所以这是一个重要、庞大而困难的设计问题。

我对 web 和 web 浏览器的抱怨是, 它们的考虑和实施多么糟糕，web 内容的功能多么薄弱，向前推进并尽可能多地修正最关键的错误的手段多么薄弱。

看待事情发展到今天的一种方式是，互联网的环境迫使 web 浏览器越来越像操作系统，但没有所需的设计和前瞻性。

1. 现在有大量的内部和外部的惯例，其中一些需要动态语言，也确实使用了它。然而，无论是这种架构还是语言的形式，或是人们如何进入语言的形式等等，都没有为终端用户进行合理规划。与需求和可能性相比，这些门槛是可笑的。

2. 现在有一种设计得非常糟糕的操作系统，它是非封装式的 Web 内容的 “功能” 的组织者和提供者。这是一场锁定的灾难，实际上几乎没有什么回报。

这一切都是在对 web 体验和权力应该是什么样子有了更好的概念之后才完成的。它看起来像 “不断发展的 hack”，部分原因是大多数用户和开发者对它所做的事情感到满意，并且不知道它应该做什么（尤其是全球计算机媒介的更大命运）。

为了尝试回答这个问题，让我用 60 年代初的 “Licklider 的愿景”：“计算机的命运是成为全人类普遍联网的交互式智识放大器”。

如果你只是试图模仿旧媒介，考虑到旧媒介难以编排和编辑的特性，这是不可行的。你必须包含计算机可以产生的所有媒介，而且必须允许所有用户 “阅读” 、“写作” 以及 “文学等价物”。

在 web 和 web 浏览器出现之前，就已经有了一些这样的例子，现在的情况是，一个极其薄弱的子集成功支配了大多数人（包括计算机人员）的想象力，以至于就所有的目的而言，什么是可能的，什么是需要的，已经消失了。

关于 “Parc 不断扩大的需求” 的脚注（由 Phillip Remaker 的评论和问题引发）
当 Gary Starkweather 发明的第一台激光打印机以惊人的速度（每秒一页，每英寸 500 个像素）运行时，有人推动在联网的 Altos（以太网就是为此而发明的）上使用这种打印机。这个想法是把 Alto 作为一个服务器，可以设置和运行激光打印机来快速打印高质量的文档。
Parc 的几位最优秀的图形人员为如何将文件发送到打印机创造了一个优秀的 “打印标准”。这个数据结构在打印机端被解析，并按照它来设置打印。
但就在这之后的几周，更多的文件要求浮出水面，随之而来的是更多的打印要求。
这导致了一个 “悲伤认识”: 如果发送方需要的自由度很大，那么向服务器发送数据结构是一个糟糕的主意。
最终，这导致了一个 “愉快认识”: 如果发送方需要的自由度很大，那么将程序发送到服务器是一个非常好的主意。 John Warnock 和 Martin Newell 正在试验一种简单灵活的语言，这种语言可以表达任意独立于分辨率的图像(称为 “JAM”，代表 “John And Martin” ）, 他们意识到，发送 JAM 程序，即 “真实物体 “到打印机是一个比发送数据结构更好的主意。
这是因为通用解释器不仅可以相当小，而且可以比任何数据结构（不是一个程序）有更多的自由度。程序必须在打印机的一个受保护的地址空间内运行，但程序可以被授权访问一个位缓冲区，无论程序对位缓冲区做什么都可以 “盲目” 地打印出来。
这为桌面出版系统（它希望在任何可用的打印机上打印，并且不必知道它们的分辨率和其他属性）和打印机（它不应该知道关于制作文档的应用程序的任何信息）之间提供了更好的匹配。
“JAM” 最终变成了 Postscript（这是另一个故事）。
关键点：“发送一个程序，而不是一个数据结构” 是一个非常大的想法（如果在程序的设置上花些心思的话，也会有很好的扩展性）。