For the average user this new kind of [Web] software will be easier, cheaper, more mobile, more reliable, and often more powerful than desktop software.
—— Hackers & Painters, The Other Way Ahead
The intended role for the Macintosh was as a client operat-ing system for nontechnical end users, implying a very low tolerance for interface complexity. Developers in the Macin-tosh culture became very, very good at designing simple interfaces.
—— The Art of UNIX Programming
我有个朋友最近忙着补救项目中走弯路浪费的时间。在项目早期，他们的 team 里有过一次大争论：UI 是全部采用 native 代码还是部分采用 Flash 。最终的结果是 Flash 一派占据了上风。理由是大客户相信 Flash 的『成功案例』。当然，像我朋友这样做过『消费者』应用的人认为所谓大客户的意见都是『企业开发』的狗屎。
事情的发展是，虽然 Flash 方案确实比 native 方案有更多开发便利（比如更方便的内存管理，更可靠的 exception 处理，以及从上一个『大客户企业方案』中继承下来的部分 code base ），但是在这个项目里反而拖累了开发进度。整个 UI 没法形成一个整体。在早期争论中被祭出的『大客户』也渐渐让位给习惯了 Apple 产品和 Photoshop 之类软件界面的挑剔消费者。走过一段弯路之后，整个项目重新回到纯 native 方案。
这让我回想起 2001 年前后，我的程序员生涯中最『惬意』的一段。因为客户很『 resonable 』，我可以经常告诉他们这个或者那个『没法做』。为什么呢？因为客户相信 Java ，他们的整个 IT 基础建立在 Java 上，他们要求我们用 Java 。所以，当你证明了 Java 不能做一件事情之后，你就证明了宇宙的最高法则。所以，是这些家伙自己放宽了自己的容忍度。
最近有一本 Paul Graham 的作品集《 Hackers & Painters 》在国内出版，网上讨论和引用很多，总体来说这是本不错的书。其中第二篇《 The Other Way Ahead 》把 Web 技术描述为软件开发未来的趋势。如果审视一下这个『未来的趋势』，我们会发现同样的问题。你想关闭某个文本框的拼写检查，而在另外一些文本框里打开吗？Web 做不到。如果你无意中按住鼠标拖过页面，划过的文字可以不被高亮选中吗？Web 做不到。希望你的『 Web app 』支持 undo/redo 的快捷键吗？Web 做不到。你的 Web app 可不可以有一个真正的『护栏』防止用户做某些从任何意义来说都不合时宜的操作而不是仅仅规劝或者提醒吗（比如点浏览器的 Back 键）？Web 做不到。 ⋯⋯ 当然，用户不会因此特别不满意。他们会说：这是个网站，有什么办法。我经常听到有 Web 开发者说：我们能掌控整个 server ，所以我们可以自由选择合适的高级语言来完成任务，而不像可怜的 native 应用开发者。他们错了，是用户放弃了对他们的应用的品质的要求，用户认为那是个网站。
作为单独 app 的 Google Earth 和作为『网页』的 Google Map 有什么不同？那就是下面这种处理网络延迟的情形在任何一个 app 的 beta 版里都是不能容忍的：
面对这些问题，乐观的 Web 开发者经常说『情况已经不是那样了』或者『马上就不是那样的』。是啊，从 canvas 这样的机制引入 HTML5 可以看出 Web 提高用户体验的努力（但是暂且别说 canvas 的支持目前有多么脆弱）。可是，用户中最挑剔的那部分的容忍度也是变化的。以 version control 这个程序员的工具来说，以前字符界面就很好，今天很多人在用矢量图界面来处理复杂的 branching ，也许明天就会有 3D 化的 UI 。软件的一个基本要求是根据用户操作改变界面的状态，比如在 Word 里改变一下行宽，或者在 PowerPoint 里修改阴影，或者按 Cmd+T 让 Firefox 创建一个新 tab ，用户一开始对这些变化没有过多要求，所以软件都是从上一个状态突变到下一个状态；然后，用户开始要求在状态变化中显示一些重要的中间态；今天，大多数变化都要求用平滑的动画显示。而 Web 技术在追赶这些不断收紧的容忍度时，其实已经失去了一部分作为『未来趋势』的优势。比如，所谓 watching users 的优势，只对于像 CGI 那样每个操作触发一次 client-server traffic 的应用才有用。为了追求用户体验而不断引入 client-side script 和 AJAX 的 Web ，在这方面早就慢慢和 native 应用拉平了。
回顾技术的发展，其实没有什么焕然一新的方案能够在不牺牲用户体验的前提下大幅度减轻程序员的工作。那些所谓的快速开发手段，只是用 PR 攻势来催眠用户放宽容忍度。这个是 cross-platform 。那个是『云』。用这些概念来降低用户的期待。当然不否认，某些技术提供了一些当时用户急需的便利，可以认为它们要求用户放宽容忍度的方式在一定期限内是合理的。关键在于，开发者往往看不到用户为便利付出的代价（而且常常是程序员独有的便利）。当一些开发者抱着用户和开发者都获得了『免费』便利的错觉时，这种技术就成了他们眼里『未来的方向』（这个词是我从《 Hackers & Painters – The Other Road Ahead 》某些段落的字里行间中读到的。当然《 Hackers & Painters – The Other Road Ahead 》这篇文章里有很多观点是建设性的，比如对软件演进和技术支持和对团队士气的看法。对 Web 过于乐观的态度，考虑到其写作的时间也情有可原。只能说，如果作者到今天还是这些观点，就略显自大了）。开发者要避免这种自大，要清楚自己和客户为了一个方案各自付出了什么，用户何时会失去容忍度。失去这种自知之明是某些 Web 时代的人面对 native 程序回归时表现出吃惊的原因。
技术奇异点 