使用JS已經二十多年，對于這門語言真是又愛又恨。
回想十三年前的那個心愿（讓JS的開發變得像Java那樣強大），經歷了許多年許多波折許多艱辛，今天可以大聲的說：我終于做到了讓JS的開發達到了Java開發的水準！
［里程碑版本］
歷經兩年多的艱苦編碼，新的JSDK（2.0）于昨晚在Github上正式發布！
https://github.com/fengboyue/jsdk
新版本完全基于ES6＋TypeScript語法開發。
而且定義了自己的類別庫加載機制，與未來的ES規范也保持方向一致。——那些過時的類別庫加載模式用不著了。
在此，先感謝ES6、TypeScript團隊！VSCode也讓我的開發作業輕松許多，真的很棒！
沒有他們的努力，JSDK無法達到如今的新高度。也只能是1.0之后的增強版，與YUI／Sencha或react／vue／Angular等后來者在同一水準上。
［JSDK的意義］
現在，越來越多的JS開發者已經意識到TypeScript的語法好處，開始轉向用TS＋VSCode開發類別庫或應用。但是，他們選擇的各種基礎JS框架帶來了很多隱性問題。比如：與ES6語法不兼容；用不上TS語法；基礎功能太弱；可移植性無；類別庫加載、組件定義真是千奇百怪。
這就好比，Java開發者都普遍使用最新Java語言規范且在Eclipse等IDE上撰寫Java代碼（沒有人僅僅只用早期過時的Java語言規范或用記事本寫Java）。可是如果沒有JDK，那么Java語言規范的版本再高也是一紙空文，于是Java工程師們都忙于去寫或集成“各自的JDK”去了，那么Java的開發世界一定是非常混亂、低效和可怕的。
如果，我是“這樣的Java世界”的一員，我得從頭學習“各家公司的JDK”才能找得到作業。可悲又無奈！
但是如今，混亂的JS世界看到了兩大利好：
一是：ES6與TS語法讓JS的語法達到編譯級語言的程度。
二是：JSDK 2.0發揮出ES6與TS語法的全部長處，可以完全解決JS通用庫長期混亂的現狀。
［新版功能］
很多新特性與功能，我就不在這里重復描述了，看官網檔案吧：
https://fengboyue.github.io/jsdk/docs/#/zh/quick
［后續路線圖］
在2.0的后續版上修BUG或區域增強，不發布大的新特性。
在3.0版本，計劃提供影片庫與游戲庫，將對影片與游戲開發帶來直接幫助。
（比如：1.0版本的JSGF游戲框架將被TS語言重寫，移植到3.0上）
uj5u.com熱心網友回復：
uj5u.com熱心網友回復：
uj5u.com熱心網友回復：
分享技術和知識者 都值得稱贊！
uj5u.com熱心網友回復：
我就是TypeScript的堅定反對者。JavaScript就是因為弱型別解釋型才無比靈活，無比自由。雖然用C#、Java十多年了，但我最喜歡的語言還是JavaScript。
如果你把一個網站上千個頁面，做成單頁面，我不得不承認這是一個大專案，沒TypeScript沒框架什么的，可能還真是不好搞。
但我覺得把上千個頁面，做成單頁面，本身就是反科學的。人們做事通常是把復雜分解，而不是把簡單整成復雜。
如果分成一個頁面又一個頁面來做，前端哪有什么大專案，每個頁面都是一個小專案的。直接用原生Js都會很方便。
uj5u.com熱心網友回復：
一、Web早已不是那個表單頁面的時代二十年前的網站曾經是！雅虎早期頁面曾經也是！谷歌第一版的頁面曾經也是！
我二十多年前用JS開發HTML3.0應用時曾經也是。
那個時代，網頁基本就是一組靜態資源鏈接，最多的互動就是表單，幾個函式操作就足夠，何必談組件或類復用。
在那個時代，后端的JSP也是一個servlet類的幾個方法完成頁面服務。哪需要什么webwork／springMVC框架。
不過一兩年后，后端web服務迅速出現框架化，以應對沉重的代碼復用需求。
同樣，十多年前前端早已進入了組件化、應用化開發的時代（甚至在你學習C#和Java之前）。
試想一下，你僅僅用函式寫組件（widget/component）而不使用任何繼承、封裝、多載等面向物件特性。你到后期會被自己蠢哭的！所以這十多年來，無數JS框架、類別庫、組件庫的jser們模擬了各種類定義／類繼承的語法糖（遠在ES6/TS語法出來之前）來實作框架級或組件級的類代碼復用。
二、TS是JS的最佳OOP方案
其實，反對TS的本質是反對JS語法面向物件化。如果你是ECMA組織的一員，你一定會反對ES6提案（因為竟然讓class關鍵字得以實作）。謝天謝地，幸好你不是。
同樣的，我也謝謝你不是Java和C＃規范組織的早期成員，否則你會把這兩門語言帶成后臺函式式編程語言如ASP/PHP的（PHP不得不從5.0開始支持OOP；ASP則廢棄已久，早被OOP化的ASP.NET取代）。
值得一提，Java8開始支持箭頭函式（作為一種快速的方法寫法，算是吸取了函式式編程的一個優點），但完全不影響Java是100%的OOP語言的本質。
三、JSDK與單頁面應用無關
JSDK中沒有任何單頁面導航的API，這類API可以集成第三方如angular/vue。
因為我覺得Web的本質是多頁面的，沒必要搞這些（但不等于我覺得單頁面完全不好）。
四、對不起：不是駁斥你，是駁斥你的認知
兩天前看到你的回復，我一直在猶豫要不要駁斥你的以下認知：
“我覺得把上千個頁面，做成單頁面，本身就是反科學的。”
“前端哪有什么大專案，每個頁面都是一個小專案的。直接用原生Js都會很方便”
今天是周末，我決定寫點回應，因為類似認知者不在少數。
（1）單頁面不是一個或幾個大大的檔案，也是分多級子頁面檔案。
（2）每個頁面的復雜度（頁面復雜度與邏輯復雜度）與代碼量如今都不小，用原生（哪怕僅僅用jQuery）寫／除錯／維護會“累死人”的。
（3）我對單頁面的認知是：一種無跳轉式良好用戶體驗的架構，也是一種強制與服務器互動全部API化（Ajax化）前端架構，更是一種減少服務端代碼侵入的架構。壞處是：1、導航不受服務端控制；2、安全性不受服務端控制；3、一些必要的服務端代碼植入困難（諸如：跟蹤打點、頭文本替換等）；4、搜索引擎不友好。
（4）我在專案中使用的架構多數是多頁面架構。有些時候使用單頁面架構是合適的，比如：操作子頁面多且不允許用戶跳轉的頁面；H5游戲／大型互動式影片等頁面；螢屏小功能多的H5手機APP。
（5）OOP并不可怕，專案中存在大量函式卻無從復用才叫可怕，花海量時間閱讀理解他人函式式代碼才叫可怕。別說用函式寫游戲了，用函式寫UI組件都是維護黑洞。如果你是一個人開發一次性代碼專案且無須嚴格測驗，那就函式式開發吧，最多用用jquery這種工具函式庫就夠了。
（6）有人一定會問：“為什么專案中存在大量函式卻無從復用”。答：函式復用僅僅只能是行為復用（20%），更多的場景（80%）是需要狀態（＋行為）復用的，只有類復用才能做到。
uj5u.com熱心網友回復：
今天發布2.1.0版本。國內檔案地址：http://fengboyue.gitee.io/jsdk/
國外檔案地址：https://fengboyue.github.io/jsdk/
新增影片庫：JSAN
轉載請註明出處，本文鏈接：https://www.uj5u.com/qianduan/30425.html
標籤：JavaScript