追求用戶端和伺服器程式設計語言的一致有多大的意義？

就我自己而言，所謂的用戶端和服務端開發，在大多數情況下，都不需要自己從很底層去解決問題，更多是使用「架構的力量」。 語言的作用只是去調用現有的各種軟體，也就是寫寫「膠水代碼」而已（所以，如果要前提是想寫 OS 的話，那就不用往下看了）。

在這個前提下來考量程式設計語言，最主要的關注就是它提供的抽象細微性是否適合它的應用場景（膠水）。 javascript 在用戶端，已經很好地扮演了它的角色，這點無需多說。 那麼，在服務端。 它也同樣可以扮演好自己的角色，成為一個好用的後端語言。 為什麼這麼說呢？

歸根結底，非同步（或者說延遲）其實是系統本身不容忽視的內在特性。 這個特性是需要被程式設計語言表達出來的，試圖假裝延遲不存在的語言（或者 API），其實都不能真正做到象它的語法所暗示的——讓程式師從這個問題中得到解脫。 況且，它對於延遲其實也是有著隱含處理策略的，這個策略通常就是等待（block）。 好吧，我們必須承認，這並不是在解決問題，而是在逃避問題。

至少也要直面問題，對吧。 實際上 javascript 一直都被用來處理延遲的問題。 對於 browser 裡的代碼來說，xhr 要到伺服器上去走一個來回，這是顯而易見的延遲，必須要用回檔來做處理。 對於 server 來說，問題還是一樣。 到資料庫裡查詢，同樣也要消耗時間（只是，這兩個時間的量級不同，但是，也不能裝作沒有吧），為什麼回檔就不適合了呢。 我們是不是可以這麼說——至少在處理與其他系統的交互時（也就是 io），在非同步這一點上，前端和後端其實是沒有區別的。

小結一下，能夠表達非同步邏輯，這是 javascript 作為膠水語言的核心優勢。 或許會有比 javascript 更好的膠水語言出現（沒准是 coffeescript ？ ），但它也一定要解決好非同步問題。

所有的程式都是在解決計算與 io 的問題（交互就是 io）。 而，這個部分跟其他語言區別不大（或者乾脆用更合適的語言來實現，提供介面供「膠水代碼」調用就好）。

再週邊的，就是 API 的豐富程度與包裝問題。 這方面，主要靠社區。 人氣旺的問題就會被解決得快一些。 人氣不旺的問題，就會被解決得慢一些。 大概總之都是會被解決的吧。 其他的都是 bonus 。 same language, same table. write once runs everywhere. 神馬的，都是廣告詞。

作者：趙東煒