iT邦幫忙

2022 iThome 鐵人賽

DAY 3
0

從上一篇可以了解到這個 Side project 的目的以及本次鐵人賽的目標,老實說 Javascript 並不是最適合實現這些功能的語言,但是因為本人的技能點數目前都點在 Javascript 上,比起學習不熟悉的技術,不如直接用自己摸過而且相對熟悉的工具直接上會比較快。

什麼是 Javascript ?

前端三元素之一

HTML, CSS 和 Javascript 被視做前端三元素,不論目前前端的工具怎麼演化,最終目的就是生出這三個東西給網頁瀏覽器執行。

一種程式語言

說到「程式語言」你腦海中會想到什麼?像這樣嗎?

還是這樣?

https://en.wikipedia.org/wiki/File:Used_Punchcard_(5151286161).jpg

還是程式語言就像是一種語言作為一種抽象概念存在,你的腦海並沒有浮現任何影像?

程式語言其實就像是法律條文一樣,是一套規範,定義了什麼樣的語法;電腦要怎麼解讀與執行,而不少程式語言是由發行者釋出編譯器/直譯器與文件,程式語言的使用者只要根據文件就能了解要如何操作這些編譯器/直譯器,這些編譯器/直譯器我們稱為「程式語言的實作」,常見的例子諸如:Python, PHP...。

那麼有沒有發行者只發布了「程式語言」而不包含實作的情況?有的,C, C++Javascript 就屬於這類。

GCC 與 Clang 便是兩個對於 C/C++ 不同的實作,而有些語法在不同的編譯器上會產生不同的行為,原因可能來自「未定義行為」,就是規範本身的沒有覆蓋到,不同的編譯器便自行以不同方式處理的結果,通常軟體人也會叮嚀初學者不要使用這些未定義行為的語法。(好像是學校老師很愛出這種題目,害初學者被誤導XD?)

Javascript 的(簡略)歷史

我在學習 Javascript 最困擾的就是會在不同的地方看見不同的語法,例如:

<script src="jquery-3.6.0.min.js"></script>
import $ from 'jquery'
var $ = require("jquery")

或是各種讓人眼花撩亂的打包工具,要了解 Javascript,就要了解它的生態;
而要了解它的生態就要從它的歷史說起。

它的名諱

首先,它的名字是最容易讓第一次接觸的人混亂的東西,
要解釋 Java 跟 Javascript 的關係最快的方式就是:

狗與熱狗的關係-除了名字接近之外沒有任何的關係

完全源自於命名者想要沾沾「很潮的Java」的光XD

後來高度參考 JavaScript 並由 ECMA International 發表的 ECMAScript 規範才是我們現在稱呼為 Javascript 的語言,ECMAScript 成為了它正式的名稱,不過大家早就 java, java 的叫習慣了

因為電腦性能與使用者使用習慣的限制,Javascript 在一段時間中處於只是讓網站增加一點效果的地位,於是 ECMAScript 自 1999 年釋出第三版一直到 2009 年釋出第五版,始終沒有太活躍的更新。

有一個重要的功能就是模組化載入,但是 ECMAScript 5 的規範尚不支援,但是需求又慢慢增加的情況下,社群只好自己擴展功能,最後發展出了:AMD, UMD 和 CommonJS,其中 CommonJS 則是被 Nodejs 所採用。

直到 2015 年,ECMAScript 釋出了 ES6 的標準後才年年大暴更來應對隨硬體發展及行動裝置普及帶來的需求激增。

百家爭鳴大亂鬥

於是我們迎來了一個混亂的時代:

  • 實作了 ES5 但是不支援 ES6 的瀏覽器
  • AMD, UMD, CommonJS 各種模組化方式
  • 實作了 ECMAScript 但是只能跑在 server 端的 NodeJs
  • 目標成為 JavaScript 超集合的 Typescript

所以就產生了一個問題:

我寫的語法,老舊瀏覽器不支援怎麼辦?

於是 Babel 這個工具就出現了,為了把一種 Javascript 轉換成另外一種 Javascript,它的名字源自巴比倫塔 (Tower of Babel) ,就是那個人類蓋了高塔觸怒了神祇而被懲罰變成說著不同的語言而無法互相溝通的故事,是不是很有意境呢?

並且作為模組化的 solution,Node.js-NPM-CommonJs 這個組合是發展的最好的,因為它解決了模組化衍生的相依性問題,但是這原先是被用於 server 端的 Javascript,這就產生了另一個問題:

我使用的模組化方案,瀏覽器不支援怎麼辦?

所以不只要把撰寫的 Jvascript 降成瀏覽器普及率比較高的語法,還要把這仰賴一整坨套件的 Jvascript 轉換成另外一坨能跑在瀏覽器的 Jvascript,這個行為我們稱為打包 (bundle),也是 Webpack 被創造出來欲解決的問題。

前端百家爭鳴大亂鬥 (Javascript)

使用 Javascript 操作 DOM 就能操作視圖,為了更方便的操作 DOM,各種工具陸續被發展出來:

  • D3.js: 愉快的操作 DOM 畫圖表
  • jQuery: 愉快的操作 DOM
  • Knockout.js: 用 binding 愉快的操作 DOM
  • Backbone.js: 用 binding 愉快的操作 DOM

接著為了解決頻繁操作 DOM 造成的效能低下問題而產生的各種基於 Virtual DOM 的工具:

  • Angular
  • Vue.js
  • React.js

小結

其實要了解一個工具,最快的方式就是去理解它是在什麼樣的時代背景為了解決什麼樣的問題而誕生的。畢竟機械降神一個工具,正常的反應只會是「這是啥?可以吃嗎?」或是「好喔,我知道了」的粗淺理解。只有了解了問題,才知道痛點是什麼,才能體會一個工具背後的緣由,並且當你又碰到其他痛點的時候,你就知道下一個工具(潮流)可能又要誕生了。


上一篇
Day 02 一個 Superset Side Project 引發的挖坑慘案(The Key Of Huanche 專案介紹)
下一篇
Day 04 可能性之海中的燈火 (Typescript 簡介)
系列文
關於用 Javascript (Typescript) Stack 打造某種 Backend 3D Rendering 的東東這檔事23

尚未有邦友留言

立即登入留言