你可能不需要一個 JavaScript 框架

You (probably) don`t need a JavaScript framework

我並不打算寫一篇類似於《為何 JavaScript 社群如此不堪》的文章那是因為我覺得真沒必要。只是我認為事情本來就很簡單，而且以“就地取材”的方式去做事情也確實十分有趣。下面我就為您一一娓娓道來，介紹到底 Web API 和原生 DOM 有多麼強大和多麼簡單。

I’m not going to post yet another rant about “Why the JavaScript community is so bad” or anything like that, because I don’t feel that way. I’d much rather show you that it’s actually pretty simple and surprisingly fun to do things from the ground-up by yourself and introduce you to how simple and powerful the Web API and native DOM really is.

為簡單起見，假設你每天都使用的乃是 React 框架——如果是別的框架那就把 React 換成你所屬的那個框架吧，我意思是你總得有個框架在用著。

For the sake of simplicity, let’s assume your everyday framework is React but if you use something else, replace React with X framework because this will still apply to you too.

React, Virtual DOM, Webpack, TypeScript, JSX…

HOLD ON! Let’s pause for a second here and think.且慢！這堆東西，容我想想~

讓我們追根溯源，回答第一個問題，當時為啥會有這些框架？

Let’s start from the beginning and ask ourselves why do these things exist in the first place?

虛擬 DOM 以效能卓越著稱，但是原生 DOM 的效能著實會慢多少，才會讓使用者察覺呢？這就是你要取捨的問題啦。雖然節省了 DOM 操作時間不過增加了 45KB 大小，使用者壓根不知道里面什麼鬼。

Virtual DOM is efficient and has good performance, but native DOM interaction is insanely fast and your users will not notice any difference. This is where you have to choose what sacrifice you want to make. Add 45KB of extra size to your app to save a couple of milliseconds for DOM manipulation that is completely invisible to the user.

某些壓力測試工具，如 DBMON，人家是為科研目的而搞的，結果呢，我見到很多人把它用來測試框架的成績，看看哪個快。然而實際中誰會在 DOM 中搞那麼多運算操作？如果你真想對比成績，我建議測試 WebGL（這裡假設你用 DOM 樹來寫遊戲，那樣就好對比）。

Stress-testing tools like DBMON is good to have for scientific purposes, but all too oftenI`ve seen these tests being used in arguments between developers to decide which framework is the best. The reality is that it is a stress-testing tool and nobody does that many DOM manipulations in reality, and if you do you seriously have to reconsider to use WebGL instead (clarification; by that point, my guess is that you`re trying to build a game using the DOM tree).

普通優化可達 46 幀每秒而 React 優化才36 幀每秒，所以我不知道 React 有什麼用？

With optimized vanilla I get 46 repaints/sec while optimized React gives 36 repaints/sec, so I don`t know what`s up with that?

我後來刪除了，因為那論點文不對題。

I`ll redact that, it`s irrelevant and doesn`t contribute to the post.

React 呢，本身是臉書用來解決大批量資料、UI 動作和資料量的方案，開源了，而且越來越多人用，甚至覺得，“臉書解決了他們的問題，就是解決了我自己的問題”。

React was created to solve the issues Facebook were facing with their massive amount of data, activity and size. They then went ahead andopen-sourced it and released it to the public, where many developers seem to have come to the conclusion that “ Facebooks’ solution to their problem is the solution to my problem”.

就大多數情況，實不盡然。

This – in the majority of cases – is not true.

更新 UPDATE (30/4 17:30 CET):

談到 React 就引發不少撕。在文末我重點談了談，尤其程式的狀體相關的討論。

Many have raised concerns about using React in this context. I`ve adressed some of these concerns at the bottom of this post, especially application state-related arguments.

另外，煩請大家通讀全文之後再下結論

Additionally, please read through the whole post if you`re going to make a statement – there`s been way too many reactions that has already been accounted for (e.g mentioning features that isn`t available in every browser is adressed in the polyfilling section).

瀏覽器本身，不容小覷 Don`t underestimate the browser

還用說麼，瀏覽器如此地強大，容納了那麼多的功能而且幾乎都跨平臺了。原生 Web API 和 DOM API 實話說已經夠你玩了，而且效能也還可以嘛，各個瀏覽器跑起來載入時間不會太久。君不見 JS 是一門實時編譯的、動態型別的語言，但諸如 V8、SpiderMonkey 和 Chakra 的 JS 引擎卻效能彪悍。我曾經把 v8 和其他編譯型、靜態型別的語言作效能對比，差距不是很大。這裡我得鄭重地表揚這些 JS 引擎開發的大神們，沒有他們的埋頭苦幹，今天 web 沒有如此出色。

The browser is a very powerful platform, considering most implementations have cross-platform support with a lot of additional functionality.

The native Web API and DOM API is more than enough to power your application and gives you really good performance, meanwhile having great loading times across all platforms.

The underlying JavaScript engines like V8, SpiderMonkey and Chakra is almost scary fast considering JavaScript is a runtime-interpreted, dynamically typed language. I`ve seen V8 rival a few compiled, statically typed languages in terms of performance, and that is not something you should take lightly. I am very thankful for the hard work these engine developer teams has put into their respective JavaScript engine. The web would not be as capable as it is today without them.

未完待續……