Rails：不是燼，不是JS響應，而是介於

Question

之間我正在開發一個標準的rails應用程序，到目前爲止我還沒有使用任何AJAX，只是好的HTML。我的計劃是反覆添加「遠程」鏈接和所有類型的東西，並支持JS響應，因爲我知道生成JS服務器端非常非常邪惡，但是我發現它非常方便，簡單，快速，它使得應用程序足夠靈活，並且i18n是即開即用的。

使用純JSON方法會更輕，但需要大量的客戶端編碼。

現在想象一下，在這個應用程序中用戶有一個郵箱，因爲他們的想法是他們能夠在不重新加載頁面的情況下執行大部分甚至全部的操作，除非刷新頁面，否則郵箱計數器將永遠不會改變手動。

所以，這裏出現了這樣一個問題：哪個是處理這個問題的最好方法？

1. 我想過用灰燼（數據綁定），並分享與軌道的觀點，通過某種車把實施紅寶石。這會非常棒，但對於開發者（我）來說不是很透明。雖然我猜想我只需要編寫將由燼用的句柄視圖，其餘的仍然可以用原始格式編寫，不是嗎？

2. 另一種選擇可能是使用某種事件系統（EventSource也許？），並且只需輕鬆使用JS視圖方法，並聽取這些事件。我想這些應該是JSON對象，並且客戶端必須被編碼以便能夠處理它們。這看起來有點麻煩，我需要一個heroku（faye？）解決方案，這是我的應用託管的地方。任何提示？

我認爲餘燼的做法是更強大的一個，但似乎是相當複雜的，以及，我不想重複自己的服務器和客戶端。

編輯：

我看到this，這是或多或少的選項＃2。

Answer 1

使用JavaScript框架的優點之一是整個應用程序可以連接並壓縮成一個JavaScript文件。只要現代瀏覽器積極緩存JavaScript，瀏覽器就不再需要在初始頁面加載後請求這些資源。

使用JavaScript框架的另一個優點是它需要你成爲你自己的API的消費者。如果可能有移動應用程序或第三方訪問應用程序的API，那麼充實自己的應用程序API可能會減少將來的工作量。

如果你不需要你的應用程序來響應每一個具有相同HTML響應的請求，我認爲一個引人注目的案例可以用於使用JavaScript框架。

如果您的應用程序需要使用等效的HTML模板響應每個請求，那麼這些好處中的許多可能會丟失。 Ember的核心一直比較有說服力，並且反對支持這種漸進式增強的風格。考慮到以這種方式使用JavaScript框架的工具相對不穩定和不成熟，我可能傾向於使用選項2來完成此任務。