同位素模板（Rails）的優缺點

Question

Isotope可以讓你在javascript中編寫模板。這些模板可以由客戶端（使用普通的javascript）或服務器（使用Johnson）呈現。

好處是DRYer代碼。在ajax或web套接字更新上更新DOM時，您不必編寫新的部分...只需將其指向您已寫入的部分即可。

有沒有人用過這個？

Answer 1

有趣的是，我不得不嘗試它，但是，我知道不是很多人這樣做，但我實際上使用HAML來模板.js文件。雖然作者提到的問題仍然存在，但每個請求都在服務器上模板化併發回html，除非您發送的是kb的負載，或者您確實有非常高負載的網站，我認爲這不是什麼大不了的事情。

理想情況下，你不應該甚至發回html數據和強制，只是JSON對象，這是由您的ajax請求在頁面上呈現。我可以看到的唯一合法用途是，如果你有大量的ajax網站，比如你加載一次頁面的地方，以及你只是一直在做Ajax請求所有的交互和javascript來處理視圖。

因此，如果你能澄清最終目標將會有所幫助。這是否適用於您控制用戶環境的一些內部應用程序（您肯定知道他們將使用哪些瀏覽器，並且他們將擁有足夠快的計算機來操縱所有此JavaScript？）或者它將成爲針對第三世界的應用程序，人們還沒有可用資源來使用所有那些花哨的javascript。所有這一切說，這是一個有趣的概念，我會嘗試我們自己，看看它的工作效果如何。

Answer 2

這使用約翰遜，最後我檢查沒有在Ruby 1.9上工作。所以這可能暗示了這個特定解決方案的一些不成熟之處。最終社區會想出一些非常有效的方法。

我使用的一種方法是製作2個完全獨立的模板，但儘量使它們儘可能相似，以便將更改從一個端口移植到另一個端口。

Answer 3

這似乎是一個壞主意。在Ajax應用程序中，我相信服務器應該負責渲染所有顯示文本。這讓i18n變得更加輕鬆，並將所有內容集中在一個地方。 JavaScript應該只接收來自服務器的數據，所有顯示文本都已經渲染，並將其放入相應的DOM對象中。

換句話說，我相信在一個Ajax應用程序中，對JS模板引擎的需求本身就是一種設計氣味。

當然，這種情況在客戶端JS應用程序中完全不同。