本系列文為節選第 468 期 JavaScript Weekly 文章的讀後整理心得。
本文為「下」，收錄內容：
- Vue 3.0 的設計概念
- TypeScript 的 const assertion
- Preact 華麗復活
- 阿 Svelte 不是很邱？
Vue 3.0 的設計概念
作者現身說法 Vue 3.0 本著什麼樣的理念在設計的。基本出發點就是先考慮「誰在用」、「怎麼用」，於是衍伸出了需要同時兼顧「好上手」又具有「可延展性」。
好上手 vs 可延展性
簡單的概括有提到的例子：
- CDN build -> 菜雞
- Vue CLI -> 狠角色
😅
- Options API -> 菜雞
- Composition API -> 狠角色
😅
- JavaScript ->
菜雞 - TypeScript ->
狠角色 - cons: learning cost
- cons: slower initial development
這邊說到 Vue 3.0 用 TypeScript 寫只是為了有效提供強力的 IDE hint，因為希望保持好上手、容易維護的本質。3.0 用 JavaScript 或是 TypeScript 寫出來的 Vue component code 會長得差不多。
😅
- Template ->
菜雞 - JSX ->
狠角色
Templates allows us to get better performance
由於使用 template 寫法可以給 compiler 更好的 diffing 捷徑，不需要走過整個 tree，Vue 3.0 使用 template 的寫法可以得到更好的效能。
力量越大、包越大
其實這 part 也是延續上一 part 的概念，但切入的角度不同，所以我就把它們分開來寫了。
用不上的功能就不要包近來：
- ES module export + tree shaking
- 連 template 寫法裡用上的內建 component，也是透過 complier 自動 import
接著就提到了有點接近於 library vs framework 的議題，這段整理的不錯，所以我打算寫詳細一點。
舉 React 當作 low-level 的範例：
優點
- 起始概念少
- 選擇很多 -> 生態蓬勃/造成困擾
- 從維護角度看，React 開發團隊只需要專注於 library 本體
缺點
- 需要自己想辦法解決較複雜的問題
- 約定成俗的規矩沒有寫在官方文件 (e.g. Redux)
- 生態系動得太快，third-party library 容易被丟包 (open source 萬歲)
接著舉 Ember.js, Angular 做為 framework 範例：
優點
- 大部分問題的解法都內建
- 整個生態系不太會有丟包的問題，大家是一起動的
缺點
- 起手門檻高
- 內建的問題解法不適用的時候，做得不夠有彈性的話，會無法解決特殊問題
- 因為包太多東西，想要做大改動比較困難 (e.g. 像 Angular 1 想要大改就掛了)
Vue 想要走的道路是 Progressive。
(秀出那張圖，你知道哪張)
- 分層的功能設計
- 低起手門檻
- 官方(文件)有提供常見問題解法
Vue 3 也會保持這個理念，你有需要，在學/用就好。
開放 low-level API 帶來更多彈性
官方提供詳細的 low-level API 用法：
- 自定 renderer
- 開放 compiler 使用
TypeScript 的 const assertion
沒在用 TypeScript 也可以大概了解它的作用。
TypeScript 在判斷型別的時候是相當嚴謹的。
一般情況下你用 const 來宣告 literal Object 或是 literal Array 的時候，就算你本意沒有要改變它們內容的意思，對 TypeScript 來說它們的型別沒有辦法被推定到接近 enum 那種的定值。
文中用的例子是 HTTP request 的 method，這邊寫精簡一點只留下四大天王：
const HTTPRequestMethod = {
DELETE: "DELETE", // type: string
GET: "GET",
POST: "POST",
PUT: "PUT"
};
// 此動作不會有 type error
HTTPRequestMethod.DELETE = "TIMON"; // type: string
// 正因為可以進行這個操作，
// HTTPRequestMethod.DELETE 才沒有被推定為 "DELETE" type
那麼使用新的 const assertion，就可以達到接近 enum 的效果：
const HTTPRequestMethod = {
DELETE: "DELETE", // type: "DELETE"
GET: "GET",
POST: "POST",
PUT: "PUT"
} as const; // <- 加在這邊
// Error: Cannot assign to 'GET'
// because it is a read-only property.
HTTPRequestMethod.DELETE = "TIMON";
同樣在 literal Array 上也適用，有把 Array 變成 Tuple 的效果：
const ORIGIN = [0, 0] as const;
// 等於 const ORIGIN: readonly [0, 0] = [0, 0]
至於為什麼不乾脆用 enum 就好了？因為 enum 就是 TypeScript 額外帶來的東西，有些工程師會希望雖然寫的是 TypeScript，在可能的範圍還是盡量接近 JavaScript。
實際上 TypeScript 的 enum 在 compile 過後也就是 JavaScript Object 這樣。
var HTTPRequestMethod;
(function (HTTPRequestMethod) {
HTTPRequestMethod["DELETE"] = "DELETE";
HTTPRequestMethod["GET"] = "GET";
HTTPRequestMethod["POST"] = "POST";
HTTPRequestMethod["PUT"] = "PUT";
})(HTTPRequestMethod || (HTTPRequestMethod = {}));
Preact 華麗復活
Preact 初心主打做為短小精悍版的 React 其實相當成功，畢竟容量實在省下太多了…
Fast 3kB alternative to React with the same modern API.
React 會這麼大當然是有原因。React 建立了一套自己的 SyntheticEvent 系統，它把瀏覽器的事件系統打包並經過正規化，提供給了 React 及 React 使用者一些彈性。而 Preact 會小是因為它直接使用瀏覽器的 Event 系統，整整少了一大包。
但從一個 React 使用者的角度，Preact 要吸引你過去當然還是要更大的誘因，畢竟 Preact 小包的前提是它能使用的 API 有限，並且不完全與 React 相容。於是，Preact 團隊推出了 preact-compact，做為銜接 React 使用者的橋樑，只要引入它就可以相容幾乎全部的 React 語法與各種現成的 React component。
前言講完了(挖靠講這麼多才講完前言)，可以進入正題啦！
Preact 的這套做法有成功吸引到一群使用者，當年 Addy Osmani 君在講 PWA 的時候也有推過，畢竟容量小 94 屌。
但 React 在進入了版號開放年代(就是 0.15.x -> 16.x)之後，功能爆炸性成長，加上 Fiber 架構的改動，Preact 在功能追趕上面漸漸顯露出疲態。
其實我一度覺得 Preact 要涼了。
現在 PreactX (版號10.x) 推出就是 Preact 回歸的一劑強心針：
- Fragments
- Hooks
- componentDidCatch
- createContext
然後他們也認清了 Preact 終究是離不開 preact-compact 這個 package，於是直接把它併入 preact package 裡面去了，之後只要 import React from 'preact/compact'; 就可以使用囉！
React 近年的爆炸性發展真的是很難跟上… Preact 真是辛苦你了。但如果每每都需要等 Preact 跟上才能使用 React 新功能的話，我想 Preact 使用者大概會漸漸跳回來吧…
之前我光等 react-apollo 官方支援 hooks 就望眼欲穿了 😫
阿 Svelte 不是很邱？
這是一篇超長的 React vs Svelte 戰文，本文作者是支持 React 那邊的。
他在看完 Svelte 官網跟 Svelte 社群發的文章之後，忍無可忍(?)跳下來開戰。
主因是 Svelte 太愛帶風向了 😆
列舉了兩個帶風向的大分類，作者都用自己的角度給予反擊。這邊我建議大家對 Svlete 跟 React 有些瞭解之後再來詳細看作者的論述。
- React 最愛重繪了
- 根本不需要什麼 vDOM
接著提了 Svelte 隨著時間可能可以解決的弱點：
- TypeScript 支援
- 還不夠成熟，相關 package 太少
最後收尾直接嘴爆：
Despite above described limitations, I think Svelte actually brings up an invaluable idea. Yes, you cannot fully express a modern app through templates without sacrificing flexibility and code reusability.
To be honest, I don’t believe Svelte in its current form can defeat React and conquer the world.
Svelte 風向仔下去～
最後段也有稍微提到一下 code 可讀性的問題，文章作者是 JSX 派的，那麼我想對 Svelte 的不喜歡應該是從一開始就埋在骨子裡了 😎
畢竟他可是愛 JSX 愛到從 Vue 跳到 React 呢！
