據我所知，JavaScript是從服務器檢索到HTML文件後，客戶端執行的唯一一種語言。據我所知，JavaScript決不是編譯的，因此它是一種解釋型語言。爲什麼客戶端Web仍在使用解釋型語言？
隨着Web變得越來越流行，以至於有人說移動和桌面應用程序將很快不復存在。
我們看到像WebGL這樣的使用JS的新技術。
當我開發的WebGL我必須優化這麼多，實現了合理的業績比較基準，那麼我將不得不爲PC或控制檯。
那麼，爲什麼我們仍然使用解釋客戶端語言？這是一個安全問題，硬件（跨平臺）問題，還是僅僅因爲很難在Web架構中引入如此大的變化？我知道web開發人員對即使是最小和最簡單的更改也感到頭疼，比如使用CSS 3，因爲並不是每個人都擁有最新的瀏覽器。
我正確地認爲互操作語言比編譯語言更慢嗎？我有意義還是我的假設完全不正確？我絕不是JS /網絡專家，請教育我。
據我所知，JavaScript是HTML文件已經從服務器檢索後，將在客戶端執行的唯一語言。
這是不對的。至少在HTML 4.01中，<script>元素具有type屬性，允許您指定任何您想要的語言。 HTML 4.01規範本身在VBScript和Tcl中有例子。
的Internet Explorer的舊版本，例如，支持VBScript作爲一種替代的腳本語言ECMAScript的。有支持Dart作爲替代腳本語言的Chrome版本。有一個項目增加了對PHP，Perl，Python，Ruby，Tcl和其他Firefox的支持。
您還可以使用任何具有輸出ECMAScript的編譯器的語言，並且幾乎所有語言現在都具有該語言，例如，有編譯器可以將C，C++，Java，Scala，Ruby，C♯，F♯以及許多其他語言編譯爲ECMAScript。還有一些語言被明確設計成ECMAScript的超集（例如TypeScript），語義上接近ECMAScript（例如CoffeeScript），或者易於編譯成ECMAScript（例如Dart）。
據我所知，JavaScript決不會被編譯，因此它是一種解釋型語言。
這是錯誤的。目前所有瀏覽器中的ECMAScript執行引擎都至少有一個編譯器。許多編譯器都有。至少有一個沒有任何解釋：
事實上，術語「解釋性語言」和「編譯語言」甚至沒有意義。語言不被解釋或編譯。僅有的語言是。編譯和解釋不是一種語言的特徵，它們是編譯器或解釋器的特徵（杜！）語言是一組數學規則和限制。而已。 「語言」的概念和「解釋」的概念生活在兩個完全不同的抽象層次上。如果英文是一種類型語言，那麼術語「解釋語言」將是一種類型錯誤。
每種語言都可以通過解釋器來實現，每種語言都可以通過編譯器來實現。有C和C++的解釋器，有ECMAScript，PHP，Python和Ruby的編譯器。
我正確地認爲互操作語言的編譯速度較慢嗎？
不是。首先，就像我上面解釋的那樣，根本就沒有解釋或編譯語言那樣的東西。只有解釋或編譯的語言實現。其次，說一種語言比另一種語言慢是沒有意義的。您可以說的是，某個特定程序在特定機器上的特定環境中由特定實現的特定版本執行時運行速度快於不同版本的不同實現在不同環境中執行的不同的程序機。
一般而言，典型程序在特定實現方面的表現主要取決於花費多少金錢，資源，精力，智力，研究，工程和人力，而不是語言的任何特定特徵。 Oracle HotSpot JVM的速度並不快，並不是因爲它是一個編譯的實現，而不是因爲Java是靜態類型的（事實上，這完全不相關，因爲HotSpot JVM執行JVM字節碼，甚至不瞭解Java的任何內容！），但是因爲Oracle Sun已經投入了大量的資源。具有諷刺意味的是，在Sun收購Smalltalk（!!!）公司及其VM技術之前，Java實際上很慢。是的，沒錯：HotSpot JVM實際上只是一個稍微修改過的Smalltalk VM，即動態語言的VM。實際上，VM HotSpot基於，是開源的，也是VM V8的基礎（這並不奇怪，因爲V8是由一些開發HotSpot JVM和Smalltalk的人開發的它基於的VM）。
注意，有上獲得通過瀏覽器接受一種新的語言兩次嘗試廠商：
asm.js是ECMAScript中的句法和語義的子集的語言（意思是任何asm.js程序也是一個語義相同的ECMAScript程序，以及一個對asm.js一無所知的瀏覽器會簡單地認爲它是ECMAScript並將其作爲ECMAScript執行，並且它將會正常工作），並具有一定的限制條件，使其成爲編譯器的良好目標（例如創建一個將C編譯爲asm.js的編譯器相對容易），同時還有一個很好的用於生成本地代碼的源代碼（即它的語義相對接近現代主流通用CPU的語義）。
同樣，WebAssembly是一種（二進制）語言，它與asm.js基本上具有相同的目標，除非沒有要求它是ECMAScript的真正子集。它是自己的獨立語言，受asm.js，LLVM位碼，ANDF，CIL，JVM字節碼，Pascal P代碼等的啓發。
Asm.js已經有了一些瀏覽器的支持，並且因爲它只是ECMAScript的一個子集，甚至在沒有支持的瀏覽器中工作......只是速度較慢。雖然WebAssembly仍處於實驗和原型設計階段，但它正在獲得牽引力。
JavaScript作爲源代碼加載，因此需要進行解釋。
你不能有代碼的水平要低得多，因爲這將不再是跨設備無處不兼容。
之一的JavaScript的額外補貼是你的代碼可以運行在幾乎任何設備的網絡瀏覽器。
如果您要編譯此代碼，它將成爲體系結構/設備特定的。
自然解釋語言將比編譯語言運行速度較慢的編譯代碼可以由CPU，其中如編譯代碼需要檢查盲目地跑/由線跑線;你可以應用優化來限制這個。
所以基本上這裏的主要問題是跨平臺兼容性？我很確定你可以使用PHP來確定用戶操作系統（如果沒有，也許可以在Web請求中爲操作系統添加一種用戶代理標籤）。那麼，如果我們檢測到操作系統是Windows，我們可以返回一個類似於exe的文件。如果沒有檢測到常見的操作系統，我們將使用JS和JIT編譯作爲回退。如果這些文件不小於標準網頁，這些文件就會一樣大。他們會跑得更快。但這只是未來瀏覽器的想法。感謝你的回答。 –
有些ASM.js--其他人講過 - 可以用C++語言編寫程序，並將其編譯爲JS的低級版本，但它並不是廣泛兼容的。你所說的整個PHP事情是相當複雜的。另外，我不確定你能否真正檢測到用戶硬件。 – 2017-01-01 04:11:54
據我所知，JavaScript是HTML文件已經從 服務器檢索後，將在 客戶端執行的唯一語言。
並非總是如此。我們還有其他選擇。比如在flash player或VB Script中運行的ActionScript 。但他們是過時
`
當我開發的WebGL我必須優化這麼多，實現了 合理的業績比較基準，那麼我將不得不爲PC或 安慰。
是的，我想我們可以做非常好的顯卡支持WebGL。但其仍然 在瀏覽器沙箱中運行。 js的行爲如何，同樣的WebGL在文件訪問或其他核心標準的意義上也表現爲 。像這樣想想 的方式，如果你開發像看門狗或gta一樣的大規模勇敢的遊戲。你想 認爲瀏覽器可以處理這些功能。但是，電腦，控制檯呢。
`
那麼，爲什麼我們仍然使用一種解釋客戶端的語言？它是一個 安全問題，硬件（跨平臺）的問題還是純粹 因爲很難推出這樣一個大的變化到Web 架構？
我想他們兩個。編譯後的代碼直接運行到機器中。那麼瀏覽器在這裏扮演什麼角色？所以我們放鬆了安全的東西。 另外JavaScript有社區的大小。如果我們需要完全改變網頁架構，我們需要一個完全不同的客戶端。 該客戶端將取代所有當前的瀏覽器。是不是 可能。但會一天一天地改變。 ES6是一個良好的開端..
`
我知道web開發者有頭痛了即使是最小的和最簡單的 變化，如使用CSS 3，只是因爲不是每個人都有 他們的瀏覽器了至今。
是的100％爲真。但是這個問題沒有別的辦法。作爲開發人員必須保持兼容性。
`
我是正確的思想，interperated語言是慢然後 編的嗎？
是的，它會很快。但最近的瀏覽器有很好的js引擎，比如chrome使用的V8。這比我們預測的要快得多。基本的東西是JS 作爲輕量級體系結構介紹。那天服務器發送 html，如果需要的話JS會修改DOM，但是最近幾天服務器只發送數據，JS正在創建DOM。所以負載更多的是JS 方面。這在良好的JS引擎的幫助下很好。
你對我的問題的回答非常好。我不能公開投票。英語有點難理解，但主持人應該爲您清理它。謝謝，我現在非常瞭解更多。我不得不不同意你和WebGL和遊戲點。如果Web應用程序通過移動設備運行，那麼是的，我同意100％。但是，如果它在PC或控制檯上運行，從技術上說它可以訪問相同的硬件。性能問題純粹是基於軟件的。這實質上正是我試圖通過問這個問題來解決/理解的東西。 –
如果您打算投票回答問題，請告訴我爲什麼我可以改變它，以便我下次可以提出更好的問題。簡單地投下它就不會向我或其他社羣提供有關提問的有用信息。 –
它的解釋並不完全準確。現代瀏覽器中的大部分Javascript都是JIT編譯的，除了一些無法編譯的構造外。 – PMV
是的，你說得對。從技術上說，JS是使用Just-In-Time編譯編譯的。但即便如此，事實仍然是這比AOT編譯速度慢。 –