聊我對 JS 一路以來學習的感想。
我注意到 JS 是從表單開始的，當初 2005 年我接案做網站系統時，

注意到一個問題是很多日期選單其實都是月份用 select 選項放 1~12 ，日期放 1~31，
這樣就會導致可能視覺上出現 2/31 這種根本不存在的選項。

另外就是像是清單型的資料，為什麼不能按個鈕就增加一行，而非得要重新整理網頁，
然後自己一一處理重新整理時欄位的重新置入，反應又慢又難寫。

我就覺得這樣的 UI 很蠢，所以就想說有沒有辦法，
能夠按照不同月份判斷不同月份的日期或是動態的新增欄位，

後來發現在 client(browser side) 上能夠對 html 做操作的，
就只有 JavaScript ，所以就試著用 JS 寫了一些類似這樣的小功能。

當初學 JavaScript 並沒有什麼特別的想法，
事實上我當時的語言背景是一年的 Java，會一點點 vb6 ，也就只有這樣。

很多人學語言時，都會考慮到這個語言紅不紅、好不好用、好不好學，
而我純粹就是因為"我需要" 所以我學他，而這也是為什麼我能專心致志的運用 JS。

早期寫 JS 的人是很孤獨的，因為你跟別人講 JS 人家都會覺得那就是網頁特效，
但是特效不夠炫的基本上也吸引不了人家注意力。

然後很多人都覺得 JS 要考慮跨瀏覽器議題很難寫、沒有好的 debugger tool ，
但其實你寫熟了就知道跨瀏覽器議題其實有一些基本的經驗法則的，
debugger tool 從有 mozilla firefox with firebug 、
IE8 開始有開發者工具之後，就已經好很多了。

而且就算是 IE6 ， Microsoft script editor 也能做 JS breakpoint ，
只怕很多人根本沒聽過沒用過。XD

最糟糕的是這個技能在履歷上的能見度非常低，零零總總加起來就變成喜歡寫 JS 的人是笨蛋。

因為因緣際會的關係寫了不少年 web ，喜歡做一些貼心的細節，
一項是我設計網站的思維，怎麼樣可以讓使用者更覺得有趣的作法是我在追求的。

很早就把 fade in , fade out 、ajax 這類的作法應用進專案，
當然也不是說有用這些作法就是好，有時候也會做得太過花俏。

以我個性如果持續性的在寫網頁 html ，但卻沒有接觸 JavaScript ，
會是很匪夷所思的事情，因為做一件事情本來就應該試著把它做得更好。

我是覺得去學自己需要的東西，如果你在寫 web ，現階段瞭解 JS 對你是好的，
如果你不是再寫 web ，是不是需要學這個看起來好像很紅得語言，那也未必。

＠學習過程跟困難

一開始學習 JS 的時候，我通常是遇到一個問題，
然後得用 JS 去解決，於是就開始一直找參考資料。

