這篇文章故意具有挑戰(zhàn)性、兩極化和發(fā)人深省的特點(diǎn)。它涵蓋了很多你很可能不知道的新鮮內(nèi)容和想法。

[[423076]]

1. 緒論

我將盡力創(chuàng)造一個(gè)連貫的邏輯論證鏈，你可以按照它來了解前端開發(fā)應(yīng)該如何運(yùn)作。

我也會(huì)盡量保持這篇博文的簡(jiǎn)單性，以便 "非開發(fā)人員 "大多能夠跟上。

2. 一臺(tái)電腦或智能手機(jī)上有多少個(gè)內(nèi)核?

你們都見過像這樣的CPU的圖片。

例如，如果你使用的是Mac，你可以點(diǎn)擊左上角的蘋果圖標(biāo)，然后點(diǎn)擊 "About This Mac"，它將顯示類似的內(nèi)容。

處理器 3,2 GHz 8核英特爾至強(qiáng)W處理器

一部iPhone有6個(gè)內(nèi)核。

每臺(tái)電腦或智能手機(jī)都有幾個(gè)核心可用。

這意味著你可以并行地運(yùn)行多個(gè)線程。

你會(huì)只用一個(gè)發(fā)動(dòng)機(jī)氣缸來跑一輛車嗎?

如果你的答案是："當(dāng)然不是!"。這將是非常緩慢的!"，那么你應(yīng)該仔細(xì)閱讀這篇文章。

3. 一個(gè)瀏覽器使用多少個(gè)內(nèi)核?

就其本身而言，瀏覽器將在每個(gè)標(biāo)簽/窗口中只使用一個(gè)內(nèi)核。

意思是：你的Angular或React應(yīng)用程序看起來像這樣。

你的應(yīng)用程序中運(yùn)行的JavaScript任務(wù)越多，它的速度就越慢。最糟糕的情況是UI完全凍結(jié)，你的一個(gè)核心處于100%的狀態(tài)，而其他所有的核心都完全閑置。

這根本就不具有可擴(kuò)展性。

[題外話】如果你正在創(chuàng)建簡(jiǎn)單、小型和相當(dāng)靜態(tài)的網(wǎng)站或應(yīng)用程序，這種設(shè)置就足夠了。

4. Web Worker API

Web Workers API - Web APIs | MDN

Web Workers使得在獨(dú)立于主執(zhí)行線程的后臺(tái)線程中運(yùn)行腳本操作成為可能... developer.mozilla.org

Web Workers 使得在一個(gè)獨(dú)立于 Web 應(yīng)用程序的主執(zhí)行線程的后臺(tái)線程中運(yùn)行腳本操作成為可能。這樣做的好處是，可以在一個(gè)單獨(dú)的線程中進(jìn)行費(fèi)力的處理，使主線程(通常是 UI)的運(yùn)行不會(huì)被阻塞/減慢。 Web Worker - 維基百科 zh.wikipedia.org

W3C和WHATWG設(shè)想Web工作者是長(zhǎng)期運(yùn)行的腳本，不會(huì)被響應(yīng)點(diǎn)擊或其他用戶交互的腳本所打斷。讓這樣的工作者不被用戶活動(dòng)打斷，應(yīng)該可以讓網(wǎng)頁(yè)在后臺(tái)運(yùn)行長(zhǎng)任務(wù)的同時(shí)保持響應(yīng)性。

Worker 最簡(jiǎn)單的用途是在不中斷用戶界面的情況下執(zhí)行一項(xiàng)計(jì)算量大的任務(wù)。

因此，使用工作者，我們實(shí)際上可以并行使用多個(gè)核心，結(jié)束這種可擴(kuò)展性的噩夢(mèng)。

讓下面這段話真正沉淀下來。

Worker最簡(jiǎn)單的用途是在不中斷用戶界面的情況下執(zhí)行一項(xiàng)計(jì)算量大的任務(wù)。

這導(dǎo)致了一個(gè)問題。

"什么是最昂貴的任務(wù)?”

答案很簡(jiǎn)單：UI框架或庫(kù)本身，以及我們用它構(gòu)建的應(yīng)用程序。

這就引出了一個(gè)想法。讓我們把所有能移出主線程的東西都移出來，這樣這個(gè)線程就能純粹地專注于它要做的事情：操作DOM。

如果你的應(yīng)用程序不再在主系統(tǒng)中運(yùn)行，那么就沒有什么東西可以減緩或阻止你的用戶界面或產(chǎn)生內(nèi)存泄漏。

這種想法正導(dǎo)致以下概念。

5. 一個(gè)應(yīng)用Worker是主要的行為者范式

為了解決這個(gè)性能瓶頸，我們希望讓主線程盡可能地空閑下來，這樣它們就可以完全專注于渲染/動(dòng)態(tài)操作DOM。

現(xiàn)在可能發(fā)生的最壞情況是，你的應(yīng)用程序工作者會(huì)放慢速度，而這個(gè)核心以100%的速度運(yùn)行。然而，這不會(huì)影響你的用戶界面(渲染線程→主線程)。

對(duì)于單頁(yè)應(yīng)用程序(SPA)來說，可能是最好的解決方案，看起來像這樣。

為了防止應(yīng)用程序Worker處理過多的邏輯，我們可以選擇使用虛擬 DOM 工作器，在那里計(jì)算狀態(tài)轉(zhuǎn)換之間的延遲更新。對(duì)于具有相當(dāng)空閑的應(yīng)用Worker的應(yīng)用程序，你可以選擇直接在應(yīng)用Worker內(nèi)部運(yùn)行虛擬DOM引擎來代替。

我們還可以使用一個(gè)數(shù)據(jù)Worker。如果我們有一個(gè)遠(yuǎn)程數(shù)據(jù)存儲(chǔ)，并希望在本地對(duì)數(shù)據(jù)進(jìn)行排序/分組/過濾，這些計(jì)算可以在那里進(jìn)行。

這篇博文介紹了如何在保持相同的 API 的情況下使Worker的使用成為可有可無的。

JavaScript開發(fā)。制作一個(gè)可供選擇的Web Worker。

如果你有很多與JavaScript相關(guān)的邏輯在主線程或Web Worker內(nèi)運(yùn)行，這就很有意義了。

6. Worker可以訪問DOM嗎?

在WorkerGlobalScope里面，window和window.document是未定義的。

意思是：你根本無法直接訪問真正的DOM。

因此，我們?cè)谶@里基本上有兩個(gè)選擇。

