本文作者 Tim Bray 是一位加拿大软件工程师，也是 Open Text 公司和 Antarctica Systems 的联合创始人，也是 XML 规范的主要作者之一（有“XML之父”之称）。在2004年至2010年期间，Bray 担任 Sun 公司 Web 技术主管。此后加入 Google 担任开发者大使（Developer Advocate），专注 Android 和 Identity。他在这篇文章中分享他对部分软件技术发展的一些看法。
Tim Bray
我们正处在构建软件的关键期。工具完善，服务端的开发者们很高兴，但说到客户端软件时，我们真不知去向何方。
前段欢乐时光。构建起的服务端代码技艺精湛，感谢你们。技术的扩展与提炼将继续持续下去。
一切都地能够与HTTP通信，而做到这点是很简单的。
一切都由MVC及类似的抽象层构建，并且有许多框架帮我们清晰稳健地完成这项工作。很多人还在使用PHP或者Spring构建重要的应用不得不说是件遗憾的事情，虽然说这些新框架也没有强迫你使用它们。
我们仍在为选择动态类型和静态类型苦恼中。最后，妥协的理由却很好理解：两种语言之间都有好与坏。我两种都会使用，并且某些时候，使用的理由是显而易见的。请参见Bánffy-Bray 准则。
并发
函数式编程渐渐在主流语言界享有一席之地。而原因在于关注性能就一定会涉及并发的问题。而一般情况下，人无法处理大量（或者根本不能处理）并发的，极易改变的共享事务。
许多人喜爱Erlang，虽然它能很优雅地处理并发，甚至提供备用方案，但是它并不能大规模地用在生产中，因为它的数据类型和类概念与其他语言不同。
Clojure的并发基础是函数式的，高效且优雅。而Lisp式的语法则是缺陷（从经验上来说，如果你不能像我一样理解Lisp的妙不可言时），而Scala虽然比Java简单，并且有像模像样的Actor模型，仍然十分繁杂。
NodeJS本身不是函数式的，如果处理的一切都是事件，并且可以单线程的话，谁会在乎呢？但是我仍然在对Node的JS部分十分不满，待会儿再说明。
Go给我的印象深刻，虽然它采用了C、Java、Ruby、Clojure等语言的做法并不能使我开心一笑。我感觉它的类型系统提供了许多针对对象的实用工具，我强烈感到Goroutines和类型管道是非常出色的设计，开发者可以够顺利地写出函数式代码。这种做法容易，直接又可读性好，我考虑下一个重大项目的服务端代码使用Go语言编写。
如果上面的这些都不符合要求，我们还考虑使用这些由高手打造的Rust、Elixir、Dart等语言。
存储
现在各种持久化方案十分成熟。我己经很长时间不再在性能关键的运行时系统中使用关系型存储了；同时它仍有用武之地并有许多开源的选择。
这些关系型数据库之后出现的方案也足够完善。从轻量级的内存缓存到可以操作巨型数据的软件，都有对应的软件可供挑选。你可以看看Cassandra，如果你最近听过Adrian Cockcroft的演讲，知道Netfilx如何使用它的时候，你就会感到吃惊。
高手们都把磁盘当成新式磁带一样，找到合理地使用它的方式。
而另一方面……
客户端的混乱
情况十分糟糕。你需要造三遍轮子：Web、iOS、Android。我们缺乏人才，而这样的开发环境十分浪费，一直折磨着我们。
移动端太糟
此处略去Android和iOS的具体差异，在工程上来说，这些差异不是十分显著，但是，仍然有以下糟糕之处：
- 首先，你需要开发两种不同的客户端。
- 更新周期十分缓慢，以基于浏览器的App比较，Android上花的几个小时，放在iOS上就需要几天时间。更糟糕的是你并不能指望移动用户接收你的每次更新。发现了一个导致数据丢失，违反用户协议隐私条款的bug？足够让你吃尽苦头了。
- 设备非常吃内存、CPU，耗电量猛增。
- 表单的加载越来越慢，出现进度条需要等待。
- 你没有编程语言的选择权，如果你厌恶ObjC和Java的话，就需要考虑换工作了。
- 单元测试很操蛋。
- 有利于用户但不利于开发者的你而言，移动端对于UX（用户体验）的要求很高，没有捷径可寻，同时需要灵感涌现和反复尝试。
- 使用互联网的正确方式是点击浏览器上方的搜索栏，输入你感兴趣的内容，点击搜索，点击结果链接，就可以得到你想要的信息。但是无论你在移动设备上搜索什么，你都需要安装相应的应用，同时意味着在手机应用商店还有另外一层搜索，而搜索结果比不上Google或者Bing的质量。
- 你不能赚钱。严肃点来说，苹果总是谈论到他们在应用商店外花的成千上万的钱。我还没有听说过谁靠着应用商店正正经经地赚了许多的钱。
当然，HTML5热潮正当其时，告诉人们，如果人们开发的是移动Web应用的时候，所有的不利之处（尤其是第一条）就将消解。
但是……
浏览器同样很糟糕 虽然这是个老生常谈的话题，但是还是看不出为什么它如此充满争议。
-
JavaScript不可理喻之处：
> [5, 10, 1].sort(); [ 1, 10, 5 ]
- 以上的例子还有很多。所以就有了CoffeeScript和Dart这类语言。他们都在想办法解决这些刻意回避的问题。
浏览器的API也很糟糕，所以人们都基于jQuery（以及类似的库）看作在此之上编程的底层库，因此让JS变成了Web时代的汇编语言。
于是，在实际构造应用程序的时候，你就需要挑选更高层次的框架。网上有很多这样的框架，很容易就能搜索到相关的信息，像这个：Rich JavaScript Applications – the Seven Frameworks (Throne of JS, 2012)。但是这个已经是18个月前的信息了，放到现在可能完全是错误的。你可能会喜欢有更多选择，但是这样下去会造成“寒武纪大爆发”式的增长。我觉得2113年的软件架构师会喜欢研究这些问题的。
（同时，请阅读：Tero Piirainen的 Frameworkless JavaScript）
- CSS也很糟糕。我本想解释这一点，不过已经有这篇文章：Why Sass?，所以我不必这么做了。同时请查看：Less vs Sass vs Stylus，看看有没有我提到的“寒武纪大爆发”问题？
- 现在还没有可以像应用商店一样能筛选应用程序大小的地方。
好了好了，我知道每个以Web为中心的大型会议，那些眼睛闪耀光芒的，充满激情，真心相信浏览器的信徒们会向你展示HTML5的酷炫之处。而且他们也可以使用加速度传感器配合麦克风写出移动设备上的独特APP呢。
那，为什么没有那么多人这么做呢？提示：请看上面列出的几条观点。
我在说”移动端太糟“，不是表面工程软件的糟糕；而事实上，Cocoa Touch和Android app framework都在GUI构建方面做得很好，吸取了很多历史教训。关键是，你所想要放到UI上的东西，都会有一个简单的，符合标准并经过测试的方法，一般会成为Google和Stack Overflow网站上的第一条内容。
但是看看投入到Web技术的所有精力吧，它真的能跟上当今移动端的技术进步吗？也许吧，那或许是在Google和苹果的精英团队及世界上顶尖的GUI工程师对它进行一番筛选扩充以后的事情。所以，我有点期待稳扎稳打，一往无前的时刻了。
收益减少
我是个老古董，仍然记得第一波Web应用兴起的时候，横扫那些用Visual Basic、 Motif、Java、Win32编写的一整代软件，正是因为人们喜欢用浏览器处理所有的事务。
当然，15分钟后，软件的VIP用户们就开始诉说浏览器界面过于笨重，反应不够灵活，而我们得找到B方案，我发现那些VIP客户们都接受了私有的B方案。于是现在我们有了B方案，至少它符合标准。
但是，我仍然半信半疑。是的，我喜欢让应用良好地相应手势，物件有滑进淡出效果，但是那也只是锦上添花，离完美，也就是80/20法则所说的那样还很远——放在服务器上的良好设计的Web应用正常运行，并保持良好的投资回报率。我非常讨厌屏幕上四个独立滚动的，用JS控制滚动，看上去外观非常拙劣的区域。我稍后会写一些出色的单页应用，故意来一些缩进让它看上去有点偏。我尤其讨厌让非技术伙伴，或者亲友们遇到上面的糟糕情况，而我得花时间解释原委。
接下来？
服务端并无惊喜，诸事顺利，一切如往日美好。
而客户端，我什么也不知道。由历史原因造成纷繁复杂的做法最终会被那些简单的，满足80/20法则的做法所替代。如果这正是未来的方向的话，应该不是来自我们这个方向，显然现在仍然让我们困惑不已。或许我们还得长期应付这种一个客户端做三份的情况。
哈尔滨品用软件有限公司致力于为哈尔滨的中小企业制作大气、美观的优秀网站，并且能够搭建符合百度排名规范的网站基底，使您的网站无需额外费用，即可稳步提升排名至首页。欢迎体验最佳的哈尔滨网站建设。