歷史上的曹操, 正負面的評價多有, 就看你站在那一邊.
在整個中國歷史中, 曹操多面多樣性的風格, 在各朝代的君主中, 顯得獨樹一幟.
而其"短歌行", 至今仍在各種文學作品中引用著, 短短128字的文, 把曹操求才若渴, 及希冀得天下良才以治大國的雄心壯志表露無遺. 可惜曹操的性格中又有著疑人的缺陷, 終於導致本來有機會打敗吳、劉而稱霸天下的野心破滅, 成為三國局面.
而天下最後是由司馬懿一家所獲(晉朝, 更明確說是西晉), 對! 那個被諸葛亮騙的團團轉的司馬懿....可見, 歷史上的成敗, 真的不是由一時的勝負所決定的.
但這些歷史和我學習JavaScript的心路歷程有什麼關聯? 各位不用看完長篇大論, 我現在就可以告訴你....沒有!
我學習JavaScript的歷程相當悠久, 遠從ASP 2.0開始, 就接觸JavaScript.

之所以會開始走入ASP 2.0, 就是為了當年服務的軟體公司(早已消失在歷史的洪流裏)接了某客戶的案子, 要開發IIS平台上的進銷存系統. 於是, 就這麼一股腦兒的投入ASP 2.0系統開發, 對JavaScript的認識與應用, 也就從那個時候開始.

其實, 當時公司裏分成三派: ASP 2.0/JavaScript、ASP 2.0/VBScript和Servlet/JSP, 小小不到十人的軟體開發團隊就分成三派, 其混亂情況可想而知, 初期根本沒人在作有生產力的事.

原來就是以VB為主要技術的團隊, 當然是以ASP 2.0/VBScript的派系人數比較多, 佔一半多. Servlet/JSP只有一人, ASP 2.0/JavaScript派只有兩人(包括我).

後來問題的解決是非常'人性化'的, 支持Servlet/JSP的那位離職投奔敵對陣營(另一家軟體公司), 我們寫JavaScript和寫VBScript的, 都是在ASP 2.0的環境下, 只是宣告script language不同, 其他HTML、ASP部份都差不多, 所以, 最後相安無事.

但, 基本上使用VBScript和JavaScript還是有相當程度的差異, 例如:

1. VBScript因為可以直接在Server端運作, 而且, Microsoft的IIS對VBScript的支持也比較夠力, 而採用VBScript對原本就慣用VB的程式設計師來說, 只是小菜一碟, 只要適應ASP 2.0的模型即可. 但, JavaScript就不一樣了, 語法上的不同需要重新學習程式設計, 以致剛開始時, 我經常被老闆叫去檢討工作進度.

2. JavaScript就只是支援Client端的動態網頁, 像是資料庫連結(透過ODBC), 都是在前端執行, 資料量大時, 效能明顯變差. 而VBScript是Server端執行, 資料庫處理的速度明顯就比較好, 以致於初期在跑些應用時, 會被老闆唸為何要用JavaScript.
   當時學習JavaScript沒有現在這麼多的網站支援, 就只有Microsoft的網站和產品光碟中有些電子文件可閱讀, 以及一些貴森森的原裝英文書籍可參考, 就這樣自修、現學現賣寫起第一個"附帶"JavaScript的系統了.

"附帶"? 對滴, JavaScript從開始就不是主要程式語言, 比較像是在主要程式語言下的附屬品, 其目的是在增加網頁的互動性.

只是, 那套進銷存系統開發完成, 交付給客戶並收到尾款後, 那家軟體公司就因故解散了...其實是分贓不均...呃..不! 是股東權益分配不均, 導致兩三個股東意見不合退股, 於是老闆就收掉公司另起爐灶去了. 他有聯絡原來寫VBScript的幾個人, 想找他們到新公司去, 就是沒找我和另一個寫JavaScript的, 可見他對JavaScript的痛惡.

而我第一次與JavaScript的緣份到此告一段落, 後來有很長一段時間在VB、Oracle的環境中打混.

再次遇見JavaScript, 是AJAX. 也就是開始學了使用C#/ASP.NET時, 使用不少資料庫元件都是AJAX提供的元件.

AJAX是Asynchronous JavaScript and XML的簡稱, 非同步JavaScript和XML. AJAX確實改善了早期使用JavaScript處理資料庫時的困擾, 允許在不更新整個網頁頁面的情況下編修資料, 而AJAX也提供了神奇的方法可以進行部份更新, 讓我在開始使用ASP.NET/C#/AJAX後, 就大量採用AJAX帶來的好處.