選項(xiàng) 1 是在Worker內(nèi)部重新創(chuàng)建整個(gè) DOM API。在我看來，這是個(gè)壞主意。Worker不了解 DOM 是有原因的，而且有大量的邏輯在頻繁變化。DOM OPs 變得不同步，如果你依次觸發(fā)了很多，就會(huì)導(dǎo)致大量的 Worker postMessages。唯一的好處是，你可以像以前一樣繼續(xù)寫你的應(yīng)用程序，這是值得懷疑的。我將在后面介紹如何做得更好。

實(shí)際上，有一個(gè)項(xiàng)目正是這樣做的。

GitHub - ampproject/worker-dom: 你所知道的相同的DOM API和框架，但在一個(gè)Web Worker中。

更聰明的做法是選項(xiàng)2：堅(jiān)持Worker不應(yīng)該知道真正的DOM的概念。

這使得使用虛擬DOM成為絕對(duì)必要的。

在社交媒體上閱讀時(shí)，我經(jīng)?？吹筋愃?"vdom is bad!"這樣的帖子，很頻繁。

這根本不是真的。這在很大程度上取決于它是如何被實(shí)施的。

Angular和React的主要障礙是基于xml或JSX的模板。這些家伙需要被轉(zhuǎn)換為我們可以使用的數(shù)據(jù)結(jié)構(gòu)。

JavaScript既不快，也不是為解析字符串而生。

解析模板的成本很高，甚至服務(wù)器端渲染(SSR)又開始流行。我在20年前就去過那里，創(chuàng)建了一個(gè)基于PHP的CMS，生成html輸出文件。

你可以說，今天有了云，可以處理更多的客戶端連接，但富/胖/厚客戶端的概念仍然完全有意義。

7. 是否有一個(gè)例外，Worker可以訪問DOM?

實(shí)際上有一個(gè)。

OffscreenCanvas - Web APIs | MDN OffscreenCanvas接口提供了一個(gè)可以在屏幕外渲染的畫布。它在窗口和屏幕外都可以使用。

Worker可以接收 Canvas DOM節(jié)點(diǎn)的所有權(quán)。

