前言
這一兩年因為工作需要接觸了JavaScript/NodeJS與Web前端，也因此對所謂的Web前端有了更深刻的體會和理解。
這篇文章雖然標題寫的是JavaScript介紹，但後面會描述JavaScript和Web前端的不可替代性。
Web前後端概念
早期的Web並沒有區分前後端，典型的開發方式是先做個Web版型，然後Web內容替換asp/php/jsp寫的function和變數，瀏覽器載入時，Server會執行這些function，並將執行結果放入Web中提供給瀏覽器。
目前的Web開發，則多半會建議前後端分離，所謂的前後端分離，指的是後端一樣是asp/php/jsp，現在甚至可以是NodeJS Express/Python Django。
後端開發後，提供的是所謂的RESTFul API，一般簡稱REST API或API。
前端開發，則幾乎都是以JavaScript/TypeScript為主的Web App。
為什麼分成前後端？有沒有必要？能不能不學JavaScript/TypeScript而用Java/Python/C++開發？
這是我在接觸Web前端時的一系列疑問，而後得到了答案。
1. 為什麼分成前後端？有沒有必要？
Google多半會查到，現在的趨勢如此，專業分工，前後端架構...等，但WordPress沒有前後端分離，一樣有很大的使用群，那需求和原因在哪？
其實最關鍵的需求和原因，是多平台支援。
現在這個時代，手機佔了很大的使用群，手機又區分了Apple和Android，Apple要使用ObjectC/Swift開發，Android要使用Java/Kotlin開發，而傳統的PC和Web要支援嗎？PC可能要用c#開發，Web要使用JS開發。
為了能夠滿足多平台開發，典型前後端一體的開發方式，無法適用在這樣的情境中，因此，將後端改為REST API，前端各自使用HTTP API串接成了解決方案，而這點，才是前後端分離開發的真正原因。
換句話說，假設今天明確的需求是，我們只使用Web瀏覽器，並且不打算支援手機，那麼是否要前後端分離其實沒這麼重要。
2. 能不能不學JavaScript/TypeScript而用Java/Python/C++開發？
這個問題，很多後端想跨入前端開發的都會問，我一開始也是如此，事實上這有好處。
想想看，團隊成員都會Java，直接用Java開發前後端，人力能自由調配，這是很大的優勢。
但實際上呢？答案是不太行，原因很簡單。
目前所有的Web瀏覽器，核心都是JavaScript Engine，而目前Web瀏覽器，尤其是Chrome，基本上跨所有作業系統平台，Chrome地位等同以前的IE，幾乎是Web瀏覽器的代名詞，因為它原生支援的是JavaScript Engine，學習JavaScript這件事就避免不了。
那TypeScript和其他語言又如何呢？
目前TypeScript和其他語言，都是透過轉譯器的方式，將程式碼轉譯成JS後，在提供給Web瀏覽器執行的。
Web前端優勢
我們先帶個比較無關的東西，看一看Google AI的TensorFlow SDK"主要"支援哪些語言？
TensorFlow SDK支援4種語言，包括：
Python/JavaScript/C++/Java
其中有趣的是，Java點進去會發現，它都寫這個支援未來可能移除。
Python因為簡單易學，是目前的顯學，學校教的程式語言，都開始改教Python，以AI主軸在類神經網路設計/訓練/推論這幾個開發點，程式語言帶出的系統架構不是重點，程式執行速度也不是重點，簡單實做和修改類神經網路才是重點，因此以Python為主要語言是合理的。
C++的優勢除了程式執行速度快，上至伺服器服務和Web後端，下至MCU都能支援，最重要的是，C++編譯後，Binary反組譯比較難，原始程式碼隱蔽性好，是主要語言合理。
Java在程式語言開發中，仍舊有非常高的使用率，因此支援Java不意外，但它的開發便利性不如Python，程式碼沒有隱蔽性，不如C++，因此有支援但可能移除就不意外了。
那JavaScript為什麼變成主要支援的語言？
簡單的說，目前所有Web瀏覽器都只支援JavaScript，而目前所有作業系統平台都有Web瀏覽器，支援JavaScript，等於能讓AI應用從PC到手機全部支援。
意思是，JavaScript與Web瀏覽器，原生就具備跨平台能力，儘管在不同平台上的整合度沒有各平台原生語言強，但套用Java以前的標語：One language run anywhere 完全沒問題。
JavaScript與分散式特性
傳統系統開發時，為了最大化系統效能，通常會測試系統可支持的最大負載量，然後將最大負載量設為80%左右。
一般而言，不論是PC/IPC/開發板，效能越強單價越高，通常都希望盡可能的降低程式CPU和記憶體的使用量，拉高系統可負載量。
當我們代入Web前後端開發後，上述的最大負載量能直覺反應，它是屬於Web後端的服務，那前端呢？
Web前端通常運作在Web瀏覽器中，因此JavaScript和Web瀏覽器執行在Client端。
一個極端的說法，對於Web前端而言，後端只需要有個Web Server提供儲存空間，能讓Web瀏覽器下載HTML和JS，後續就能在Client端的瀏覽器中執行。
從這個觀點看JavaScript和Web前端，它是完美的分散式架構，所有程式都分散運行在全部的Client當中，不會佔用後端Server服務資源。
白話的說，如果盡可能在Web前端用JS開發和執行，能最大程度降低後端服務器的負載量，增加整個系統的使用效率。
而目前Web瀏覽器和JS SDK能夠支援的運算越來越多，已不是傳統的JS function只處理頁面顯示，像是TensorFlow能夠直接用Web瀏覽器在本地執行Ai程式，WebGL能夠直接在Web瀏覽器繪圖，瀏覽器內嵌的影片播放器能夠直接播放影片並進行H264/H265...等影像格式解碼，以往這些負載較大的程式，現在都能轉到Web前端運行，以分散式觀點而言，能很大程度的降低後端負載，增加系統負載量。
Web3.0與區塊鍊
區塊鍊細節這裡不提，一方面熟悉度沒這麼高，一方面是要描述Web3.0與分散式發展的觀點。
前面提到，從Web前後端觀點看JavaScript和Web瀏覽器的應用，JavaScript和Web形成了完美的分散式架構，有沒有一種可能，讓全部的Web瀏覽器之間互相連線，運行同一支JavaScript程式，變成一個全分散的執行環境和系統？
我認為，Web3.0提出的區塊鍊就是答案。
我們把記憶回到以前的P2P，包括eDonkey和BT，並以eDonkey設計思考。
eDonkey這類P2P的典型設計如下：
所有P2P Client都有檔案清單，所有資源都在P2P Client，eDonkey Server處理的，是紀錄和提供P2P Client的IP列表。
P2P Client啟動後，先連上eDonkey Server詢問最新的P2P Client列表，再跟自己的P2P Client列表比對，接著根據上傳或下載提供檔案(資源)清單，接著進行檔案(資源)上傳和下載。
Server主要服務是維護P2P Client清單。
BT則進一步透過DHT，讓P2P Client之間能夠互相連線取得這份清單，進一步降低Server的依賴性。
那麼，有沒有可能這樣的設計用JavaScript開發在Web瀏覽器上面執行？
我認為區塊鍊是這樣設計的變形。
典型的區塊鍊，每個Client(錢包)都以token形式表示，Client(錢包)中每個代幣(資源)也都以token表示，每個所謂的主鍊(P2P Network)，所有的代幣(資源)都以linklist的形式串接，新的代幣(資源)要加入到主鍊(P2P Network)，需要主鍊上超過一半以上的Client認可後，串入其中。
會發現，Server在其中的角色和傳統P2P網路的Server有一點相似，Server所謂的交易處理，可看做傳統P2P網路中，新增檔案(資源)時，通知各個P2P Client，進行資源清單同步的動作。
當然，在區塊鍊下，區塊鍊的Server的服務更多，區塊鍊錢包的功能是以錢包為主，沒有所謂的資源，但如果以P2P和Web瀏覽器的分散性思考，比較能夠體會坊間將區塊鍊介紹為Web3.0的原因。
結論
JavaScript從一開始就是Web瀏覽器主要的執行引擎，在目前的Web開發中，具有Web瀏覽器執行的不可取代性。
因為Web的普及，Web瀏覽器是很重要的跨平台環境，這讓JavaScript具有特殊性。
又因為Web瀏覽器是在Client端作業系統中運行，讓JavaScript具有分散性。
以前Java所謂的One language run anywhere，現在的作業系統中，Windows Linux PC預設都沒有Java，Apple iOS也沒有Java，只有Android還以JavaVM為基礎。
但看看現在的Web瀏覽器，PC/Android/Apple iOS，每個平台都有，JavaScript在這個時代成為了One language run anywhere的代表。
以此為基礎，NodeJS可單獨執行，並且有Express這樣的Framework，這讓JavaScript從Web瀏覽器前端跨入伺服器後端服務程式，回想一開始期望的，假如團隊中都是Java開發者，前端到後端都使用Java開發，人力調配的便利性，如果Java改成JavaScript和NodeJS呢？
(圖和排版後續補上)
沒有留言:
張貼留言