為什么 Javascript 內置方法/函數是用 C/C++ 而不是 JS 語法編寫的

Question

這個問題參考了這個老問題Where-can-i-find-javascript-native-functions-source-code

該頁面上的答案說，源代碼在c或c++中，但我很好奇為什么源代碼（定義）使用這些語言？ 我的意思是它們是 JS 函數定義，例如toString()方法。 它是一個 JavaScript function 所以它的定義必須使用 Javascript 語法來編寫。

toString; 在 chrome 控制台輸出function toString() { [native code] } 。

如果它是用戶定義的 function 那么您可以看到定義但看不到toString()或與此相關的其他內置函數，畢竟它們只是必須在 JavaScript 語法中定義的函數/方法，以便引擎正確解釋它們。

我希望你能明白我想表達的意思。

Answer 1

正如評論中指出的那樣，您對JavaScript的工作原理有基本的誤解。

從最純粹的意義上講，JavaScript是一種腳本語言，即，它旨在編寫宿主環境腳本。 它打算嵌入到更大的系統（在這種情況下，是用C / C ++編寫的Web瀏覽器）中，從而以有限的方式操縱該系統。

其他一些示例包括bash作為unix的腳本語言，python作為崇高的文本編輯器的腳本語言，elisp作為emacs的腳本語言，lua作為《魔獸世界》的腳本語言等。

當我們說一個函數是“內置的”時，是指它實際上是托管環境（例如Web瀏覽器）的函數，而不是腳本語言（JavaScript）的函數。

盡管JavaScript標准強制要求某些內置函數，但這意味着符合標准的宿主環境需要公開該功能，而不管底層實現所使用的語言是什么。

Answer 2

這個問題為初學者打開了很多大門，讓他們更多地了解 Javascript 如何工作並幫助我。 給出的答案/評論雖然有幫助，但在我認為可能有幫助的大局上卻止步不前。 我以一種假設對想要答案的人知識有限的方式寫了一個答案。 在 2016 年，那將是 op。

Javascript 被構建為在另一個環境中運行，而不是在桌面或服務器或任何其他可編程功能上運行。 在這種情況下，瀏覽器。 它的構建是為了與瀏覽器 API 交互，例如 DOM 和其他有用的瀏覽器 API，這些 API 已發布日期。 Javascript 本身不附帶內置模塊，例如訪問用戶主機系統/創建 UI。 它不需要這個來實現它的創建目的。 它不像 Python 或 Java 那樣帶有內置模塊，可以通過其內置庫/模塊訪問文件系統以及各種其他功能。 是的，就像我們可以安裝一個庫來訪問文件系統的任何語言一樣，但是這將被瀏覽器沙盒的安全性阻止。

Javascript

是的 Javascript 是一種編程語言，但它通常被稱為“腳本語言” ，盡管我還沒有看到除了能很好地描述它之外的官方術語。

ECMAScript 是瀏覽器中所有 JS 引擎都遵守的標准。 當我們編寫 javascript 代碼時，我們期望得到一個基於 ECMAScript 規范的結果。 如果使用我們自己的功能，例如

Const sayName(name) = ()=> {
  return name
} 

sayName('Kevin')

JS 引擎（本身是用另一種語言編寫的另一個程序，更常見的是 C++）在執行過程中解釋我們的代碼。 JS引擎有各種函數可以在當前運行的執行過程中被調用。 首先，代碼被解析，解析器識別關鍵字“Const”，然后期待常量的名稱，然后是 = 符號。 解析器對 return 關鍵字以及 () 和 {} 執行相同的操作。

如果程序中的任何語法錯誤，解析器將失敗，我們的執行將不會 go 到引擎的下一階段，即抽象語法樹（今天不用擔心，因為我們有跑題的危險。 )

一旦創建了抽象語法樹，我認為這就是 Op（和 I）過去常常混淆的地方，這是我們到達解釋器的階段。 現在解釋器可以清楚地理解我們上面寫的簡單的function了。 然而，Javascript 附帶的這些“內置”東西怎么樣。 例如，數組字符串數學方法等。作為 javascript 的開發人員，我們調用這些方法，實際上我喜歡將其視為“我們的工作完成了”。 我們稱之為方法。 現在，無論是 Static 方法還是我們創建的對象之一（例如數組）的實例方法，我都希望在運行我的代碼時得到 ECMAScript 向我承諾的准確結果。

重要的是要注意，其中一些函數/方法可能在 Javascript 中實現，但大多數將在較低級別的代碼（如 C/C++）中實現。 這類似於 Python 的工作方式，它的內置模塊是在 C 中編寫的，並通過 Python 解釋執行。 回到 Javascript - 這些功能如何實現對我自己或 ECMAScript 都不重要。 這是瀏覽器的選擇，它是如何做到這一點的，還有一些非常有才華的低級程序員。 （那些 C 程序員和那些被瀏覽器雇佣來實現引擎功能以符合 ECMAScripts 預期結果的人）。 現在我們擁有了所需的所有功能，解釋器開始工作，並在其他進程（取決於使用的引擎）將其轉換為 CPU 可以理解的機器代碼（再次解釋這將是題外話）。 因此，如果我們向控制台記錄一個函數/方法的定義，它在 JS 引擎中，我們沒有自己編寫，那就是我們獲得本機代碼的地方。 例如

console.log(Math.random)

那是當我們得到

function random() {
[native code]
}

在上面，一位優秀且經驗豐富的開發人員將其描述為“如果其托管環境的 function 將出現本機代碼”，這是瀏覽器，並以 SetTimeout 為例。 是的，這也會顯示為本機代碼，這不是我們自己編寫的代碼，但這是瀏覽器的 Function，而不是 Javascript 語言本身的一部分。 所有不是由我們編寫的功能/方法，例如在瀏覽器中或在較低級別，將顯示為“本機代碼”。

節點

然而，現在我們有了另一個 JS 引擎可以適應的運行時環境。 一種眾所周知的技術，稱為 Nodejs。 我們的瀏覽器被替換為其他在服務器上更有用的 Api。 我們現在可以在 Node 運行時環境中訪問文件系統。 訪問我們自己服務器上的文件系統沒有錯。 這些 API 適用於服務器，但是我們仍然處於運行環境中，我們仍然有一個 javascript 解釋器，我們的代碼仍然被解釋，我們仍然在解釋過程中調用較低級別的函數，這只是意味着我們在 Nodejs 運行環境中，而不是比我們“最喜歡的”瀏覽器。