這在Chromium中已經(jīng)運(yùn)行得很好了，Safari(Webkit)和Firefox正在積極實(shí)施。這可能還需要6個(gè)月的時(shí)間，所以這是2022年的一個(gè)話題。

8. 如何以一種聰明的方式創(chuàng)建虛擬DOM?

雖然JavaScript不擅長(zhǎng)解析字符串，但它擅長(zhǎng)處理嵌套的對(duì)象/陣列結(jié)構(gòu)。這種格式有一個(gè)名字，你肯定很熟悉。JSON。

如果我們堅(jiān)持使用基于JSON的vdom語法，就不需要在你的用戶界面中反復(fù)進(jìn)行昂貴的模板解析，甚至不需要將這部分移到構(gòu)建步驟中。

這無疑在某種程度上類似于直接使用JSX輸出的工作。

做得好的話，虛擬DOM里面沒有變量、if/else語句、綁定、方法、循環(huán)或任何形式的邏輯。你永遠(yuǎn)不會(huì)看到有1000多行代碼的模板(看Angular)。

使用程序化的方法，你將在屬于它的地方使用邏輯：在JavaScript內(nèi)部。例如，在創(chuàng)建一個(gè)列表時(shí)，你可以先創(chuàng)建一個(gè)骨架的Vdom，一旦數(shù)據(jù)存儲(chǔ)被加載，就在記錄上進(jìn)行迭代，并在運(yùn)行中創(chuàng)建新的虛擬DOM節(jié)點(diǎn)。

這個(gè)概念允許我們?cè)谶\(yùn)行時(shí)從根本上改變一個(gè)組件的Vdom。是的，在一個(gè)組件被安裝之前和之后，改變它的vdom的工作方式是完全一樣的。

• 實(shí)現(xiàn)無限滾動(dòng)或其他高級(jí)功能變得很容易。
• 你可以在這里找到更多的投入。
• 您使用基于JSON的虛擬DOM的好處。
• 基于JSON的虛擬DOM的新格式化概念。

雖然程序化的方法對(duì)低級(jí)別的vdom OPs來說是有意義的，但我們肯定更喜歡用聲明式的方法來創(chuàng)建我們的應(yīng)用程序。

為了實(shí)現(xiàn)這兩點(diǎn)，我們唯一需要做的就是在vdom上面增加一個(gè)聲明性的抽象層：組件樹。

意思是：你只在創(chuàng)建你的組件類時(shí)使用vdom。對(duì)于創(chuàng)建應(yīng)用程序，你可以只堅(jiān)持使用組件樹。

9. UI開發(fā)可以直接在瀏覽器中進(jìn)行嗎?

當(dāng)React在5到8年前開始流行的時(shí)候，瀏覽器在支持最新的ECMAScript功能方面的狀況很糟糕。

例如，沒有對(duì)類(ES6)或JS模塊的支持。

在這一點(diǎn)上，將UI開發(fā)轉(zhuǎn)移到node中是完全合理的。

意思是：你可以使用最新的語言功能，并以一個(gè)構(gòu)建步驟為代價(jià)，將你的代碼編譯/轉(zhuǎn)譯成瀏覽器能夠理解的Javascript。

瀏覽器供應(yīng)商在追趕方面做得很好。今天，許多閃亮的新功能都可以直接使用，而且大多數(shù)第三階段的建議確實(shí)可以立即實(shí)施。

在Worker范圍內(nèi)，JS模塊在Chromium內(nèi)工作正常。Webkit(Safari)也完成了實(shí)現(xiàn)，但它仍然限于Safari技術(shù)預(yù)覽版。Mozilla(火狐)正在積極地推動(dòng)它。

我們可以肯定地認(rèn)為，全面支持在2022年準(zhǔn)備就緒。

構(gòu)建步驟很昂貴，對(duì)于UI庫(kù)或框架的開發(fā)模式來說，應(yīng)該不再需要。

其優(yōu)勢(shì)是顯而易見的。

• JavaScript是為了成為唯一能被瀏覽器引擎理解的編程語言。
• 以瀏覽器無法理解的方式編寫JS，感覺就是錯(cuò)誤的。
• 通過將UI開發(fā)帶回瀏覽器，我們可以調(diào)試我們的真實(shí)代碼，而不需要任何形式的構(gòu)建/轉(zhuǎn)譯或使用源代碼地圖。
• 我們不需要熱模塊的替換。

