本文為《數位時代》獲授權轉載自軟體工程師張以承Medium部落格
講在前面
我是 Ruby 的愛好者，但是不得已的，我也用了不少不是 Ruby 的語言來做前端的開發。Mobile 就是 Objective-C，Web 則是 JavaScript。當然文章這種東西難免都會有偏頗，如果你是死忠的 Ruby 使用者，這篇文章你可以讀來深有同感，但是如果你是 JavaScript 的愛好者，你絕對可以想到一百種理由辯駁…
起源
JavaScript 是一個公認的設計糟糕的程式語言，如果你無法體會他的糟糕，那恭喜你的職業生涯出奇的順利…
不過正因為他是一個設計糟糕的語言，所以有很多人嘗試把它當成一個 compile target ，舉凡現在已經不紅的CoffeeScript，或是微軟支持的 TypeScript.. 等等。通俗地講就是，讓我們來用這個比較好而且可以編譯成 JS 的語言。
但是你知道 Ruby 其實也是可以編成 JavaScript 的嗎？這個專案叫做 Opal。他讓 Ruby 開發者一圓了用 Ruby 寫網頁前端的夢想。
而我在去年年底的 RubyConfTW 的 talk 一直鼓吹的想法則是，很多人會排斥這個點子。儘管是一個資深的 Ruby 工程師，還是覺得網頁前端的就應該要用 JavaScript 寫。理由不外乎是，這才是正統啊，效能啊，豐富的第三方套件等等…。
JavaScript 才是網頁前端的正統
說真的如果你是指 ES5 (ECMAScript 5) 的話，那我覺得你可以槍斃你自己了。一個錯誤的工具，就算他是原生的，也會大幅的減緩開發的速度，你會堅持用機械碼寫桌面 app 嗎？更別提很難找到堪用的 Junior Developer 了。
接下來你可能會說，我們現在就可以用 ES6 了啊！？
平心而論，ES6 是 JS 社群想要把這個語言修好的一個有效的嘗試，開始寫 ES6 後我變得比較沒有那麼痛恨這個語言了。但是，事實上，你並不是真的在使用原生的 ES6 功能，為了支持舊的瀏覽器，你還是要用 Transpiler (e.g. Babel) 來幫你把程式碼轉變成 ES5。
而最弔詭的是，大家不只用 ES6 ，甚至有不少人會更進一步用一些還沒有打算被瀏覽器實作的語言功能。(e.g. decorator, async function)
所以說到底，你確定你真的在寫 JavaScript 嗎？還是其實只是一個 JS 的方言。而如果需要靠轉譯後才能執行，那其實跟用 Ruby 寫其實是同樣的道理。
用 Ruby 感覺效能會變差
Opal 運作的原理其實很先進的，Ruby 的物件跟 JS 的物件是一對一對應的，method 也是對應到 JS 的 Function，如果 JS 有對應的東西，他也會盡可能一對一的轉譯（Array, String…)。
這跟一般在 server 跑的 MRI, CRuby 其實是完全不同的原理，MRI 實作了自己的 Virtual Machine 跟一套指令集。但是 Opal 因為是幾乎一對一的對應到 JS ，所以你其實還是跑在 JS VM 上，沒有額外的一層。
當然有些語言功能還是會有 runtime overhead（例如 method_missing 是用 Exception 實作的），不過整體來說是非常高效的。
如果要我在開發速度跟實際運行速度上做抉擇，我會毫不猶豫地選 Ruby，來避免種種光怪陸離的語言陷阱讓開發速度陷入泥淖。
JS 有豐富的第三方套件
Opal 有個有趣的功能叫做 x-string 或是 backtick，讓你可以安插任意的 JS 程式碼在 Ruby Code 裡面，甚至也可以把 JS 物件當作 Ruby 物件來使用。那這樣談 JS 豐富的第三方套件其實就沒有什麼意義了，因為 Opal 都可以無縫的調用那些現成的套件。
%x{
console.log("opal version is:");
console.log(#{ RUBY_ENGINE_VERSION });
}
官方文件裡的 JavaScript from Ruby 那一節有更詳細的展示。
結語
我寫這篇文章當然不是為了打擊工程師的信心什麼的（儘管我們都知道工程師們都有顆玻璃心），而是在技術領域，永遠要抱持著開放的心態。當下你覺得糟糕的點子，說不定其實剛好是解決問題或是避免問題的捷徑。
而到底該用 JS 還是 Ruby 來做產品呢？我沒辦法給你絕對的答案，但是正如同所有的技術決策一樣，永遠要知道這個決定好跟壞，而不是一股腦地聽信網路上沒事寫部落格的鍵人們。
『讓我看看現在流行什麼，然後我們下一個產品就要用它』才是最糟糕的點子。
