观点：应该鼓励更多人开发小型浏览器

我认为应该有更多人去开发浏览器。

倒不一定是能和 Chrome 竞争、或试图包揽一切的浏览器。小浏览器、奇怪的浏览器，围绕某种特定的阅读、工作、研究方式，或者只是围绕在互联网上闲逛的某种方式而构建的浏览器。

juno，一个奇怪的浏览器。

关于浏览，大概还有不少好点子没人试过。倒不是因为它们不可能实现，而是因为“让人去做一个浏览器”这件事本身就相当不讲道理。

你当然需要能访问渲染引擎。但你还得处理引擎之上的那一堆东西：导航、配置文件、权限、下载、弹窗、会话恢复，以及网站和你的应用之间的安全边界。从一个“浏览应该是什么感觉”的想法，到能拿真实网站去试用它，中间隔着大量的工作。

这些工作对做通用浏览器的公司来说是值得的。但对一个只想弄清楚“换一种组织页面的方式是否有用、是否有趣”的人来说，就远没那么值得了。

我希望这段距离能更短一些。而我认为用 Electron 是一个合理的办法。

我不是从外部得出这个结论的。在此之前，我在 Surf 上工作过，那是一个基于 Electron 构建的研究型浏览器。围绕它的讨论，相当一部分归结为两点抱怨：Electron 太臃肿，或者基于它构建的浏览器不可能做到安全。这两个问题都问得有理，它们值得比“其实还好啦”更好的回答。这篇文章就是我尝试给出的回答，同时也是在描述：我希望下一个开发奇怪浏览器的人从什么开始。

人们谈论开发浏览器时，大部分讨论都偏向引擎。Chromium、Firefox、WebKit，以及为了让现代 Web 正常工作而投入的海量工程工作。

那是重要的工作，同时也是大多数试验浏览界面的人没有特别理由去重做的工作。

一个思想实验：假设你想让研究这件事不再那么像无休止地收集标签页。

你在读三篇关于同一主题的文章。你想从其中一篇里摘一段，也许保留出处，把它放在一条笔记旁边，明天再回到这整个安排。也许你的浏览器里有用的单位是研究项目，页面、文件和笔记都在一起。

或者你想要一个完全围绕键盘导航构建的浏览器。或者一个网站存在于空间画布上的浏览器。或者一个把浏览视为一串可以离开再回来的路径的浏览器。

这些都是对浏览体验的重大改变。但它们中没有一个必然需要改变 Chromium 渲染网站的方式。

在这个语境下，大部分有意思的工作都在引擎之上。问题在于，你仍然需要那些实验底下的机制。而把这套机制弄到可用的状态，可能会耗掉你本想花在那个点子上的大部分时间。

我认为这会影响我们最终得到什么样的浏览器。

当构建某样东西需要投入大量时间和资源时，你自然会对自己选择构建什么更加谨慎。你想要人们会使用它的证据。你想要一个可辨识的产品、一个说得通的受众，以及对工作会有回报的一些信心。

这些本能并不坏，它们是对昂贵开发的相当合理的反应。但有些想法在你真正用过之前很难评估。

你可能会发明一种新的页面组织方式，花一周时间与它相处，发现它很烦人，然后把其中一半扔掉。然后你可能会尝试完全不同的东西。当起步成本很低时，这种实验要容易得多。

我们已经看到，易用的开发工具能怎样改变软件的其他领域。游戏引擎让小团队能专注于他们想做的游戏，而不是先写一个渲染器（不一定喜欢现有的那些，但你明白意思）。

类似地，Web 框架让构建和丢弃应用想法变得可行，而不必每次都实现同样的基础设施（绝对不喜欢现有的那些）。

让某样东西更容易构建，并不保证人们会用它发明出美妙的东西。但它会改变谁能参与、能负担多少次实验，以及这些实验能有多不寻常。

我坚信浏览器会从更多这样的东西中受益。

Electron 有个可以理解的声誉问题。假设你在用它构建某样东西，对话可能在你解释清楚这东西是干什么之前就已经跑到内存占用上了。

其中一些批评是应得的。我用过不少桌面应用，它们似乎需要一个小型数据中心才能显示一个列表。我也希望我的电脑能留点内存和处理能力给我实际上在做的其他事情。

但浏览器恰恰是提出这种常见抱怨的特别有趣的地方！你打包了一整个浏览器引擎！是的。这在实现的某个地方总是会出现的。

如果你选择了 Chromium，Electron 给了你一种把它嵌进去、并用 Web 技术构建周边应用的方式。

渲染网站本来就是核心工作负载。HTML、CSS、JavaScript、网络、媒体，以及运行现代 Web 所需的机制，无论你怎么画标签栏，都会是应用的一部分。

Electron 还继承了 Chromium 的多进程架构。一个特权主进程管理应用及其渲染器。渲染器显示 Web 内容。在这个桌面应用框架之下，有一个可辨识的浏览器架构。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）