再好的 template engine，也解決不了網頁設計上套版的問題
我們先來看看套版的問題好了。也許是雙方對「套版」兩字的定義不同吧？我的意思是，在一般網站的開發過程中，程式設計師將動態網頁的功能寫好時，通常網頁的畫面是「素」的，非常陽春不經任何裝飾。接下來要做的就是，將轉交給版面設計師，也就是俗稱的美工，所設計好的華麗版面，套在這個「素」的版面上。對於程式設計師來說，這個「套版」的過程，通常是非常痛苦無聊的，但又不可能交給版面設計師處理，因為通常版面設計師，並無法處理到「碼」的層級。面對美麗的美工姊姊，小小工程師只好乖乖地與複雜的 HTML 混碼奮鬥。
更恐怖的是，通常來說，這個過程不會只做一遍，通常會形成一個循環，程式改好後套版，版面或程式稍微改寫之後，又要重新套版，循環不休。這當然是因為，在專案進行的過程當中，通常不可能很幸運地可以一條鞭式地順著瀑布溜下來。
對於套版問題，目前已經成熟的技術，是各式各樣的 template engine，如 PHP 的 Smarty。除了解決了 security-concern、separate-from-login 與 caching 等需求之外，簡單的語法，也讓套版的困難度，降低了少許。但無論如何，template 仍然是以「碼」的形式存在，要處理套版，仍然是只能讓程式設計師會版面設計，或者是讓版面設計師會寫點程式。
幸好，這個世界有在慢慢地改善，隨著 CSS/W3CStd. 的普及，以及 Ajax 的流行，套版的問題，將可以得到相當大的改進。如果網頁是功能性的，像 Gmail 那樣，比較好的解法會是使用如 ZK、GWT 這類的 Ajax framework，讓擅長處理複雜度的程式設計師處理套版；而若網頁是視覺性的，注重美觀與閱讀性，使用 CSS + semantic-rich XHTML，便可以讓擅長視覺設計的版面設計師處理套版。
但真正要解決套版問題，還是需要依靠「拉一拉」以及「WYSIWYG editor」，並且必須要做到，「版面設計師看到的是華麗的頁面，程式設計師看到的是素的頁面」以便應付隨著專案進行而來的修改循環。
那 RoR 有解決了套版的問題嗎？目前看來似乎是還沒有。雖然透過 Ruby 的語法，讓 RoR 的 template 十分地好用，但仍然是以「碼」的方式呈現，故仍然還是處於目前網頁技術的等級，並沒有什麼突破性的進展。更由於其「年輕」的特質，對應於 RoR 的「拉一拉」以及「WYSIWYG editor」的開發環境，相對於其他已經佔有市場極大份額的開發語言來說，能夠出線的機率就少了很多[1][2]。
Scale/performance 不僅僅是系統架構的問題，程式架構也影響很大
如果要單純比較 RoR 與 PHP 的 scaling 能力，搬出系統架構，實在是很沒有意義。不管前端是用 RoR 還是 PHP，server 都要 tune，系統架構都是要特別規劃的。並不是說 RoR 有 MemCache，PHP 就沒有，RoR 有 ViewCache，PHP 就沒有，或是 RoR 可以搭配 reverse proxy、multi-db，PHP 就不行。
使用 framework 最大的問題，就是程式架構的彈性。就如同 thegiive 所說的，「如果你希望一個框架就可以解決 Scaling 問題，不如先去問小叮噹比較快。」使用 RoR 增加了很多程式架構的彈性嗎？我反倒覺得陷在 convention 裡，是限制了程式架構的彈性。正如 thegiive 在 COSCUP2006 裡說的，如果是要開發一套全新的系統，那 RoR 非常適合；但如果是要與既有的系統介接整合，那 RoR 還力有未逮[3]。這是什麼意思呢？用白話講，就是：如果不照 RoR 的玩法走，那就幾乎是玩不下去了。Framework 的存在，通常是為了好讀好懂，好擴充功能而存在的。但實際的情形是，MVC 模型其實是個與 web/http 不太合的模型，硬要包裝成 MVC，代價就是程式的效能[4]。而更糟糕的是，透過 MVC 所減少的開發時間，與因套版問題而必須花費的時間比起來，常是九牛一毛。
因此，在使用 framework 反而會限制了程式架構的彈性時，「framework 能夠促進 scaling 的彈性」這樣子的陳述，就顯得有些弔詭。舉例來說，首頁的被存取量，相對內頁來說，通常大了很多。為了 scale/performance 的考量，在「程式架構」上，我們會把首頁裡靜態的內容部分，甚至只是較少更動的部分，使用 static-html-generation 的方式處理，事先或每個小時，重先產生。若是要按照 RoR 的「玩法」的話，這樣的機制，也不是辦不到，改寫一個 model 即可。但這就像為賦新詞強說愁一樣，脫褲子放屁。
