這些年，前端發生了顛覆性的變革，這種變化極大地改變了前端的生態，前端從很多年前一個不起眼的角色跨步式的演變為一個不可或缺的存在，
前端的技術不僅是在前端開發本身，它的觸角伸向移動開發，后端開發，如果要評選一種全堆疊式的技術，那后端，移動端本身的一些技術是無法與前端相抗衡的，
前端已今非昔比！
但是，由于我個人從事了很多年的后端與移動端的開發，在將前端的現狀與后端移動端等做對比后，我仍然覺得前端存在一些它自身需要突破的困境，
本周，繼續就前端闡述自己的思考與分析，這是前端之變系列文章的第七篇，前六篇分別是：
- 前端之變（一）：技術的變與不變
- 前端之變（二）：不變的前端
- 前端之變（三）：變革與突破
- 前端之變（四）：進擊的前端
- 前端之變（五）：王者歸來
- 前端之變（六）：引領式變革，從命令式UI到宣告式UI
寫在最開始的話
由于是講前端的困境，所以我希望能做一個簡單的申明：
-
前端技術的發展是很快的，本身是非常出色的，這篇文章說的問題，并不是我個人對它的否定，只是基于我個人的全堆疊式的技術背景下的一些思考
-
這些只是個人的思考，它當然有大概率是錯誤或偏頗的，但闡述個人的意見也是一件有價值的事，
-
下一篇，我會講到相反的一面，就是對前端未來發展的一些思考，在那里，會分析前端具備的優勢及對前端技術發展前景的一些預測
三個維度的問題
在思考與整理前端的問題，我把它歸納為三個維度，我認為這三個維度的問題是前端技術需要著力改進的，一旦這些得到改進，前端的未來不可小覷
我分析與總結前端面臨的困境，歸納起來就是：
- 語言之困
- 生態之困
- 開發者之困
接下來，我會逐一闡述我的思考
語言之困
JavaScript
前端語言的核心是JavaScript，想必這個大家都沒有意見，
基于我使用過Java,OC,Kotlin,還有前端的TypeScript等語言，將JavaScript語言與這些相比，我可以很輕易的下一個結論：
JavaScript遠稱不上是一個優秀的語言
JavaScript是10天設計及開發出來的，網景公司最開始的目標是"設計一種與Java足夠相似又更簡單的語言"，但JavaScript的設計者對Java并不是很認可，更偏向函式式風格的設計風格，于是在這種情況下，JavaScript誕生了，
它結合了設計者喜歡的面向函式式的一些風格，又不得不遵照公司的要求，讓它與Java有點相似，具備面向物件的一些風格，它的設計者并不是非常喜歡它，以致于說了"與其說我愛Javascript，不如說我恨它，它是C語言和Self語言一夜情的產物"這樣一句話，
關于JavaScript的語言設計缺陷，在《javascript語言精粹》書中有比較多的闡述，這篇文章我不詳細闡述這些，
可想而知，無論今天javascript的應用范圍有多廣，這改變不了一個顯著的事實，
一個優秀的語言更容易產生優秀可維護的代碼，而不好的語言，則會困難很多，
而幾乎整個前端生態都建立在JavaScript之上，
不能不說，這是前端的一大困境，就算是在TypeScript出現之后，很多有名的框架都在轉向TypeScript，但JavaScript對前端的影響仍將一直存在，
TypeScript
說完JavaScript，我就不得不說前端的另一門語言：TypeScript
想必微軟之所以要設計另一種語言，與JavaScript自身所帶的問題也有很大的關聯，不管如何，一門能取代JavaScript的新的前端語言TypeScript出現了，
與JavaScript這種四不像相比，TypeScript與Java更相似，
在這里我貼一段我的Java代碼與Typescript代碼以作對比，
TypeScript
public async fetchUnconfirm(): Promise<number> {
const fetchUrl = Config.getInstance().api + "/bings/" + BingMessage.tagString(BingTag.Unconfirm) + "?skip=0&limit=0";
const response: BaseResponse = await this.request.requestForGet(fetchUrl);
if (response.resultSuccess()) {
return response.result.total_count;
}
return -1;
}
Java
public Goods addGoods(){
this.created = System.currentTimeMillis();
Goods goods = getGoodsRepository().addGoods(this);
getItemRepository().createInventoryItemFromGoods(goods.getId());
return goods;
}
可以看出，TypeScript與Java更類似，可以說TypeScript是一門面向物件的語言，
TypeScript遠比JavaScript優秀，更像一門現代語言，但TypeScript在現在的前端也面臨著一些問題
- 它畢竟是依賴于JavaScript的，它無法取代或消除JavaScript，只能共存
- 它只適合于一些使用了Node環境的場景，如果你不是用的npm及node來做前端，比如用的純JS或JQuery，除了JavaScript，你別無選擇
- 很多前端程式員對TypeScript的理解停留在它是一個帶Type的JavaScript，我不只一次的見過許多人將Flow與TypeScrip相提并論，因為Flow也是給javaScript提供Type支持，大多數前端人員對TypeScript帶來的面向物件的編程思維要不就是不太理解，要不就是視而不見，
生態之困
在『后』前端時代，前端也出現了npm包管理，這與后端Java的maven依賴如出一轍，
npm上的包的數量巨多，我一開始也沒意識到它存在的問題，直至我使用了awesome-typescript-loader這個依賴之后，我才慢慢意識到前端的生態是存在一些問題的，
起源
我在2020年做PCX的時候，用的是typescript 3+webpack 4+react 16+mbox 5的整體技術架構，其中webpack用來轉換ts的插件就是awesome-typescript-loader，當然，還有ts-loader，以及babel也能轉換ts代碼，
ts-loader是webpack官方檔案中推薦的搭配，
我之所以會用awesome-typescript-loader，原因在于我在typescript官方博客或其它博客（印象不深刻了）上，它們推薦了awesome-typescript-loader這個，并列舉了awesome-typescript-loader比ts-loader優秀在哪的一些原因，基于這個原因，我在專案中選擇了awesome-typescript-loader，
這是很正常的一件事，事實上，它也一直運作的比較正常，
直到…
問題
2021年，我在整理myddd-electron，準備把pcx的幾個核心依賴進行升級，升級為webpack 5 + typescript 4 + mbox 6 + electron 12等，升級完后，其它的都還比較正常，但awesome-typescript-loader遇到問題了，
它始終有問題，我非常奇怪，我想著是不是要升級新版本，然后我去npm官網查找了下，希望升級到最新版本，支持typescript 4以及webpack 5的版本，
我看到的是這種情況：
這個框架，早在3年就就停止更新了，
當然，這個問題以我切換使用ts-loader而解決，
我掃了一下，這個問題還不只是個案，我使用的ioc框架–typescript ioc也停止更新了，后面不得已我又切換到微軟的tsyringe而解決，
我覺得很驚奇，因為在Java我從未遇上類似的情況，可能很多前端程式員不太清楚，但我可以明白無誤的告訴前端開發者：
在Java的主流依賴中，沒有任何一個框架，會長時間不更新，幾乎沒有出現類似的情況
調查與思考
基于這種情況，我稍微調查了下前端的生態，再結合與Java的生態相比，我發現前端的生態有很多明顯的問題，表現在：
生態以個人開發為主
Java的主流生態，無論是Spring,或是hibernate，或是Vert.x等任何一個主流的被程式員使用的框架或類別庫，幾乎無一例外后面是由一個公司或基金會在支撐運營，當然它們大多也是開源運作的，
而前端的許多生態，基本上是個人開發者為主，比如著名的webpack，最開始幾乎是以一個開發者做的，后面是出名了后，很多個人開發者添加插件，才形成現在的局面，但它直至現在，依然是由這個開發者在主導，還有類似上面我說的awesome-typescript-loader，ts-loader等，都幾乎是屬于個人開發者的產物，
我不是批評這種個人開發的生態，它在某種程度上是前端生態能迅速發展的一個優勢所在，但我想說的，與后端的一個明顯的區別在于：后端的生態使用的主流的技術，基本上都是公司在背后支撐，它們的質量與可靠性，更新的及時性，的確遠優于個人開發者，
個人開發沒問題，但往上是不是應該自然而然的提升至公司或開源基金會？這是前端生態不得不面臨的挑戰之一，
從另一個角度來對比，typescript,react這些都是由大公司主導的開源，可以看到，它們的更新及時，可靠性有保障，我想程式員在使用typescript或react時，應該較少懷疑到它們會有很多問題，或會有一天沒人更新了吧？
框架各自為戰，沒有形成標準
我在做pcx時，在針對ioc與資料庫兩個方面，我在尋找合適的框架來處理它，
可能很多前端程式員壓根不清楚IOC是什么，這一點我在后面的開發者之困會再講到這一點，
“控制反轉（英語：Inversion of Control，縮寫為IoC），是面向物件編程中的一種設計原則，可以用來減低計算機代碼之間的耦合度，其中最常見的方式叫做依賴注入（Dependency Injection，簡稱DI），還有一種方式叫“依賴查找”（Dependency Lookup），”
在后端Java的生態中，無論是IOC或是資料庫ORM，雖然最開始都是各有不同的框架誕生，但很快，由于它們的重要性及普及性，標準便誕生了，在ORM資料庫方面誕生了JPA標準，而在IOC，Java添加了IOC的標準annotaion，而具體的一些框架，后面都遵守這個標準，是這個標準的實作，
但很可惜，在前端，無論是IOC還是ORM資料庫，無一不是各自為戰，每個框架有自己的一套標準與概念，互不相通，
IOC我調研過typescript-ioc,inversifyjs，后面在typescript-ioc不適配typescript4后，我又發現了微軟的tsyringe，考慮到它是微軟的東西，質量肯定有所保證，我毫不猶豫的使用了它，它們之間沒有任何共通之處，
而orm資料庫方面，有Sequelize，TypeORM等，但它們同樣幾乎沒有任何相通之處，每種框架都有自己的風格與模式，
缺少頂級的開源基金會
做java的程式員，不可能不知道apache基金會，
apache基金會代表了開源框架質量控制的一種最高生態，它是一種頂級開源基金會，只有質量極為可靠，有保障的開源框架才能納入apahe開源基金會，比如國內阿里公司前些年的dubbo開源框架，因為依靠阿里的強大技術實力，這個框架在國內中小企業早就使用非常廣，但就算是如此，它也是在流行很多年后，才申請并被批準進入apache基金會的，
很可惜的是，前端并沒有類似的基金會，總體還是一些大公司主導的類似React的框架與廣大個人開發者的開源作品混合的一種生態，
由于有公司，有基金會的支持與管控，后端主流的框架，幾乎不會出現不更新的情況，我幾乎沒有遇上類似的情況，
而前端相比，生態的確還有差距，Java的生態運作方式很值得前端借鑒與學習的，
開發者之困
我在前面講到IOC時，我做了一個斷言：可能很多前端程式員不太清楚IOC是什么，
這便是我要講的困境的第三點：開發者之困
我認為一個顯而易見的事實是：前端程式員對面向物件編碼理念的理解遠遜于后端程式員
當然，這并不是前端程式員的問題，由于前端是以JavaScript起家，JavaScript怎么說都不能說是一門面向物件的語言，自然而然前端程式員對面向物件的編碼理念并不太知情，也是理所當然的，
與前端程式員不同，后端程式員不管有意還是無意，幾乎在編碼生涯的一開始，就能遇到一些面向物件的理念，比如：
- 面向物件的基本特性：封裝，繼承，多型
- 解耦的關鍵方式：IOC依賴注入
- 面向介面編程，而不是面向實作編程
- MVC模式，分層等
等等
并不是一定有人在刻意教導后端程式員這些理念，關鍵是后端程式使用的框架從一開始就是這樣倡導的，比如我剛畢業時，后端當時流行的是SSH架構，也就Spring+Struts+Hibernate的一種技術搭配，
在這種搭配中，本身就帶有一些理念
- SSH是MVC模式的一種實作
- Spring負責IOC，也就是依賴注入
以下這些理念，對后端程式員來說，它們是最熟悉的，而我認為前端程式員的理解就可能就稍差一些：
- 面向物件語言的基本特性：封裝，繼承，多型
- 面向物件的五大基本原則：單一職責原則，開閉原則，里氏替換原則，介面隔離原則，依賴倒轉原則
- 二十多種常見的設計模式：單例模式，觀察式模式，工廠模式，配接器模式，模板模式等
- 常見的架構風格：MVC模式，分層模式，領域驅動設計風格，六邊形架構等
- 測驗驅動理念，重構理念，敏捷軟體開發理念等
以上這些，決定了代碼質量好壞，可維護性的一些基本原則與理念，可以說前端程式員對它們的熟悉情況可能是三個技術方向中最差的，從根本上說也是因為前端本質是由JavaScript驅動的原因導致的，
而JavaScript并不能算是面向物件的語言，
以致于在TypeScript出現后，很多前端程式員仍然把它當作另一個Flow，把它視為帶Type的JavaScript，
TypeScript不是帶來了Type這么簡單的事，很多前端程式員沒有理解到，TypeScript更重要的意義在于，它給前端帶來了面向物件的一整套優秀理念與模式，使得前端終于能夠跨入面向物件的世界，
而面向物件的上面這些理念，仍然是當今我們程式世界最優秀的理念，雖然近些年函式式有越來越流行的趨勢，但就理念上來說，面向物件的這些概念與理念，仍然是最好地能帶來優秀的，可維護的代碼的原則與理念，
這就是為什么幾乎現在所有技術方向的所有語言，都是由面向物件語言主導的原因所在，后端的Java，移動端的Kotlin,Swift,OC,前端的TypeScript,它們幾乎無一例外的屬于面向物件的語言，
而我們前端的程式員，必須要去學習現理解這些優秀的理念，
前端的未來
雖然有我說的這些困境，但前端的變化仍然是瑕不掩瑜的，今天唯有前端的技術，最接近全堆疊式編碼的可能，類似我這種，又搞過后端，又搞過移動端，又搞過前端終究是少數，
很多年前，有一位程式員說過一句話：
Atwood’s Law: Any application that can be written in JavaScript, will eventually be written in JavaScript.
任何可以用 JavaScript 來寫的應用，最終都將用 JavaScript 來寫，
這是事實嗎？它會是前端的未來么？它會成為我們的編程的未來么？
下一篇，前端之變的最終篇：前端之變（終）：前端的未來，闡述我對前端未來發展的一些個人的思考，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/325561.html
標籤：java