本文作者  Tim Bray 是一位加拿大軟件工程師，也是 Open Text 公司和 Antarctica Systems 的聯(lián)合創(chuàng)始人，也是 XML 規(guī)范的主要作者之一（有“XML之父”之稱）。在2004年至2010年期間，Bray 擔(dān)任 Sun 公司 Web 技術(shù)主管。此后加入 Google 擔(dān)任開發(fā)者大使（Developer Advocate），專注 Android 和 Identity。他在這篇文章中分享他對部分軟件技術(shù)發(fā)展的一些看法。

Tim Bray

Tim Bray

　　我們正處在構(gòu)建軟件的關(guān)鍵期。工具完善，服務(wù)端的開發(fā)者們很高興，但說到客戶端軟件時，我們真不知去向何方。

　　前段歡樂時光。構(gòu)建起的服務(wù)端代碼技藝精湛，感謝你們。技術(shù)的擴(kuò)展與提煉將繼續(xù)持續(xù)下去。

　　一切都地能夠與HTTP通信，而做到這點是很簡單的。

　　一切都由MVC及類似的抽象層構(gòu)建，并且有許多框架幫我們清晰穩(wěn)健地完成這項工作。很多人還在使用PHP或者Spring構(gòu)建重要的應(yīng)用不得不說是件遺憾的事情，雖然說這些新框架也沒有強(qiáng)迫你使用它們。

　　我們?nèi)栽跒檫x擇動態(tài)類型和靜態(tài)類型苦惱中。最后，妥協(xié)的理由卻很好理解：兩種語言之間都有好與壞。我兩種都會使用，并且某些時候，使用的理由是顯而易見的。請參見Bánffy-Bray 準(zhǔn)則。

　　并發(fā)

　　函數(shù)式編程漸漸在主流語言界享有一席之地。而原因在于關(guān)注性能就一定會涉及并發(fā)的問題。而一般情況下，人無法處理大量（或者根本不能處理）并發(fā)的，極易改變的共享事務(wù)。

　　許多人喜愛Erlang，雖然它能很優(yōu)雅地處理并發(fā)，甚至提供備用方案，但是它并不能大規(guī)模地用在生產(chǎn)中，因為它的數(shù)據(jù)類型和類概念與其他語言不同。

　　Clojure的并發(fā)基礎(chǔ)是函數(shù)式的，高效且優(yōu)雅。而Lisp式的語法則是缺陷（從經(jīng)驗上來說，如果你不能像我一樣理解Lisp的妙不可言時），而Scala雖然比Java簡單，并且有像模像樣的Actor模型，仍然十分繁雜。

　　NodeJS本身不是函數(shù)式的，如果處理的一切都是事件，并且可以單線程的話，誰會在乎呢？但是我仍然在對Node的JS部分十分不滿，待會兒再說明。

　　Go給我的印象深刻，雖然它采用了C、Java、Ruby、Clojure等語言的做法并不能使我開心一笑。我感覺它的類型系統(tǒng)提供了許多針對對象的實用工具，我強(qiáng)烈感到Goroutines和類型管道是非常出色的設(shè)計，開發(fā)者可以夠順利地寫出函數(shù)式代碼。這種做法容易，直接又可讀性好，我考慮下一個重大項目的服務(wù)端代碼使用Go語言編寫。

　　如果上面的這些都不符合要求，我們還考慮使用這些由高手打造的Rust、Elixir、Dart等語言。

　　存儲

　　現(xiàn)在各種持久化方案十分成熟。我己經(jīng)很長時間不再在性能關(guān)鍵的運(yùn)行時系統(tǒng)中使用關(guān)系型存儲了；同時它仍有用武之地并有許多開源的選擇。

　　這些關(guān)系型數(shù)據(jù)庫之后出現(xiàn)的方案也足夠完善。從輕量級的內(nèi)存緩存到可以操作巨型數(shù)據(jù)的軟件，都有對應(yīng)的軟件可供挑選。你可以看看Cassandra，如果你最近聽過Adrian Cockcroft的演講，知道Netfilx如何使用它的時候，你就會感到吃驚。

　　高手們都把磁盤當(dāng)成新式磁帶一樣，找到合理地使用它的方式。

　　而另一方面……

　　客戶端的混亂

　　情況十分糟糕。你需要造三遍輪子：Web、iOS、Android。我們?nèi)狈θ瞬?，而這樣的開發(fā)環(huán)境十分浪費(fèi)，一直折磨著我們。

　　移動端太糟

　　此處略去Android和iOS的具體差異，在工程上來說，這些差異不是十分顯著，但是，仍然有以下糟糕之處：

　　當(dāng)然，HTML5熱潮正當(dāng)其時，告訴人們，如果人們開發(fā)的是移動Web應(yīng)用的時候，所有的不利之處（尤其是第一條）就將消解。

