最近接觸到一些 RoR 的東西，覺得很有趣，以開發速度而言 RoR 真的很快，且 生態完整，但效能就是問題。反觀 node.js 族群，效能好些，但似乎開發速度還 沒那麼快。很可能接下來會變成看是 Ruby 先出現 HHVM 那樣的 VM，還是 JavaScript 開發時間也越來越短，最終真的一統天下。
以語言來說並不喜歡 JavaScript，就算到 ES6 也還是沒有很愛，但若把目 標放在 full stack，那一定得懂前端，要懂前端，就一定得把 JavaScript 學好。 既然學好了，後端時若能繼續用同樣語言開發，就能少學一種語言。
然而，若以開發時間而論，這不一定是最快的方式。因為很多 best practice (convention) 仍然存在 RoR 之中，所以花時間去學 Ruby，然後直接用 RoR，現 階段來說省下的功夫很可能可以把學習 Ruby 的時間賺回來。
語言跟應用領域，往往有很強的相關性。例如 Linux 之於 C，userspace 的基礎 架構如 database, browser engine, server 之於 C/C++，資料科學之於 R。但 也有相當通用的語言，例如 Python 以及 Java 用途都相當廣，Python 開發快， Java 效能好。所以說，若打定主意專精於 web 領域，那為了 RoR 學習 Ruby 是 很合理的。
但這優勢其實可取代。因 JavaScript 在 web 應用太廣泛，而基於 isomorphic 的需求，JS 會很自然的往後端與 mobile app 那邊長。且 async non-blocking 的天性已經在語言中，這並不只是效能問題，還牽涉到 scale up 的難易程度。 若把 node.js 的 opinionated web framework 例如 sails.js 開發到像 RoR 一 樣的方便，那麼全部轉換到 JS 為基礎的全端架構，有明顯的優勢。
這件事適合熟悉 RoR，知道其中哪些特性相對於其他解決方案是比較有優勢的工 程師去做。相對於寫一個 VM 可能要公司的能力才做得到，把 sails.js 這類 framework 往 RoR 的方向改善則只需要幾個工程師就行了，後者或許比較容易發 生。
另一個有趣的可能性是，Ruby 到 WebAssembly 的 interpreter 被發展出來且內 建到瀏覽器。由於 client 端運算能力日漸強大，interpreter 慢些也還好，說 不定 RoR 也可以用目前的方式往前端長，直接用一樣的方式寫前端行為，打包成 一整個 full stack web app，這樣感覺也是很厲害。