下午在某家公司討論架構設計的顧問服務時，與該公司主管會後的閒聊，其中一個話題，就是聊到 JavaScript，我又不假思維的回答：JavaScript 是爛東西。
啊！我亂說話的毛病又犯了… :-/
前兩年，也是在某家軟體公司所承接上億元的案子上，當時我是某家顧問團隊的 Member 之一。在與該公司數十位軟體開發人員的顧問輔導會議上，我也是直接就講出這句話，當然，我會去說明認為爛東西的理由。不過會後，我們團隊其中一位 member 很不高興，認為我不應該如此的批判，還有一個重點，當時，他是負責教授學員們 JavaScript 設計的講師，他說了，如果我對未來會上課的學員直接批判 JavaScript，那他如何教課呢？ 是滴～ 不過當年我 “年輕氣盛”，就與他說了，那麼，我們課程互換，他來教授高階設計，我來教授 JavaScript，然後，也允許他直接批判 JavaScript。;)
這是之前的往事了．．． 想起來還是蠻有趣的一段話題。
對 JavaScript 印象不好的原因，源自於 ASP/JSP 網頁設計的時期，其實，我也很清楚，程式語言本身，那有什麼爛不爛的，會爛的原因是… 程式設計師把它變成爛東西了。 :>>
這怎麼說呢？ 我看到好幾位的程式設計師，因為非常不習慣於原來從傳統 Client/Server 的表單設計，因為潮流，公司需要把系統 Web 化，而往 Web 設計時，卻發現到，怎麼以往 Client/Server 的表單很好寫，為何轉到 Web 後，不僅開發工具的缺乏，以往很容易表達如 “Master/Detail”，卻怎麼在 Web 上如此難寫？
舉一個最簡單的例子，Client/Server 的表單設計，當操作人員輸入客戶ID 時，按【TAB】鍵移到下一欄位時，就會自動顯示出客戶姓名。嘿，當時若用 ASP/JSP 來寫這樣的作法，並不是一件容易的事呢。
為什麼？ Web 的表單設計，是當操作者填完整個表單的資料後，才會按【Submit】送出至 Web Server 處理，處理後傳回結果，連線就中斷了。所以，Browser/Web Server 的溝通，是屬於 “Stateless(無狀態)” 的方式；相對於 Client/Server，因為表單一直是連線著資料庫，不管你有沒有在用，資料庫就是一直連線著，我把這稱之為 “佔著茅坑不拉屎”。:) 表單與資料庫的持續連線，稱之為 “Stateful”，也正因如此，所以表單要資料處理時，隨時就可以至資料庫 “撈資料”。
“Stateless” 是為了節省系統資源，因為 Web Server 所服務的 Client 是至少以百計以上，不可能讓每個 Client 都一直連線著；”Stateful” 會浪費系統資源，但是可以盡善盡美地來服務 Client，在 MIS 內部，操作者規模在 100 人以內，系統的負荷是不會有問題的，當然就可以這樣作。
結果，許多程式設計師，搞不懂 “Stateless” 與 “Stateful” 的原理，不僅是新手而已，也有很多算是老手級的了，以上剛我所舉的例子，為了能達成輸入客戶 ID 後，就能馬上秀出客戶姓名，竟然就乾脆一次把位於資料庫的客戶資料全部傳到 Browser 內，然後，用 JavaScript 寫個 For-Loop 的迴圈啊，來找出對應 ID 的客戶姓名。
離譜吧？ 會犯這種低級錯誤的，還可真不少呢。 除了增加傳輸頻寬的負載外，根本就沒有基本安全性的防護，赤裸裸地將客戶資料全部儲存在 Browser 內。我在輔導 Web 化的專案時，絕對是嚴禁利用 JavaScript 作上述這種事情，甚至，也不容許企業邏輯寫在 JavaScript 內，例如，計算員工薪資，一定是在 Middleware 來負責處理的。
難道，JavaScript 真的是一無是處，是個爛東西？ 不然啦～ 我會用 “爛東西” 來凸顯，其實是要提醒，程式設計師，可千萬不能濫用。我們要為 JavaScript 來正名，瞭解它真正的角色與責任。
我最激賞的網頁設計技術，就是微軟所提出的 ASP.NET。在其技術裡，總算找到了為 JavaScript 定位的最好名稱了，就是 “間諜(Spy)”。
且聽我道來～
網頁設計的技術，最大的挑戰，就是要能把 Stateless 的現實環境，”模擬” 成具 Stateful 的狀態。也就是說，Web 化的表單，即使還沒按下【Submit】之前，很有可能會根據某某欄位的資料，而即時送至 Web Server 處理，並傳回部分的結果，但請記得，因為表單還沒有完全送出，所以，表單的資料，是需要被保存其狀態的，ASP.NET，簡單的說，就是利用在 Web Server 有個 “State Bag” 的機制來為 Client 儲存尚未【Submit】的表單資料。
那麼，是誰來負責傳送欄位的資料？ 當然就是 JavaScript 囉～
UI 的設計，除了 Style 的美感之外，在技術面，最為重要的，就是 UI 元件的狀態與事件(Event)的處理了。仍然舉上述的例子，當輸入客戶ID 後，操作者可能按下【TAB】鍵或是以滑鼠點選移至下一個欄位，這兩種動作，都會觸發了事件，此時，JavaScript 當作 UI 的事件處理者(Event Handler)，收到事件後，根據 UI 所設計條件邏輯，來決定是否後送至 Web Server 來處理，再把結果傳回，並秀出在 UI 上。整個後送的過程，操作者完全沒有感覺，可能就是畫面閃了一下，其實就是作一次 “Refresh” 的動作，JavaScript 已經偷偷地把資料後送至 Web Server 處理了。
Javascript 除了可以在 Browser 端，作一些動態的展示呈現效果外，在企業應用系統的 Web 化表單設計，就讓它回歸最單純的角色，UI 事件的處理者，簡單的說，就是 “間諜”。如此，就不會把 Web UI 的設計搞成複雜又糾纏不清，JavaScript 反而會變成 “好東西” 了。 😉
….
我覺得你文章有一句話很對
就是是程式設計師在爛
現在的網路世界 如果沒有javascript
不知道有多不方便
反倒是很多適應不良的老人
說些不著邊際的話~~~好爛喔~~~
很早前寫的這篇文章~
算是提醒軟體開發人員對設計的重視吧。
哈哈！我個人則是覺得JavaScript真的是個好東西
可以非常精準的控制Browser端的每個細節
我已經大量的利用JavaScript在Browser端的畫面顯示
以及部份的程式也都交由JavaScript幫我執行！
WEB已經慢慢退到單純負責傳遞資料以及丟Template和Layout
Data、Template、Layout被我丟到Browser之後
剩下就通通都是JavaScript在跑！
真的大量節省WEB端的運算資源
幾乎是把Browser當作Window Form在用！
只要瀏覽器還存在一天，JavaScript就是一個不可或缺的工具程式！
我把我們.NET上慣用的DataTable的物件，用JavaScript直接實作了一個出來
真的是有夠好用！你可以在Browser端操作大量的資料！
另外WEB端常用的GridView，我也用JavaScript實作了一個出來
所以當Data從WEB端餵給Browser之後
Browser端就是透過 JavaScript 版的 DataTable 和 DataGridExp 物件
負責產生要顯示的，塞到指定的 $(“show_resulr”).innerHTML
真的很好用..^^..大家可以自己玩看看！
自己開發一個 AJAX-Framework 比較屌！
改天再分享給大家..!!
您能對某種實用技術熱衷且願意擴展做出更好用的工具給後進用，那是好事的。 ^^
對於 Javascript，我實在沒有喜好或厭惡的區別。對我來說，工具好用也就可以了。
這一篇文章是好久以前發表的。很多人以為，我是對 Javascript 很不屑，殊不知，我僅是利用它來當成案例而已，旨要說明軟與提醒體人員關於設計的基礎觀念。
請再仔細思考我主題最後面那個 (?)，再冷靜地看一下文章內容，大概就可以知道我想表達的是甚麼了。
嗯！看完了..^^..!!
其實我也只是分享開發的心得而已！
JavaScript這個東西實在太好用了
玩的越深，越覺得JavaScript的強大
已經不只是UI上好用了
就連WEB SERVER效能的問題JavaScript也可以幫上很大的忙
透過完整的AJAX Framework，可以讓WEB拋最少的資料
讓JavaScript利用Browser端的CPU和記憶體來協助運算
WEB做的事情越少，WEB的Loading就越少！
同時就能承受更大量的存取！
但是USER端卻不會有太大的感覺
已上是我的心得分享..^^..!!
這個是屬於 “責任分派 (responsibility)” 的設計議題 🙂
對於 Brower, Web Server, Application Server, Database 這些比較 “大” 一點的元件 (component)，軟體設計者會先仔細斟酌這些元件應盡的責任為何。
ex. Javascript 負責 Browser 動態 UI 效果的呈現與 Event 觸發後的轉派(給 Web Server)；但不負責企業邏輯的運算。
軟體設計者對於系統的開發，不僅是考量 “好用與否” 的問題而已，甚而要評估是否需要讓應用系統具延展性與彈性度，以提升系統的再利用性價值。
企業層級的應用系統，可不是說只有 “做” 出來、美侖美奐而已，更講究的是上述相關議題的價值。 ^^
沒錯..!!
不管哪一種語言
只要物件邏輯設計的好
就會具備非常好的彈性和延展性
以及可再利用性
只要邏輯設計的漂亮
就可以實作在各種不同的語言上
達到高可用度！
到今天才看到這篇文章
不過既然看了就回個文吧
一開始看到作者這個標題真的還滿訝異的
不過這應該是時空上的差異
(就如同AJAX的技術早就有了直到google才發揚光大)
我想作者本身在表達的意思是程式設計師對工具(語言)的認知
如果對一個工具或機制認知不夠完整的話就會發生這類的問題
這些問題直到現在還是有不少人在犯
前陣子我在求職面試時
有一個軟體公司的技術主管居然還跟我說
三層式架構的系統(client-Server-DB)其實跟client-Server是一樣的
因為他們是做client-Server起家的所以現在還在摸索三層式架構
怎麼開發比較好….
這個例子大家可以當作看笑話,但是卻是在2009年真實發生的事….
Hi, 請注意，我的標題特別加了個 “？” ，呵呵，不加這個，早被擁護 Javascript 的人給 “公幹” 了。 ^^
沒錯，關於工具，都各有其用途，而 Javascript 可更是 Browser 中的靈魂所在，我是沒資格去批評這個的。 本篇文章僅是借反諷來說明軟體人員應重視軟體設計的基礎功夫。
關於三層式架構，連諸多實做很高竿的程式人員，甚而還有出書甚而教課的作者等，因重視的方向不同 (重於實做技術)，也是會搞混了所謂的三層式架構的本質。 IT 主管搞不懂，相當正常的一件事。 🙂
寫不好說一個東西爛
……
Hello chaN：
應該是你太激動了點，還沒看完個人的本文，就 “義憤填膺” 地作回應了。 🙂
其實，若再 “稍微” 心平氣和的思考一下個人寫本篇文章的 “假設點” 為何。 個人在該文內，其實並不是說 “Javascript 是爛東西” 喔，而是另有所指的。 ^^
JS是爛東西？，現在不懂一點JS可能找工作都會有點問題
我們公司連美術都懂一些JS的運用
JS作用這麼多，你因為一小部分的人應用他一小部分的能力就來否定他
也未免太以偏概全了
Hello JonesLai :
語言是無罪的，沒有錯！ ^^
後面您那段話正是軟體開發的調和之道，您蠻能瞭解我個人在此篇文章的意涵。 🙂
把資料撈到客戶端用JavaScript解析真的還蠻危險的,像我習慣用Firefox去參觀大家寫出來的架構,其實還有人這樣亂搞,這種你就跟著他的程式去拿資料就基本上會全部給你,還看過把密碼帳號乾脆傳給JavaScript認證的勒……= =b…..也不是伺服器端都做掉就一定安全,之前有發生過CGI權限太大,可以把伺服器檔案列表出來,下載密碼本分析,反正就是不是光會寫程式,也要想想安全問題吧~
語言無罪吧~而且我覺得重點是在系統資料安全架構上的問題,太過安全就是要忍受速度慢的痛苦吧~要拿捏得宜吧! 銅牆鐵壁,容易寸步難行~~~幕牆圍籬,歡迎光臨….哈
這一篇主旨應該想說這個吧~
JavaScript 是爛東西？
下午在某家公司討論架構設計的顧問服務時，與該公司主管會後的閒聊，其中一個話題，就是聊到 JavaScript，我又不假思維的回答：JavaScript 是爛東西。
JavaScript是爛東西??
在網頁使用上asp.net用的比較多還是JavaScript??
我倒覺得asp.net是垃圾
這位 Jimmy 讀者：
如果能稍稍微用心看一下個人寫的這一篇文章，就可以了解到我想表達的 “意涵” 了。
另，無論是 Javascript or asp.net，去擁護這一些工具，是沒啥意義的。
Dear 克明兄:
我想您誤會了我的意思
追逐新技術有兩種層次
1. 工程師level 的
2. SA/SD level的
一個重的是實作面 一個重的是改善現有技術缺陷不便與應用面
我所著重的是第二種level 強調的是以User 為出發點來找尋
謝！
Hi Nick, Jeff, CHWu:
思考許久，原來不想回應，但想想，還是給個忠告。
我寫這篇文章有一個用意，就是希望技術人員不要只看表面的技術。AJAX or ASP.NET，要能學會觀察這兩者相同的本質。我一而再地提及，Stateless and Stateful 的設計與互補，這會是 Web 化 UI 設計的根本道理之一。
甚至，UI 的 even and state 變化，那又是 UI 設計的重心所在。再牽連廣一點，與交易元件呼應的設計，又是影響系統穩定與效能的要素。
我似乎感受不到軟體人員對這些根本方面的認識與認知，而若只是一直追逐新技術，我會覺得那是本末倒置的學習方式～ 這樣的話，再怎麼學，也學不完的。
AJAX定義
2.0的AJAX利劍-Atlas
JavaScript不是爛東西，但要好好正確的用它是對的
正確說，現在Web Rich Client技術架構已經靠兩邊站了
Flash vs. AJAX
JavaScript早已不是網頁設計師在用的小玩具了，
不管用哪種，JavaScript都是架構上關鍵性的「黏合劑」，不能不會用。
至於ASP.NET與Javascript關係就好像Jsp跟Javascript
其實沒什麼必然衝突關係，
何況ASP.NET也推出數個AJAX Framework，還有MS官方的版本
擁抱AJAX~
XML資料交換
減少RELOAD
減少等待時間
好處多多
it’s Atlas Framework.
Hi visitor:
不不，我指的 “爛東西” 絕非是 JavaScript，但確是意有所指，只是指向的不是 JavaScript，而是另有其它。 🙂
我想，你雖然在此文章中說：「我會用 “爛東西” 來凸顯，其實是要提醒，程式設計師，可千萬不能濫用。」，其實，你應該是打從心底就這麼認為並成為潛意識，所以才會那樣脫口而出。
呵呵，不過你說的JavaScrip的優缺點是事實。
Hello smart:
謝謝您的支持。^^
Hello william:
瞭解瞭解。 ^^
不過，那不一定是好的作法，仍須視現實的環境因素來判斷。
Hi nick:
剛好看到 AJAX 的介紹了。 🙂
確實它是把 Javascript 當成 “Spy” 來用，與我的推論不謀而合。 ^^
我的意思是說,有一些framework,例如structs會把form的validation,弄成可設定的,除了方便開發之外,更減少程式師在javascript上的開發與出錯.
安全性和便利性始終比較難取得一各平衝點。
每次都很喜歡看Kenming Wang 兄所寫的文章，可以學到很多東西。 ^-^
Hi nick:
我並不知道 AJAX 是什麼。 🙂
Hi march:
這是屬於過渡期，Browser 端，回歸至最基本的責任：負責 UI 的呈現，如此而已，至於 Web UI 的技術，仍在變革中，應該仍尚未定論。
Hi william:
不太懂你的意思？
script-based 的語言，有它好寫易用的便利性，只是，要知道它的角色與定位，不要濫用即可。
JavaScript真是設計的罩門之一,也難怪很多framework都紛紛將牠包起來,希望大家都不要摸到.
基本上如果使用太多javascript就會因此限制了USER的瀏覽器
的廠別，因此也增加了測試的困難，因此通常會限定使用IE(javascript 支援最完整)，
這對 WEB AP 不知是幸或不幸?
當輸入客戶ID 後，操作者可能按下【TAB】鍵或是以滑鼠點選移至下一個欄位，這兩種動作，都會觸發了事件，此時，JavaScript 當作 UI 的事件處理者(Event Handler)，收到事件後，根據 UI 所設計條件邏輯，來決定是否後送至 Web Server 來處理，再把結果傳回，並秀出在 UI 上。
ASP.Net vs AJAX ??