一開始碰到比較大的問題是 Dom 物件的清單跟 JS 屬性的對應，
因為對 html/dom 本身的瞭解不夠，當時主要是參考 w3cschool 的網站資料做對照。
(雖然後來是發現 w3cschool 上面也會有瑕疵的小問題，
但是就當時來講已經算是很不錯的參考資料。）

像是
http://www.w3schools.com/TAGS/tag_img.asp
或是
http://www.w3schools.com/jsref/dom_obj_style.asp

有這種屬性表其實蠻不錯得，可以知道自己能做什麼事。

當然這過程中也是要一直學 CSS 相關的，一開始我們寫 JS ，
可以說是學 HTML 跟 CSS 比寫 JS 來得多。

＠瀏覽器相容性議題

其實現在回頭想想，瀏覽器相容性議題只要有養成開兩個 browser 測試的習慣，
基本上是不太會困擾我們的，只有想偷懶或是跟著唸的工程師會一直抱怨。

其實我們常常都只是偷酸 IE ，但是是酸好玩的，誰叫他們不做自動更新機制...
現在誰還叫我 support IE6 我就殺了他。（咦，不是說好不抱怨瀏覽器嗎）

記憶中當時比較明顯的問題就是 padding 判定 issue (IE6)、zoom:1 (IE6) 、event binding 的不一致 (IE*)，什麼 CSS3 跟 HTML5 因為當年根本就還沒有瀏覽器（連 chrome 都還沒出現），所以也就沒什麼現在那麼複雜的相容性的問題。

然後 IE6 JS 引擎真的很慢，但是做的事情反正也沒現在多，就當時應該算是夠用了。

＠ 多層事件

單一事件的處理寫久了，就會開始碰到多重事件的處理，事件跟事件的層層套疊，
開始網站的頁面層次變得複雜，但是到了這一步，現在我會希望回頭問問自己。

這個頁面變得這麼複雜對使用者來講負擔不會太大嗎？
每個地方連點兩下都可以編輯真的是使用者要得嗎？
到處都有功能，會不會讓使用者搞不清楚一個功能到底要去哪找。It worth to think.

到現在，我知道多層事件的處理有許多技巧，像是 pub-sub 觀念、
像 namespace 加上 delegate 觀念，該怎麼做 template 等。

但即使你有技巧能更優雅的做這件事情，一樣節省不了他的複雜度。

好的程式碼可以讓你減少犯錯、讓你容易看清楚清楚程式的結構，
但沒有程式碼可以減低程式的複雜度。

假設你程式就是要做一百件事，這一百件事不會因為你最後寫成一行或一百行而變多或變少，
所以寫下任何程式碼之前，想想複雜度這回事，然後想想你是否已經決定付出這個代價。

＠ 資料管理

因為你頁面上總是會有很多動態處裡的資料，你多少會需要 cache 一些 models 在你的頁面上，
像是編輯、處理中的清單啦或是頁面上有的一些資料啦，

需要不斷更新的一些頁面資料區塊，都可能需要你對目前的資料做儲存、fetch、update 等，
而且不同區塊的資料可能會有一些彼此互相參考的需要。

這時候你要面臨的最大的問題是因為疏忽造成的記憶體管理問題，還有資料過期造成的問題，
有些被快取的資料不是資料庫裡最新的資料，這會是個大問題。

而且你得跟後端充分的合作將你需要得資料請後端送到前端，
或是跟他們協商你應該送什麼資料給後端，

擁有"資料"傳輸的觀念也是前端人該點的技能。

＠ 跨服務整合

寫到後面你可能還會需要煩惱一些跨服務的整合，像是 google map 、Facebook api 之類的，
這些都需要跟服務商的系統打交道，有時可說是毫無道理跟規則可言。

===============

其實 JS 本身是一個很簡單的語言，
上面說得複雜度其實都是頁面操作邏輯的複雜度轉換來的，
也就是說如果你的功能不複雜，你的 JS 就可以寫得很簡單。

你會覺得 JS 是很複雜，其實是你要做的功能很複雜。

近年來網站系統有複雜化的傾向，不管大小網站都是，
很有些人太技術狂熱喜歡把簡單的事情用很複雜的方式做，
很多時候我們真的應該回頭想想這些功能，是否有值得用這麼複雜的方式去打造的價值。

當然也很有一些中型或大型系統是真的需要運用大量前端技巧去打造的，
但目前很遺憾的是台灣由於過去產業斷層，蠻缺少能夠自由運用前端經驗的工匠，

即使現在慢慢能有前端的職缺，卻仍然是出現找不到技能完備的人。

我認為理想的前端是應該同時具有前後端一定經驗，
又願意花時間在 JS/css/html 上，這樣才能夠達到最好的發揮。

也因為這樣，一個好的前端工程師的培養動輒需要好幾年，而以台灣產業環境過去又無法給前端一個溫床，
不重視前端且後端職缺普遍比前端待遇好、受重視，開發者因為後端待遇較高就轉往後端就職，
然後這些好的工程師又會因為某些迷思從後端轉往管理職，導致連後端圈自己都很難以技術深研，
就更不用說再轉回前端來完成前端 F2E 所該走得路徑了。

目前資深 F2E 多是本身就是持續在 web 上開發，且有需要一直運用到 JS 的人。

相信接下來不管 mobile web ，web 也好，甚至是新的 epub 市場也好，
html 這個簡易而且許多人會得樣板、UI 語言，短時間內看起來是屹立不搖的狀態，

相信 JS 這個前端語言還能夠有一定程度的興盛。

只是台灣的產業是不是已經承認前端本身就已經足夠豐富到成為一個職缺與產業的問題。

不過他們不承認也不行，因為今年我至少聽到幾十家公司說他們想徵前端，
但完全找不到能用的人，而這完全就是過去這幾年忽視這技能所種下的歷史共業。

文末回顧一下標題，在過去有人說學 JS 是笨蛋，而現在很多人覺得學 JS 是聰明人，
但是那些都不重要，重要得是你想要做什麼事、當什麼樣的人。

在過去我樂於當笨蛋，在現在我也不排斥當聰明人，
但別人怎麼說別人怎麼看，其實還是比不上自己想要做什麼來得重要。

--
這篇好像有點太心得了 哈哈哈哈，沒啥技術含量啊。將就著看。