建站
咨詢
售后
建站咨詢
新聞中心
在我的日常工作中，我致力于一個(gè) JavaScript 框架（LWC）。盡管我已經(jīng)在這個(gè)項(xiàng)目上工作了將近三年，但我仍然覺得自己是一個(gè)業(yè)余愛好者。當(dāng)我閱讀有關(guān)更大的框架世界的信息時(shí)，常常因?yàn)椴涣私獾氖虑樘喽械讲恢搿?/p>
公司主營(yíng)業(yè)務(wù)：成都網(wǎng)站建設(shè)、網(wǎng)站制作、移動(dòng)網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競(jìng)爭(zhēng)能力。創(chuàng)新互聯(lián)是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對(duì)我們的高要求，感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn)，讓我們激情的團(tuán)隊(duì)有機(jī)會(huì)用頭腦與智慧不斷的給客戶帶來驚喜。創(chuàng)新互聯(lián)推出博野免費(fèi)做網(wǎng)站回饋大家。
然而，學(xué)習(xí)事物的最佳方法之一是親自動(dòng)手構(gòu)建。而且，我們要繼續(xù)保持那些 “距上一個(gè) JavaScript 框架的天數(shù)” 模因的持續(xù)。因此，讓我們來編寫我們自己的現(xiàn)代 JavaScript 框架吧！
什么是“現(xiàn)代 JavaScript 框架”？
React 是一個(gè)出色的框架，我不是來貶低它的。但在這篇文章中，“現(xiàn)代 JavaScript 框架”指的是“React 時(shí)代后的框架” - 即 Lit、Solid、Svelte、Vue 等。
由于 React 在前端領(lǐng)域占據(jù)主導(dǎo)地位已久，每個(gè)更新的框架都在其陰影下成長(zhǎng)。這些框架都受到了 React 的很大啟發(fā)，但它們?cè)谘葸M(jìn)中以出奇的相似方式遠(yuǎn)離了 React。盡管 React 本身一直在創(chuàng)新，但我發(fā)現(xiàn)后來的框架在現(xiàn)今更類似于彼此，而不是 React。
為了保持簡(jiǎn)單，我還將避免討論像 Astro、Marko 和 Qwik 這樣以服務(wù)器為先的框架。這些框架在其自身的領(lǐng)域表現(xiàn)出色，但與以客戶端為重點(diǎn)的框架相比，它們來自稍微不同的思維傳統(tǒng)。因此，在本文中，我們只討論客戶端渲染。
現(xiàn)代框架有哪些特點(diǎn)？
從我的角度來看，React 時(shí)代后的框架都集中在相同的基本理念上：
- 使用響應(yīng)性（例如 signals）進(jìn)行 DOM 更新。
- 使用克隆的模板進(jìn)行 DOM 渲染。
- 使用像 和 Proxy 這樣的現(xiàn)代 Web API，使上述所有工作更容易。
需要明確的是，這些框架在微觀層面上差異很大，它們?cè)谔幚碇T如 Web 組件、編譯和用戶界面 API 等方面的方式也不同。并非所有的框架都使用 Proxy。但總體來說，大多數(shù)框架作者似乎在上述理念上達(dá)成了共識(shí)，或者正在朝著這個(gè)方向發(fā)展。
因此，對(duì)于我們自己的框架，讓我們?cè)囍鴮?shí)現(xiàn)這些理念的最基本部分，首先從響應(yīng)性開始。
響應(yīng)性
人們常說 “?React 不是響應(yīng)式的”。這意味著 React 具有更多基于拉取而不是推送的模型。簡(jiǎn)單來說，在最糟糕的情況下，React 假設(shè)整個(gè)虛擬 DOM 樹都需要從頭開始重建，防止這些更新的唯一方法是實(shí)現(xiàn) React.memo（或在舊時(shí)代，shouldComponentUpdate）。
虛擬 DOM 緩解了“摧毀一切，從頭開始”的策略的一些成本，但并未完全解決它。要求開發(fā)人員編寫正確的 memo 代碼是一場(chǎng)失敗的戰(zhàn)斗（請(qǐng)查看 ?React Forget，這是一個(gè)持續(xù)嘗試解決此問題的項(xiàng)目）。
相反，現(xiàn)代框架使用了一種推送式的響應(yīng)模型。在這種模型中，組件樹的各個(gè)部分訂閱狀態(tài)更新，并僅在相關(guān)狀態(tài)更改時(shí)更新 DOM。這更注重“默認(rèn)情況下高性能”的設(shè)計(jì)，以換取一些前期記賬（bookkeeping）成本（特別是在內(nèi)存方面），以跟蹤哪些狀態(tài)部分與 UI 的哪些部分相關(guān)。
需要注意的是，這種技術(shù)不一定與虛擬 DOM 方法不兼容：Preact Signals 和 Million 這樣的工具表明你可以有一個(gè)混合系統(tǒng)。如果你的目標(biāo)是保留現(xiàn)有的虛擬 DOM 框架（例如 React），但對(duì)于性能敏感的情況有選擇地應(yīng)用推送模型，則這是有用的。
在這篇文章中，我不打算詳細(xì)討論信號(hào)本身的細(xì)節(jié)，或者像細(xì)粒度響應(yīng)等更微妙的主題，但我會(huì)假設(shè)我們將使用一種響應(yīng)系統(tǒng)。
注意：在討論什么算是 “響應(yīng)式” 時(shí)有很多細(xì)微差別。我的目標(biāo)是在這里對(duì)比 React 和 React 時(shí)代后的框架，尤其是 Solid、Svelte v5 的“runes”模式和 Vue Vapor。
克隆 DOM 樹
很長(zhǎng)一段時(shí)間以來，在 JavaScript 框架的共同智慧中，渲染 DOM 的最快方法被認(rèn)為是逐個(gè)創(chuàng)建和掛載每個(gè) DOM 節(jié)點(diǎn)。換句話說，您使用諸如 createElement、setAttribute 和 textContent 這樣的 API 逐步構(gòu)建 DOM：
const div = document.createElement('div')
div.setAttribute('class', 'blue')
div.textContent = 'Blue!'另一種選擇是將一個(gè)龐大的 HTML 字符串直接插入 innerHTML，讓瀏覽器為您解析它：
const container = document.createElement('div')
container.innerHTML = `
Blue!
`這種天真的方法有一個(gè)很大的缺點(diǎn)：如果您的 HTML 中有任何動(dòng)態(tài)內(nèi)容（例如，紅色而不是藍(lán)色），那么您將需要一遍又一遍地解析 HTML 字符串。此外，您會(huì)在每次更新時(shí)清除 DOM，這將重置諸如 的值之類的狀態(tài)。
注意：使用 innerHTML 也涉及到 ?安全性問題。但在本文的目的中，讓我們假設(shè) HTML 內(nèi)容是可信任的。
然而，有一天人們發(fā)現(xiàn)，解析一次 HTML，然后對(duì)整個(gè)內(nèi)容調(diào)用 cloneNode(true) 是相當(dāng)快的：
const template = document.createElement('template')
template.innerHTML = `
Blue!
`
template.content.cloneNode(true) // this is fast!在這里，我使用了 標(biāo)簽，它的優(yōu)勢(shì)在于創(chuàng)建 “不活動(dòng)”（inert）的 DOM。換句話說，諸如 或
與手動(dòng)使用 DOM API 相比，這種克隆技術(shù)有多快呢？為了演示，這里有一個(gè)?小型基準(zhǔn)測(cè)試。Tachometer 報(bào)告稱，在 Chrome 中，克隆技術(shù)大約快 50%，在 Firefox 中快 15%，在 Safari 中快 10%（這將根據(jù) DOM 大小和迭代次數(shù)而變化，但您能夠理解主要趨勢(shì)）。
有趣的是， 是一個(gè)較新的瀏覽器 API，在 IE11 中不可用，最初設(shè)計(jì)用于 Web 組件。有些諷刺的是，這種技術(shù)現(xiàn)在被用于各種 JavaScript 框架，無論它們是否使用 Web 組件。
注：供參考，這里是在 Solid、Vue Vapor 和 Svelte v5 中對(duì) 使用 cloneNode 的方式。
這種技術(shù)有一個(gè)主要挑戰(zhàn)，即如何在不重置 DOM 狀態(tài)的情況下高效更新動(dòng)態(tài)內(nèi)容。在構(gòu)建我們的玩具框架時(shí)，我們將在后面詳細(xì)介紹這一點(diǎn)。
現(xiàn)代 JavaScript API
我們已經(jīng)接觸到了一個(gè)在很大程度上很有幫助的新 API，那就是 。另一個(gè)穩(wěn)步獲得關(guān)注的是 ?Proxy，它可以使構(gòu)建響應(yīng)系統(tǒng)變得更加簡(jiǎn)單。
在構(gòu)建我們的玩具示例時(shí)，我們還將使用帶標(biāo)簽的模板文字（tagged template literals）創(chuàng)建一個(gè)像這樣的 API：
const dom = html`
Hello ${ name }!
`并非所有的框架都使用這個(gè)工具，但一些顯著的框架包括 Lit、HyperHTML 和 ArrowJS。帶標(biāo)簽的模板文字可以在不需要編譯器的情況下更輕松地構(gòu)建人體工學(xué)的 HTML 模板 API。
步驟 1：構(gòu)建響應(yīng)性
響應(yīng)性是我們將構(gòu)建框架的基礎(chǔ)。響應(yīng)性將定義狀態(tài)的管理方式以及在狀態(tài)更改時(shí) DOM 如何更新。
讓我們從一些“夢(mèng)幻代碼”開始，以說明我們想要的：
const state = {}
state.a = 1
state.b = 2
createEffect(() => {
state.sum = state.a + state.b
})基本上，我們想要一個(gè)稱為 state 的“魔術(shù)對(duì)象”，有兩個(gè)屬性：a 和 b。每當(dāng)這些屬性發(fā)生變化時(shí)，我們希望設(shè)置 sum 為這兩個(gè)屬性的和。
假設(shè)我們事先不知道屬性（或者沒有編譯器來確定它們），一個(gè)普通的對(duì)象將無法滿足這個(gè)要求。所以讓我們使用 Proxy，它可以在設(shè)置新值時(shí)作出反應(yīng)：
const state = new Proxy({}, {
get(obj, prop) {
onGet(prop)
return obj[prop]
},
set(obj, prop, value) {
obj[prop] = value
onSet(prop, value)
return true
}
})目前，我們的 Proxy 沒有做任何有趣的事情，只是給我們提供了一些 onGet 和 onSet 鉤子。所以讓我們使其在微任務(wù)之后刷新更新：
let queued = false
function onSet(prop, value) {
if (!queued) {
queued = true
queueMicrotask(() => {
queued = false
flush()
})
}
}注意：如果您對(duì) queueMicrotask 不熟悉，它是一個(gè)較新的 DOM API，基本上與 Promise.resolve().then(...) 相同，但輸入更少。
為什么要刷新更新呢？主要是因?yàn)槲覀儾幌Ｍ\(yùn)行太多的計(jì)算。如果我們?cè)?a 和 b 都改變時(shí)更新，那么我們將無用地計(jì)算兩次和。通過將刷新合并到一個(gè)微任務(wù)中，我們可以變得更加高效。
接下來，讓我們讓刷新更新 sum：
function flush() {
state.sum = state.a + state.b
}這很好，但它還不是我們的“夢(mèng)幻代碼”。我們需要實(shí)現(xiàn) createEffect，以便僅在 a 和 b 更改時(shí)計(jì)算 sum（而不是在其他地方更改時(shí)）。
為此，讓我們使用一個(gè)對(duì)象來跟蹤哪些效果需要運(yùn)行哪些屬性：
const propsToEffects = {}接下來是至關(guān)重要的部分！我們需要確保我們的效果可以訂閱正確的屬性。為此，我們將運(yùn)行效果，記錄它調(diào)用的任何 get 調(diào)用，并創(chuàng)建屬性與效果之間的映射。
為了解釋清楚，記住我們的“夢(mèng)幻代碼”是：
createEffect(() => {
state.sum = state.a + state.b
})當(dāng)這個(gè)函數(shù)運(yùn)行時(shí)，它調(diào)用了兩個(gè) getter：state.a 和 state.b。這些 getter 應(yīng)該觸發(fā)響應(yīng)系統(tǒng)注意到該函數(shù)依賴于這兩個(gè)屬性。
為了實(shí)現(xiàn)這一點(diǎn)，讓我們從一個(gè)簡(jiǎn)單的全局變量開始，用于跟蹤“當(dāng)前”效果：
let currentEffect然后，createEffect 函數(shù)將在調(diào)用函數(shù)之前設(shè)置此全局變量：
function createEffect(effect) {
currentEffect = effect
effect()
currentEffect = undefined
}這里的重要之處在于，效果會(huì)立即被調(diào)用，同時(shí)全局的 currentEffect 在提前設(shè)置。這是我們跟蹤它可能調(diào)用的任何 getter 的方式。
現(xiàn)在，我們可以在我們的 Proxy 中實(shí)現(xiàn) onGet，它將設(shè)置全局 currentEffect 與屬性之間的映射：
function onGet(prop) {
const effects = propsToEffects[prop] ??
(propsToEffects[prop] = [])
effects.push(currentEffect)
}運(yùn)行一次后，propsToEffects 應(yīng)該如下所示：
{
"a": [theEffect],
"b": [theEffect]
}這里的 theEffect 是我們想要運(yùn)行的“sum”函數(shù)。
接下來，我們的 onSet 應(yīng)該將需要運(yùn)行的任何效果添加到一個(gè) dirtyEffects 數(shù)組中：
const dirtyEffects = []
function onSet(prop, value) {
if (propsToEffects[prop]) {
dirtyEffects.push(...propsToEffects[prop])
// ...
}
}此時(shí)，我們已經(jīng)有了所有的要素，使 flush 調(diào)用所有 dirtyEffects：
function flush() {
while (dirtyEffects.length) {
dirtyEffects.shift()()
}
}把它們結(jié)合在一起，我們現(xiàn)在有了一個(gè)完全功能的響應(yīng)性系統(tǒng)！您可以自己嘗試在 DevTools 控制臺(tái)中設(shè)置 state.a 和 state.b - 只要其中一個(gè)發(fā)生更改，state.sum 就會(huì)更新。
現(xiàn)在，有很多高級(jí)情況我們?cè)谶@里沒有涵蓋：
- 在效果拋出錯(cuò)誤時(shí)使用 try/catch
- 避免運(yùn)行相同的效果兩次
- 防止無限循環(huán)
- 在后續(xù)運(yùn)行中訂閱效果到新的屬性（例如，如果某些 getter 僅在 if 塊中被調(diào)用）
然而，對(duì)于我們的玩具示例來說，這已經(jīng)足夠了。讓我們繼續(xù)進(jìn)行 DOM 渲染。
步驟 2：DOM 渲染
我們現(xiàn)在有了一個(gè)功能完備的響應(yīng)性系統(tǒng)，但它實(shí)質(zhì)上是“無頭”的。它可以跟蹤變化并計(jì)算效果，但僅此而已。
然而，在某個(gè)時(shí)候，我們的 JavaScript 框架實(shí)際上需要將一些 DOM 渲染到屏幕上（這其實(shí)是整個(gè)目的）。
在本節(jié)中，讓我們暫時(shí)忘記響應(yīng)性，想象一下我們只是嘗試構(gòu)建一個(gè)函數(shù)，它能夠 1）構(gòu)建一個(gè) DOM 樹，和 2）高效地更新它。
再次，讓我們從一些“夢(mèng)幻代碼”開始：
function render(state) {
return html`
${state.text}
`
}正如我提到的，我正在使用帶標(biāo)簽的模板文字，就像 Lit 一樣，因?yàn)槲野l(fā)現(xiàn)它們是一種在不需要編譯器的情況下編寫 HTML 模板的好方法。（我們馬上會(huì)看到為什么我們實(shí)際上可能希望使用編譯器。）
我們從之前復(fù)用了我們的 state 對(duì)象，這次有一個(gè) color 和 text 屬性。也許 state 是這樣的：
state.color = 'blue'
state.text = 'Blue!'當(dāng)我們將這個(gè) state 傳遞給 render 時(shí)，它應(yīng)該返回應(yīng)用了 state 的 DOM 樹：
Blue!然而，在我們繼續(xù)之前，我們需要簡(jiǎn)要了解一下帶標(biāo)簽的模板文字。我們的 html 標(biāo)簽只是一個(gè)接收兩個(gè)參數(shù)的函數(shù)：tokens（靜態(tài) HTML 字符串的數(shù)組）和 expressions（評(píng)估的動(dòng)態(tài)表達(dá)式）：
function html(tokens, ...expressions) {
}在這種情況下，tokens 是（去掉空白）：
[
"",
""
]和 expressions：
[
"blue",
"Blue!"
]tokens 數(shù)組的長(zhǎng)度始終比 expressions 數(shù)組長(zhǎng) 1，因此我們可以簡(jiǎn)單地將它們一起進(jìn)行壓縮：
const allTokens = tokens
.map((token, i) => (expressions[i - 1] ?? '') + token)這將給我們一個(gè)字符串?dāng)?shù)組：
[
"",
"Blue!"
]我們可以將這些字符串連接在一起以生成我們的 HTML：
const htmlString = allTokens.join('');然后，我們可以使用 innerHTML 將其解析為 ：
function parseTemplate(htmlString) {
const template = document.createElement('template');
template.innerHTML = htmlString;
return template;
}這個(gè)模板包含了我們的惰性 DOM（在技術(shù)上是 DocumentFragment），我們可以隨時(shí)克隆它：
const cloned = template.content.cloneNode(true);當(dāng)然，每次調(diào)用 html 函數(shù)時(shí)都解析完整的 HTML 對(duì)性能來說不是很好。幸運(yùn)的是，帶標(biāo)簽的模板文字具有一個(gè)內(nèi)建特性，將在這里非常有幫助。
對(duì)于帶標(biāo)簽的模板文字的每個(gè)獨(dú)特用法，每當(dāng)調(diào)用該函數(shù)時(shí)，tokens 數(shù)組始終相同 - 實(shí)際上，它是相同的對(duì)象！
例如，考慮這種情況：
function sayHello(name) {
return html`Hello ${name}`;
}每當(dāng)調(diào)用 sayHello 時(shí)，tokens 數(shù)組將始終相同：
[
"Hello ",
""
]tokens 的唯一不同之處是對(duì)帶標(biāo)簽?zāi)０宓耐耆煌恢茫?/p>
html``
html`` // 與上述不同我們可以利用這一點(diǎn)，通過使用 WeakMap 將 tokens 數(shù)組映射到生成的模板：
const tokensToTemplate = new WeakMap();
function html(tokens, ...expressions) {
let template = tokensToTemplate.get(tokens);
if (!template) {
// ...
template = parseTemplate(htmlString);
tokensToTemplate.set(tokens, template);
}
return template;
}這有點(diǎn)令人驚嘆的概念，但 tokens 數(shù)組的唯一性實(shí)際上意味著我們可以確保每次對(duì) html 進(jìn)行調(diào)用時(shí)只解析一次 HTML。
接下來，我們只需要一種方法來使用 expressions 數(shù)組（與 tokens 不同，它可能在每次調(diào)用時(shí)都不同）更新克隆的 DOM 節(jié)點(diǎn)。
為了簡(jiǎn)單起見，讓我們只是用占位符替換 expressions 數(shù)組中的每個(gè)索引：
const stubs = expressions.map((_, i) => `__stub-${i}__`);如果我們像以前一樣將其壓縮，它將創(chuàng)建這個(gè) HTML：
__stub-1__
我們可以編寫一個(gè)簡(jiǎn)單的字符串替換函數(shù)來替換這些占位符：
function replaceStubs(string) {
return string.replaceAll(/__stub-(\d+)__/g, (_, i) => (
expressions[i]
));
}現(xiàn)在每當(dāng)調(diào)用 html 函數(shù)時(shí)，我們可以克隆模板并更新占位符：
const element = cloned.firstElementChild;
for (const { name, value } of element.attributes) {
element.setAttribute(name, replaceStubs(value));
}
element.textContent = replaceStubs(element.textContent);注意：我們使用 firstElementChild 來獲取模板中的第一個(gè)頂級(jí)元素。對(duì)于我們的玩具框架，我們假設(shè)只有一個(gè)。
現(xiàn)在，這仍然不是非常高效的 - 特別是，我們正在更新不一定需要更新的 textContent 和屬性。但對(duì)于我們的玩具框架來說，這已經(jīng)足夠好了。
我們可以通過使用不同的 state 進(jìn)行渲染來測(cè)試它：
document.body.appendChild(render({ color: 'blue', text: 'Blue!' }));
document.body.appendChild(render({ color: 'red', text: 'Red!' }));這樣就可以了！
步驟 3：結(jié)合響應(yīng)性和 DOM 渲染
由于我們已經(jīng)有了上面渲染系統(tǒng)中的 createEffect，現(xiàn)在我們可以將兩者結(jié)合起來根據(jù)狀態(tài)更新 DOM：
const container = document.getElementById('container');
createEffect(() => {
const dom = render(state);
if (container.firstElementChild) {
container.firstElementChild.replaceWith(dom);
} else {
container.appendChild(dom);
}
});這實(shí)際上是有效的！我們可以將這個(gè)與響應(yīng)性部分的 “sum” 示例結(jié)合起來，只需創(chuàng)建另一個(gè)效果來設(shè)置文本：
createEffect(() => {
state.text = `Sum is: ${state.sum}`;
});這將呈現(xiàn) “Sum is 3”：
你可以嘗試操作這個(gè)玩具示例。如果你設(shè)置 state.a = 5，那么文本將自動(dòng)更新為 “Sum is 7”。
下一步
有許多改進(jìn)我們可以對(duì)這個(gè)系統(tǒng)進(jìn)行，特別是 DOM 渲染部分。
最值得注意的是，我們?nèi)鄙僖环N更新深度 DOM 樹內(nèi)元素內(nèi)容的方法，例如：
${text}
為此，我們需要一種方法來唯一標(biāo)識(shí)模板內(nèi)的每個(gè)元素。有很多方法可以做到這一點(diǎn)：
- Lit 在解析 HTML 時(shí)使用一套正則表達(dá)式和字符匹配的系統(tǒng)，以確定占位符是否在屬性或文本內(nèi)容中，以及目標(biāo)元素的索引（按深度優(yōu)先 TreeWalker 順序）。
- Svelte 和 Solid 等框架在編譯期間有幸解析整個(gè) HTML 模板，這提供了相同的信息。它們還生成調(diào)用 firstChild 和 nextSibling 遍歷 DOM 的代碼，以找到要更新的元素。
注意：使用 firstChild 和 nextSibling 進(jìn)行遍歷類似于 TreeWalker 方法，但比 element.children 更高效。這是因?yàn)闉g覽器在內(nèi)部使用鏈表來表示 DOM。
無論我們決定采用 Lit 風(fēng)格的客戶端解析還是 Svelte/Solid 風(fēng)格的編譯時(shí)解析，我們想要的是類似于這樣的映射：
[
{
elementIndex: 0, // 上面的
attributeName: 'class',
stubIndex: 0 // 表達(dá)式數(shù)組中的索引
},
{
elementIndex: 1 // 上面的
textContent: true,
stubIndex: 1 // 表達(dá)式數(shù)組中的索引
}
]這些綁定將告訴我們確切需要更新哪些元素，需要設(shè)置哪個(gè)屬性（或 textContent），以及在哪里找到替換占位符的表達(dá)式。
下一步是避免每次都克隆模板，而是直接基于表達(dá)式更新 DOM。換句話說，我們不僅想要一次解析 - 我們只想一次克隆和設(shè)置綁定。這將將每個(gè)后續(xù)更新減少到最少的 setAttribute 和 textContent 調(diào)用。
注意：你可能會(huì)想知道模板克隆的目的是什么，如果我們最終還是需要調(diào)用 setAttribute 和 textContent。答案是，大多數(shù) HTML 模板在很大程度上都是靜態(tài)內(nèi)容，只有一些動(dòng)態(tài)的“孔”。通過使用模板克隆，我們克隆了絕大多數(shù)的 DOM，只對(duì)“孔”做額外的工作。這是使這個(gè)系統(tǒng)如此出色的關(guān)鍵洞察。
另一個(gè)有趣的模式是實(shí)現(xiàn)迭代（或重復(fù)器），這帶來了一系列的挑戰(zhàn)，比如在更新之間協(xié)調(diào)列表以及處理有效替換的“鍵”。
不過我有點(diǎn)疲倦，這篇博文已經(jīng)夠長(zhǎng)了。所以我把剩下的部分留給讀者自己來完成吧！
結(jié)論
就是這樣。在這篇（冗長(zhǎng)的）博文中，我們實(shí)現(xiàn)了自己的 JavaScript 框架。請(qǐng)隨意將其用作你全新 JavaScript 框架的基礎(chǔ)，發(fā)布到世界上，激怒 Hacker News 的群眾。
個(gè)人而言，我發(fā)現(xiàn)這個(gè)項(xiàng)目非常有教育意義，這也是我一開始為什么要做的一部分。我還希望用一個(gè)更小、更自定義的解決方案替換我的表情符號(hào)選擇器組件的當(dāng)前框架。在這個(gè)過程中，我成功地編寫了一個(gè)微小的框架，通過所有現(xiàn)有的測(cè)試，并比當(dāng)前實(shí)現(xiàn)小約 6kB，我對(duì)此感到相當(dāng)自豪。
在將來，我認(rèn)為如果瀏覽器 API 足夠全面，將更容易構(gòu)建自定義框架將會(huì)很有趣。例如，DOM Part API 提案將消除我們上面構(gòu)建的 DOM 解析和替換系統(tǒng)的很多繁瑣工作，同時(shí)也為潛在的瀏覽器性能優(yōu)化敞開了大門。我還可以想象（帶有一些瘋狂的手勢(shì)）Proxy 的擴(kuò)展可能會(huì)使構(gòu)建完整的響應(yīng)性系統(tǒng)變得更容易，而不用擔(dān)心刷新、批處理或循環(huán)檢測(cè)等細(xì)節(jié)。
如果所有這些東西都到位，那么你可以想象在實(shí)際上擁有一個(gè)“在瀏覽器中的 Lit”，或者至少一種快速構(gòu)建你自己“在瀏覽器中的 Lit”的方法。與此同時(shí)，我希望這個(gè)小練習(xí)有助于說明一些框架作者考慮的事情，以及你最喜歡的 JavaScript 框架底層的一些機(jī)制。
感謝 Pierre-Marie Dartus 在這篇文章初稿中提供的反饋。
原文：?https://nolanlawson.com/2023/12/02/lets-learn-how-modern-javascript-frameworks-work-by-building-one/
文章題目：讓我們通過構(gòu)建一個(gè)現(xiàn)代JavaScript框架來學(xué)習(xí)它是如何工作的
文章源于：http://www.5511xx.com/article/coojggd.html
