程序開發如火如荼，如果你是程序員，你還不懂小程序的開發，恐怕會被同行認為太LOW了吧！不過，新入行小程序開發者確實會被新的名詞搞得一頭霧水。

比如JavaScript不是在瀏覽器端運行嗎，怎么還可以寫服務器端的程序，NodeJS是干啥的，V8和NodeJS有啥區別，什么NMP命令，它是干嘛的，想把這些東東的本質看透嗎，我們來剖析一下吧。

01

JavaScript是啥

JavaScript是一種屬于網絡的解釋性腳本語言,已經被廣泛用于Web應用開發,用來給HTML網頁增加動態功能,為用戶提供更流暢美觀的瀏覽效果。通常JavaScript腳本是通過嵌入在HTML中來實現自身的功能的。它的解釋器被稱為JavaScript引擎，為瀏覽器的一部分。

02

V8是啥

V8引擎就是JavaScript運行的解釋器，是JavaScript一種引擎。它是Google開發的，作為chrome瀏覽器的JavaScript執行解釋器，性能十分優秀，被廣泛的使用。

03

何謂NodeJS

在2009年的歐洲JavaScript大會上， 年輕程序員Ryan Dahl展示了他正在從事的一個項目，該項目是一個集成了Google V8 JavaScript引擎、事件循環和底層I/O應用編程接口(Application Programming Interface, API）的平臺。

與其他服務器端的JavaScript平臺不同，Dahl的平臺中所有I/O原語都是事件驅動的，除此以外別無他途。借助JavaScript的影響力和易用性，Dahl的項目使得編寫基于事件驅動的服務器端應用程序的任務由難變易， 因此，該項目受到了熱烈歡迎， 并且它的發展、普及和被接受程度都是前所未有的。這個項目被命名為NodeJS。NodeJS不單單是JavaScript引擎，JavaScript引擎只是它的一個子集。

NodeJS中的JavaScript引擎沒有BOM、DOM。NodeJS是JavaScript的一種運行環境，是對Google V8引擎進行的封裝。是一個服務器端的JavaScript的解釋器。

04

什么是NPM

除了使用NodeJS語言特性及核心函數，我們還需要使用一些已經編寫好的優秀的第三方庫， 這也是為什么大多數編程平臺都具有一個系統用來下載、 安裝和管理第三方模塊的原因。 在NodeJS中這個系統被稱為NodeJS包管理器(NodePackage Manager, NPM）。NPM是三位一體的系統第三方包庫、管理計算機中安裝的包的機制以及定義包依賴關系的標準。NPM提供了一種公共注冊服務，它包含了程序員在NPM中發布的所有包，NPM還提供了一個命令行工具用來下載、安裝和管理這些包。

在早期，NPM和NodeJS是要分別獨立安裝的，但是從0.6.0版開始，NPM就己經包含在Node的安裝包中。NodeJS中含有NPM。

可能已經聽說過Project Quantum ...它是Firefox的內部部件的重大改寫，使Firefox快速。我們正在從我們的實驗瀏覽器Servo中進行部分交換，并對引擎的其他部分進行了大量改進。

該項目已經與噴氣式飛機仍在飛行中替換噴氣發動機相比較。我們正在按組件進行更改，以便在每個組件準備就緒后，您可以在Firefox中看到效果。

而Servo的第一個主要組件 - 名為Quantum CSS（以前稱為Stylo）的新CSS引擎 - 現在可以在我們的Nightly版本中進行測試。您可以通過轉到about:config并設置layout.css.servo.enabled為true 來確保它已打開。

這款新引擎將來自四個不同瀏覽器的最先進的創新融合在一起，以創建一個新的超級CSS引擎。

它利用了現代硬件，并行化了機器中所有內核的工作。這意味著它最多可以運行2或4甚至18倍。

除此之外，它結合了來自其他瀏覽器的現有最新優化。所以即使沒有并行運行，它仍然是一個快速的CSS引擎。

但是什么是CSS引擎呢？首先，我們來看看CSS引擎，以及它如何適應瀏覽器的其余部分。那么我們可以看看Quantum CSS如何使它更快。

什么是CSS引擎？

CSS引擎是瀏覽器渲染引擎的一部分。渲染引擎采用網站的HTML和CSS文件，并將其轉換為屏幕上的像素。

每個瀏覽器都有一個渲染引擎。在Chrome中，它叫做Blink。在Edge中，它被稱為EdgeHTML。在Safari中，它被稱為WebKit。在Firefox中，它被稱為Gecko。

要從文件到像素，所有這些渲染引擎基本上都做同樣的事情：

1. 將文件解析為瀏覽器可以理解的對象，包括DOM。在這一點上，DOM知道頁面的結構。它知道元素之間的父/子關系。不知道這些元素應該是什么樣的。

2. 找出這些元素應該是什么樣的。對于每個DOM節點，CSS引擎都會確定哪些CSS規則適用。然后，它會為該DOM節點的每個CSS屬性確定值。

1. 繪出每個節點的尺寸及其在屏幕上的位置。將為屏幕上顯示的每個東西創建框。這些方框不僅僅代表DOM節點，還可以為DOM節點內的東西，如文本行。

1. 畫不同的盒子。這可能發生在多層。我想起了這個像老式的手繪動畫，帶有洋蔥的紙層。這樣就可以改變一個層，而不必在其他層上重繪某些東西。

2. 拿這些不同的繪圖層，應用任何只有合成器的屬性，如transforms，并將它們變成一個圖像。這基本上就像是將層疊在一起的圖片。此圖像將在屏幕上呈現。

這意味著當它開始計算樣式時，CSS引擎有兩件事情：

• 一個DOM樹

• 風格規則清單

它逐個瀏覽每個DOM節點，并計算出該DOM節點的樣式。作為其中的一部分，它為DOM節點提供了每個CSS屬性的值，即使樣式表未聲明該屬性的值。

我想像這樣像一個人通過填寫一個表單。他們需要為每個DOM節點填寫這些表單之一。而對于每個表格領域，他們需要有一個答案。

要做到這一點，CSS引擎需要做兩件事情：

• 找出哪些規則適用于節點 - aka 選擇器匹配

• 使用父級值或默認值（也稱為級聯）填充任何缺少的值

選擇器匹配

對于此步驟，我們將添加與DOM節點匹配的任何規則到列表。因為多個規則可以匹配，所以同一屬性可能有多個聲明。

此外，瀏覽器本身還添加了一些默認的CSS（稱為用戶代理樣式表）。CSS引擎知道要選擇哪個值？

這就是特定性規則的出現。CSS引擎基本上創建一個電子表格。然后它根據不同的列對聲明進行排序。

具有最高特異性的規則勝出。所以基于這個電子表格，CSS引擎填寫了它可以的值。

對于其余的，我們將使用級聯。

級聯

級聯使得CSS易于編寫和維護。因為級聯，可以設置color在機身性能和知道該文本p，并span和li元素都將使用該顏色（除非你有一個更具體的覆蓋）。

為此，CSS引擎會查看其表單上的空白框。如果該屬性默認繼承，那么CSS引擎將向上爬樹，以查看其中一個祖先是否具有值。如果沒有一個祖先有一個值，或者該屬性不繼承，它將獲得一個默認值。

所以現在所有的樣式都已經為這個DOM節點計算了。

一個sidenote：風格結構共享

我向你展示的形式有點虛偽。CSS有數以百計的屬性。如果CSS引擎持有每個DOM節點的每個屬性的值，它將很快耗盡內存。

相反，引擎通常會做一些所謂的樣式結構共享。它們通常在一起被稱為樣式結構的不同對象中存儲數據（如字體屬性）。然后，代替在同一對象中擁有所有屬性，計算的樣式對象只有指針。對于每個類別，都有一個指向具有該DOM節點正確值的樣式結構的指針。

這將節省內存和時間。具有類似屬性的節點（如兄弟姐妹）可以指向與它們共享的屬性相同的結構體。并且因為許多屬性都被繼承，所以祖先可以與沒有指定自己的覆蓋的任何后代共享一個結構體。

現在，我們如何做到這一點呢？

那么當你沒有優化它時，這就是什么樣的計算。

這里有很多工作。它不僅僅需要在第一頁的加載中發生。當用戶與頁面進行交互，將鼠標懸停在元素上或對DOM進行更改時，會重復出現，從而觸發重新啟動。

這意味著CSS樣式計算是優化的最佳選擇...而瀏覽器已經測試出不同的策略，以優化它在過去20年。什么Quantum CSS做的是從不同的引擎中充分利用這些策略，并結合它們來創建一個超快的新引擎。

所以我們來看看這些工作如何共同的細節。

并行運行

Servo項目（Quantum CSS來自）是一個實驗瀏覽器，它試圖并行化渲染網頁的所有不同部分。這意味著什么？

一臺電腦就像一只大腦。有一部分做這個想法（ALU）。在這個附近，有一些短期記憶（寄存器）。這些在CPU上組合在一起。那么長期的內存是RAM。

早期的電腦一次只能用這種CPU來思考一件事情。但是在過去十年中，CPU已經轉移到擁有多個ALU和寄存器，分組在一起。這意味著CPU可以一次思考多個東西 - 并行。

Quantum CSS通過分散不同核心上的不同DOM節點的樣式計算來利用計算機的最新功能。

這似乎是一件容易的事情，只需拆分樹的分支，并在不同的核心上進行。這實際上比這更難，原因很多。一個原因是DOM樹往往是不均勻的。這意味著一個核心將比其他核心更多的工作要做。

為了平衡工作，Quantum CSS使用了一種稱為工作竊取的技術。正在處理DOM節點時，代碼將其直接子代并將其分解為1個或多個“工作單元”。這些工作單位放在隊列中。

當一個核心完成了隊列中的工作時，它可以在其他隊列中查找更多的工作。這意味著我們可以平均分配工作，而不用花時間去走樹，找出如何提前平衡。

在大多數瀏覽器中，很難得到這個權利。并行是一個已知的困難問題，CSS引擎非常復雜。它也坐在渲染引擎的另外兩個最復雜的部分之間 - DOM和布局。所以很容易引入一個bug，并行性可能會導致很難追蹤的錯誤，稱為數據競爭。我在另一篇文章中更多地解釋了這些錯誤。

如果您接受來自數百或數千名工程師的貢獻，您如何并行編程而不用擔心？這就是我們有Rust的。

使用Rust，您可以靜態地驗證您沒有數據競爭。這意味著您只需不要讓他們進入您的代碼，避免棘手的調試錯誤。編譯器不會讓你這樣做。我將在以后的文章中寫下更多關于這一點。在此期間，您可以觀看關于Rust中的并行性的介紹視頻，或者更深入地討論工作竊取。

有了這個CSS樣式計算就會變成一個令人尷尬的并行問題 - 幾乎沒有什么可以讓你有效地并行運行它。這意味著我們可以接近線性加速。如果您的機器上有4個內核，那么它的運行速度將提高近4倍。

用規則樹加速重新開始

對于每個DOM節點，CSS引擎需要完成所有規則以進行選擇器匹配。對于大多數節點，這種匹配可能不會很頻繁地變化。例如，如果用戶將鼠標懸停在父項上，則與之匹配的規則可能會更改。我們仍然需要重新計算其后代的樣式來處理屬性繼承，但是與這些后代匹配的規則可能不會改變。

如果我們可以記下哪些規則與這些后代相匹配，那么這將是很好的，所以我們不必再為它們進行選擇器匹配，這就是Firefox以前的CSS引擎借來的規則樹。

CSS引擎將通過查找匹配的選擇器的過程，然后通過特異性對它們進行排序。從此，它創建了一個鏈接的規則列表。

該列表將被添加到樹中。

CSS引擎嘗試將樹中的分支數保持在最小。為此，它將盡可能地重用一個分支。

如果列表中的大多數選擇器與現有分支相同，則它將遵循相同的路徑。但是它可能會到達列表中的下一個規則不在樹的這個分支中。只有在這一點上它才會添加一個新的分支。

DOM節點將獲得指向最后插入的規則的指針（在本示例中為div#warning規則）。這是最具體的一個。

在restyle上，引擎會快速檢查以查看父母的更改是否可能改變與孩子相匹配的規則。如果沒有，則對于任何后代，引擎可以跟隨后代節點上的指針來獲得該規則。從那里，它可以將樹跟隨到根，以獲得匹配規則的完整列表，從最具體到最不具體。這意味著它可以完全跳過選擇器匹配和排序。

因此，這有助于減少重建期間所需的工作。但是，在初始設計時，還是有很多工作。如果您有10,000個節點，您仍然需要選擇器匹配10,000次。但還有另一種加速方式。

加快樣式共享緩存的初始渲染（和級聯）

想想一個具有數千個節點的頁面。許多節點將匹配相同的規則。例如，想想一個漫長的維基百科頁面...主要內容區域中的段落應該完全匹配完全相同的規則，并且具有完全相同的計算樣式。

如果沒有優化，則CSS引擎必須單獨匹配每個段落的選擇器和計算樣式。但是，如果有一種方式來證明樣式將從段落到段落相同，則引擎可以只做一次工作，并將每個段落節點指向相同的計算方式。

這就是Safari和Chrome瀏覽器啟發的風格共享緩存。完成處理節點后，將計算的樣式放入緩存中。然后，在開始下一個節點的計算樣式之前，它會運行一些檢查來查看是否可以使用緩存中的某些內容。

這些支票是：

• 2節點是否具有相同的ids，類等？如果是這樣，那么他們會匹配相同的規則。

• 對于任何不是基于選擇器的內聯樣式，例如，節點是否具有相同的值？如果是這樣，那么上面的規則也不會被覆蓋，也不會被同樣的覆蓋。

• 父母雙方指向相同的計算樣式對象嗎？如果是這樣，那么繼承的值也將是一樣的。

這些檢查一開始就在早期的風格共享緩存中。但是還有很多其他樣式可能不匹配的小案例。例如，如果CSS規則使用:first-child選擇器，則兩個段落可能不匹配，即使上面的檢查表明它們應該是。

在WebKit和Blink中，樣式共享緩存將在這些情況下放棄，而不使用緩存。隨著越來越多的網站使用這些現代選擇器，優化越來越有用，所以Blink團隊最近刪除了它。但事實證明，風格共享緩存有一種方法來跟上這些變化。

在Quantum CSS中，我們收集所有這些奇怪的選擇器，并檢查它們是否適用于DOM節點。然后我們將答案存儲為1和0。如果兩個元素具有相同的一個和零個，我們知道它們絕對匹配。

如果DOM節點可以共享已經計算的樣式，則可以跳過幾乎所有的工作。因為頁面通常具有多個具有相同樣式的DOM節點，所以這種風格共享緩存可以節省內存并且還能夠加快速度。