特別是創(chuàng)建和調(diào)試代碼將再次成為一種樂趣，因?yàn)槲覀兛梢源_保沒有外部因素導(dǎo)致的錯(cuò)誤。

像webpack這樣的工具肯定還是需要的，以創(chuàng)造地區(qū)/生產(chǎn)的輸出。然而，它們將是構(gòu)建工具，而不是運(yùn)行時(shí)環(huán)境。

從node到deno的轉(zhuǎn)換將進(jìn)一步促進(jìn)這一點(diǎn)。CommonJS將遲早消亡。一旦deno有了一個(gè)包管理器，越來越多的包將使用可以在瀏覽器中運(yùn)行的語法(例如，不使用裸模塊指定符→導(dǎo)入無效的路徑和沒有文件名擴(kuò)展)。

10. TypeScript有前途嗎?

這一條可能是本文中最有爭(zhēng)議的部分。JS社區(qū)一分為二：有些人喜歡使用TS，而有些人則拒絕碰它。期待大家的討論。

我的意見。

現(xiàn)在，當(dāng)在node中開發(fā)UI，并且有一個(gè)必要的構(gòu)建/轉(zhuǎn)譯步驟時(shí)，使用TS就可以了。

一旦UI開發(fā)重新進(jìn)入瀏覽器，這種情況將發(fā)生根本性的改變。

你會(huì)為使用TS而設(shè)置一個(gè)完整的構(gòu)建步驟嗎?

在這一點(diǎn)上，它變得太昂貴了。

問題是。TS不是一個(gè)網(wǎng)絡(luò)標(biāo)準(zhǔn)。目前還沒有計(jì)劃在瀏覽器中實(shí)施它。

歷史已經(jīng)多次告訴我們，不基于網(wǎng)絡(luò)標(biāo)準(zhǔn)的網(wǎng)絡(luò)技術(shù)會(huì)發(fā)生什么：它們會(huì)在某個(gè)時(shí)刻消失。MS Silverlight就是一個(gè)完美的例子。

一般來說，類型檢查是個(gè)好東西。主要問題是Angular和React沒有使用基于JSDoc的注釋，而JSDoc可以讓IDE在寫代碼時(shí)給你發(fā)出警告。

實(shí)際上，甚至有可能使用基于JSDoc的評(píng)論來 "偽造 "TS。

如何在JSDoc注釋中編寫TypeScript接口

這絕對(duì)是一個(gè)選擇，我們可以討論。

如果你真的想在你的編程語言中直接進(jìn)行類型檢查，并且不關(guān)心構(gòu)建步驟，那么Dart2是不是更適合?

Dart2完全支持Worker，所以我們也可以讓W(xué)orker的設(shè)置在那里運(yùn)行。在移動(dòng)方面的優(yōu)勢(shì)包括AOT編譯。

11. React有什么問題?

公平地說：在React之前，有JQuery。當(dāng)React開始流行時(shí)，這是一個(gè)很大的改進(jìn)，React是第一個(gè)使虛擬DOM流行的庫(kù)。

那么，為什么我們不應(yīng)該在2022年使用React呢?

• React在主線程內(nèi)運(yùn)行。
• React的代碼庫(kù)是基于CommonJS的→沒有構(gòu)建步驟，它不能在瀏覽器內(nèi)運(yùn)行。
• 沒有JSDoc的評(píng)論。
• JSX模板的解析成本很高。甚至還有像Svelte這樣的編譯器來把它移到服務(wù)器端。
• React并沒有暴露出一個(gè)核心。所有的東西都擴(kuò)展了Component，這一點(diǎn)都沒有意義。
• 狀態(tài)管理無緣無故地太難了。
• render()方法無疑是有問題的。

讓我更深入地解釋一下這個(gè)問題：要防止?fàn)顟B(tài)變化觸發(fā)渲染，肯定是很復(fù)雜的。如果一個(gè)React組件包含子組件(render()里面的自定義標(biāo)簽)，在你沒有仔細(xì)使用key的情況下，新的實(shí)例會(huì)被創(chuàng)建。

