本文作者 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不可理喻之處：
12> [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法則的做法所替代。如果這正是未來的方向的話，應該不是來自我們這個方向，顯然現在仍然讓我們困惑不已。或許我們還得長期應付這種一個客戶端做三份的情況。