本文作者TimBray是加拿大软件工程师，OpenTextCorporation和AntarcticaSystems的联合创始人，也是XML规范的主要作者之一（知名正如“XML之父”）所说）。从2004年到2010年，Bray担任SunCorporation的网络技术总监。此后加入谷歌担任开发者倡导者（DeveloperAdvocate），专注于Android和Identity。在这篇文章中，他分享了他对一些软件技术发展的一些看法。TimBray我们正处于构建软件的关键时刻。工具很好，服务器端的开发者很高兴，但是到了客户端软件，我们就真的不知道往哪里去了。未来的欢乐时光。构建的服务器端代码非常棒，谢谢。技术的扩展和完善将继续。一切都可以通过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，如果你最近听过AdrianCockcroft的演讲，你会惊讶于Netflix如何使用它。高手们都把磁盘当作一种新型的磁带，想方设法合理地使用它。另一方面......客户端混乱非常糟糕。你需要造三个轮子：Web、iOS、Android。我们缺乏人才，这种开发环境浪费并折磨着我们。移动端太差了。Android和iOS的具体区别这里就不赘述了。从工程的角度来看，这些差异并不是很大，但仍然存在以下不足之处：首先，您需要开发两个不同的客户端。更新周期很慢。与基于浏览器的App相比，在Android上需要几个小时，在iOS上需要几天。更糟糕的是，您不能指望移动用户收到您的所有更新。发现导致数据丢失和违反用户协议隐私条款的错误？足以让你痛苦。设备占用大量内存和CPU，功耗飙升。表单加载越来越慢，进度条需要等待。你没有编程语言的选择，如果你讨厌ObjC和Java，你需要考虑换工作。单元测试很糟糕。对用户好但对开发者不好的你，移动端对UX（用户体验）的要求很高，没有捷径，需要灵感和试错。正确的上网方式是点击浏览器上方的搜索栏，输入自己感兴趣的内容，点击搜索，点击结果链接，即可得到想要的信息。但无论你在移动设备上搜索什么，都需要安装相应的应用程序，这意味着移动应用商店中还有一层搜索，搜索结果的质量无法与谷歌或必应相提并论。你赚不到钱。说真的，Apple总是谈论他们在应用商店之外花费的数千。我还没有听说过有人从应用商店赚了很多钱。当然，HTML5的兴起恰逢其时，它告诉人们，如果人们开发移动Web应用，所有的缺点（尤其是第一个）都会被消除。但是……浏览器也很糟糕虽然这是一个陈词滥调的话题，但我不明白为什么它会引起如此大的争议。JavaScript不通的地方：>[5,10,1].sort();[1,10,5]上面还有很多例子。于是就有了像CoffeeScript、Dart这样的语言。他们都在想办法解决这些刻意回避的问题。浏览器API也很糟糕，所以人们都以jQuery（以及类似的库）作为底层库，在其之上进行编程，从而使JS成为了web时代的汇编语言。因此，在实际构建应用时，需要选择更高层次的框架。网上有很多这样的框架，搜索相关资料很容易，像这样：RichJavaScriptApplications–theSevenFrameworks(ThroneofJS,2012)。但这个信息已经是18个月前的事了，现在可能完全错了。你可能希望有更多的选择，但这会导致增长的“寒武纪大爆发”。我认为2113年的软件架构师会喜欢研究这些问题。（另请阅读：TeroPiirainen的FrameworklessJavaScript）CSS也很糟糕。我很想解释这一点，但已经有这篇文章：为什么是Sass？，所以我不必解释。另请查看：针对我提到的“寒武纪爆炸”问题，LessvsSassvsStylus？没有地方可以像应用商店那样按大小过滤应用。好吧好吧，我知道每一个以网络为中心的大型会议，那些眼睛闪闪发光、热情洋溢、真正的浏览器信徒都会向你展示HTML5有多酷。并且他们还可以使用带有麦克风的加速度传感器在移动设备上编写一个独特的APP。那么，为什么没有那么多人这样做呢？提示：请看上面列出的几点。我说的是“移动端不好”，不是表面工程软件不好；事实上，无论是CocoaTouch还是Androidappframework，都在GUI构建方面做得很好，吸取了很多历史教训。关键是，无论您想在UI中放置什么，都会有一个简单、符合标准且经过测试的方法，通常最终会成为Google和StackOverflow上的第一件事。但是看看在网络技术上付出的所有努力，它真的能跟上当今移动技术的进步吗？也许吧，也许那是谷歌和苹果的精英团队和世界上最优秀的GUI工程师筛选扩充后的结果。所以，我有点期待我稳步前进的时候。收入减少我是个老人，我还记得第一波Web应用程序出现的时间，席卷了用VisualBasic、Motif、Java、Win32编写的整整一代软件，只是因为人们更喜欢在浏览器中做所有事情.当然，过了15分钟，软件的VIP用户开始抱怨浏览器界面太笨重，响应不够灵活，我们只好另辟蹊径，我发现那些VIP客户都接受了私人计划B。所以现在我们有计划B，至少符合标准。但是，我仍然持怀疑态度。是的，我希望应用程序能够很好地响应手势，对象可以滑入和滑出，但这只是锦上添花，距离***还有很长的路要走，这就是80/20规则所说的-在服务器上设计良好的Web应用程序可以正常工作并保持良好的投资回报率。非常讨厌屏幕上四个独立的滚动区域，由JS滚动控制，看起来很差。稍后我会写一些很棒的单页应用程序，我故意缩进一些让它看起来有点不对劲。我特别讨厌有非技术的小伙伴，或者亲戚朋友遇到上面这些不好的情况，还得花时间解释为什么。下一个？服务器端没有任何意外，一切顺利，一如既往的好。而客户端，我什么都不知道。历史原因导致的复杂做法最终会被满足80/20法则的简单做法所取代。如果这是未来的方向，那不是来自我们的方向，这显然仍然让我们感到困惑。可能我们要处理这种一个client长期做三份的情况。原文链接：https://www.tbray.org/ongoing/When/201x/2014/01/01/Software-in-2014翻译链接：http://blog.jobbole.com/58671/