可是, AJAX帶來的問題主要有:

1. 網頁更新的時機點不好掌握, 例如, 我經常面臨網頁中有兩個TextBox輸入資料後才POST並向資料庫查詢擷取資料後顯示在GridView中, 可是, 沒有控制好變成輸入第一個TextBox更新一次, 輸入第二個TextBox又更新一次. 就算是寫AJAX已有五年的時間, 這部份的掌握還是讓我很頭痛.

2. DataGridView元件的控制, 如果想在DataGridView中直接進行資料列的新增、修改等動作, 最後由Server產生的網頁大小將是只有檢視資料列功能的N倍大, 視資料量與新增、修改等動作程式碼的複雜度. 如果頻寬不足, 就很容易因為產生的網頁太大而變得很慢.

3. 同樣還是DataGridView元件的控制問題, 如果一次擷取顯示的資料量太大, 經常會造成Timeout的錯誤發生.

4. 資料更新的問題, 如果有兩個使用者先後修改相同資料列, 就剛好一前一後把相同資料列修改, 沒有產生Deadlock問題, 因為AJAX不會同步更新, 所以前一個修改資料列的使用者會以為資料列內容沒有變更, 結果, 有時會造成一些困擾, 比方說前一位使用者會指著螢幕對你大吼: 為什麼我看到的和別人看到的不一樣, 這時要出動F5....可是使用者和其主管那有那個耐心聽你供瞎咪技術細節?

5. 我個人認為AJAX是Webforms會那麼胖又遲緩的最主要原因.

雖然有些缺點, 我還是用AJAX在C#/ASP.NET環境下寫了上百支程式來支援各部門在ERP系統的功能補強需求上.

大約三年前, 我注意到JavaScript成為網頁設計技術的主流語言的趨勢, 其中最為顯著的是Node.js及jQuery, 可惜因為工作上的因素, 當時帶領團隊重新導入公司使用的ERP系統, 走到不同的路線上去了, 只有在偶爾回來修改舊系統功能時, 會看看JavaScript的發展如何.

直到去年新ERP系統導入後期, 以及參加iT邦忍者活動及JSDC 2012擔任志工, 讓我又重新認識JavaScript, 原來, 強者如雲啊!

於是又開始JavaScript的旅程, 而HTML5(強者們說HTML5=HTML+JavaScript+CSS)的逐漸推展, 以及各個JavaScript的社群活動, 讓JavaScript一下子成為台灣的熱門程式設計技術討論, 而我在去年八月開始創業的時候, 就準備投入HTML5的系統開發.

只是, 強者何在?

自從1996年NetScape公司把JavaScript開放給ECMA開始至今, JavaScript的版本為1.8.5, 從早期原始、單純的腳本語言, 演變成為具有完整功能的程式語言, 更完整的支援JSON, 使其能夠處理結構化資料, 而從網頁的附屬品成為網頁的主幹.

但, 可惜的是, 也因為JavaScript的開放性格, 各式各樣功能參差不齊的Library有如雨後春筍在市場上百家爭鳴.

比方說, 有強者說他用Yahoo!'s Mojito, 那慣用Node.js及jQuery的強者又如何? 或者, 有強者說用MooTools, 然後也有強者說用Google Web Toolkit, 有如金庸筆下的華山大會師.

不知道該不該建議JSDC的強哥、TonyQ等前輩大師在JSDC辦場擂台賽, 讓各派強者們上場踢館, 看看那種JavaScript Library才是真正強者手中的倚天屠龍劍.

於是, 在多年後, 我又回到當初開發進銷存系統的路線, 這回, JavaScript已非當年吳下阿蒙, 我主要採用的就只有jQuery、jQuery UI、HTML5, 以及使用Microsoft ASP.NET MVC 4.0的環境而已, 先從自已熟悉的開發工具來著手設計. 其他那一大堆JavaScript Libraries, 就等第一個版本(以IIS環境為主)開發完成後, 考慮Linux環境的Apache版本開發時, 再來看了.

而, 我還是想找強者來一起合作開發, 只是與強者無緣.

青青子矜, 悠悠我心! 但為君故, 沉吟至今.

那使用JavaScript的IT人, 我一直在尋尋覓覓, 希望能找到可以互相搭配的強者們, 也因為有強者們不斷的Push在JavaScript的應用, 讓我至今依然停留JavaScript的領域裏.