重新創(chuàng)建Component實(shí)例使函數(shù)式編程流行起來，因?yàn)閯?chuàng)建類實(shí)例的頻率超過了必要的范圍，而且在你自己的Component實(shí)現(xiàn)中的內(nèi)存泄漏會(huì)造成傷害。

如果你有很多狀態(tài)道具，例如影響項(xiàng)目的位置，你將需要在你的JSX中添加相當(dāng)多的邏輯。

React只是一個(gè)庫(kù)，而不是一個(gè)框架。意思是說。組件幾乎是里面的全部?jī)?nèi)容。沒有邏輯上的層次鏈，比如。

core.Base -> component.Base -> button.Base -> tab.header.Button

一旦解決了render()的瘋狂，你就可以為你想創(chuàng)建的東西挑選最合適的基類。例如，一個(gè)容器有一個(gè)vdom對(duì)象，它包含對(duì)其子項(xiàng)的vdom對(duì)象的引用。然后，我們可以改變子組件的vdom，而不需要重新創(chuàng)建它們基于JS的實(shí)例。

在這一點(diǎn)上，狀態(tài)管理變得微不足道，我們甚至不需要鉤子。特別是在確保對(duì)vdom引擎最多有一次調(diào)用的情況下，并行改變?cè)S多配置是關(guān)鍵。

12. 多窗口應(yīng)用程序

將Worker的設(shè)置換成使用SharedWorkers，可以選擇性地增強(qiáng)這一概念。

這使我們能夠在不同的瀏覽器窗口中移動(dòng)整個(gè)組件樹，同時(shí)保持其JS實(shí)例的位置。

多窗口狀態(tài)管理，不需要后臺(tái)。

可以進(jìn)行跨窗口拖放。

13. 我們是否需要自己實(shí)現(xiàn)工人的設(shè)置?

獨(dú)自實(shí)施所有提到的想法簡(jiǎn)直要花上幾年時(shí)間。

你很幸運(yùn)，我已經(jīng)為你做了。生態(tài)系統(tǒng)內(nèi)有超過12,000個(gè)提交，完全由MIT授權(quán)。

GitHub - neomjs/neo：應(yīng)用工作者驅(qū)動(dòng)的前端框架。

這包括一個(gè)遠(yuǎn)程方法訪問API，使你能夠通過承諾(消息傳遞之上的抽象層)直接調(diào)用不同工作者或主的方法。

大量的組件已經(jīng)到位，還有控制器、視圖模型、應(yīng)用程序和其他實(shí)用類。

你不需要任何第三方庫(kù)來支持像MVVM、Observable和其他許多架構(gòu)設(shè)計(jì)模式。

尤其是狀態(tài)管理是非常容易的(提示：一個(gè)類的配置系統(tǒng))。

CLI是先進(jìn)的：你可以用一個(gè)單行字創(chuàng)建一個(gè)新的應(yīng)用程序(工作區(qū))：npx neo-app 。我們甚至可以得到跨應(yīng)用的分割塊，所以在把多個(gè)應(yīng)用放在一個(gè)頁(yè)面上時(shí)，幾乎沒有開銷。

14. 最后的想法

其實(shí)你不必等到2022年，你現(xiàn)在就可以使用這些想法，讓你的前端開發(fā)更上一層樓。一些公司和開發(fā)人員已經(jīng)在做了，并且正在利用他們的先機(jī)將新技術(shù)轉(zhuǎn)化為商業(yè)優(yōu)勢(shì)。

neo.mjs被提名為 "最令人興奮的技術(shù)應(yīng)用"。

大多數(shù)開發(fā)者仍然不知道neo.mjs項(xiàng)目的存在，這讓人很無奈。

我很想看到有人在這些概念上證明我是錯(cuò)的。

要做到這一點(diǎn)，你將需要?jiǎng)?chuàng)建你的第一個(gè)基于neo的PoC應(yīng)用。

在這種情況下，我希望能審查你的代碼。

對(duì)于在運(yùn)行時(shí)的動(dòng)態(tài)DOM操作，neo是最快的選擇。特別是當(dāng)它涉及到大型和復(fù)雜的應(yīng)用程序時(shí)。

15. 如何開始?

我剛剛創(chuàng)建了一個(gè)關(guān)于如何使用這項(xiàng)技術(shù)實(shí)際建立一個(gè)應(yīng)用程序的教程。

定義一個(gè)web4.0應(yīng)用為多線程的應(yīng)用。