　　但是……

　　瀏覽器同樣很糟糕 雖然這是個老生常談的話題，但是還是看不出為什么它如此充滿爭議。

　　瀏覽器的API也很糟糕，所以人們都基于jQuery（以及類似的庫）看作在此之上編程的底層庫，因此讓JS變成了Web時代的匯編語言。

　　于是，在實際構(gòu)造應(yīng)用程序的時候，你就需要挑選更高層次的框架。網(wǎng)上有很多這樣的框架，很容易就能搜索到相關(guān)的信息，像這個：Rich JavaScript Applications – the Seven Frameworks (Throne of JS, 2012)。但是這個已經(jīng)是18個月前的信息了，放到現(xiàn)在可能完全是錯誤的。你可能會喜歡有更多選擇，但是這樣下去會造成“寒武紀(jì)大爆發(fā)”式的增長。我覺得2113年的軟件架構(gòu)師會喜歡研究這些問題的。

　　（同時，請閱讀：Tero Piirainen的 Frameworkless JavaScript）

　　好了好了，我知道每個以Web為中心的大型會議，那些眼睛閃耀光芒的，充滿激情，真心相信瀏覽器的信徒們會向你展示HTML5的酷炫之處。而且他們也可以使用加速度傳感器配合麥克風(fēng)寫出移動設(shè)備上的獨(dú)特APP呢。

　　那，為什么沒有那么多人這么做呢？提示：請看上面列出的幾條觀點。

　　我在說”移動端太糟“，不是表面工程軟件的糟糕；而事實上，Cocoa Touch和Android app framework都在GUI構(gòu)建方面做得很好，吸取了很多歷史教訓(xùn)。關(guān)鍵是，你所想要放到UI上的東西，都會有一個簡單的，符合標(biāo)準(zhǔn)并經(jīng)過測試的方法，一般會成為Google和Stack Overflow網(wǎng)站上的第一條內(nèi)容。

　　但是看看投入到Web技術(shù)的所有精力吧，它真的能跟上當(dāng)今移動端的技術(shù)進(jìn)步嗎？也許吧，那或許是在Google和蘋果的精英團(tuán)隊及世界上頂尖的GUI工程師對它進(jìn)行一番篩選擴(kuò)充以后的事情。所以，我有點期待穩(wěn)扎穩(wěn)打，一往無前的時刻了。

　　收益減少

　　我是個老古董，仍然記得第一波Web應(yīng)用興起的時候，橫掃那些用Visual Basic、 Motif、Java、Win32編寫的一整代軟件，正是因為人們喜歡用瀏覽器處理所有的事務(wù)。

　　當(dāng)然，15分鐘后，軟件的VIP用戶們就開始訴說瀏覽器界面過于笨重，反應(yīng)不夠靈活，而我們得找到B方案，我發(fā)現(xiàn)那些VIP客戶們都接受了私有的B方案。于是現(xiàn)在我們有了B方案，至少它符合標(biāo)準(zhǔn)。

　　但是，我仍然半信半疑。是的，我喜歡讓應(yīng)用良好地相應(yīng)手勢，物件有滑進(jìn)淡出效果，但是那也只是錦上添花，離完美，也就是80/20法則所說的那樣還很遠(yuǎn)——放在服務(wù)器上的良好設(shè)計的Web應(yīng)用正常運(yùn)行，并保持良好的投資回報率。我非常討厭屏幕上四個獨(dú)立滾動的，用JS控制滾動，看上去外觀非常拙劣的區(qū)域。我稍后會寫一些出色的單頁應(yīng)用，故意來一些縮進(jìn)讓它看上去有點偏。我尤其討厭讓非技術(shù)伙伴，或者親友們遇到上面的糟糕情況，而我得花時間解釋原委。

　　接下來？

　　服務(wù)端并無驚喜，諸事順利，一切如往日美好。

　　而客戶端，我什么也不知道。由歷史原因造成紛繁復(fù)雜的做法最終會被那些簡單的，滿足80/20法則的做法所替代。如果這正是未來的方向的話，應(yīng)該不是來自我們這個方向，顯然現(xiàn)在仍然讓我們困惑不已?；蛟S我們還得長期應(yīng)付這種一個客戶端做三份的情況。

　　原文鏈接： Tim Bray   翻譯： 伯樂在線 - 埃姆杰

　　哈爾濱品用軟件有限公司致力于為哈爾濱的中小企業(yè)制作大氣、美觀的優(yōu)秀網(wǎng)站，并且能夠搭建符合百度排名規(guī)范的網(wǎng)站基底，使您的網(wǎng)站無需額外費(fèi)用，即可穩(wěn)步提升排名至首頁。歡迎體驗最佳的哈爾濱網(wǎng)站建設(shè)。