雖然早就有想要換到客戶端渲染的想法了，但是一直在考慮現有的狀況，
TeaMeow 在未來是不會有「原生」手機版是很確定的一件事情，
有人為此擔心，我告訴他這不代表 TeaMeow 沒有手機版，
因為我打算把網頁手機版做得比原生手機版更順暢，所以我必須顧慮到相關的生產力工具，
至少近日確定在 MTK6589 的手機上執行 Vue.js 1 撰寫的 TodoMVC 不會有卡頓問題，
但還是有點擔心未來的走向，未來到底會是 「客戶端的手機都將做視圖用途」還是「每個客戶端都做渲染用途」呢？
如果是前者，那麼每個人的手機將會更加廉價化，前提是網路要能夠普及，還有速度也是，
但如果是後者，每個人手機的運算速度就必須夠快，而手機成本是否會提高也是個問題，
至於伺服端渲染的部分，我現在還沒有放棄亞凡芽的計畫，但可能要先擱置一陣子了。
雖然說 Avane.JS 原本是要用來應付前端渲染，這樣就不用讓資料在伺服器端渲染完成，
這樣可以分散一些工作，不過這個構想原本是來自於 Vue.JS，後來發現自幹一個太麻煩了，
最終只留下後端渲染的 Avane（PHP）。
原本是想不出來要怎麼解讀迴圈，
不如說原本知道要怎麼解讀，但是一遇到「迴圈內有迴圈」的狀況，
兩個的索引就會被覆蓋，後來的做法是在每個 endforeach 都做處理，
反正就是把每個迴圈的索引分開記就是了。
雖然市面上有 Smarty，但是自己做的 Avane 貌似也不會輸給它，
更何況產品是自己的，一：霸氣、二：更好掌控，
至少對我來說，Avane 的縮寫確實省了我不少的「<?php ?>」標籤。
是時候該提到 Avane 的速度性能問題了，Avane 大概是在一年前出生的，
那個時候還沒想到「性能」的問題，只有想到關於編譯器（Avane 有自己的編譯器，看這裡暸解更多）
還有怎麼處理跟快取而已，但是最近發現就算 Avane 有快取，速度怎麼還是慢 PHP 原生的 Require 四分之一倍！？閱讀更多»
TeaMeow Developers 