過去一年，米奇主要都是用Xajax來處理有關Ajax請求的問題的，這個Class是在大陸討論區認識的，有好多華人程式員在用，而官方提供的文件也很有用。只可惜Xajax有好些先天性缺陷，最明顯的就是它不能用來傳遞Javascript物件和變數。
今時今日，Ajax (Asynchronous JavaScript and XML) 已經進化至Ajaj (Asynchronous JavaScript and JSON) 的階段，即是不再用XML來作為信息傳遞的載具，改而採用JSON。使用JSON (JavaScript Object Notation) 比XML好的地方就是它本身就是Javascript物件的基本模型，不需要多餘的轉換，只要一句eval()就可以將從網站傳遞過來的回應立即變成有用的東西，直接為Javascript所用；而且它格式簡單明快，不像XML那麼複雜笨重。一旦做到Auto-Complete的應用時，能夠使用JSON可以帶來不錯的便利，要在後台將PHP的物件或陣列變成JSON，新版本的PHP 5.2已內置了JSON編碼和解碼插件，即使在舊版本伺服器中，只要使用FastJSON物件庫便可以，一句FastJSNO::encode()就搞定，完全無痛。所以Ajax應用的潮流的確是一步一步的邁向Ajaj的。
Xajax在這方面的確是在努力，正進行beta測試的0.5版本已經將回應資料的格式從回應的內容中分離出來，以便將來可以轉成輸出JSON。不過這個0.5beta的推出日期實在是拖得太長了，從測試到現在已經過了5個月。另一個問題是Xajax好像沒有打算解決以Ajax回應Javascript物件的問題。不能簡單直接地傳回Javascript物件的話，換上JSON也不會有意義。
正因如此，當米奇在將自己已經使用了一年的CPCMS架構，升級至全新的PartyFrame架構時，就決定放棄使用Xajax，改而採用Yahoo! UI 的 Connection Manager。YUI的好處是想要甚麼就裝甚麼，沒用的可以不裝。只裝YUI本身加上CM很輕巧。YUI CM只負責Ajax的發出請求和接收回應，後續的處理就由自己動手做。跟Xajax很不同的是Xajax主要的編程是在PHP伺服端著手指令Javascript的xajax物件去做事，總讓人有點隔山打牛的感覺，而且加上回應的方式與一般網頁請求不同，所以在CPCMS架構裡，回應HTTP請求的函式與回應Ajax請求的函式要分開來寫，即使它們在做著相同的事情。
換上了YUI CM之後，編程工作的重點落在Javascript Callback物件那邊，雖然要混用兩種語言會帶來一點點麻煩，但就變成可以直接控制怎麼利用伺服端的回應，加上在伺服端那邊編程工序減少了，令到在PartyFrame中，同一條回應函式基本上是可以同時用在傳統HTTP和Ajax回應上，減輕了不少除錯的負擔。另外最便利，當然就是今後可以直接傳遞Javascript物件了。
經過幾天的改裝和統一兩種回應方式的錯誤處理基制後，測試結果顯示使用YUI CM比使用Xajax不單輕巧了，而且處理速度也有顯著的加快。PartyFrame現在還是開發階段，新的Javascript端Ajax函式庫還在構築中，將來或許還會發現新的問題，不過現在來說，從Xajax中解放出來之後，的確感覺得輕鬆不少。
