"

特別說明

這是一個由 simviso 團隊對 JSConf.Asia 中關於 WebAssembly 相關話題進行翻譯的文檔,內容並非直譯,其中有一些是譯者自身的思考。分享者是 Kas Perch,Cloudflare 的一名開發人員。現在,讓我們一起來了解下什麼是 WebAssembly。

一、前言

"

特別說明

這是一個由 simviso 團隊對 JSConf.Asia 中關於 WebAssembly 相關話題進行翻譯的文檔,內容並非直譯,其中有一些是譯者自身的思考。分享者是 Kas Perch,Cloudflare 的一名開發人員。現在,讓我們一起來了解下什麼是 WebAssembly。

一、前言

JS 的未來和 Web 多語言開發

大家好,太棒了。就像他們所說,如果我們搞定了 WebAssembly 技術,那麼就搞定了 JS 的未來和 Web 多語言開發。

正如介紹所言,我叫 Kas Perch,現在是 Cloudflare 公司的一名 Avocado 開發人員。同時,我也很痴迷於機器人編程,並且寫過相關書籍。

我已經寫了兩本使用 JS 給機器人編程的書。我週末也會在 twitch 上直播一些硬件和軟件相關的東西。

我養了兩隻貓,它們是我的最愛。左邊的貓叫 Ace,右邊的叫 Aria。它們現在對我很生氣,因為我已經離開它們三個星期了。

"

特別說明

這是一個由 simviso 團隊對 JSConf.Asia 中關於 WebAssembly 相關話題進行翻譯的文檔,內容並非直譯,其中有一些是譯者自身的思考。分享者是 Kas Perch,Cloudflare 的一名開發人員。現在,讓我們一起來了解下什麼是 WebAssembly。

一、前言

JS 的未來和 Web 多語言開發

大家好,太棒了。就像他們所說,如果我們搞定了 WebAssembly 技術,那麼就搞定了 JS 的未來和 Web 多語言開發。

正如介紹所言,我叫 Kas Perch,現在是 Cloudflare 公司的一名 Avocado 開發人員。同時,我也很痴迷於機器人編程,並且寫過相關書籍。

我已經寫了兩本使用 JS 給機器人編程的書。我週末也會在 twitch 上直播一些硬件和軟件相關的東西。

我養了兩隻貓,它們是我的最愛。左邊的貓叫 Ace,右邊的叫 Aria。它們現在對我很生氣,因為我已經離開它們三個星期了。

JS 的未來和 Web 多語言開發

我可能再過一個星期才回去,它們是真的很生我的氣。

言歸正傳,你們來到這裡就是為了聽一些關於 WebAssembly 的一些東西

二、什麼是 WebAssembly

這項技術已經有五年了,我們還在維護中,我們冷靜下來思考一下,為什麼直到現在還沒有人指出該如何使用它。因為人們很難做到該如何更容易的去理解它(因為它很抽象),這也是為什麼我們要來談下它到底是什麼。

首先,我想說,它不是一個編程語言(注:WebAssembly 是驅動編程語言的存在,此處就相當於一個獵頭,針對後面這句話),就像你曾經去領英上面招聘員工一樣,你說你需要一個有十年開發經驗的 Node.js 程序員。

這個就像是在說,我是一個 WebAssembly 程序員,就好像如果你不會 WebAssembly 編程,你就不會寫 WebAssembly 程序(就好比如果你不會 Nodejs,你就不會使用 Nodejs 編程)。

其次,WebAssembly 不會取代 JS ,同時它可以讓 JS 駕馭任何事。

JS 並不會沒落,更不會被 WebAssembly 打敗,因為它並不是為了打敗 JS 而設計的。

WebAssembly 恰恰是我們無法去忽視的東西,因為它可以讓我們走得更遠

我希望在接下來二十幾分鍾你們能被我征服,因為 WebAssembly 是未來的發展趨勢。

不好意思,按錯了。

那麼 WebAssembly 到底是什麼呢?

"

特別說明

這是一個由 simviso 團隊對 JSConf.Asia 中關於 WebAssembly 相關話題進行翻譯的文檔,內容並非直譯,其中有一些是譯者自身的思考。分享者是 Kas Perch,Cloudflare 的一名開發人員。現在,讓我們一起來了解下什麼是 WebAssembly。

一、前言

JS 的未來和 Web 多語言開發

大家好,太棒了。就像他們所說,如果我們搞定了 WebAssembly 技術,那麼就搞定了 JS 的未來和 Web 多語言開發。

正如介紹所言,我叫 Kas Perch,現在是 Cloudflare 公司的一名 Avocado 開發人員。同時,我也很痴迷於機器人編程,並且寫過相關書籍。

我已經寫了兩本使用 JS 給機器人編程的書。我週末也會在 twitch 上直播一些硬件和軟件相關的東西。

我養了兩隻貓,它們是我的最愛。左邊的貓叫 Ace,右邊的叫 Aria。它們現在對我很生氣,因為我已經離開它們三個星期了。

JS 的未來和 Web 多語言開發

我可能再過一個星期才回去,它們是真的很生我的氣。

言歸正傳,你們來到這裡就是為了聽一些關於 WebAssembly 的一些東西

二、什麼是 WebAssembly

這項技術已經有五年了,我們還在維護中,我們冷靜下來思考一下,為什麼直到現在還沒有人指出該如何使用它。因為人們很難做到該如何更容易的去理解它(因為它很抽象),這也是為什麼我們要來談下它到底是什麼。

首先,我想說,它不是一個編程語言(注:WebAssembly 是驅動編程語言的存在,此處就相當於一個獵頭,針對後面這句話),就像你曾經去領英上面招聘員工一樣,你說你需要一個有十年開發經驗的 Node.js 程序員。

這個就像是在說,我是一個 WebAssembly 程序員,就好像如果你不會 WebAssembly 編程,你就不會寫 WebAssembly 程序(就好比如果你不會 Nodejs,你就不會使用 Nodejs 編程)。

其次,WebAssembly 不會取代 JS ,同時它可以讓 JS 駕馭任何事。

JS 並不會沒落,更不會被 WebAssembly 打敗,因為它並不是為了打敗 JS 而設計的。

WebAssembly 恰恰是我們無法去忽視的東西,因為它可以讓我們走得更遠

我希望在接下來二十幾分鍾你們能被我征服,因為 WebAssembly 是未來的發展趨勢。

不好意思,按錯了。

那麼 WebAssembly 到底是什麼呢?

JS 的未來和 Web 多語言開發

它為其他語言提供編譯服務,你可以將其他語言編譯成 WebAssembly,它是一種規範(類似於 jvm 支持的 class 字節碼)和要編譯成的目標文件類型。

這對於 JS 來說是一種能力的增強。WebAssembly 根本就不是想要取代 JS ,而是仍然讓 JS 做它所擅長的領域,同時也能讓 JS 也能做它所不擅長的領域,這就是它要做的事情。

但更重要的是,WebAssembly 表面上很神奇,但卻不僅僅只是表面上神奇,我會在後面解釋這點。

WebAssembly 的目標就是將你用其他語言寫的代碼編譯成 wasm 類型文件。

WebAssembly 已經很好的支持了 Rust 語言,C/C++,GO 和 C# 已經可以用 WebAssembly 編譯。

還有很多語言沒有提到,當然我能想到的主要就這四個,尤其是 Rust, WebAssembly 對它進行了相當多的優化,你有機會可以嘗試一下,這絕對是一個非常酷的編程體驗。

"

特別說明

這是一個由 simviso 團隊對 JSConf.Asia 中關於 WebAssembly 相關話題進行翻譯的文檔,內容並非直譯,其中有一些是譯者自身的思考。分享者是 Kas Perch,Cloudflare 的一名開發人員。現在,讓我們一起來了解下什麼是 WebAssembly。

一、前言

JS 的未來和 Web 多語言開發

大家好,太棒了。就像他們所說,如果我們搞定了 WebAssembly 技術,那麼就搞定了 JS 的未來和 Web 多語言開發。

正如介紹所言,我叫 Kas Perch,現在是 Cloudflare 公司的一名 Avocado 開發人員。同時,我也很痴迷於機器人編程,並且寫過相關書籍。

我已經寫了兩本使用 JS 給機器人編程的書。我週末也會在 twitch 上直播一些硬件和軟件相關的東西。

我養了兩隻貓,它們是我的最愛。左邊的貓叫 Ace,右邊的叫 Aria。它們現在對我很生氣,因為我已經離開它們三個星期了。

JS 的未來和 Web 多語言開發

我可能再過一個星期才回去,它們是真的很生我的氣。

言歸正傳,你們來到這裡就是為了聽一些關於 WebAssembly 的一些東西

二、什麼是 WebAssembly

這項技術已經有五年了,我們還在維護中,我們冷靜下來思考一下,為什麼直到現在還沒有人指出該如何使用它。因為人們很難做到該如何更容易的去理解它(因為它很抽象),這也是為什麼我們要來談下它到底是什麼。

首先,我想說,它不是一個編程語言(注:WebAssembly 是驅動編程語言的存在,此處就相當於一個獵頭,針對後面這句話),就像你曾經去領英上面招聘員工一樣,你說你需要一個有十年開發經驗的 Node.js 程序員。

這個就像是在說,我是一個 WebAssembly 程序員,就好像如果你不會 WebAssembly 編程,你就不會寫 WebAssembly 程序(就好比如果你不會 Nodejs,你就不會使用 Nodejs 編程)。

其次,WebAssembly 不會取代 JS ,同時它可以讓 JS 駕馭任何事。

JS 並不會沒落,更不會被 WebAssembly 打敗,因為它並不是為了打敗 JS 而設計的。

WebAssembly 恰恰是我們無法去忽視的東西,因為它可以讓我們走得更遠

我希望在接下來二十幾分鍾你們能被我征服,因為 WebAssembly 是未來的發展趨勢。

不好意思,按錯了。

那麼 WebAssembly 到底是什麼呢?

JS 的未來和 Web 多語言開發

它為其他語言提供編譯服務,你可以將其他語言編譯成 WebAssembly,它是一種規範(類似於 jvm 支持的 class 字節碼)和要編譯成的目標文件類型。

這對於 JS 來說是一種能力的增強。WebAssembly 根本就不是想要取代 JS ,而是仍然讓 JS 做它所擅長的領域,同時也能讓 JS 也能做它所不擅長的領域,這就是它要做的事情。

但更重要的是,WebAssembly 表面上很神奇,但卻不僅僅只是表面上神奇,我會在後面解釋這點。

WebAssembly 的目標就是將你用其他語言寫的代碼編譯成 wasm 類型文件。

WebAssembly 已經很好的支持了 Rust 語言,C/C++,GO 和 C# 已經可以用 WebAssembly 編譯。

還有很多語言沒有提到,當然我能想到的主要就這四個,尤其是 Rust, WebAssembly 對它進行了相當多的優化,你有機會可以嘗試一下,這絕對是一個非常酷的編程體驗。

JS 的未來和 Web 多語言開發

那麼這裡,你可能會問:為什麼要用其他語言來寫 Web 程序?你為什麼要這麼做?為什麼你會在這裡放上 Laurie Voss(npm 的作者) 的演講照片,然後你使用其他語言來講這些東西?

主要有兩個理由:A,我想要和 Laurie Voss 進行合照。B,讓大家一起擁抱 WebAssembly。

三、下一個 Ajax

對於瀏覽器來說它就像是下一個 Ajax(就好比是下一個喬布斯)。

在這週末,我已經看到了很多有這樣(驚訝)表情了。

OK,就像下一個喬布斯(這裡是 Ajax),聽起來很酷。

但是我的意思是說 Ajax 真的高度可信並且使客戶端層面應用成為可能,所以說,Ajax 是一個變革,而 WebAssembly 將是下一步的一個變革。

這是我今天早上找到的一張超可愛的寶可夢 GIF,我就想著要把它貼上來。

"

特別說明

這是一個由 simviso 團隊對 JSConf.Asia 中關於 WebAssembly 相關話題進行翻譯的文檔,內容並非直譯,其中有一些是譯者自身的思考。分享者是 Kas Perch,Cloudflare 的一名開發人員。現在,讓我們一起來了解下什麼是 WebAssembly。

一、前言

JS 的未來和 Web 多語言開發

大家好,太棒了。就像他們所說,如果我們搞定了 WebAssembly 技術,那麼就搞定了 JS 的未來和 Web 多語言開發。

正如介紹所言,我叫 Kas Perch,現在是 Cloudflare 公司的一名 Avocado 開發人員。同時,我也很痴迷於機器人編程,並且寫過相關書籍。

我已經寫了兩本使用 JS 給機器人編程的書。我週末也會在 twitch 上直播一些硬件和軟件相關的東西。

我養了兩隻貓,它們是我的最愛。左邊的貓叫 Ace,右邊的叫 Aria。它們現在對我很生氣,因為我已經離開它們三個星期了。

JS 的未來和 Web 多語言開發

我可能再過一個星期才回去,它們是真的很生我的氣。

言歸正傳,你們來到這裡就是為了聽一些關於 WebAssembly 的一些東西

二、什麼是 WebAssembly

這項技術已經有五年了,我們還在維護中,我們冷靜下來思考一下,為什麼直到現在還沒有人指出該如何使用它。因為人們很難做到該如何更容易的去理解它(因為它很抽象),這也是為什麼我們要來談下它到底是什麼。

首先,我想說,它不是一個編程語言(注:WebAssembly 是驅動編程語言的存在,此處就相當於一個獵頭,針對後面這句話),就像你曾經去領英上面招聘員工一樣,你說你需要一個有十年開發經驗的 Node.js 程序員。

這個就像是在說,我是一個 WebAssembly 程序員,就好像如果你不會 WebAssembly 編程,你就不會寫 WebAssembly 程序(就好比如果你不會 Nodejs,你就不會使用 Nodejs 編程)。

其次,WebAssembly 不會取代 JS ,同時它可以讓 JS 駕馭任何事。

JS 並不會沒落,更不會被 WebAssembly 打敗,因為它並不是為了打敗 JS 而設計的。

WebAssembly 恰恰是我們無法去忽視的東西,因為它可以讓我們走得更遠

我希望在接下來二十幾分鍾你們能被我征服,因為 WebAssembly 是未來的發展趨勢。

不好意思,按錯了。

那麼 WebAssembly 到底是什麼呢?

JS 的未來和 Web 多語言開發

它為其他語言提供編譯服務,你可以將其他語言編譯成 WebAssembly,它是一種規範(類似於 jvm 支持的 class 字節碼)和要編譯成的目標文件類型。

這對於 JS 來說是一種能力的增強。WebAssembly 根本就不是想要取代 JS ,而是仍然讓 JS 做它所擅長的領域,同時也能讓 JS 也能做它所不擅長的領域,這就是它要做的事情。

但更重要的是,WebAssembly 表面上很神奇,但卻不僅僅只是表面上神奇,我會在後面解釋這點。

WebAssembly 的目標就是將你用其他語言寫的代碼編譯成 wasm 類型文件。

WebAssembly 已經很好的支持了 Rust 語言,C/C++,GO 和 C# 已經可以用 WebAssembly 編譯。

還有很多語言沒有提到,當然我能想到的主要就這四個,尤其是 Rust, WebAssembly 對它進行了相當多的優化,你有機會可以嘗試一下,這絕對是一個非常酷的編程體驗。

JS 的未來和 Web 多語言開發

那麼這裡,你可能會問:為什麼要用其他語言來寫 Web 程序?你為什麼要這麼做?為什麼你會在這裡放上 Laurie Voss(npm 的作者) 的演講照片,然後你使用其他語言來講這些東西?

主要有兩個理由:A,我想要和 Laurie Voss 進行合照。B,讓大家一起擁抱 WebAssembly。

三、下一個 Ajax

對於瀏覽器來說它就像是下一個 Ajax(就好比是下一個喬布斯)。

在這週末,我已經看到了很多有這樣(驚訝)表情了。

OK,就像下一個喬布斯(這裡是 Ajax),聽起來很酷。

但是我的意思是說 Ajax 真的高度可信並且使客戶端層面應用成為可能,所以說,Ajax 是一個變革,而 WebAssembly 將是下一步的一個變革。

這是我今天早上找到的一張超可愛的寶可夢 GIF,我就想著要把它貼上來。

JS 的未來和 Web 多語言開發

為了跟貼圖保持一致我特意選用了“進化”這個詞,不知道你們注沒注意 GIF 周邊我還寫了字的哈。

這時候你可能想著說,行吧,可能這就是下一個 Ajax,但還是抱著幾分遲疑態度。

這幅畫是我早上在 OneNote 上畫的。

"

特別說明

這是一個由 simviso 團隊對 JSConf.Asia 中關於 WebAssembly 相關話題進行翻譯的文檔,內容並非直譯,其中有一些是譯者自身的思考。分享者是 Kas Perch,Cloudflare 的一名開發人員。現在,讓我們一起來了解下什麼是 WebAssembly。

一、前言

JS 的未來和 Web 多語言開發

大家好,太棒了。就像他們所說,如果我們搞定了 WebAssembly 技術,那麼就搞定了 JS 的未來和 Web 多語言開發。

正如介紹所言,我叫 Kas Perch,現在是 Cloudflare 公司的一名 Avocado 開發人員。同時,我也很痴迷於機器人編程,並且寫過相關書籍。

我已經寫了兩本使用 JS 給機器人編程的書。我週末也會在 twitch 上直播一些硬件和軟件相關的東西。

我養了兩隻貓,它們是我的最愛。左邊的貓叫 Ace,右邊的叫 Aria。它們現在對我很生氣,因為我已經離開它們三個星期了。

JS 的未來和 Web 多語言開發

我可能再過一個星期才回去,它們是真的很生我的氣。

言歸正傳,你們來到這裡就是為了聽一些關於 WebAssembly 的一些東西

二、什麼是 WebAssembly

這項技術已經有五年了,我們還在維護中,我們冷靜下來思考一下,為什麼直到現在還沒有人指出該如何使用它。因為人們很難做到該如何更容易的去理解它(因為它很抽象),這也是為什麼我們要來談下它到底是什麼。

首先,我想說,它不是一個編程語言(注:WebAssembly 是驅動編程語言的存在,此處就相當於一個獵頭,針對後面這句話),就像你曾經去領英上面招聘員工一樣,你說你需要一個有十年開發經驗的 Node.js 程序員。

這個就像是在說,我是一個 WebAssembly 程序員,就好像如果你不會 WebAssembly 編程,你就不會寫 WebAssembly 程序(就好比如果你不會 Nodejs,你就不會使用 Nodejs 編程)。

其次,WebAssembly 不會取代 JS ,同時它可以讓 JS 駕馭任何事。

JS 並不會沒落,更不會被 WebAssembly 打敗,因為它並不是為了打敗 JS 而設計的。

WebAssembly 恰恰是我們無法去忽視的東西,因為它可以讓我們走得更遠

我希望在接下來二十幾分鍾你們能被我征服,因為 WebAssembly 是未來的發展趨勢。

不好意思,按錯了。

那麼 WebAssembly 到底是什麼呢?

JS 的未來和 Web 多語言開發

它為其他語言提供編譯服務,你可以將其他語言編譯成 WebAssembly,它是一種規範(類似於 jvm 支持的 class 字節碼)和要編譯成的目標文件類型。

這對於 JS 來說是一種能力的增強。WebAssembly 根本就不是想要取代 JS ,而是仍然讓 JS 做它所擅長的領域,同時也能讓 JS 也能做它所不擅長的領域,這就是它要做的事情。

但更重要的是,WebAssembly 表面上很神奇,但卻不僅僅只是表面上神奇,我會在後面解釋這點。

WebAssembly 的目標就是將你用其他語言寫的代碼編譯成 wasm 類型文件。

WebAssembly 已經很好的支持了 Rust 語言,C/C++,GO 和 C# 已經可以用 WebAssembly 編譯。

還有很多語言沒有提到,當然我能想到的主要就這四個,尤其是 Rust, WebAssembly 對它進行了相當多的優化,你有機會可以嘗試一下,這絕對是一個非常酷的編程體驗。

JS 的未來和 Web 多語言開發

那麼這裡,你可能會問:為什麼要用其他語言來寫 Web 程序?你為什麼要這麼做?為什麼你會在這裡放上 Laurie Voss(npm 的作者) 的演講照片,然後你使用其他語言來講這些東西?

主要有兩個理由:A,我想要和 Laurie Voss 進行合照。B,讓大家一起擁抱 WebAssembly。

三、下一個 Ajax

對於瀏覽器來說它就像是下一個 Ajax(就好比是下一個喬布斯)。

在這週末,我已經看到了很多有這樣(驚訝)表情了。

OK,就像下一個喬布斯(這裡是 Ajax),聽起來很酷。

但是我的意思是說 Ajax 真的高度可信並且使客戶端層面應用成為可能,所以說,Ajax 是一個變革,而 WebAssembly 將是下一步的一個變革。

這是我今天早上找到的一張超可愛的寶可夢 GIF,我就想著要把它貼上來。

JS 的未來和 Web 多語言開發

為了跟貼圖保持一致我特意選用了“進化”這個詞,不知道你們注沒注意 GIF 周邊我還寫了字的哈。

這時候你可能想著說,行吧,可能這就是下一個 Ajax,但還是抱著幾分遲疑態度。

這幅畫是我早上在 OneNote 上畫的。

JS 的未來和 Web 多語言開發

我把它稱為 “ancient.png.”

讓我們回過來看這張圖,這上面有 HTML,CSS 和 JS。

比如當你打開社交網頁的時候js就會播放煩人的音樂,服務器會返回所有這些東西,所有的東西都在這裡。

請將你的視線隨著我手指移動,當你點擊一個鏈接的時候,它會返回一個頁面,你一直點擊它就一直會給我們返回一個頁面。

每當你想要從服務器獲取新信息的時候,你就需要手動對瀏覽器進行刷新操作。

"

特別說明

這是一個由 simviso 團隊對 JSConf.Asia 中關於 WebAssembly 相關話題進行翻譯的文檔,內容並非直譯,其中有一些是譯者自身的思考。分享者是 Kas Perch,Cloudflare 的一名開發人員。現在,讓我們一起來了解下什麼是 WebAssembly。

一、前言

JS 的未來和 Web 多語言開發

大家好,太棒了。就像他們所說,如果我們搞定了 WebAssembly 技術,那麼就搞定了 JS 的未來和 Web 多語言開發。

正如介紹所言,我叫 Kas Perch,現在是 Cloudflare 公司的一名 Avocado 開發人員。同時,我也很痴迷於機器人編程,並且寫過相關書籍。

我已經寫了兩本使用 JS 給機器人編程的書。我週末也會在 twitch 上直播一些硬件和軟件相關的東西。

我養了兩隻貓,它們是我的最愛。左邊的貓叫 Ace,右邊的叫 Aria。它們現在對我很生氣,因為我已經離開它們三個星期了。

JS 的未來和 Web 多語言開發

我可能再過一個星期才回去,它們是真的很生我的氣。

言歸正傳,你們來到這裡就是為了聽一些關於 WebAssembly 的一些東西

二、什麼是 WebAssembly

這項技術已經有五年了,我們還在維護中,我們冷靜下來思考一下,為什麼直到現在還沒有人指出該如何使用它。因為人們很難做到該如何更容易的去理解它(因為它很抽象),這也是為什麼我們要來談下它到底是什麼。

首先,我想說,它不是一個編程語言(注:WebAssembly 是驅動編程語言的存在,此處就相當於一個獵頭,針對後面這句話),就像你曾經去領英上面招聘員工一樣,你說你需要一個有十年開發經驗的 Node.js 程序員。

這個就像是在說,我是一個 WebAssembly 程序員,就好像如果你不會 WebAssembly 編程,你就不會寫 WebAssembly 程序(就好比如果你不會 Nodejs,你就不會使用 Nodejs 編程)。

其次,WebAssembly 不會取代 JS ,同時它可以讓 JS 駕馭任何事。

JS 並不會沒落,更不會被 WebAssembly 打敗,因為它並不是為了打敗 JS 而設計的。

WebAssembly 恰恰是我們無法去忽視的東西,因為它可以讓我們走得更遠

我希望在接下來二十幾分鍾你們能被我征服,因為 WebAssembly 是未來的發展趨勢。

不好意思,按錯了。

那麼 WebAssembly 到底是什麼呢?

JS 的未來和 Web 多語言開發

它為其他語言提供編譯服務,你可以將其他語言編譯成 WebAssembly,它是一種規範(類似於 jvm 支持的 class 字節碼)和要編譯成的目標文件類型。

這對於 JS 來說是一種能力的增強。WebAssembly 根本就不是想要取代 JS ,而是仍然讓 JS 做它所擅長的領域,同時也能讓 JS 也能做它所不擅長的領域,這就是它要做的事情。

但更重要的是,WebAssembly 表面上很神奇,但卻不僅僅只是表面上神奇,我會在後面解釋這點。

WebAssembly 的目標就是將你用其他語言寫的代碼編譯成 wasm 類型文件。

WebAssembly 已經很好的支持了 Rust 語言,C/C++,GO 和 C# 已經可以用 WebAssembly 編譯。

還有很多語言沒有提到,當然我能想到的主要就這四個,尤其是 Rust, WebAssembly 對它進行了相當多的優化,你有機會可以嘗試一下,這絕對是一個非常酷的編程體驗。

JS 的未來和 Web 多語言開發

那麼這裡,你可能會問:為什麼要用其他語言來寫 Web 程序?你為什麼要這麼做?為什麼你會在這裡放上 Laurie Voss(npm 的作者) 的演講照片,然後你使用其他語言來講這些東西?

主要有兩個理由:A,我想要和 Laurie Voss 進行合照。B,讓大家一起擁抱 WebAssembly。

三、下一個 Ajax

對於瀏覽器來說它就像是下一個 Ajax(就好比是下一個喬布斯)。

在這週末,我已經看到了很多有這樣(驚訝)表情了。

OK,就像下一個喬布斯(這裡是 Ajax),聽起來很酷。

但是我的意思是說 Ajax 真的高度可信並且使客戶端層面應用成為可能,所以說,Ajax 是一個變革,而 WebAssembly 將是下一步的一個變革。

這是我今天早上找到的一張超可愛的寶可夢 GIF,我就想著要把它貼上來。

JS 的未來和 Web 多語言開發

為了跟貼圖保持一致我特意選用了“進化”這個詞,不知道你們注沒注意 GIF 周邊我還寫了字的哈。

這時候你可能想著說,行吧,可能這就是下一個 Ajax,但還是抱著幾分遲疑態度。

這幅畫是我早上在 OneNote 上畫的。

JS 的未來和 Web 多語言開發

我把它稱為 “ancient.png.”

讓我們回過來看這張圖,這上面有 HTML,CSS 和 JS。

比如當你打開社交網頁的時候js就會播放煩人的音樂,服務器會返回所有這些東西,所有的東西都在這裡。

請將你的視線隨著我手指移動,當你點擊一個鏈接的時候,它會返回一個頁面,你一直點擊它就一直會給我們返回一個頁面。

每當你想要從服務器獲取新信息的時候,你就需要手動對瀏覽器進行刷新操作。

JS 的未來和 Web 多語言開發

我將這張圖稱之為 then.png,Ajax 不是一個 button 但勝似 button。

Ajax 請求頁面,然後獲取頁面內容,我們通過發送 Ajax 請求,來避免刷新頁面的操作。

我們通過 Ajax 得到返回的結果,Ajax 結果可能會是另外一個頁面的請求。

基於這個,我們得到了一系列的單頁應用程序。

當我們的服務器提供了Restful 風格的 API 的時候,也提供臨時的 HTML CSS 和 JS 文件。

這才是我要說的,請看我用高亮顏色所標記出的 WebAssembly 的內容,這裡突出了它的工作原理。

"

特別說明

這是一個由 simviso 團隊對 JSConf.Asia 中關於 WebAssembly 相關話題進行翻譯的文檔,內容並非直譯,其中有一些是譯者自身的思考。分享者是 Kas Perch,Cloudflare 的一名開發人員。現在,讓我們一起來了解下什麼是 WebAssembly。

一、前言

JS 的未來和 Web 多語言開發

大家好,太棒了。就像他們所說,如果我們搞定了 WebAssembly 技術,那麼就搞定了 JS 的未來和 Web 多語言開發。

正如介紹所言,我叫 Kas Perch,現在是 Cloudflare 公司的一名 Avocado 開發人員。同時,我也很痴迷於機器人編程,並且寫過相關書籍。

我已經寫了兩本使用 JS 給機器人編程的書。我週末也會在 twitch 上直播一些硬件和軟件相關的東西。

我養了兩隻貓,它們是我的最愛。左邊的貓叫 Ace,右邊的叫 Aria。它們現在對我很生氣,因為我已經離開它們三個星期了。

JS 的未來和 Web 多語言開發

我可能再過一個星期才回去,它們是真的很生我的氣。

言歸正傳,你們來到這裡就是為了聽一些關於 WebAssembly 的一些東西

二、什麼是 WebAssembly

這項技術已經有五年了,我們還在維護中,我們冷靜下來思考一下,為什麼直到現在還沒有人指出該如何使用它。因為人們很難做到該如何更容易的去理解它(因為它很抽象),這也是為什麼我們要來談下它到底是什麼。

首先,我想說,它不是一個編程語言(注:WebAssembly 是驅動編程語言的存在,此處就相當於一個獵頭,針對後面這句話),就像你曾經去領英上面招聘員工一樣,你說你需要一個有十年開發經驗的 Node.js 程序員。

這個就像是在說,我是一個 WebAssembly 程序員,就好像如果你不會 WebAssembly 編程,你就不會寫 WebAssembly 程序(就好比如果你不會 Nodejs,你就不會使用 Nodejs 編程)。

其次,WebAssembly 不會取代 JS ,同時它可以讓 JS 駕馭任何事。

JS 並不會沒落,更不會被 WebAssembly 打敗,因為它並不是為了打敗 JS 而設計的。

WebAssembly 恰恰是我們無法去忽視的東西,因為它可以讓我們走得更遠

我希望在接下來二十幾分鍾你們能被我征服,因為 WebAssembly 是未來的發展趨勢。

不好意思,按錯了。

那麼 WebAssembly 到底是什麼呢?

JS 的未來和 Web 多語言開發

它為其他語言提供編譯服務,你可以將其他語言編譯成 WebAssembly,它是一種規範(類似於 jvm 支持的 class 字節碼)和要編譯成的目標文件類型。

這對於 JS 來說是一種能力的增強。WebAssembly 根本就不是想要取代 JS ,而是仍然讓 JS 做它所擅長的領域,同時也能讓 JS 也能做它所不擅長的領域,這就是它要做的事情。

但更重要的是,WebAssembly 表面上很神奇,但卻不僅僅只是表面上神奇,我會在後面解釋這點。

WebAssembly 的目標就是將你用其他語言寫的代碼編譯成 wasm 類型文件。

WebAssembly 已經很好的支持了 Rust 語言,C/C++,GO 和 C# 已經可以用 WebAssembly 編譯。

還有很多語言沒有提到,當然我能想到的主要就這四個,尤其是 Rust, WebAssembly 對它進行了相當多的優化,你有機會可以嘗試一下,這絕對是一個非常酷的編程體驗。

JS 的未來和 Web 多語言開發

那麼這裡,你可能會問:為什麼要用其他語言來寫 Web 程序?你為什麼要這麼做?為什麼你會在這裡放上 Laurie Voss(npm 的作者) 的演講照片,然後你使用其他語言來講這些東西?

主要有兩個理由:A,我想要和 Laurie Voss 進行合照。B,讓大家一起擁抱 WebAssembly。

三、下一個 Ajax

對於瀏覽器來說它就像是下一個 Ajax(就好比是下一個喬布斯)。

在這週末,我已經看到了很多有這樣(驚訝)表情了。

OK,就像下一個喬布斯(這裡是 Ajax),聽起來很酷。

但是我的意思是說 Ajax 真的高度可信並且使客戶端層面應用成為可能,所以說,Ajax 是一個變革,而 WebAssembly 將是下一步的一個變革。

這是我今天早上找到的一張超可愛的寶可夢 GIF,我就想著要把它貼上來。

JS 的未來和 Web 多語言開發

為了跟貼圖保持一致我特意選用了“進化”這個詞,不知道你們注沒注意 GIF 周邊我還寫了字的哈。

這時候你可能想著說,行吧,可能這就是下一個 Ajax,但還是抱著幾分遲疑態度。

這幅畫是我早上在 OneNote 上畫的。

JS 的未來和 Web 多語言開發

我把它稱為 “ancient.png.”

讓我們回過來看這張圖,這上面有 HTML,CSS 和 JS。

比如當你打開社交網頁的時候js就會播放煩人的音樂,服務器會返回所有這些東西,所有的東西都在這裡。

請將你的視線隨著我手指移動,當你點擊一個鏈接的時候,它會返回一個頁面,你一直點擊它就一直會給我們返回一個頁面。

每當你想要從服務器獲取新信息的時候,你就需要手動對瀏覽器進行刷新操作。

JS 的未來和 Web 多語言開發

我將這張圖稱之為 then.png,Ajax 不是一個 button 但勝似 button。

Ajax 請求頁面,然後獲取頁面內容,我們通過發送 Ajax 請求,來避免刷新頁面的操作。

我們通過 Ajax 得到返回的結果,Ajax 結果可能會是另外一個頁面的請求。

基於這個,我們得到了一系列的單頁應用程序。

當我們的服務器提供了Restful 風格的 API 的時候,也提供臨時的 HTML CSS 和 JS 文件。

這才是我要說的,請看我用高亮顏色所標記出的 WebAssembly 的內容,這裡突出了它的工作原理。

JS 的未來和 Web 多語言開發

可以看到頁面請求、返回的頁面結果,在這個過程中 WebAssembly 只是做一些計算而已。

我們依然來看兩個圖中左側的 Browser,然後使用 service worker 作為你的第三方模塊。同樣是在這個Browser中,你可以使用一些 Ajax 請求,同時服務器就類似於圖上的 LOL OK。我可能甚至都不是一個真正的服務器,我只是 serverless 服務器上的一個函數而已。

然後返回你的結果。整個過程簡直不可思議!

OK,相信你現在應該有點感覺了。

四、對 JS 進行增強

能夠在瀏覽器中計算內容,不一定非要用 JS 來實現。

這就是一件大事!相當重要!

那為什麼這很重要?為什麼我們要這麼關注?

我們之所以這麼關心是因為我們對 JS 進行增強。

"

特別說明

這是一個由 simviso 團隊對 JSConf.Asia 中關於 WebAssembly 相關話題進行翻譯的文檔,內容並非直譯,其中有一些是譯者自身的思考。分享者是 Kas Perch,Cloudflare 的一名開發人員。現在,讓我們一起來了解下什麼是 WebAssembly。

一、前言

JS 的未來和 Web 多語言開發

大家好,太棒了。就像他們所說,如果我們搞定了 WebAssembly 技術,那麼就搞定了 JS 的未來和 Web 多語言開發。

正如介紹所言,我叫 Kas Perch,現在是 Cloudflare 公司的一名 Avocado 開發人員。同時,我也很痴迷於機器人編程,並且寫過相關書籍。

我已經寫了兩本使用 JS 給機器人編程的書。我週末也會在 twitch 上直播一些硬件和軟件相關的東西。

我養了兩隻貓,它們是我的最愛。左邊的貓叫 Ace,右邊的叫 Aria。它們現在對我很生氣,因為我已經離開它們三個星期了。

JS 的未來和 Web 多語言開發

我可能再過一個星期才回去,它們是真的很生我的氣。

言歸正傳,你們來到這裡就是為了聽一些關於 WebAssembly 的一些東西

二、什麼是 WebAssembly

這項技術已經有五年了,我們還在維護中,我們冷靜下來思考一下,為什麼直到現在還沒有人指出該如何使用它。因為人們很難做到該如何更容易的去理解它(因為它很抽象),這也是為什麼我們要來談下它到底是什麼。

首先,我想說,它不是一個編程語言(注:WebAssembly 是驅動編程語言的存在,此處就相當於一個獵頭,針對後面這句話),就像你曾經去領英上面招聘員工一樣,你說你需要一個有十年開發經驗的 Node.js 程序員。

這個就像是在說,我是一個 WebAssembly 程序員,就好像如果你不會 WebAssembly 編程,你就不會寫 WebAssembly 程序(就好比如果你不會 Nodejs,你就不會使用 Nodejs 編程)。

其次,WebAssembly 不會取代 JS ,同時它可以讓 JS 駕馭任何事。

JS 並不會沒落,更不會被 WebAssembly 打敗,因為它並不是為了打敗 JS 而設計的。

WebAssembly 恰恰是我們無法去忽視的東西,因為它可以讓我們走得更遠

我希望在接下來二十幾分鍾你們能被我征服,因為 WebAssembly 是未來的發展趨勢。

不好意思,按錯了。

那麼 WebAssembly 到底是什麼呢?

JS 的未來和 Web 多語言開發

它為其他語言提供編譯服務,你可以將其他語言編譯成 WebAssembly,它是一種規範(類似於 jvm 支持的 class 字節碼)和要編譯成的目標文件類型。

這對於 JS 來說是一種能力的增強。WebAssembly 根本就不是想要取代 JS ,而是仍然讓 JS 做它所擅長的領域,同時也能讓 JS 也能做它所不擅長的領域,這就是它要做的事情。

但更重要的是,WebAssembly 表面上很神奇,但卻不僅僅只是表面上神奇,我會在後面解釋這點。

WebAssembly 的目標就是將你用其他語言寫的代碼編譯成 wasm 類型文件。

WebAssembly 已經很好的支持了 Rust 語言,C/C++,GO 和 C# 已經可以用 WebAssembly 編譯。

還有很多語言沒有提到,當然我能想到的主要就這四個,尤其是 Rust, WebAssembly 對它進行了相當多的優化,你有機會可以嘗試一下,這絕對是一個非常酷的編程體驗。

JS 的未來和 Web 多語言開發

那麼這裡,你可能會問:為什麼要用其他語言來寫 Web 程序?你為什麼要這麼做?為什麼你會在這裡放上 Laurie Voss(npm 的作者) 的演講照片,然後你使用其他語言來講這些東西?

主要有兩個理由:A,我想要和 Laurie Voss 進行合照。B,讓大家一起擁抱 WebAssembly。

三、下一個 Ajax

對於瀏覽器來說它就像是下一個 Ajax(就好比是下一個喬布斯)。

在這週末,我已經看到了很多有這樣(驚訝)表情了。

OK,就像下一個喬布斯(這裡是 Ajax),聽起來很酷。

但是我的意思是說 Ajax 真的高度可信並且使客戶端層面應用成為可能,所以說,Ajax 是一個變革,而 WebAssembly 將是下一步的一個變革。

這是我今天早上找到的一張超可愛的寶可夢 GIF,我就想著要把它貼上來。

JS 的未來和 Web 多語言開發

為了跟貼圖保持一致我特意選用了“進化”這個詞,不知道你們注沒注意 GIF 周邊我還寫了字的哈。

這時候你可能想著說,行吧,可能這就是下一個 Ajax,但還是抱著幾分遲疑態度。

這幅畫是我早上在 OneNote 上畫的。

JS 的未來和 Web 多語言開發

我把它稱為 “ancient.png.”

讓我們回過來看這張圖,這上面有 HTML,CSS 和 JS。

比如當你打開社交網頁的時候js就會播放煩人的音樂,服務器會返回所有這些東西,所有的東西都在這裡。

請將你的視線隨著我手指移動,當你點擊一個鏈接的時候,它會返回一個頁面,你一直點擊它就一直會給我們返回一個頁面。

每當你想要從服務器獲取新信息的時候,你就需要手動對瀏覽器進行刷新操作。

JS 的未來和 Web 多語言開發

我將這張圖稱之為 then.png,Ajax 不是一個 button 但勝似 button。

Ajax 請求頁面,然後獲取頁面內容,我們通過發送 Ajax 請求,來避免刷新頁面的操作。

我們通過 Ajax 得到返回的結果,Ajax 結果可能會是另外一個頁面的請求。

基於這個,我們得到了一系列的單頁應用程序。

當我們的服務器提供了Restful 風格的 API 的時候,也提供臨時的 HTML CSS 和 JS 文件。

這才是我要說的,請看我用高亮顏色所標記出的 WebAssembly 的內容,這裡突出了它的工作原理。

JS 的未來和 Web 多語言開發

可以看到頁面請求、返回的頁面結果,在這個過程中 WebAssembly 只是做一些計算而已。

我們依然來看兩個圖中左側的 Browser,然後使用 service worker 作為你的第三方模塊。同樣是在這個Browser中,你可以使用一些 Ajax 請求,同時服務器就類似於圖上的 LOL OK。我可能甚至都不是一個真正的服務器,我只是 serverless 服務器上的一個函數而已。

然後返回你的結果。整個過程簡直不可思議!

OK,相信你現在應該有點感覺了。

四、對 JS 進行增強

能夠在瀏覽器中計算內容,不一定非要用 JS 來實現。

這就是一件大事!相當重要!

那為什麼這很重要?為什麼我們要這麼關注?

我們之所以這麼關心是因為我們對 JS 進行增強。

JS 的未來和 Web 多語言開發

我知道,這個話題你也許聽到過很多次,甚至都已經厭倦了。但是這也是事實,JS 在某些方面的確不擅長。

我們並不需要為了使用 WebAssembly 而重寫整個項目代碼,誰也不想重構整個代碼庫,就像五年前那些包含了單元測試的代碼,我想沒人願意來幹這個事情(想重構舉起你們的手,但是沒有)。

挺好

更少的請求調用意味著更少的延遲,也就意味著我們可以為用戶提供更快的 Web 應用。

高性能一直都是很重要的。這樣的話,我們就無需對服務器進行成千上百萬次的請求。

所以,我們來談談該如何對 JS 進行增強。

我相信在你的工作過程中已經看到過很多次這種表達式(0.1 + 0.2 === 0.3 // false)了吧,其實0.1 + 0.2 = 0.30000000000000004(精度運算),所以 0.1 + 0.2 === 0.3 是 false

"

特別說明

這是一個由 simviso 團隊對 JSConf.Asia 中關於 WebAssembly 相關話題進行翻譯的文檔,內容並非直譯,其中有一些是譯者自身的思考。分享者是 Kas Perch,Cloudflare 的一名開發人員。現在,讓我們一起來了解下什麼是 WebAssembly。

一、前言

JS 的未來和 Web 多語言開發

大家好,太棒了。就像他們所說,如果我們搞定了 WebAssembly 技術,那麼就搞定了 JS 的未來和 Web 多語言開發。

正如介紹所言,我叫 Kas Perch,現在是 Cloudflare 公司的一名 Avocado 開發人員。同時,我也很痴迷於機器人編程,並且寫過相關書籍。

我已經寫了兩本使用 JS 給機器人編程的書。我週末也會在 twitch 上直播一些硬件和軟件相關的東西。

我養了兩隻貓,它們是我的最愛。左邊的貓叫 Ace,右邊的叫 Aria。它們現在對我很生氣,因為我已經離開它們三個星期了。

JS 的未來和 Web 多語言開發

我可能再過一個星期才回去,它們是真的很生我的氣。

言歸正傳,你們來到這裡就是為了聽一些關於 WebAssembly 的一些東西

二、什麼是 WebAssembly

這項技術已經有五年了,我們還在維護中,我們冷靜下來思考一下,為什麼直到現在還沒有人指出該如何使用它。因為人們很難做到該如何更容易的去理解它(因為它很抽象),這也是為什麼我們要來談下它到底是什麼。

首先,我想說,它不是一個編程語言(注:WebAssembly 是驅動編程語言的存在,此處就相當於一個獵頭,針對後面這句話),就像你曾經去領英上面招聘員工一樣,你說你需要一個有十年開發經驗的 Node.js 程序員。

這個就像是在說,我是一個 WebAssembly 程序員,就好像如果你不會 WebAssembly 編程,你就不會寫 WebAssembly 程序(就好比如果你不會 Nodejs,你就不會使用 Nodejs 編程)。

其次,WebAssembly 不會取代 JS ,同時它可以讓 JS 駕馭任何事。

JS 並不會沒落,更不會被 WebAssembly 打敗,因為它並不是為了打敗 JS 而設計的。

WebAssembly 恰恰是我們無法去忽視的東西,因為它可以讓我們走得更遠

我希望在接下來二十幾分鍾你們能被我征服,因為 WebAssembly 是未來的發展趨勢。

不好意思,按錯了。

那麼 WebAssembly 到底是什麼呢?

JS 的未來和 Web 多語言開發

它為其他語言提供編譯服務,你可以將其他語言編譯成 WebAssembly,它是一種規範(類似於 jvm 支持的 class 字節碼)和要編譯成的目標文件類型。

這對於 JS 來說是一種能力的增強。WebAssembly 根本就不是想要取代 JS ,而是仍然讓 JS 做它所擅長的領域,同時也能讓 JS 也能做它所不擅長的領域,這就是它要做的事情。

但更重要的是,WebAssembly 表面上很神奇,但卻不僅僅只是表面上神奇,我會在後面解釋這點。

WebAssembly 的目標就是將你用其他語言寫的代碼編譯成 wasm 類型文件。

WebAssembly 已經很好的支持了 Rust 語言,C/C++,GO 和 C# 已經可以用 WebAssembly 編譯。

還有很多語言沒有提到,當然我能想到的主要就這四個,尤其是 Rust, WebAssembly 對它進行了相當多的優化,你有機會可以嘗試一下,這絕對是一個非常酷的編程體驗。

JS 的未來和 Web 多語言開發

那麼這裡,你可能會問:為什麼要用其他語言來寫 Web 程序?你為什麼要這麼做?為什麼你會在這裡放上 Laurie Voss(npm 的作者) 的演講照片,然後你使用其他語言來講這些東西?

主要有兩個理由:A,我想要和 Laurie Voss 進行合照。B,讓大家一起擁抱 WebAssembly。

三、下一個 Ajax

對於瀏覽器來說它就像是下一個 Ajax(就好比是下一個喬布斯)。

在這週末,我已經看到了很多有這樣(驚訝)表情了。

OK,就像下一個喬布斯(這裡是 Ajax),聽起來很酷。

但是我的意思是說 Ajax 真的高度可信並且使客戶端層面應用成為可能,所以說,Ajax 是一個變革,而 WebAssembly 將是下一步的一個變革。

這是我今天早上找到的一張超可愛的寶可夢 GIF,我就想著要把它貼上來。

JS 的未來和 Web 多語言開發

為了跟貼圖保持一致我特意選用了“進化”這個詞,不知道你們注沒注意 GIF 周邊我還寫了字的哈。

這時候你可能想著說,行吧,可能這就是下一個 Ajax,但還是抱著幾分遲疑態度。

這幅畫是我早上在 OneNote 上畫的。

JS 的未來和 Web 多語言開發

我把它稱為 “ancient.png.”

讓我們回過來看這張圖,這上面有 HTML,CSS 和 JS。

比如當你打開社交網頁的時候js就會播放煩人的音樂,服務器會返回所有這些東西,所有的東西都在這裡。

請將你的視線隨著我手指移動,當你點擊一個鏈接的時候,它會返回一個頁面,你一直點擊它就一直會給我們返回一個頁面。

每當你想要從服務器獲取新信息的時候,你就需要手動對瀏覽器進行刷新操作。

JS 的未來和 Web 多語言開發

我將這張圖稱之為 then.png,Ajax 不是一個 button 但勝似 button。

Ajax 請求頁面,然後獲取頁面內容,我們通過發送 Ajax 請求,來避免刷新頁面的操作。

我們通過 Ajax 得到返回的結果,Ajax 結果可能會是另外一個頁面的請求。

基於這個,我們得到了一系列的單頁應用程序。

當我們的服務器提供了Restful 風格的 API 的時候,也提供臨時的 HTML CSS 和 JS 文件。

這才是我要說的,請看我用高亮顏色所標記出的 WebAssembly 的內容,這裡突出了它的工作原理。

JS 的未來和 Web 多語言開發

可以看到頁面請求、返回的頁面結果,在這個過程中 WebAssembly 只是做一些計算而已。

我們依然來看兩個圖中左側的 Browser,然後使用 service worker 作為你的第三方模塊。同樣是在這個Browser中,你可以使用一些 Ajax 請求,同時服務器就類似於圖上的 LOL OK。我可能甚至都不是一個真正的服務器,我只是 serverless 服務器上的一個函數而已。

然後返回你的結果。整個過程簡直不可思議!

OK,相信你現在應該有點感覺了。

四、對 JS 進行增強

能夠在瀏覽器中計算內容,不一定非要用 JS 來實現。

這就是一件大事!相當重要!

那為什麼這很重要?為什麼我們要這麼關注?

我們之所以這麼關心是因為我們對 JS 進行增強。

JS 的未來和 Web 多語言開發

我知道,這個話題你也許聽到過很多次,甚至都已經厭倦了。但是這也是事實,JS 在某些方面的確不擅長。

我們並不需要為了使用 WebAssembly 而重寫整個項目代碼,誰也不想重構整個代碼庫,就像五年前那些包含了單元測試的代碼,我想沒人願意來幹這個事情(想重構舉起你們的手,但是沒有)。

挺好

更少的請求調用意味著更少的延遲,也就意味著我們可以為用戶提供更快的 Web 應用。

高性能一直都是很重要的。這樣的話,我們就無需對服務器進行成千上百萬次的請求。

所以,我們來談談該如何對 JS 進行增強。

我相信在你的工作過程中已經看到過很多次這種表達式(0.1 + 0.2 === 0.3 // false)了吧,其實0.1 + 0.2 = 0.30000000000000004(精度運算),所以 0.1 + 0.2 === 0.3 是 false

JS 的未來和 Web 多語言開發

所以如果你正在做的事情對數字精讀有很高的要求,比如:金融應用、股票交易、貨幣兌換。那麼很顯然,這些並不是 JS 的強項。

你需要對那些運行著不同語言的服務器發送一個 Ajax 請求,服務器會返回給你精確的結果,然後你對返回的結果進行了錯誤的轉換(通過 JS 對返回的 JSON包含的數字類型的字符串進行轉換,出現精讀丟失)。

所以通過 WebAssembly,你就可以在瀏覽器中使用正確的工具來完成這項工作,比如:Rust,C,或者其他浮點數超過32位的語言。

"

特別說明

這是一個由 simviso 團隊對 JSConf.Asia 中關於 WebAssembly 相關話題進行翻譯的文檔,內容並非直譯,其中有一些是譯者自身的思考。分享者是 Kas Perch,Cloudflare 的一名開發人員。現在,讓我們一起來了解下什麼是 WebAssembly。

一、前言

JS 的未來和 Web 多語言開發

大家好,太棒了。就像他們所說,如果我們搞定了 WebAssembly 技術,那麼就搞定了 JS 的未來和 Web 多語言開發。

正如介紹所言,我叫 Kas Perch,現在是 Cloudflare 公司的一名 Avocado 開發人員。同時,我也很痴迷於機器人編程,並且寫過相關書籍。

我已經寫了兩本使用 JS 給機器人編程的書。我週末也會在 twitch 上直播一些硬件和軟件相關的東西。

我養了兩隻貓,它們是我的最愛。左邊的貓叫 Ace,右邊的叫 Aria。它們現在對我很生氣,因為我已經離開它們三個星期了。

JS 的未來和 Web 多語言開發

我可能再過一個星期才回去,它們是真的很生我的氣。

言歸正傳,你們來到這裡就是為了聽一些關於 WebAssembly 的一些東西

二、什麼是 WebAssembly

這項技術已經有五年了,我們還在維護中,我們冷靜下來思考一下,為什麼直到現在還沒有人指出該如何使用它。因為人們很難做到該如何更容易的去理解它(因為它很抽象),這也是為什麼我們要來談下它到底是什麼。

首先,我想說,它不是一個編程語言(注:WebAssembly 是驅動編程語言的存在,此處就相當於一個獵頭,針對後面這句話),就像你曾經去領英上面招聘員工一樣,你說你需要一個有十年開發經驗的 Node.js 程序員。

這個就像是在說,我是一個 WebAssembly 程序員,就好像如果你不會 WebAssembly 編程,你就不會寫 WebAssembly 程序(就好比如果你不會 Nodejs,你就不會使用 Nodejs 編程)。

其次,WebAssembly 不會取代 JS ,同時它可以讓 JS 駕馭任何事。

JS 並不會沒落,更不會被 WebAssembly 打敗,因為它並不是為了打敗 JS 而設計的。

WebAssembly 恰恰是我們無法去忽視的東西,因為它可以讓我們走得更遠

我希望在接下來二十幾分鍾你們能被我征服,因為 WebAssembly 是未來的發展趨勢。

不好意思,按錯了。

那麼 WebAssembly 到底是什麼呢?

JS 的未來和 Web 多語言開發

它為其他語言提供編譯服務,你可以將其他語言編譯成 WebAssembly,它是一種規範(類似於 jvm 支持的 class 字節碼)和要編譯成的目標文件類型。

這對於 JS 來說是一種能力的增強。WebAssembly 根本就不是想要取代 JS ,而是仍然讓 JS 做它所擅長的領域,同時也能讓 JS 也能做它所不擅長的領域,這就是它要做的事情。

但更重要的是,WebAssembly 表面上很神奇,但卻不僅僅只是表面上神奇,我會在後面解釋這點。

WebAssembly 的目標就是將你用其他語言寫的代碼編譯成 wasm 類型文件。

WebAssembly 已經很好的支持了 Rust 語言,C/C++,GO 和 C# 已經可以用 WebAssembly 編譯。

還有很多語言沒有提到,當然我能想到的主要就這四個,尤其是 Rust, WebAssembly 對它進行了相當多的優化,你有機會可以嘗試一下,這絕對是一個非常酷的編程體驗。

JS 的未來和 Web 多語言開發

那麼這裡,你可能會問:為什麼要用其他語言來寫 Web 程序?你為什麼要這麼做?為什麼你會在這裡放上 Laurie Voss(npm 的作者) 的演講照片,然後你使用其他語言來講這些東西?

主要有兩個理由:A,我想要和 Laurie Voss 進行合照。B,讓大家一起擁抱 WebAssembly。

三、下一個 Ajax

對於瀏覽器來說它就像是下一個 Ajax(就好比是下一個喬布斯)。

在這週末,我已經看到了很多有這樣(驚訝)表情了。

OK,就像下一個喬布斯(這裡是 Ajax),聽起來很酷。

但是我的意思是說 Ajax 真的高度可信並且使客戶端層面應用成為可能,所以說,Ajax 是一個變革,而 WebAssembly 將是下一步的一個變革。

這是我今天早上找到的一張超可愛的寶可夢 GIF,我就想著要把它貼上來。

JS 的未來和 Web 多語言開發

為了跟貼圖保持一致我特意選用了“進化”這個詞,不知道你們注沒注意 GIF 周邊我還寫了字的哈。

這時候你可能想著說,行吧,可能這就是下一個 Ajax,但還是抱著幾分遲疑態度。

這幅畫是我早上在 OneNote 上畫的。

JS 的未來和 Web 多語言開發

我把它稱為 “ancient.png.”

讓我們回過來看這張圖,這上面有 HTML,CSS 和 JS。

比如當你打開社交網頁的時候js就會播放煩人的音樂,服務器會返回所有這些東西,所有的東西都在這裡。

請將你的視線隨著我手指移動,當你點擊一個鏈接的時候,它會返回一個頁面,你一直點擊它就一直會給我們返回一個頁面。

每當你想要從服務器獲取新信息的時候,你就需要手動對瀏覽器進行刷新操作。

JS 的未來和 Web 多語言開發

我將這張圖稱之為 then.png,Ajax 不是一個 button 但勝似 button。

Ajax 請求頁面,然後獲取頁面內容,我們通過發送 Ajax 請求,來避免刷新頁面的操作。

我們通過 Ajax 得到返回的結果,Ajax 結果可能會是另外一個頁面的請求。

基於這個,我們得到了一系列的單頁應用程序。

當我們的服務器提供了Restful 風格的 API 的時候,也提供臨時的 HTML CSS 和 JS 文件。

這才是我要說的,請看我用高亮顏色所標記出的 WebAssembly 的內容,這裡突出了它的工作原理。

JS 的未來和 Web 多語言開發

可以看到頁面請求、返回的頁面結果,在這個過程中 WebAssembly 只是做一些計算而已。

我們依然來看兩個圖中左側的 Browser,然後使用 service worker 作為你的第三方模塊。同樣是在這個Browser中,你可以使用一些 Ajax 請求,同時服務器就類似於圖上的 LOL OK。我可能甚至都不是一個真正的服務器,我只是 serverless 服務器上的一個函數而已。

然後返回你的結果。整個過程簡直不可思議!

OK,相信你現在應該有點感覺了。

四、對 JS 進行增強

能夠在瀏覽器中計算內容,不一定非要用 JS 來實現。

這就是一件大事!相當重要!

那為什麼這很重要?為什麼我們要這麼關注?

我們之所以這麼關心是因為我們對 JS 進行增強。

JS 的未來和 Web 多語言開發

我知道,這個話題你也許聽到過很多次,甚至都已經厭倦了。但是這也是事實,JS 在某些方面的確不擅長。

我們並不需要為了使用 WebAssembly 而重寫整個項目代碼,誰也不想重構整個代碼庫,就像五年前那些包含了單元測試的代碼,我想沒人願意來幹這個事情(想重構舉起你們的手,但是沒有)。

挺好

更少的請求調用意味著更少的延遲,也就意味著我們可以為用戶提供更快的 Web 應用。

高性能一直都是很重要的。這樣的話,我們就無需對服務器進行成千上百萬次的請求。

所以,我們來談談該如何對 JS 進行增強。

我相信在你的工作過程中已經看到過很多次這種表達式(0.1 + 0.2 === 0.3 // false)了吧,其實0.1 + 0.2 = 0.30000000000000004(精度運算),所以 0.1 + 0.2 === 0.3 是 false

JS 的未來和 Web 多語言開發

所以如果你正在做的事情對數字精讀有很高的要求,比如:金融應用、股票交易、貨幣兌換。那麼很顯然,這些並不是 JS 的強項。

你需要對那些運行著不同語言的服務器發送一個 Ajax 請求,服務器會返回給你精確的結果,然後你對返回的結果進行了錯誤的轉換(通過 JS 對返回的 JSON包含的數字類型的字符串進行轉換,出現精讀丟失)。

所以通過 WebAssembly,你就可以在瀏覽器中使用正確的工具來完成這項工作,比如:Rust,C,或者其他浮點數超過32位的語言。

JS 的未來和 Web 多語言開發

其它 JS 不太強的地方還有,JS 的類型強制轉換會有一些負面效應,比如:” “ == 0 為 true。我真的很難去理解它,我可以說他們輸入了一個非零的數字。

得到和預想中不一樣的結果,這個結果對我來講完全是出乎意料的,比如你用 1 和通過選擇器(document.getElementById)獲取的 input 的值相加,結果只是連接字符串。但是你使用 Number函數處理 input 元素的值,那就會進行兩個數字相加,即使後者不是一個真正的數字,可能只是一個 NaN,然後 1+ 9可能也是 NaN。

這下知道我的意思了吧,類型強制轉換在這裡會很棘手。

說到類型,typeof 關鍵字是一個迷。就像圖中最後一條一樣,讓人煩躁了很多年(typeof [] === ‘array’ // false)

如果你之前看過我的演講,你就會知道使用了 WebAssembly 也就意味著使用了正確的工具來完成對應的工作。工欲善其事必先利其器。

WebAssembly 使用正確的工具來完成 Web 上的工作。

我們不需要再通過 JS 來做它不擅長的事情。

這對 Web 和瀏覽器應用程序來說都是一件大事。

但是這將會幹掉 JS。

噢, 我們將會使用 WebAssembly 去寫所有的應用程序,WebAssembly 將會…,不,冷靜,冷靜。開個玩笑,它不會幹掉 JS。

它讓 JS 做它擅長的事情,從而使它變得更好。在 DOM 操作上,React 和其他框架會快得離譜,JS 引擎也使 DOM 操作速度更加快。

我不認為 WebAssembly 會很快打敗 JS 和 DOM 操作。也許在遙遠的將來,它可以做到,但是近期看來並不會實現。

並且 JS 也很擅長於操作 CSS 樣式,WebAssembly 也不會取代 JS 去操作 CSS。

所以,WebAssembly 用於增強 JS,同時你也可以在此基礎上使用 JS,這並不矛盾。

並且 WebAssembly 解決了 JS 所不擅長的,這也減輕了 JS 的負擔。

就好像我和我的對象一樣。他是很討厭洗衣服的,真的,特別討厭。而我又特別討厭做菜,所以他做菜我洗衣服,並且這樣搭配非常完美。

但是現在他還是必須洗自己的衣服,因為我要出差三週,而他只有兩週的衣服穿,所以不得不洗。

就像 Ajax 做的那樣,WebAssembly 通過營造更好的瀏覽器體驗來使互聯網變得更好。

當你想到這些影響時,這更好的瀏覽器體驗簡直令人激動。就像 Jeff Goldblum(美國演員)令人激動那樣。

"

特別說明

這是一個由 simviso 團隊對 JSConf.Asia 中關於 WebAssembly 相關話題進行翻譯的文檔,內容並非直譯,其中有一些是譯者自身的思考。分享者是 Kas Perch,Cloudflare 的一名開發人員。現在,讓我們一起來了解下什麼是 WebAssembly。

一、前言

JS 的未來和 Web 多語言開發

大家好,太棒了。就像他們所說,如果我們搞定了 WebAssembly 技術,那麼就搞定了 JS 的未來和 Web 多語言開發。

正如介紹所言,我叫 Kas Perch,現在是 Cloudflare 公司的一名 Avocado 開發人員。同時,我也很痴迷於機器人編程,並且寫過相關書籍。

我已經寫了兩本使用 JS 給機器人編程的書。我週末也會在 twitch 上直播一些硬件和軟件相關的東西。

我養了兩隻貓,它們是我的最愛。左邊的貓叫 Ace,右邊的叫 Aria。它們現在對我很生氣,因為我已經離開它們三個星期了。

JS 的未來和 Web 多語言開發

我可能再過一個星期才回去,它們是真的很生我的氣。

言歸正傳,你們來到這裡就是為了聽一些關於 WebAssembly 的一些東西

二、什麼是 WebAssembly

這項技術已經有五年了,我們還在維護中,我們冷靜下來思考一下,為什麼直到現在還沒有人指出該如何使用它。因為人們很難做到該如何更容易的去理解它(因為它很抽象),這也是為什麼我們要來談下它到底是什麼。

首先,我想說,它不是一個編程語言(注:WebAssembly 是驅動編程語言的存在,此處就相當於一個獵頭,針對後面這句話),就像你曾經去領英上面招聘員工一樣,你說你需要一個有十年開發經驗的 Node.js 程序員。

這個就像是在說,我是一個 WebAssembly 程序員,就好像如果你不會 WebAssembly 編程,你就不會寫 WebAssembly 程序(就好比如果你不會 Nodejs,你就不會使用 Nodejs 編程)。

其次,WebAssembly 不會取代 JS ,同時它可以讓 JS 駕馭任何事。

JS 並不會沒落,更不會被 WebAssembly 打敗,因為它並不是為了打敗 JS 而設計的。

WebAssembly 恰恰是我們無法去忽視的東西,因為它可以讓我們走得更遠

我希望在接下來二十幾分鍾你們能被我征服,因為 WebAssembly 是未來的發展趨勢。

不好意思,按錯了。

那麼 WebAssembly 到底是什麼呢?

JS 的未來和 Web 多語言開發

它為其他語言提供編譯服務,你可以將其他語言編譯成 WebAssembly,它是一種規範(類似於 jvm 支持的 class 字節碼)和要編譯成的目標文件類型。

這對於 JS 來說是一種能力的增強。WebAssembly 根本就不是想要取代 JS ,而是仍然讓 JS 做它所擅長的領域,同時也能讓 JS 也能做它所不擅長的領域,這就是它要做的事情。

但更重要的是,WebAssembly 表面上很神奇,但卻不僅僅只是表面上神奇,我會在後面解釋這點。

WebAssembly 的目標就是將你用其他語言寫的代碼編譯成 wasm 類型文件。

WebAssembly 已經很好的支持了 Rust 語言,C/C++,GO 和 C# 已經可以用 WebAssembly 編譯。

還有很多語言沒有提到,當然我能想到的主要就這四個,尤其是 Rust, WebAssembly 對它進行了相當多的優化,你有機會可以嘗試一下,這絕對是一個非常酷的編程體驗。

JS 的未來和 Web 多語言開發

那麼這裡,你可能會問:為什麼要用其他語言來寫 Web 程序?你為什麼要這麼做?為什麼你會在這裡放上 Laurie Voss(npm 的作者) 的演講照片,然後你使用其他語言來講這些東西?

主要有兩個理由:A,我想要和 Laurie Voss 進行合照。B,讓大家一起擁抱 WebAssembly。

三、下一個 Ajax

對於瀏覽器來說它就像是下一個 Ajax(就好比是下一個喬布斯)。

在這週末,我已經看到了很多有這樣(驚訝)表情了。

OK,就像下一個喬布斯(這裡是 Ajax),聽起來很酷。

但是我的意思是說 Ajax 真的高度可信並且使客戶端層面應用成為可能,所以說,Ajax 是一個變革,而 WebAssembly 將是下一步的一個變革。

這是我今天早上找到的一張超可愛的寶可夢 GIF,我就想著要把它貼上來。

JS 的未來和 Web 多語言開發

為了跟貼圖保持一致我特意選用了“進化”這個詞,不知道你們注沒注意 GIF 周邊我還寫了字的哈。

這時候你可能想著說,行吧,可能這就是下一個 Ajax,但還是抱著幾分遲疑態度。

這幅畫是我早上在 OneNote 上畫的。

JS 的未來和 Web 多語言開發

我把它稱為 “ancient.png.”

讓我們回過來看這張圖,這上面有 HTML,CSS 和 JS。

比如當你打開社交網頁的時候js就會播放煩人的音樂,服務器會返回所有這些東西,所有的東西都在這裡。

請將你的視線隨著我手指移動,當你點擊一個鏈接的時候,它會返回一個頁面,你一直點擊它就一直會給我們返回一個頁面。

每當你想要從服務器獲取新信息的時候,你就需要手動對瀏覽器進行刷新操作。

JS 的未來和 Web 多語言開發

我將這張圖稱之為 then.png,Ajax 不是一個 button 但勝似 button。

Ajax 請求頁面,然後獲取頁面內容,我們通過發送 Ajax 請求,來避免刷新頁面的操作。

我們通過 Ajax 得到返回的結果,Ajax 結果可能會是另外一個頁面的請求。

基於這個,我們得到了一系列的單頁應用程序。

當我們的服務器提供了Restful 風格的 API 的時候,也提供臨時的 HTML CSS 和 JS 文件。

這才是我要說的,請看我用高亮顏色所標記出的 WebAssembly 的內容,這裡突出了它的工作原理。

JS 的未來和 Web 多語言開發

可以看到頁面請求、返回的頁面結果,在這個過程中 WebAssembly 只是做一些計算而已。

我們依然來看兩個圖中左側的 Browser,然後使用 service worker 作為你的第三方模塊。同樣是在這個Browser中,你可以使用一些 Ajax 請求,同時服務器就類似於圖上的 LOL OK。我可能甚至都不是一個真正的服務器,我只是 serverless 服務器上的一個函數而已。

然後返回你的結果。整個過程簡直不可思議!

OK,相信你現在應該有點感覺了。

四、對 JS 進行增強

能夠在瀏覽器中計算內容,不一定非要用 JS 來實現。

這就是一件大事!相當重要!

那為什麼這很重要?為什麼我們要這麼關注?

我們之所以這麼關心是因為我們對 JS 進行增強。

JS 的未來和 Web 多語言開發

我知道,這個話題你也許聽到過很多次,甚至都已經厭倦了。但是這也是事實,JS 在某些方面的確不擅長。

我們並不需要為了使用 WebAssembly 而重寫整個項目代碼,誰也不想重構整個代碼庫,就像五年前那些包含了單元測試的代碼,我想沒人願意來幹這個事情(想重構舉起你們的手,但是沒有)。

挺好

更少的請求調用意味著更少的延遲,也就意味著我們可以為用戶提供更快的 Web 應用。

高性能一直都是很重要的。這樣的話,我們就無需對服務器進行成千上百萬次的請求。

所以,我們來談談該如何對 JS 進行增強。

我相信在你的工作過程中已經看到過很多次這種表達式(0.1 + 0.2 === 0.3 // false)了吧,其實0.1 + 0.2 = 0.30000000000000004(精度運算),所以 0.1 + 0.2 === 0.3 是 false

JS 的未來和 Web 多語言開發

所以如果你正在做的事情對數字精讀有很高的要求,比如:金融應用、股票交易、貨幣兌換。那麼很顯然,這些並不是 JS 的強項。

你需要對那些運行著不同語言的服務器發送一個 Ajax 請求,服務器會返回給你精確的結果,然後你對返回的結果進行了錯誤的轉換(通過 JS 對返回的 JSON包含的數字類型的字符串進行轉換,出現精讀丟失)。

所以通過 WebAssembly,你就可以在瀏覽器中使用正確的工具來完成這項工作,比如:Rust,C,或者其他浮點數超過32位的語言。

JS 的未來和 Web 多語言開發

其它 JS 不太強的地方還有,JS 的類型強制轉換會有一些負面效應,比如:” “ == 0 為 true。我真的很難去理解它,我可以說他們輸入了一個非零的數字。

得到和預想中不一樣的結果,這個結果對我來講完全是出乎意料的,比如你用 1 和通過選擇器(document.getElementById)獲取的 input 的值相加,結果只是連接字符串。但是你使用 Number函數處理 input 元素的值,那就會進行兩個數字相加,即使後者不是一個真正的數字,可能只是一個 NaN,然後 1+ 9可能也是 NaN。

這下知道我的意思了吧,類型強制轉換在這裡會很棘手。

說到類型,typeof 關鍵字是一個迷。就像圖中最後一條一樣,讓人煩躁了很多年(typeof [] === ‘array’ // false)

如果你之前看過我的演講,你就會知道使用了 WebAssembly 也就意味著使用了正確的工具來完成對應的工作。工欲善其事必先利其器。

WebAssembly 使用正確的工具來完成 Web 上的工作。

我們不需要再通過 JS 來做它不擅長的事情。

這對 Web 和瀏覽器應用程序來說都是一件大事。

但是這將會幹掉 JS。

噢, 我們將會使用 WebAssembly 去寫所有的應用程序,WebAssembly 將會…,不,冷靜,冷靜。開個玩笑,它不會幹掉 JS。

它讓 JS 做它擅長的事情,從而使它變得更好。在 DOM 操作上,React 和其他框架會快得離譜,JS 引擎也使 DOM 操作速度更加快。

我不認為 WebAssembly 會很快打敗 JS 和 DOM 操作。也許在遙遠的將來,它可以做到,但是近期看來並不會實現。

並且 JS 也很擅長於操作 CSS 樣式,WebAssembly 也不會取代 JS 去操作 CSS。

所以,WebAssembly 用於增強 JS,同時你也可以在此基礎上使用 JS,這並不矛盾。

並且 WebAssembly 解決了 JS 所不擅長的,這也減輕了 JS 的負擔。

就好像我和我的對象一樣。他是很討厭洗衣服的,真的,特別討厭。而我又特別討厭做菜,所以他做菜我洗衣服,並且這樣搭配非常完美。

但是現在他還是必須洗自己的衣服,因為我要出差三週,而他只有兩週的衣服穿,所以不得不洗。

就像 Ajax 做的那樣,WebAssembly 通過營造更好的瀏覽器體驗來使互聯網變得更好。

當你想到這些影響時,這更好的瀏覽器體驗簡直令人激動。就像 Jeff Goldblum(美國演員)令人激動那樣。

JS 的未來和 Web 多語言開發

五、舉個例子

讓我們通過這個 Demo 來進一步表達我的意思。

"

特別說明

這是一個由 simviso 團隊對 JSConf.Asia 中關於 WebAssembly 相關話題進行翻譯的文檔,內容並非直譯,其中有一些是譯者自身的思考。分享者是 Kas Perch,Cloudflare 的一名開發人員。現在,讓我們一起來了解下什麼是 WebAssembly。

一、前言

JS 的未來和 Web 多語言開發

大家好,太棒了。就像他們所說,如果我們搞定了 WebAssembly 技術,那麼就搞定了 JS 的未來和 Web 多語言開發。

正如介紹所言,我叫 Kas Perch,現在是 Cloudflare 公司的一名 Avocado 開發人員。同時,我也很痴迷於機器人編程,並且寫過相關書籍。

我已經寫了兩本使用 JS 給機器人編程的書。我週末也會在 twitch 上直播一些硬件和軟件相關的東西。

我養了兩隻貓,它們是我的最愛。左邊的貓叫 Ace,右邊的叫 Aria。它們現在對我很生氣,因為我已經離開它們三個星期了。

JS 的未來和 Web 多語言開發

我可能再過一個星期才回去,它們是真的很生我的氣。

言歸正傳,你們來到這裡就是為了聽一些關於 WebAssembly 的一些東西

二、什麼是 WebAssembly

這項技術已經有五年了,我們還在維護中,我們冷靜下來思考一下,為什麼直到現在還沒有人指出該如何使用它。因為人們很難做到該如何更容易的去理解它(因為它很抽象),這也是為什麼我們要來談下它到底是什麼。

首先,我想說,它不是一個編程語言(注:WebAssembly 是驅動編程語言的存在,此處就相當於一個獵頭,針對後面這句話),就像你曾經去領英上面招聘員工一樣,你說你需要一個有十年開發經驗的 Node.js 程序員。

這個就像是在說,我是一個 WebAssembly 程序員,就好像如果你不會 WebAssembly 編程,你就不會寫 WebAssembly 程序(就好比如果你不會 Nodejs,你就不會使用 Nodejs 編程)。

其次,WebAssembly 不會取代 JS ,同時它可以讓 JS 駕馭任何事。

JS 並不會沒落,更不會被 WebAssembly 打敗,因為它並不是為了打敗 JS 而設計的。

WebAssembly 恰恰是我們無法去忽視的東西,因為它可以讓我們走得更遠

我希望在接下來二十幾分鍾你們能被我征服,因為 WebAssembly 是未來的發展趨勢。

不好意思,按錯了。

那麼 WebAssembly 到底是什麼呢?

JS 的未來和 Web 多語言開發

它為其他語言提供編譯服務,你可以將其他語言編譯成 WebAssembly,它是一種規範(類似於 jvm 支持的 class 字節碼)和要編譯成的目標文件類型。

這對於 JS 來說是一種能力的增強。WebAssembly 根本就不是想要取代 JS ,而是仍然讓 JS 做它所擅長的領域,同時也能讓 JS 也能做它所不擅長的領域,這就是它要做的事情。

但更重要的是,WebAssembly 表面上很神奇,但卻不僅僅只是表面上神奇,我會在後面解釋這點。

WebAssembly 的目標就是將你用其他語言寫的代碼編譯成 wasm 類型文件。

WebAssembly 已經很好的支持了 Rust 語言,C/C++,GO 和 C# 已經可以用 WebAssembly 編譯。

還有很多語言沒有提到,當然我能想到的主要就這四個,尤其是 Rust, WebAssembly 對它進行了相當多的優化,你有機會可以嘗試一下,這絕對是一個非常酷的編程體驗。

JS 的未來和 Web 多語言開發

那麼這裡,你可能會問:為什麼要用其他語言來寫 Web 程序?你為什麼要這麼做?為什麼你會在這裡放上 Laurie Voss(npm 的作者) 的演講照片,然後你使用其他語言來講這些東西?

主要有兩個理由:A,我想要和 Laurie Voss 進行合照。B,讓大家一起擁抱 WebAssembly。

三、下一個 Ajax

對於瀏覽器來說它就像是下一個 Ajax(就好比是下一個喬布斯)。

在這週末,我已經看到了很多有這樣(驚訝)表情了。

OK,就像下一個喬布斯(這裡是 Ajax),聽起來很酷。

但是我的意思是說 Ajax 真的高度可信並且使客戶端層面應用成為可能,所以說,Ajax 是一個變革,而 WebAssembly 將是下一步的一個變革。

這是我今天早上找到的一張超可愛的寶可夢 GIF,我就想著要把它貼上來。

JS 的未來和 Web 多語言開發

為了跟貼圖保持一致我特意選用了“進化”這個詞,不知道你們注沒注意 GIF 周邊我還寫了字的哈。

這時候你可能想著說,行吧,可能這就是下一個 Ajax,但還是抱著幾分遲疑態度。

這幅畫是我早上在 OneNote 上畫的。

JS 的未來和 Web 多語言開發

我把它稱為 “ancient.png.”

讓我們回過來看這張圖,這上面有 HTML,CSS 和 JS。

比如當你打開社交網頁的時候js就會播放煩人的音樂,服務器會返回所有這些東西,所有的東西都在這裡。

請將你的視線隨著我手指移動,當你點擊一個鏈接的時候,它會返回一個頁面,你一直點擊它就一直會給我們返回一個頁面。

每當你想要從服務器獲取新信息的時候,你就需要手動對瀏覽器進行刷新操作。

JS 的未來和 Web 多語言開發

我將這張圖稱之為 then.png,Ajax 不是一個 button 但勝似 button。

Ajax 請求頁面,然後獲取頁面內容,我們通過發送 Ajax 請求,來避免刷新頁面的操作。

我們通過 Ajax 得到返回的結果,Ajax 結果可能會是另外一個頁面的請求。

基於這個,我們得到了一系列的單頁應用程序。

當我們的服務器提供了Restful 風格的 API 的時候,也提供臨時的 HTML CSS 和 JS 文件。

這才是我要說的,請看我用高亮顏色所標記出的 WebAssembly 的內容,這裡突出了它的工作原理。

JS 的未來和 Web 多語言開發

可以看到頁面請求、返回的頁面結果,在這個過程中 WebAssembly 只是做一些計算而已。

我們依然來看兩個圖中左側的 Browser,然後使用 service worker 作為你的第三方模塊。同樣是在這個Browser中,你可以使用一些 Ajax 請求,同時服務器就類似於圖上的 LOL OK。我可能甚至都不是一個真正的服務器,我只是 serverless 服務器上的一個函數而已。

然後返回你的結果。整個過程簡直不可思議!

OK,相信你現在應該有點感覺了。

四、對 JS 進行增強

能夠在瀏覽器中計算內容,不一定非要用 JS 來實現。

這就是一件大事!相當重要!

那為什麼這很重要?為什麼我們要這麼關注?

我們之所以這麼關心是因為我們對 JS 進行增強。

JS 的未來和 Web 多語言開發

我知道,這個話題你也許聽到過很多次,甚至都已經厭倦了。但是這也是事實,JS 在某些方面的確不擅長。

我們並不需要為了使用 WebAssembly 而重寫整個項目代碼,誰也不想重構整個代碼庫,就像五年前那些包含了單元測試的代碼,我想沒人願意來幹這個事情(想重構舉起你們的手,但是沒有)。

挺好

更少的請求調用意味著更少的延遲,也就意味著我們可以為用戶提供更快的 Web 應用。

高性能一直都是很重要的。這樣的話,我們就無需對服務器進行成千上百萬次的請求。

所以,我們來談談該如何對 JS 進行增強。

我相信在你的工作過程中已經看到過很多次這種表達式(0.1 + 0.2 === 0.3 // false)了吧,其實0.1 + 0.2 = 0.30000000000000004(精度運算),所以 0.1 + 0.2 === 0.3 是 false

JS 的未來和 Web 多語言開發

所以如果你正在做的事情對數字精讀有很高的要求,比如:金融應用、股票交易、貨幣兌換。那麼很顯然,這些並不是 JS 的強項。

你需要對那些運行著不同語言的服務器發送一個 Ajax 請求,服務器會返回給你精確的結果,然後你對返回的結果進行了錯誤的轉換(通過 JS 對返回的 JSON包含的數字類型的字符串進行轉換,出現精讀丟失)。

所以通過 WebAssembly,你就可以在瀏覽器中使用正確的工具來完成這項工作,比如:Rust,C,或者其他浮點數超過32位的語言。

JS 的未來和 Web 多語言開發

其它 JS 不太強的地方還有,JS 的類型強制轉換會有一些負面效應,比如:” “ == 0 為 true。我真的很難去理解它,我可以說他們輸入了一個非零的數字。

得到和預想中不一樣的結果,這個結果對我來講完全是出乎意料的,比如你用 1 和通過選擇器(document.getElementById)獲取的 input 的值相加,結果只是連接字符串。但是你使用 Number函數處理 input 元素的值,那就會進行兩個數字相加,即使後者不是一個真正的數字,可能只是一個 NaN,然後 1+ 9可能也是 NaN。

這下知道我的意思了吧,類型強制轉換在這裡會很棘手。

說到類型,typeof 關鍵字是一個迷。就像圖中最後一條一樣,讓人煩躁了很多年(typeof [] === ‘array’ // false)

如果你之前看過我的演講,你就會知道使用了 WebAssembly 也就意味著使用了正確的工具來完成對應的工作。工欲善其事必先利其器。

WebAssembly 使用正確的工具來完成 Web 上的工作。

我們不需要再通過 JS 來做它不擅長的事情。

這對 Web 和瀏覽器應用程序來說都是一件大事。

但是這將會幹掉 JS。

噢, 我們將會使用 WebAssembly 去寫所有的應用程序,WebAssembly 將會…,不,冷靜,冷靜。開個玩笑,它不會幹掉 JS。

它讓 JS 做它擅長的事情,從而使它變得更好。在 DOM 操作上,React 和其他框架會快得離譜,JS 引擎也使 DOM 操作速度更加快。

我不認為 WebAssembly 會很快打敗 JS 和 DOM 操作。也許在遙遠的將來,它可以做到,但是近期看來並不會實現。

並且 JS 也很擅長於操作 CSS 樣式,WebAssembly 也不會取代 JS 去操作 CSS。

所以,WebAssembly 用於增強 JS,同時你也可以在此基礎上使用 JS,這並不矛盾。

並且 WebAssembly 解決了 JS 所不擅長的,這也減輕了 JS 的負擔。

就好像我和我的對象一樣。他是很討厭洗衣服的,真的,特別討厭。而我又特別討厭做菜,所以他做菜我洗衣服,並且這樣搭配非常完美。

但是現在他還是必須洗自己的衣服,因為我要出差三週,而他只有兩週的衣服穿,所以不得不洗。

就像 Ajax 做的那樣,WebAssembly 通過營造更好的瀏覽器體驗來使互聯網變得更好。

當你想到這些影響時,這更好的瀏覽器體驗簡直令人激動。就像 Jeff Goldblum(美國演員)令人激動那樣。

JS 的未來和 Web 多語言開發

五、舉個例子

讓我們通過這個 Demo 來進一步表達我的意思。

JS 的未來和 Web 多語言開發

這個 Demo 使用了 wasm-imagemagick 技術,如果你之前沒有用過 imagemagick 的話我可以解釋一下:imagemagick 是一個命令行工具,專用於創建和操縱圖片。

它能夠創建GIF動畫,它能夠創建圖片的單元格,它能夠創建分形圖。它是一個非常強大的庫以至於我不想用任何其他語言去重寫它,更不用說 JS。

我們將要以十倍快於 JS 的速度來操縱這些圖片,所以從某種意義上說 JS 本身並不能做到。

它真正強大的地方在於你不用重寫任何代碼就可以通過該工具來完成我們的工作。

讓我們來看看。希望這行得通。

它之前都是好好的所以這次可能就不行了,你知道我意思吧。

好了我攝像頭打開了。我們來選擇一張照片,我要點下面(做鬼臉),照片照出來總是顯得我很蠢,所以我放棄掙扎了。

OK,這些按鈕的意思是……我把它調大一點你們就看得清了我的舌頭和這些按鈕了。

"

特別說明

這是一個由 simviso 團隊對 JSConf.Asia 中關於 WebAssembly 相關話題進行翻譯的文檔,內容並非直譯,其中有一些是譯者自身的思考。分享者是 Kas Perch,Cloudflare 的一名開發人員。現在,讓我們一起來了解下什麼是 WebAssembly。

一、前言

JS 的未來和 Web 多語言開發

大家好,太棒了。就像他們所說,如果我們搞定了 WebAssembly 技術,那麼就搞定了 JS 的未來和 Web 多語言開發。

正如介紹所言,我叫 Kas Perch,現在是 Cloudflare 公司的一名 Avocado 開發人員。同時,我也很痴迷於機器人編程,並且寫過相關書籍。

我已經寫了兩本使用 JS 給機器人編程的書。我週末也會在 twitch 上直播一些硬件和軟件相關的東西。

我養了兩隻貓,它們是我的最愛。左邊的貓叫 Ace,右邊的叫 Aria。它們現在對我很生氣,因為我已經離開它們三個星期了。

JS 的未來和 Web 多語言開發

我可能再過一個星期才回去,它們是真的很生我的氣。

言歸正傳,你們來到這裡就是為了聽一些關於 WebAssembly 的一些東西

二、什麼是 WebAssembly

這項技術已經有五年了,我們還在維護中,我們冷靜下來思考一下,為什麼直到現在還沒有人指出該如何使用它。因為人們很難做到該如何更容易的去理解它(因為它很抽象),這也是為什麼我們要來談下它到底是什麼。

首先,我想說,它不是一個編程語言(注:WebAssembly 是驅動編程語言的存在,此處就相當於一個獵頭,針對後面這句話),就像你曾經去領英上面招聘員工一樣,你說你需要一個有十年開發經驗的 Node.js 程序員。

這個就像是在說,我是一個 WebAssembly 程序員,就好像如果你不會 WebAssembly 編程,你就不會寫 WebAssembly 程序(就好比如果你不會 Nodejs,你就不會使用 Nodejs 編程)。

其次,WebAssembly 不會取代 JS ,同時它可以讓 JS 駕馭任何事。

JS 並不會沒落,更不會被 WebAssembly 打敗,因為它並不是為了打敗 JS 而設計的。

WebAssembly 恰恰是我們無法去忽視的東西,因為它可以讓我們走得更遠

我希望在接下來二十幾分鍾你們能被我征服,因為 WebAssembly 是未來的發展趨勢。

不好意思,按錯了。

那麼 WebAssembly 到底是什麼呢?

JS 的未來和 Web 多語言開發

它為其他語言提供編譯服務,你可以將其他語言編譯成 WebAssembly,它是一種規範(類似於 jvm 支持的 class 字節碼)和要編譯成的目標文件類型。

這對於 JS 來說是一種能力的增強。WebAssembly 根本就不是想要取代 JS ,而是仍然讓 JS 做它所擅長的領域,同時也能讓 JS 也能做它所不擅長的領域,這就是它要做的事情。

但更重要的是,WebAssembly 表面上很神奇,但卻不僅僅只是表面上神奇,我會在後面解釋這點。

WebAssembly 的目標就是將你用其他語言寫的代碼編譯成 wasm 類型文件。

WebAssembly 已經很好的支持了 Rust 語言,C/C++,GO 和 C# 已經可以用 WebAssembly 編譯。

還有很多語言沒有提到,當然我能想到的主要就這四個,尤其是 Rust, WebAssembly 對它進行了相當多的優化,你有機會可以嘗試一下,這絕對是一個非常酷的編程體驗。

JS 的未來和 Web 多語言開發

那麼這裡,你可能會問:為什麼要用其他語言來寫 Web 程序?你為什麼要這麼做?為什麼你會在這裡放上 Laurie Voss(npm 的作者) 的演講照片,然後你使用其他語言來講這些東西?

主要有兩個理由:A,我想要和 Laurie Voss 進行合照。B,讓大家一起擁抱 WebAssembly。

三、下一個 Ajax

對於瀏覽器來說它就像是下一個 Ajax(就好比是下一個喬布斯)。

在這週末,我已經看到了很多有這樣(驚訝)表情了。

OK,就像下一個喬布斯(這裡是 Ajax),聽起來很酷。

但是我的意思是說 Ajax 真的高度可信並且使客戶端層面應用成為可能,所以說,Ajax 是一個變革,而 WebAssembly 將是下一步的一個變革。

這是我今天早上找到的一張超可愛的寶可夢 GIF,我就想著要把它貼上來。

JS 的未來和 Web 多語言開發

為了跟貼圖保持一致我特意選用了“進化”這個詞,不知道你們注沒注意 GIF 周邊我還寫了字的哈。

這時候你可能想著說,行吧,可能這就是下一個 Ajax,但還是抱著幾分遲疑態度。

這幅畫是我早上在 OneNote 上畫的。

JS 的未來和 Web 多語言開發

我把它稱為 “ancient.png.”

讓我們回過來看這張圖,這上面有 HTML,CSS 和 JS。

比如當你打開社交網頁的時候js就會播放煩人的音樂,服務器會返回所有這些東西,所有的東西都在這裡。

請將你的視線隨著我手指移動,當你點擊一個鏈接的時候,它會返回一個頁面,你一直點擊它就一直會給我們返回一個頁面。

每當你想要從服務器獲取新信息的時候,你就需要手動對瀏覽器進行刷新操作。

JS 的未來和 Web 多語言開發

我將這張圖稱之為 then.png,Ajax 不是一個 button 但勝似 button。

Ajax 請求頁面,然後獲取頁面內容,我們通過發送 Ajax 請求,來避免刷新頁面的操作。

我們通過 Ajax 得到返回的結果,Ajax 結果可能會是另外一個頁面的請求。

基於這個,我們得到了一系列的單頁應用程序。

當我們的服務器提供了Restful 風格的 API 的時候,也提供臨時的 HTML CSS 和 JS 文件。

這才是我要說的,請看我用高亮顏色所標記出的 WebAssembly 的內容,這裡突出了它的工作原理。

JS 的未來和 Web 多語言開發

可以看到頁面請求、返回的頁面結果,在這個過程中 WebAssembly 只是做一些計算而已。

我們依然來看兩個圖中左側的 Browser,然後使用 service worker 作為你的第三方模塊。同樣是在這個Browser中,你可以使用一些 Ajax 請求,同時服務器就類似於圖上的 LOL OK。我可能甚至都不是一個真正的服務器,我只是 serverless 服務器上的一個函數而已。

然後返回你的結果。整個過程簡直不可思議!

OK,相信你現在應該有點感覺了。

四、對 JS 進行增強

能夠在瀏覽器中計算內容,不一定非要用 JS 來實現。

這就是一件大事!相當重要!

那為什麼這很重要?為什麼我們要這麼關注?

我們之所以這麼關心是因為我們對 JS 進行增強。

JS 的未來和 Web 多語言開發

我知道,這個話題你也許聽到過很多次,甚至都已經厭倦了。但是這也是事實,JS 在某些方面的確不擅長。

我們並不需要為了使用 WebAssembly 而重寫整個項目代碼,誰也不想重構整個代碼庫,就像五年前那些包含了單元測試的代碼,我想沒人願意來幹這個事情(想重構舉起你們的手,但是沒有)。

挺好

更少的請求調用意味著更少的延遲,也就意味著我們可以為用戶提供更快的 Web 應用。

高性能一直都是很重要的。這樣的話,我們就無需對服務器進行成千上百萬次的請求。

所以,我們來談談該如何對 JS 進行增強。

我相信在你的工作過程中已經看到過很多次這種表達式(0.1 + 0.2 === 0.3 // false)了吧,其實0.1 + 0.2 = 0.30000000000000004(精度運算),所以 0.1 + 0.2 === 0.3 是 false

JS 的未來和 Web 多語言開發

所以如果你正在做的事情對數字精讀有很高的要求,比如:金融應用、股票交易、貨幣兌換。那麼很顯然,這些並不是 JS 的強項。

你需要對那些運行著不同語言的服務器發送一個 Ajax 請求,服務器會返回給你精確的結果,然後你對返回的結果進行了錯誤的轉換(通過 JS 對返回的 JSON包含的數字類型的字符串進行轉換,出現精讀丟失)。

所以通過 WebAssembly,你就可以在瀏覽器中使用正確的工具來完成這項工作,比如:Rust,C,或者其他浮點數超過32位的語言。

JS 的未來和 Web 多語言開發

其它 JS 不太強的地方還有,JS 的類型強制轉換會有一些負面效應,比如:” “ == 0 為 true。我真的很難去理解它,我可以說他們輸入了一個非零的數字。

得到和預想中不一樣的結果,這個結果對我來講完全是出乎意料的,比如你用 1 和通過選擇器(document.getElementById)獲取的 input 的值相加,結果只是連接字符串。但是你使用 Number函數處理 input 元素的值,那就會進行兩個數字相加,即使後者不是一個真正的數字,可能只是一個 NaN,然後 1+ 9可能也是 NaN。

這下知道我的意思了吧,類型強制轉換在這裡會很棘手。

說到類型,typeof 關鍵字是一個迷。就像圖中最後一條一樣,讓人煩躁了很多年(typeof [] === ‘array’ // false)

如果你之前看過我的演講,你就會知道使用了 WebAssembly 也就意味著使用了正確的工具來完成對應的工作。工欲善其事必先利其器。

WebAssembly 使用正確的工具來完成 Web 上的工作。

我們不需要再通過 JS 來做它不擅長的事情。

這對 Web 和瀏覽器應用程序來說都是一件大事。

但是這將會幹掉 JS。

噢, 我們將會使用 WebAssembly 去寫所有的應用程序,WebAssembly 將會…,不,冷靜,冷靜。開個玩笑,它不會幹掉 JS。

它讓 JS 做它擅長的事情,從而使它變得更好。在 DOM 操作上,React 和其他框架會快得離譜,JS 引擎也使 DOM 操作速度更加快。

我不認為 WebAssembly 會很快打敗 JS 和 DOM 操作。也許在遙遠的將來,它可以做到,但是近期看來並不會實現。

並且 JS 也很擅長於操作 CSS 樣式,WebAssembly 也不會取代 JS 去操作 CSS。

所以,WebAssembly 用於增強 JS,同時你也可以在此基礎上使用 JS,這並不矛盾。

並且 WebAssembly 解決了 JS 所不擅長的,這也減輕了 JS 的負擔。

就好像我和我的對象一樣。他是很討厭洗衣服的,真的,特別討厭。而我又特別討厭做菜,所以他做菜我洗衣服,並且這樣搭配非常完美。

但是現在他還是必須洗自己的衣服,因為我要出差三週,而他只有兩週的衣服穿,所以不得不洗。

就像 Ajax 做的那樣,WebAssembly 通過營造更好的瀏覽器體驗來使互聯網變得更好。

當你想到這些影響時,這更好的瀏覽器體驗簡直令人激動。就像 Jeff Goldblum(美國演員)令人激動那樣。

JS 的未來和 Web 多語言開發

五、舉個例子

讓我們通過這個 Demo 來進一步表達我的意思。

JS 的未來和 Web 多語言開發

這個 Demo 使用了 wasm-imagemagick 技術,如果你之前沒有用過 imagemagick 的話我可以解釋一下:imagemagick 是一個命令行工具,專用於創建和操縱圖片。

它能夠創建GIF動畫,它能夠創建圖片的單元格,它能夠創建分形圖。它是一個非常強大的庫以至於我不想用任何其他語言去重寫它,更不用說 JS。

我們將要以十倍快於 JS 的速度來操縱這些圖片,所以從某種意義上說 JS 本身並不能做到。

它真正強大的地方在於你不用重寫任何代碼就可以通過該工具來完成我們的工作。

讓我們來看看。希望這行得通。

它之前都是好好的所以這次可能就不行了,你知道我意思吧。

好了我攝像頭打開了。我們來選擇一張照片,我要點下面(做鬼臉),照片照出來總是顯得我很蠢,所以我放棄掙扎了。

OK,這些按鈕的意思是……我把它調大一點你們就看得清了我的舌頭和這些按鈕了。

JS 的未來和 Web 多語言開發

我們點右旋,然後在下面你就可以看到右旋的圖片了。這真的真的是很快的了,再左旋一下,你用 CSS 也能快速做到,這好像沒什麼了不起。我們來調個灰度,boom, 灰度,沒有閃屏。我們來加點對比度。去掉對比度呢?去掉對比度了。JS 能這麼快嗎?不可能!

對,這就是我的 Demo,我會在推特上發一下這個 Github 倉庫,這是完全開源的,你想的話可以嘗試一下。

對,這是我的 Demo。

哈謝謝你們

六、關於 Nodejs

但是 Nodejs 呢?等等……關於 Nodejs?

這是瀏覽器的工作,對,這完全是瀏覽器中的技術,我剛剛說的也完全是跟瀏覽器相關的。

但是,為什麼我會提到 Nodejs 呢?

我提及它(Nodejs)的原因是它是模塊本地化的,有誰在跑 npm install 的時候看到過 C 編譯出錯?

大部分人的手都應該舉起來了,因為這實在是太常見了,模塊本地化實在是 Node 中的一個大坑。

這東西真的非常愚蠢,甚至讓你想喊出 Bryan Cranston(絕命毒師男主)嘴裡喊的。你可能能從他的脣語裡讀出來,他喊的是 BLAH,他喊得並不是…額你知道的

為什麼這些模塊如此之坑?原因是它們必須在下載時重新編譯,而且必須為每一個體繫結構重新編譯它們。

就拿樹莓派平臺來說,因為在這個平臺上根本不能正常的工作,就會有人在 Github 上面去提issue ,同時也就意味著你會花很長時間在 Github 上去討論這個問題。

他們要麼會為你的平臺編譯一個版本,要不就直接不支持這個平臺。

的確這也是很棘手的,Github 上面的討論的確讓人感到糟糕。但是我很遺憾的告訴你,這個並不支持 Windows 系統。

首先聲明,我很感激hecc(高等教育協調理事會)在 node-gyp 方面所做的研究,他們完成了這是個似乎不可能完成的任務。因此我很尊重他們。

"

特別說明

這是一個由 simviso 團隊對 JSConf.Asia 中關於 WebAssembly 相關話題進行翻譯的文檔,內容並非直譯,其中有一些是譯者自身的思考。分享者是 Kas Perch,Cloudflare 的一名開發人員。現在,讓我們一起來了解下什麼是 WebAssembly。

一、前言

JS 的未來和 Web 多語言開發

大家好,太棒了。就像他們所說,如果我們搞定了 WebAssembly 技術,那麼就搞定了 JS 的未來和 Web 多語言開發。

正如介紹所言,我叫 Kas Perch,現在是 Cloudflare 公司的一名 Avocado 開發人員。同時,我也很痴迷於機器人編程,並且寫過相關書籍。

我已經寫了兩本使用 JS 給機器人編程的書。我週末也會在 twitch 上直播一些硬件和軟件相關的東西。

我養了兩隻貓,它們是我的最愛。左邊的貓叫 Ace,右邊的叫 Aria。它們現在對我很生氣,因為我已經離開它們三個星期了。

JS 的未來和 Web 多語言開發

我可能再過一個星期才回去,它們是真的很生我的氣。

言歸正傳,你們來到這裡就是為了聽一些關於 WebAssembly 的一些東西

二、什麼是 WebAssembly

這項技術已經有五年了,我們還在維護中,我們冷靜下來思考一下,為什麼直到現在還沒有人指出該如何使用它。因為人們很難做到該如何更容易的去理解它(因為它很抽象),這也是為什麼我們要來談下它到底是什麼。

首先,我想說,它不是一個編程語言(注:WebAssembly 是驅動編程語言的存在,此處就相當於一個獵頭,針對後面這句話),就像你曾經去領英上面招聘員工一樣,你說你需要一個有十年開發經驗的 Node.js 程序員。

這個就像是在說,我是一個 WebAssembly 程序員,就好像如果你不會 WebAssembly 編程,你就不會寫 WebAssembly 程序(就好比如果你不會 Nodejs,你就不會使用 Nodejs 編程)。

其次,WebAssembly 不會取代 JS ,同時它可以讓 JS 駕馭任何事。

JS 並不會沒落,更不會被 WebAssembly 打敗,因為它並不是為了打敗 JS 而設計的。

WebAssembly 恰恰是我們無法去忽視的東西,因為它可以讓我們走得更遠

我希望在接下來二十幾分鍾你們能被我征服,因為 WebAssembly 是未來的發展趨勢。

不好意思,按錯了。

那麼 WebAssembly 到底是什麼呢?

JS 的未來和 Web 多語言開發

它為其他語言提供編譯服務,你可以將其他語言編譯成 WebAssembly,它是一種規範(類似於 jvm 支持的 class 字節碼)和要編譯成的目標文件類型。

這對於 JS 來說是一種能力的增強。WebAssembly 根本就不是想要取代 JS ,而是仍然讓 JS 做它所擅長的領域,同時也能讓 JS 也能做它所不擅長的領域,這就是它要做的事情。

但更重要的是,WebAssembly 表面上很神奇,但卻不僅僅只是表面上神奇,我會在後面解釋這點。

WebAssembly 的目標就是將你用其他語言寫的代碼編譯成 wasm 類型文件。

WebAssembly 已經很好的支持了 Rust 語言,C/C++,GO 和 C# 已經可以用 WebAssembly 編譯。

還有很多語言沒有提到,當然我能想到的主要就這四個,尤其是 Rust, WebAssembly 對它進行了相當多的優化,你有機會可以嘗試一下,這絕對是一個非常酷的編程體驗。

JS 的未來和 Web 多語言開發

那麼這裡,你可能會問:為什麼要用其他語言來寫 Web 程序?你為什麼要這麼做?為什麼你會在這裡放上 Laurie Voss(npm 的作者) 的演講照片,然後你使用其他語言來講這些東西?

主要有兩個理由:A,我想要和 Laurie Voss 進行合照。B,讓大家一起擁抱 WebAssembly。

三、下一個 Ajax

對於瀏覽器來說它就像是下一個 Ajax(就好比是下一個喬布斯)。

在這週末,我已經看到了很多有這樣(驚訝)表情了。

OK,就像下一個喬布斯(這裡是 Ajax),聽起來很酷。

但是我的意思是說 Ajax 真的高度可信並且使客戶端層面應用成為可能,所以說,Ajax 是一個變革,而 WebAssembly 將是下一步的一個變革。

這是我今天早上找到的一張超可愛的寶可夢 GIF,我就想著要把它貼上來。

JS 的未來和 Web 多語言開發

為了跟貼圖保持一致我特意選用了“進化”這個詞,不知道你們注沒注意 GIF 周邊我還寫了字的哈。

這時候你可能想著說,行吧,可能這就是下一個 Ajax,但還是抱著幾分遲疑態度。

這幅畫是我早上在 OneNote 上畫的。

JS 的未來和 Web 多語言開發

我把它稱為 “ancient.png.”

讓我們回過來看這張圖,這上面有 HTML,CSS 和 JS。

比如當你打開社交網頁的時候js就會播放煩人的音樂,服務器會返回所有這些東西,所有的東西都在這裡。

請將你的視線隨著我手指移動,當你點擊一個鏈接的時候,它會返回一個頁面,你一直點擊它就一直會給我們返回一個頁面。

每當你想要從服務器獲取新信息的時候,你就需要手動對瀏覽器進行刷新操作。

JS 的未來和 Web 多語言開發

我將這張圖稱之為 then.png,Ajax 不是一個 button 但勝似 button。

Ajax 請求頁面,然後獲取頁面內容,我們通過發送 Ajax 請求,來避免刷新頁面的操作。

我們通過 Ajax 得到返回的結果,Ajax 結果可能會是另外一個頁面的請求。

基於這個,我們得到了一系列的單頁應用程序。

當我們的服務器提供了Restful 風格的 API 的時候,也提供臨時的 HTML CSS 和 JS 文件。

這才是我要說的,請看我用高亮顏色所標記出的 WebAssembly 的內容,這裡突出了它的工作原理。

JS 的未來和 Web 多語言開發

可以看到頁面請求、返回的頁面結果,在這個過程中 WebAssembly 只是做一些計算而已。

我們依然來看兩個圖中左側的 Browser,然後使用 service worker 作為你的第三方模塊。同樣是在這個Browser中,你可以使用一些 Ajax 請求,同時服務器就類似於圖上的 LOL OK。我可能甚至都不是一個真正的服務器,我只是 serverless 服務器上的一個函數而已。

然後返回你的結果。整個過程簡直不可思議!

OK,相信你現在應該有點感覺了。

四、對 JS 進行增強

能夠在瀏覽器中計算內容,不一定非要用 JS 來實現。

這就是一件大事!相當重要!

那為什麼這很重要?為什麼我們要這麼關注?

我們之所以這麼關心是因為我們對 JS 進行增強。

JS 的未來和 Web 多語言開發

我知道,這個話題你也許聽到過很多次,甚至都已經厭倦了。但是這也是事實,JS 在某些方面的確不擅長。

我們並不需要為了使用 WebAssembly 而重寫整個項目代碼,誰也不想重構整個代碼庫,就像五年前那些包含了單元測試的代碼,我想沒人願意來幹這個事情(想重構舉起你們的手,但是沒有)。

挺好

更少的請求調用意味著更少的延遲,也就意味著我們可以為用戶提供更快的 Web 應用。

高性能一直都是很重要的。這樣的話,我們就無需對服務器進行成千上百萬次的請求。

所以,我們來談談該如何對 JS 進行增強。

我相信在你的工作過程中已經看到過很多次這種表達式(0.1 + 0.2 === 0.3 // false)了吧,其實0.1 + 0.2 = 0.30000000000000004(精度運算),所以 0.1 + 0.2 === 0.3 是 false

JS 的未來和 Web 多語言開發

所以如果你正在做的事情對數字精讀有很高的要求,比如:金融應用、股票交易、貨幣兌換。那麼很顯然,這些並不是 JS 的強項。

你需要對那些運行著不同語言的服務器發送一個 Ajax 請求,服務器會返回給你精確的結果,然後你對返回的結果進行了錯誤的轉換(通過 JS 對返回的 JSON包含的數字類型的字符串進行轉換,出現精讀丟失)。

所以通過 WebAssembly,你就可以在瀏覽器中使用正確的工具來完成這項工作,比如:Rust,C,或者其他浮點數超過32位的語言。

JS 的未來和 Web 多語言開發

其它 JS 不太強的地方還有,JS 的類型強制轉換會有一些負面效應,比如:” “ == 0 為 true。我真的很難去理解它,我可以說他們輸入了一個非零的數字。

得到和預想中不一樣的結果,這個結果對我來講完全是出乎意料的,比如你用 1 和通過選擇器(document.getElementById)獲取的 input 的值相加,結果只是連接字符串。但是你使用 Number函數處理 input 元素的值,那就會進行兩個數字相加,即使後者不是一個真正的數字,可能只是一個 NaN,然後 1+ 9可能也是 NaN。

這下知道我的意思了吧,類型強制轉換在這裡會很棘手。

說到類型,typeof 關鍵字是一個迷。就像圖中最後一條一樣,讓人煩躁了很多年(typeof [] === ‘array’ // false)

如果你之前看過我的演講,你就會知道使用了 WebAssembly 也就意味著使用了正確的工具來完成對應的工作。工欲善其事必先利其器。

WebAssembly 使用正確的工具來完成 Web 上的工作。

我們不需要再通過 JS 來做它不擅長的事情。

這對 Web 和瀏覽器應用程序來說都是一件大事。

但是這將會幹掉 JS。

噢, 我們將會使用 WebAssembly 去寫所有的應用程序,WebAssembly 將會…,不,冷靜,冷靜。開個玩笑,它不會幹掉 JS。

它讓 JS 做它擅長的事情,從而使它變得更好。在 DOM 操作上,React 和其他框架會快得離譜,JS 引擎也使 DOM 操作速度更加快。

我不認為 WebAssembly 會很快打敗 JS 和 DOM 操作。也許在遙遠的將來,它可以做到,但是近期看來並不會實現。

並且 JS 也很擅長於操作 CSS 樣式,WebAssembly 也不會取代 JS 去操作 CSS。

所以,WebAssembly 用於增強 JS,同時你也可以在此基礎上使用 JS,這並不矛盾。

並且 WebAssembly 解決了 JS 所不擅長的,這也減輕了 JS 的負擔。

就好像我和我的對象一樣。他是很討厭洗衣服的,真的,特別討厭。而我又特別討厭做菜,所以他做菜我洗衣服,並且這樣搭配非常完美。

但是現在他還是必須洗自己的衣服,因為我要出差三週,而他只有兩週的衣服穿,所以不得不洗。

就像 Ajax 做的那樣,WebAssembly 通過營造更好的瀏覽器體驗來使互聯網變得更好。

當你想到這些影響時,這更好的瀏覽器體驗簡直令人激動。就像 Jeff Goldblum(美國演員)令人激動那樣。

JS 的未來和 Web 多語言開發

五、舉個例子

讓我們通過這個 Demo 來進一步表達我的意思。

JS 的未來和 Web 多語言開發

這個 Demo 使用了 wasm-imagemagick 技術,如果你之前沒有用過 imagemagick 的話我可以解釋一下:imagemagick 是一個命令行工具,專用於創建和操縱圖片。

它能夠創建GIF動畫,它能夠創建圖片的單元格,它能夠創建分形圖。它是一個非常強大的庫以至於我不想用任何其他語言去重寫它,更不用說 JS。

我們將要以十倍快於 JS 的速度來操縱這些圖片,所以從某種意義上說 JS 本身並不能做到。

它真正強大的地方在於你不用重寫任何代碼就可以通過該工具來完成我們的工作。

讓我們來看看。希望這行得通。

它之前都是好好的所以這次可能就不行了,你知道我意思吧。

好了我攝像頭打開了。我們來選擇一張照片,我要點下面(做鬼臉),照片照出來總是顯得我很蠢,所以我放棄掙扎了。

OK,這些按鈕的意思是……我把它調大一點你們就看得清了我的舌頭和這些按鈕了。

JS 的未來和 Web 多語言開發

我們點右旋,然後在下面你就可以看到右旋的圖片了。這真的真的是很快的了,再左旋一下,你用 CSS 也能快速做到,這好像沒什麼了不起。我們來調個灰度,boom, 灰度,沒有閃屏。我們來加點對比度。去掉對比度呢?去掉對比度了。JS 能這麼快嗎?不可能!

對,這就是我的 Demo,我會在推特上發一下這個 Github 倉庫,這是完全開源的,你想的話可以嘗試一下。

對,這是我的 Demo。

哈謝謝你們

六、關於 Nodejs

但是 Nodejs 呢?等等……關於 Nodejs?

這是瀏覽器的工作,對,這完全是瀏覽器中的技術,我剛剛說的也完全是跟瀏覽器相關的。

但是,為什麼我會提到 Nodejs 呢?

我提及它(Nodejs)的原因是它是模塊本地化的,有誰在跑 npm install 的時候看到過 C 編譯出錯?

大部分人的手都應該舉起來了,因為這實在是太常見了,模塊本地化實在是 Node 中的一個大坑。

這東西真的非常愚蠢,甚至讓你想喊出 Bryan Cranston(絕命毒師男主)嘴裡喊的。你可能能從他的脣語裡讀出來,他喊的是 BLAH,他喊得並不是…額你知道的

為什麼這些模塊如此之坑?原因是它們必須在下載時重新編譯,而且必須為每一個體繫結構重新編譯它們。

就拿樹莓派平臺來說,因為在這個平臺上根本不能正常的工作,就會有人在 Github 上面去提issue ,同時也就意味著你會花很長時間在 Github 上去討論這個問題。

他們要麼會為你的平臺編譯一個版本,要不就直接不支持這個平臺。

的確這也是很棘手的,Github 上面的討論的確讓人感到糟糕。但是我很遺憾的告訴你,這個並不支持 Windows 系統。

首先聲明,我很感激hecc(高等教育協調理事會)在 node-gyp 方面所做的研究,他們完成了這是個似乎不可能完成的任務。因此我很尊重他們。

JS 的未來和 Web 多語言開發

但是 WebAssembly 只能在 Node8.0 以上版本正常工作。記住這個8.0版本,為什麼他可以在 Node8.0 以上的版本運行呢?

因為這個版本的 WebAssembly 模塊已經預編譯了,不需要構建。所以這對於任何平臺都是十分便捷,都

可以通過 Node 來運行。所以對於整個架構,都不會再有下載重編譯這個步驟了。

的確是這樣,我已經試過了,你也可以嘗試一下,這真的太棒了。

引用 Laurie Voss 今天早上說的一句話

"

特別說明

這是一個由 simviso 團隊對 JSConf.Asia 中關於 WebAssembly 相關話題進行翻譯的文檔,內容並非直譯,其中有一些是譯者自身的思考。分享者是 Kas Perch,Cloudflare 的一名開發人員。現在,讓我們一起來了解下什麼是 WebAssembly。

一、前言

JS 的未來和 Web 多語言開發

大家好,太棒了。就像他們所說,如果我們搞定了 WebAssembly 技術,那麼就搞定了 JS 的未來和 Web 多語言開發。

正如介紹所言,我叫 Kas Perch,現在是 Cloudflare 公司的一名 Avocado 開發人員。同時,我也很痴迷於機器人編程,並且寫過相關書籍。

我已經寫了兩本使用 JS 給機器人編程的書。我週末也會在 twitch 上直播一些硬件和軟件相關的東西。

我養了兩隻貓,它們是我的最愛。左邊的貓叫 Ace,右邊的叫 Aria。它們現在對我很生氣,因為我已經離開它們三個星期了。

JS 的未來和 Web 多語言開發

我可能再過一個星期才回去,它們是真的很生我的氣。

言歸正傳,你們來到這裡就是為了聽一些關於 WebAssembly 的一些東西

二、什麼是 WebAssembly

這項技術已經有五年了,我們還在維護中,我們冷靜下來思考一下,為什麼直到現在還沒有人指出該如何使用它。因為人們很難做到該如何更容易的去理解它(因為它很抽象),這也是為什麼我們要來談下它到底是什麼。

首先,我想說,它不是一個編程語言(注:WebAssembly 是驅動編程語言的存在,此處就相當於一個獵頭,針對後面這句話),就像你曾經去領英上面招聘員工一樣,你說你需要一個有十年開發經驗的 Node.js 程序員。

這個就像是在說,我是一個 WebAssembly 程序員,就好像如果你不會 WebAssembly 編程,你就不會寫 WebAssembly 程序(就好比如果你不會 Nodejs,你就不會使用 Nodejs 編程)。

其次,WebAssembly 不會取代 JS ,同時它可以讓 JS 駕馭任何事。

JS 並不會沒落,更不會被 WebAssembly 打敗,因為它並不是為了打敗 JS 而設計的。

WebAssembly 恰恰是我們無法去忽視的東西,因為它可以讓我們走得更遠

我希望在接下來二十幾分鍾你們能被我征服,因為 WebAssembly 是未來的發展趨勢。

不好意思,按錯了。

那麼 WebAssembly 到底是什麼呢?

JS 的未來和 Web 多語言開發

它為其他語言提供編譯服務,你可以將其他語言編譯成 WebAssembly,它是一種規範(類似於 jvm 支持的 class 字節碼)和要編譯成的目標文件類型。

這對於 JS 來說是一種能力的增強。WebAssembly 根本就不是想要取代 JS ,而是仍然讓 JS 做它所擅長的領域,同時也能讓 JS 也能做它所不擅長的領域,這就是它要做的事情。

但更重要的是,WebAssembly 表面上很神奇,但卻不僅僅只是表面上神奇,我會在後面解釋這點。

WebAssembly 的目標就是將你用其他語言寫的代碼編譯成 wasm 類型文件。

WebAssembly 已經很好的支持了 Rust 語言,C/C++,GO 和 C# 已經可以用 WebAssembly 編譯。

還有很多語言沒有提到,當然我能想到的主要就這四個,尤其是 Rust, WebAssembly 對它進行了相當多的優化,你有機會可以嘗試一下,這絕對是一個非常酷的編程體驗。

JS 的未來和 Web 多語言開發

那麼這裡,你可能會問:為什麼要用其他語言來寫 Web 程序?你為什麼要這麼做?為什麼你會在這裡放上 Laurie Voss(npm 的作者) 的演講照片,然後你使用其他語言來講這些東西?

主要有兩個理由:A,我想要和 Laurie Voss 進行合照。B,讓大家一起擁抱 WebAssembly。

三、下一個 Ajax

對於瀏覽器來說它就像是下一個 Ajax(就好比是下一個喬布斯)。

在這週末,我已經看到了很多有這樣(驚訝)表情了。

OK,就像下一個喬布斯(這裡是 Ajax),聽起來很酷。

但是我的意思是說 Ajax 真的高度可信並且使客戶端層面應用成為可能,所以說,Ajax 是一個變革,而 WebAssembly 將是下一步的一個變革。

這是我今天早上找到的一張超可愛的寶可夢 GIF,我就想著要把它貼上來。

JS 的未來和 Web 多語言開發

為了跟貼圖保持一致我特意選用了“進化”這個詞,不知道你們注沒注意 GIF 周邊我還寫了字的哈。

這時候你可能想著說,行吧,可能這就是下一個 Ajax,但還是抱著幾分遲疑態度。

這幅畫是我早上在 OneNote 上畫的。

JS 的未來和 Web 多語言開發

我把它稱為 “ancient.png.”

讓我們回過來看這張圖,這上面有 HTML,CSS 和 JS。

比如當你打開社交網頁的時候js就會播放煩人的音樂,服務器會返回所有這些東西,所有的東西都在這裡。

請將你的視線隨著我手指移動,當你點擊一個鏈接的時候,它會返回一個頁面,你一直點擊它就一直會給我們返回一個頁面。

每當你想要從服務器獲取新信息的時候,你就需要手動對瀏覽器進行刷新操作。

JS 的未來和 Web 多語言開發

我將這張圖稱之為 then.png,Ajax 不是一個 button 但勝似 button。

Ajax 請求頁面,然後獲取頁面內容,我們通過發送 Ajax 請求,來避免刷新頁面的操作。

我們通過 Ajax 得到返回的結果,Ajax 結果可能會是另外一個頁面的請求。

基於這個,我們得到了一系列的單頁應用程序。

當我們的服務器提供了Restful 風格的 API 的時候,也提供臨時的 HTML CSS 和 JS 文件。

這才是我要說的,請看我用高亮顏色所標記出的 WebAssembly 的內容,這裡突出了它的工作原理。

JS 的未來和 Web 多語言開發

可以看到頁面請求、返回的頁面結果,在這個過程中 WebAssembly 只是做一些計算而已。

我們依然來看兩個圖中左側的 Browser,然後使用 service worker 作為你的第三方模塊。同樣是在這個Browser中,你可以使用一些 Ajax 請求,同時服務器就類似於圖上的 LOL OK。我可能甚至都不是一個真正的服務器,我只是 serverless 服務器上的一個函數而已。

然後返回你的結果。整個過程簡直不可思議!

OK,相信你現在應該有點感覺了。

四、對 JS 進行增強

能夠在瀏覽器中計算內容,不一定非要用 JS 來實現。

這就是一件大事!相當重要!

那為什麼這很重要?為什麼我們要這麼關注?

我們之所以這麼關心是因為我們對 JS 進行增強。

JS 的未來和 Web 多語言開發

我知道,這個話題你也許聽到過很多次,甚至都已經厭倦了。但是這也是事實,JS 在某些方面的確不擅長。

我們並不需要為了使用 WebAssembly 而重寫整個項目代碼,誰也不想重構整個代碼庫,就像五年前那些包含了單元測試的代碼,我想沒人願意來幹這個事情(想重構舉起你們的手,但是沒有)。

挺好

更少的請求調用意味著更少的延遲,也就意味著我們可以為用戶提供更快的 Web 應用。

高性能一直都是很重要的。這樣的話,我們就無需對服務器進行成千上百萬次的請求。

所以,我們來談談該如何對 JS 進行增強。

我相信在你的工作過程中已經看到過很多次這種表達式(0.1 + 0.2 === 0.3 // false)了吧,其實0.1 + 0.2 = 0.30000000000000004(精度運算),所以 0.1 + 0.2 === 0.3 是 false

JS 的未來和 Web 多語言開發

所以如果你正在做的事情對數字精讀有很高的要求,比如:金融應用、股票交易、貨幣兌換。那麼很顯然,這些並不是 JS 的強項。

你需要對那些運行著不同語言的服務器發送一個 Ajax 請求,服務器會返回給你精確的結果,然後你對返回的結果進行了錯誤的轉換(通過 JS 對返回的 JSON包含的數字類型的字符串進行轉換,出現精讀丟失)。

所以通過 WebAssembly,你就可以在瀏覽器中使用正確的工具來完成這項工作,比如:Rust,C,或者其他浮點數超過32位的語言。

JS 的未來和 Web 多語言開發

其它 JS 不太強的地方還有,JS 的類型強制轉換會有一些負面效應,比如:” “ == 0 為 true。我真的很難去理解它,我可以說他們輸入了一個非零的數字。

得到和預想中不一樣的結果,這個結果對我來講完全是出乎意料的,比如你用 1 和通過選擇器(document.getElementById)獲取的 input 的值相加,結果只是連接字符串。但是你使用 Number函數處理 input 元素的值,那就會進行兩個數字相加,即使後者不是一個真正的數字,可能只是一個 NaN,然後 1+ 9可能也是 NaN。

這下知道我的意思了吧,類型強制轉換在這裡會很棘手。

說到類型,typeof 關鍵字是一個迷。就像圖中最後一條一樣,讓人煩躁了很多年(typeof [] === ‘array’ // false)

如果你之前看過我的演講,你就會知道使用了 WebAssembly 也就意味著使用了正確的工具來完成對應的工作。工欲善其事必先利其器。

WebAssembly 使用正確的工具來完成 Web 上的工作。

我們不需要再通過 JS 來做它不擅長的事情。

這對 Web 和瀏覽器應用程序來說都是一件大事。

但是這將會幹掉 JS。

噢, 我們將會使用 WebAssembly 去寫所有的應用程序,WebAssembly 將會…,不,冷靜,冷靜。開個玩笑,它不會幹掉 JS。

它讓 JS 做它擅長的事情,從而使它變得更好。在 DOM 操作上,React 和其他框架會快得離譜,JS 引擎也使 DOM 操作速度更加快。

我不認為 WebAssembly 會很快打敗 JS 和 DOM 操作。也許在遙遠的將來,它可以做到,但是近期看來並不會實現。

並且 JS 也很擅長於操作 CSS 樣式,WebAssembly 也不會取代 JS 去操作 CSS。

所以,WebAssembly 用於增強 JS,同時你也可以在此基礎上使用 JS,這並不矛盾。

並且 WebAssembly 解決了 JS 所不擅長的,這也減輕了 JS 的負擔。

就好像我和我的對象一樣。他是很討厭洗衣服的,真的,特別討厭。而我又特別討厭做菜,所以他做菜我洗衣服,並且這樣搭配非常完美。

但是現在他還是必須洗自己的衣服,因為我要出差三週,而他只有兩週的衣服穿,所以不得不洗。

就像 Ajax 做的那樣,WebAssembly 通過營造更好的瀏覽器體驗來使互聯網變得更好。

當你想到這些影響時,這更好的瀏覽器體驗簡直令人激動。就像 Jeff Goldblum(美國演員)令人激動那樣。

JS 的未來和 Web 多語言開發

五、舉個例子

讓我們通過這個 Demo 來進一步表達我的意思。

JS 的未來和 Web 多語言開發

這個 Demo 使用了 wasm-imagemagick 技術,如果你之前沒有用過 imagemagick 的話我可以解釋一下:imagemagick 是一個命令行工具,專用於創建和操縱圖片。

它能夠創建GIF動畫,它能夠創建圖片的單元格,它能夠創建分形圖。它是一個非常強大的庫以至於我不想用任何其他語言去重寫它,更不用說 JS。

我們將要以十倍快於 JS 的速度來操縱這些圖片,所以從某種意義上說 JS 本身並不能做到。

它真正強大的地方在於你不用重寫任何代碼就可以通過該工具來完成我們的工作。

讓我們來看看。希望這行得通。

它之前都是好好的所以這次可能就不行了,你知道我意思吧。

好了我攝像頭打開了。我們來選擇一張照片,我要點下面(做鬼臉),照片照出來總是顯得我很蠢,所以我放棄掙扎了。

OK,這些按鈕的意思是……我把它調大一點你們就看得清了我的舌頭和這些按鈕了。

JS 的未來和 Web 多語言開發

我們點右旋,然後在下面你就可以看到右旋的圖片了。這真的真的是很快的了,再左旋一下,你用 CSS 也能快速做到,這好像沒什麼了不起。我們來調個灰度,boom, 灰度,沒有閃屏。我們來加點對比度。去掉對比度呢?去掉對比度了。JS 能這麼快嗎?不可能!

對,這就是我的 Demo,我會在推特上發一下這個 Github 倉庫,這是完全開源的,你想的話可以嘗試一下。

對,這是我的 Demo。

哈謝謝你們

六、關於 Nodejs

但是 Nodejs 呢?等等……關於 Nodejs?

這是瀏覽器的工作,對,這完全是瀏覽器中的技術,我剛剛說的也完全是跟瀏覽器相關的。

但是,為什麼我會提到 Nodejs 呢?

我提及它(Nodejs)的原因是它是模塊本地化的,有誰在跑 npm install 的時候看到過 C 編譯出錯?

大部分人的手都應該舉起來了,因為這實在是太常見了,模塊本地化實在是 Node 中的一個大坑。

這東西真的非常愚蠢,甚至讓你想喊出 Bryan Cranston(絕命毒師男主)嘴裡喊的。你可能能從他的脣語裡讀出來,他喊的是 BLAH,他喊得並不是…額你知道的

為什麼這些模塊如此之坑?原因是它們必須在下載時重新編譯,而且必須為每一個體繫結構重新編譯它們。

就拿樹莓派平臺來說,因為在這個平臺上根本不能正常的工作,就會有人在 Github 上面去提issue ,同時也就意味著你會花很長時間在 Github 上去討論這個問題。

他們要麼會為你的平臺編譯一個版本,要不就直接不支持這個平臺。

的確這也是很棘手的,Github 上面的討論的確讓人感到糟糕。但是我很遺憾的告訴你,這個並不支持 Windows 系統。

首先聲明,我很感激hecc(高等教育協調理事會)在 node-gyp 方面所做的研究,他們完成了這是個似乎不可能完成的任務。因此我很尊重他們。

JS 的未來和 Web 多語言開發

但是 WebAssembly 只能在 Node8.0 以上版本正常工作。記住這個8.0版本,為什麼他可以在 Node8.0 以上的版本運行呢?

因為這個版本的 WebAssembly 模塊已經預編譯了,不需要構建。所以這對於任何平臺都是十分便捷,都

可以通過 Node 來運行。所以對於整個架構,都不會再有下載重編譯這個步驟了。

的確是這樣,我已經試過了,你也可以嘗試一下,這真的太棒了。

引用 Laurie Voss 今天早上說的一句話

JS 的未來和 Web 多語言開發

每個人都不看好 node-gyp,但是 WebAssembly 恰恰讓我們做到了。

這是 Nodejs 的里程碑。在不久的將來,當 Node8 不在維護的時候,Node8 以下的版本將不再兼容。

這並不意味著人們不能使用它,比如 Android3.0 版本。

其它

OK,WebAssembly 正在往 serverless 上進擊。例如,我在 CloudFlare 工作,我們有運行著 V8 引擎的雲平臺,所以你可以在 serverless 上運行 WebAssembly,這很酷!

"

特別說明

這是一個由 simviso 團隊對 JSConf.Asia 中關於 WebAssembly 相關話題進行翻譯的文檔,內容並非直譯,其中有一些是譯者自身的思考。分享者是 Kas Perch,Cloudflare 的一名開發人員。現在,讓我們一起來了解下什麼是 WebAssembly。

一、前言

JS 的未來和 Web 多語言開發

大家好,太棒了。就像他們所說,如果我們搞定了 WebAssembly 技術,那麼就搞定了 JS 的未來和 Web 多語言開發。

正如介紹所言,我叫 Kas Perch,現在是 Cloudflare 公司的一名 Avocado 開發人員。同時,我也很痴迷於機器人編程,並且寫過相關書籍。

我已經寫了兩本使用 JS 給機器人編程的書。我週末也會在 twitch 上直播一些硬件和軟件相關的東西。

我養了兩隻貓,它們是我的最愛。左邊的貓叫 Ace,右邊的叫 Aria。它們現在對我很生氣,因為我已經離開它們三個星期了。

JS 的未來和 Web 多語言開發

我可能再過一個星期才回去,它們是真的很生我的氣。

言歸正傳,你們來到這裡就是為了聽一些關於 WebAssembly 的一些東西

二、什麼是 WebAssembly

這項技術已經有五年了,我們還在維護中,我們冷靜下來思考一下,為什麼直到現在還沒有人指出該如何使用它。因為人們很難做到該如何更容易的去理解它(因為它很抽象),這也是為什麼我們要來談下它到底是什麼。

首先,我想說,它不是一個編程語言(注:WebAssembly 是驅動編程語言的存在,此處就相當於一個獵頭,針對後面這句話),就像你曾經去領英上面招聘員工一樣,你說你需要一個有十年開發經驗的 Node.js 程序員。

這個就像是在說,我是一個 WebAssembly 程序員,就好像如果你不會 WebAssembly 編程,你就不會寫 WebAssembly 程序(就好比如果你不會 Nodejs,你就不會使用 Nodejs 編程)。

其次,WebAssembly 不會取代 JS ,同時它可以讓 JS 駕馭任何事。

JS 並不會沒落,更不會被 WebAssembly 打敗,因為它並不是為了打敗 JS 而設計的。

WebAssembly 恰恰是我們無法去忽視的東西,因為它可以讓我們走得更遠

我希望在接下來二十幾分鍾你們能被我征服,因為 WebAssembly 是未來的發展趨勢。

不好意思,按錯了。

那麼 WebAssembly 到底是什麼呢?

JS 的未來和 Web 多語言開發

它為其他語言提供編譯服務,你可以將其他語言編譯成 WebAssembly,它是一種規範(類似於 jvm 支持的 class 字節碼)和要編譯成的目標文件類型。

這對於 JS 來說是一種能力的增強。WebAssembly 根本就不是想要取代 JS ,而是仍然讓 JS 做它所擅長的領域,同時也能讓 JS 也能做它所不擅長的領域,這就是它要做的事情。

但更重要的是,WebAssembly 表面上很神奇,但卻不僅僅只是表面上神奇,我會在後面解釋這點。

WebAssembly 的目標就是將你用其他語言寫的代碼編譯成 wasm 類型文件。

WebAssembly 已經很好的支持了 Rust 語言,C/C++,GO 和 C# 已經可以用 WebAssembly 編譯。

還有很多語言沒有提到,當然我能想到的主要就這四個,尤其是 Rust, WebAssembly 對它進行了相當多的優化,你有機會可以嘗試一下,這絕對是一個非常酷的編程體驗。

JS 的未來和 Web 多語言開發

那麼這裡,你可能會問:為什麼要用其他語言來寫 Web 程序?你為什麼要這麼做?為什麼你會在這裡放上 Laurie Voss(npm 的作者) 的演講照片,然後你使用其他語言來講這些東西?

主要有兩個理由:A,我想要和 Laurie Voss 進行合照。B,讓大家一起擁抱 WebAssembly。

三、下一個 Ajax

對於瀏覽器來說它就像是下一個 Ajax(就好比是下一個喬布斯)。

在這週末,我已經看到了很多有這樣(驚訝)表情了。

OK,就像下一個喬布斯(這裡是 Ajax),聽起來很酷。

但是我的意思是說 Ajax 真的高度可信並且使客戶端層面應用成為可能,所以說,Ajax 是一個變革,而 WebAssembly 將是下一步的一個變革。

這是我今天早上找到的一張超可愛的寶可夢 GIF,我就想著要把它貼上來。

JS 的未來和 Web 多語言開發

為了跟貼圖保持一致我特意選用了“進化”這個詞,不知道你們注沒注意 GIF 周邊我還寫了字的哈。

這時候你可能想著說,行吧,可能這就是下一個 Ajax,但還是抱著幾分遲疑態度。

這幅畫是我早上在 OneNote 上畫的。

JS 的未來和 Web 多語言開發

我把它稱為 “ancient.png.”

讓我們回過來看這張圖,這上面有 HTML,CSS 和 JS。

比如當你打開社交網頁的時候js就會播放煩人的音樂,服務器會返回所有這些東西,所有的東西都在這裡。

請將你的視線隨著我手指移動,當你點擊一個鏈接的時候,它會返回一個頁面,你一直點擊它就一直會給我們返回一個頁面。

每當你想要從服務器獲取新信息的時候,你就需要手動對瀏覽器進行刷新操作。

JS 的未來和 Web 多語言開發

我將這張圖稱之為 then.png,Ajax 不是一個 button 但勝似 button。

Ajax 請求頁面,然後獲取頁面內容,我們通過發送 Ajax 請求,來避免刷新頁面的操作。

我們通過 Ajax 得到返回的結果,Ajax 結果可能會是另外一個頁面的請求。

基於這個,我們得到了一系列的單頁應用程序。

當我們的服務器提供了Restful 風格的 API 的時候,也提供臨時的 HTML CSS 和 JS 文件。

這才是我要說的,請看我用高亮顏色所標記出的 WebAssembly 的內容,這裡突出了它的工作原理。

JS 的未來和 Web 多語言開發

可以看到頁面請求、返回的頁面結果,在這個過程中 WebAssembly 只是做一些計算而已。

我們依然來看兩個圖中左側的 Browser,然後使用 service worker 作為你的第三方模塊。同樣是在這個Browser中,你可以使用一些 Ajax 請求,同時服務器就類似於圖上的 LOL OK。我可能甚至都不是一個真正的服務器,我只是 serverless 服務器上的一個函數而已。

然後返回你的結果。整個過程簡直不可思議!

OK,相信你現在應該有點感覺了。

四、對 JS 進行增強

能夠在瀏覽器中計算內容,不一定非要用 JS 來實現。

這就是一件大事!相當重要!

那為什麼這很重要?為什麼我們要這麼關注?

我們之所以這麼關心是因為我們對 JS 進行增強。

JS 的未來和 Web 多語言開發

我知道,這個話題你也許聽到過很多次,甚至都已經厭倦了。但是這也是事實,JS 在某些方面的確不擅長。

我們並不需要為了使用 WebAssembly 而重寫整個項目代碼,誰也不想重構整個代碼庫,就像五年前那些包含了單元測試的代碼,我想沒人願意來幹這個事情(想重構舉起你們的手,但是沒有)。

挺好

更少的請求調用意味著更少的延遲,也就意味著我們可以為用戶提供更快的 Web 應用。

高性能一直都是很重要的。這樣的話,我們就無需對服務器進行成千上百萬次的請求。

所以,我們來談談該如何對 JS 進行增強。

我相信在你的工作過程中已經看到過很多次這種表達式(0.1 + 0.2 === 0.3 // false)了吧,其實0.1 + 0.2 = 0.30000000000000004(精度運算),所以 0.1 + 0.2 === 0.3 是 false

JS 的未來和 Web 多語言開發

所以如果你正在做的事情對數字精讀有很高的要求,比如:金融應用、股票交易、貨幣兌換。那麼很顯然,這些並不是 JS 的強項。

你需要對那些運行著不同語言的服務器發送一個 Ajax 請求,服務器會返回給你精確的結果,然後你對返回的結果進行了錯誤的轉換(通過 JS 對返回的 JSON包含的數字類型的字符串進行轉換,出現精讀丟失)。

所以通過 WebAssembly,你就可以在瀏覽器中使用正確的工具來完成這項工作,比如:Rust,C,或者其他浮點數超過32位的語言。

JS 的未來和 Web 多語言開發

其它 JS 不太強的地方還有,JS 的類型強制轉換會有一些負面效應,比如:” “ == 0 為 true。我真的很難去理解它,我可以說他們輸入了一個非零的數字。

得到和預想中不一樣的結果,這個結果對我來講完全是出乎意料的,比如你用 1 和通過選擇器(document.getElementById)獲取的 input 的值相加,結果只是連接字符串。但是你使用 Number函數處理 input 元素的值,那就會進行兩個數字相加,即使後者不是一個真正的數字,可能只是一個 NaN,然後 1+ 9可能也是 NaN。

這下知道我的意思了吧,類型強制轉換在這裡會很棘手。

說到類型,typeof 關鍵字是一個迷。就像圖中最後一條一樣,讓人煩躁了很多年(typeof [] === ‘array’ // false)

如果你之前看過我的演講,你就會知道使用了 WebAssembly 也就意味著使用了正確的工具來完成對應的工作。工欲善其事必先利其器。

WebAssembly 使用正確的工具來完成 Web 上的工作。

我們不需要再通過 JS 來做它不擅長的事情。

這對 Web 和瀏覽器應用程序來說都是一件大事。

但是這將會幹掉 JS。

噢, 我們將會使用 WebAssembly 去寫所有的應用程序,WebAssembly 將會…,不,冷靜,冷靜。開個玩笑,它不會幹掉 JS。

它讓 JS 做它擅長的事情,從而使它變得更好。在 DOM 操作上,React 和其他框架會快得離譜,JS 引擎也使 DOM 操作速度更加快。

我不認為 WebAssembly 會很快打敗 JS 和 DOM 操作。也許在遙遠的將來,它可以做到,但是近期看來並不會實現。

並且 JS 也很擅長於操作 CSS 樣式,WebAssembly 也不會取代 JS 去操作 CSS。

所以,WebAssembly 用於增強 JS,同時你也可以在此基礎上使用 JS,這並不矛盾。

並且 WebAssembly 解決了 JS 所不擅長的,這也減輕了 JS 的負擔。

就好像我和我的對象一樣。他是很討厭洗衣服的,真的,特別討厭。而我又特別討厭做菜,所以他做菜我洗衣服,並且這樣搭配非常完美。

但是現在他還是必須洗自己的衣服,因為我要出差三週,而他只有兩週的衣服穿,所以不得不洗。

就像 Ajax 做的那樣,WebAssembly 通過營造更好的瀏覽器體驗來使互聯網變得更好。

當你想到這些影響時,這更好的瀏覽器體驗簡直令人激動。就像 Jeff Goldblum(美國演員)令人激動那樣。

JS 的未來和 Web 多語言開發

五、舉個例子

讓我們通過這個 Demo 來進一步表達我的意思。

JS 的未來和 Web 多語言開發

這個 Demo 使用了 wasm-imagemagick 技術,如果你之前沒有用過 imagemagick 的話我可以解釋一下:imagemagick 是一個命令行工具,專用於創建和操縱圖片。

它能夠創建GIF動畫,它能夠創建圖片的單元格,它能夠創建分形圖。它是一個非常強大的庫以至於我不想用任何其他語言去重寫它,更不用說 JS。

我們將要以十倍快於 JS 的速度來操縱這些圖片,所以從某種意義上說 JS 本身並不能做到。

它真正強大的地方在於你不用重寫任何代碼就可以通過該工具來完成我們的工作。

讓我們來看看。希望這行得通。

它之前都是好好的所以這次可能就不行了,你知道我意思吧。

好了我攝像頭打開了。我們來選擇一張照片,我要點下面(做鬼臉),照片照出來總是顯得我很蠢,所以我放棄掙扎了。

OK,這些按鈕的意思是……我把它調大一點你們就看得清了我的舌頭和這些按鈕了。

JS 的未來和 Web 多語言開發

我們點右旋,然後在下面你就可以看到右旋的圖片了。這真的真的是很快的了,再左旋一下,你用 CSS 也能快速做到,這好像沒什麼了不起。我們來調個灰度,boom, 灰度,沒有閃屏。我們來加點對比度。去掉對比度呢?去掉對比度了。JS 能這麼快嗎?不可能!

對,這就是我的 Demo,我會在推特上發一下這個 Github 倉庫,這是完全開源的,你想的話可以嘗試一下。

對,這是我的 Demo。

哈謝謝你們

六、關於 Nodejs

但是 Nodejs 呢?等等……關於 Nodejs?

這是瀏覽器的工作,對,這完全是瀏覽器中的技術,我剛剛說的也完全是跟瀏覽器相關的。

但是,為什麼我會提到 Nodejs 呢?

我提及它(Nodejs)的原因是它是模塊本地化的,有誰在跑 npm install 的時候看到過 C 編譯出錯?

大部分人的手都應該舉起來了,因為這實在是太常見了,模塊本地化實在是 Node 中的一個大坑。

這東西真的非常愚蠢,甚至讓你想喊出 Bryan Cranston(絕命毒師男主)嘴裡喊的。你可能能從他的脣語裡讀出來,他喊的是 BLAH,他喊得並不是…額你知道的

為什麼這些模塊如此之坑?原因是它們必須在下載時重新編譯,而且必須為每一個體繫結構重新編譯它們。

就拿樹莓派平臺來說,因為在這個平臺上根本不能正常的工作,就會有人在 Github 上面去提issue ,同時也就意味著你會花很長時間在 Github 上去討論這個問題。

他們要麼會為你的平臺編譯一個版本,要不就直接不支持這個平臺。

的確這也是很棘手的,Github 上面的討論的確讓人感到糟糕。但是我很遺憾的告訴你,這個並不支持 Windows 系統。

首先聲明,我很感激hecc(高等教育協調理事會)在 node-gyp 方面所做的研究,他們完成了這是個似乎不可能完成的任務。因此我很尊重他們。

JS 的未來和 Web 多語言開發

但是 WebAssembly 只能在 Node8.0 以上版本正常工作。記住這個8.0版本,為什麼他可以在 Node8.0 以上的版本運行呢?

因為這個版本的 WebAssembly 模塊已經預編譯了,不需要構建。所以這對於任何平臺都是十分便捷,都

可以通過 Node 來運行。所以對於整個架構,都不會再有下載重編譯這個步驟了。

的確是這樣,我已經試過了,你也可以嘗試一下,這真的太棒了。

引用 Laurie Voss 今天早上說的一句話

JS 的未來和 Web 多語言開發

每個人都不看好 node-gyp,但是 WebAssembly 恰恰讓我們做到了。

這是 Nodejs 的里程碑。在不久的將來,當 Node8 不在維護的時候,Node8 以下的版本將不再兼容。

這並不意味著人們不能使用它,比如 Android3.0 版本。

其它

OK,WebAssembly 正在往 serverless 上進擊。例如,我在 CloudFlare 工作,我們有運行著 V8 引擎的雲平臺,所以你可以在 serverless 上運行 WebAssembly,這很酷!

JS 的未來和 Web 多語言開發

我們現在為現場的聽眾提供了一個免費的 serverless 平臺。

的意思是,假設你們中的某些人正在觀看這段視頻或者直播,但是你們沒有這個平臺的會員,然後還想白嫖。不要誤會我的意思哈,我只是也不喜歡付款而已。

如果你掃描這個二維碼,你可以保留一個 workers 的子域,而不是 dev 環境,它包含了 30 個 worker ,每天能處理 10 萬個請求,在每秒內,比我不使用 JS 做運算要稍微多一點。

這個我之後會再展示,它在我們的展位上也有放。但我會等你們都掃完,我再切到下一個 PPT。放二維碼顯然不是因為我不想讓你們看見我。

我想大家基本都掃完了。

"

特別說明

這是一個由 simviso 團隊對 JSConf.Asia 中關於 WebAssembly 相關話題進行翻譯的文檔,內容並非直譯,其中有一些是譯者自身的思考。分享者是 Kas Perch,Cloudflare 的一名開發人員。現在,讓我們一起來了解下什麼是 WebAssembly。

一、前言

JS 的未來和 Web 多語言開發

大家好,太棒了。就像他們所說,如果我們搞定了 WebAssembly 技術,那麼就搞定了 JS 的未來和 Web 多語言開發。

正如介紹所言,我叫 Kas Perch,現在是 Cloudflare 公司的一名 Avocado 開發人員。同時,我也很痴迷於機器人編程,並且寫過相關書籍。

我已經寫了兩本使用 JS 給機器人編程的書。我週末也會在 twitch 上直播一些硬件和軟件相關的東西。

我養了兩隻貓,它們是我的最愛。左邊的貓叫 Ace,右邊的叫 Aria。它們現在對我很生氣,因為我已經離開它們三個星期了。

JS 的未來和 Web 多語言開發

我可能再過一個星期才回去,它們是真的很生我的氣。

言歸正傳,你們來到這裡就是為了聽一些關於 WebAssembly 的一些東西

二、什麼是 WebAssembly

這項技術已經有五年了,我們還在維護中,我們冷靜下來思考一下,為什麼直到現在還沒有人指出該如何使用它。因為人們很難做到該如何更容易的去理解它(因為它很抽象),這也是為什麼我們要來談下它到底是什麼。

首先,我想說,它不是一個編程語言(注:WebAssembly 是驅動編程語言的存在,此處就相當於一個獵頭,針對後面這句話),就像你曾經去領英上面招聘員工一樣,你說你需要一個有十年開發經驗的 Node.js 程序員。

這個就像是在說,我是一個 WebAssembly 程序員,就好像如果你不會 WebAssembly 編程,你就不會寫 WebAssembly 程序(就好比如果你不會 Nodejs,你就不會使用 Nodejs 編程)。

其次,WebAssembly 不會取代 JS ,同時它可以讓 JS 駕馭任何事。

JS 並不會沒落,更不會被 WebAssembly 打敗,因為它並不是為了打敗 JS 而設計的。

WebAssembly 恰恰是我們無法去忽視的東西,因為它可以讓我們走得更遠

我希望在接下來二十幾分鍾你們能被我征服,因為 WebAssembly 是未來的發展趨勢。

不好意思,按錯了。

那麼 WebAssembly 到底是什麼呢?

JS 的未來和 Web 多語言開發

它為其他語言提供編譯服務,你可以將其他語言編譯成 WebAssembly,它是一種規範(類似於 jvm 支持的 class 字節碼)和要編譯成的目標文件類型。

這對於 JS 來說是一種能力的增強。WebAssembly 根本就不是想要取代 JS ,而是仍然讓 JS 做它所擅長的領域,同時也能讓 JS 也能做它所不擅長的領域,這就是它要做的事情。

但更重要的是,WebAssembly 表面上很神奇,但卻不僅僅只是表面上神奇,我會在後面解釋這點。

WebAssembly 的目標就是將你用其他語言寫的代碼編譯成 wasm 類型文件。

WebAssembly 已經很好的支持了 Rust 語言,C/C++,GO 和 C# 已經可以用 WebAssembly 編譯。

還有很多語言沒有提到,當然我能想到的主要就這四個,尤其是 Rust, WebAssembly 對它進行了相當多的優化,你有機會可以嘗試一下,這絕對是一個非常酷的編程體驗。

JS 的未來和 Web 多語言開發

那麼這裡,你可能會問:為什麼要用其他語言來寫 Web 程序?你為什麼要這麼做?為什麼你會在這裡放上 Laurie Voss(npm 的作者) 的演講照片,然後你使用其他語言來講這些東西?

主要有兩個理由:A,我想要和 Laurie Voss 進行合照。B,讓大家一起擁抱 WebAssembly。

三、下一個 Ajax

對於瀏覽器來說它就像是下一個 Ajax(就好比是下一個喬布斯)。

在這週末,我已經看到了很多有這樣(驚訝)表情了。

OK,就像下一個喬布斯(這裡是 Ajax),聽起來很酷。

但是我的意思是說 Ajax 真的高度可信並且使客戶端層面應用成為可能,所以說,Ajax 是一個變革,而 WebAssembly 將是下一步的一個變革。

這是我今天早上找到的一張超可愛的寶可夢 GIF,我就想著要把它貼上來。

JS 的未來和 Web 多語言開發

為了跟貼圖保持一致我特意選用了“進化”這個詞,不知道你們注沒注意 GIF 周邊我還寫了字的哈。

這時候你可能想著說,行吧,可能這就是下一個 Ajax,但還是抱著幾分遲疑態度。

這幅畫是我早上在 OneNote 上畫的。

JS 的未來和 Web 多語言開發

我把它稱為 “ancient.png.”

讓我們回過來看這張圖,這上面有 HTML,CSS 和 JS。

比如當你打開社交網頁的時候js就會播放煩人的音樂,服務器會返回所有這些東西,所有的東西都在這裡。

請將你的視線隨著我手指移動,當你點擊一個鏈接的時候,它會返回一個頁面,你一直點擊它就一直會給我們返回一個頁面。

每當你想要從服務器獲取新信息的時候,你就需要手動對瀏覽器進行刷新操作。

JS 的未來和 Web 多語言開發

我將這張圖稱之為 then.png,Ajax 不是一個 button 但勝似 button。

Ajax 請求頁面,然後獲取頁面內容,我們通過發送 Ajax 請求,來避免刷新頁面的操作。

我們通過 Ajax 得到返回的結果,Ajax 結果可能會是另外一個頁面的請求。

基於這個,我們得到了一系列的單頁應用程序。

當我們的服務器提供了Restful 風格的 API 的時候,也提供臨時的 HTML CSS 和 JS 文件。

這才是我要說的,請看我用高亮顏色所標記出的 WebAssembly 的內容,這裡突出了它的工作原理。

JS 的未來和 Web 多語言開發

可以看到頁面請求、返回的頁面結果,在這個過程中 WebAssembly 只是做一些計算而已。

我們依然來看兩個圖中左側的 Browser,然後使用 service worker 作為你的第三方模塊。同樣是在這個Browser中,你可以使用一些 Ajax 請求,同時服務器就類似於圖上的 LOL OK。我可能甚至都不是一個真正的服務器,我只是 serverless 服務器上的一個函數而已。

然後返回你的結果。整個過程簡直不可思議!

OK,相信你現在應該有點感覺了。

四、對 JS 進行增強

能夠在瀏覽器中計算內容,不一定非要用 JS 來實現。

這就是一件大事!相當重要!

那為什麼這很重要?為什麼我們要這麼關注?

我們之所以這麼關心是因為我們對 JS 進行增強。

JS 的未來和 Web 多語言開發

我知道,這個話題你也許聽到過很多次,甚至都已經厭倦了。但是這也是事實,JS 在某些方面的確不擅長。

我們並不需要為了使用 WebAssembly 而重寫整個項目代碼,誰也不想重構整個代碼庫,就像五年前那些包含了單元測試的代碼,我想沒人願意來幹這個事情(想重構舉起你們的手,但是沒有)。

挺好

更少的請求調用意味著更少的延遲,也就意味著我們可以為用戶提供更快的 Web 應用。

高性能一直都是很重要的。這樣的話,我們就無需對服務器進行成千上百萬次的請求。

所以,我們來談談該如何對 JS 進行增強。

我相信在你的工作過程中已經看到過很多次這種表達式(0.1 + 0.2 === 0.3 // false)了吧,其實0.1 + 0.2 = 0.30000000000000004(精度運算),所以 0.1 + 0.2 === 0.3 是 false

JS 的未來和 Web 多語言開發

所以如果你正在做的事情對數字精讀有很高的要求,比如:金融應用、股票交易、貨幣兌換。那麼很顯然,這些並不是 JS 的強項。

你需要對那些運行著不同語言的服務器發送一個 Ajax 請求,服務器會返回給你精確的結果,然後你對返回的結果進行了錯誤的轉換(通過 JS 對返回的 JSON包含的數字類型的字符串進行轉換,出現精讀丟失)。

所以通過 WebAssembly,你就可以在瀏覽器中使用正確的工具來完成這項工作,比如:Rust,C,或者其他浮點數超過32位的語言。

JS 的未來和 Web 多語言開發

其它 JS 不太強的地方還有,JS 的類型強制轉換會有一些負面效應,比如:” “ == 0 為 true。我真的很難去理解它,我可以說他們輸入了一個非零的數字。

得到和預想中不一樣的結果,這個結果對我來講完全是出乎意料的,比如你用 1 和通過選擇器(document.getElementById)獲取的 input 的值相加,結果只是連接字符串。但是你使用 Number函數處理 input 元素的值,那就會進行兩個數字相加,即使後者不是一個真正的數字,可能只是一個 NaN,然後 1+ 9可能也是 NaN。

這下知道我的意思了吧,類型強制轉換在這裡會很棘手。

說到類型,typeof 關鍵字是一個迷。就像圖中最後一條一樣,讓人煩躁了很多年(typeof [] === ‘array’ // false)

如果你之前看過我的演講,你就會知道使用了 WebAssembly 也就意味著使用了正確的工具來完成對應的工作。工欲善其事必先利其器。

WebAssembly 使用正確的工具來完成 Web 上的工作。

我們不需要再通過 JS 來做它不擅長的事情。

這對 Web 和瀏覽器應用程序來說都是一件大事。

但是這將會幹掉 JS。

噢, 我們將會使用 WebAssembly 去寫所有的應用程序,WebAssembly 將會…,不,冷靜,冷靜。開個玩笑,它不會幹掉 JS。

它讓 JS 做它擅長的事情,從而使它變得更好。在 DOM 操作上,React 和其他框架會快得離譜,JS 引擎也使 DOM 操作速度更加快。

我不認為 WebAssembly 會很快打敗 JS 和 DOM 操作。也許在遙遠的將來,它可以做到,但是近期看來並不會實現。

並且 JS 也很擅長於操作 CSS 樣式,WebAssembly 也不會取代 JS 去操作 CSS。

所以,WebAssembly 用於增強 JS,同時你也可以在此基礎上使用 JS,這並不矛盾。

並且 WebAssembly 解決了 JS 所不擅長的,這也減輕了 JS 的負擔。

就好像我和我的對象一樣。他是很討厭洗衣服的,真的,特別討厭。而我又特別討厭做菜,所以他做菜我洗衣服,並且這樣搭配非常完美。

但是現在他還是必須洗自己的衣服,因為我要出差三週,而他只有兩週的衣服穿,所以不得不洗。

就像 Ajax 做的那樣,WebAssembly 通過營造更好的瀏覽器體驗來使互聯網變得更好。

當你想到這些影響時,這更好的瀏覽器體驗簡直令人激動。就像 Jeff Goldblum(美國演員)令人激動那樣。

JS 的未來和 Web 多語言開發

五、舉個例子

讓我們通過這個 Demo 來進一步表達我的意思。

JS 的未來和 Web 多語言開發

這個 Demo 使用了 wasm-imagemagick 技術,如果你之前沒有用過 imagemagick 的話我可以解釋一下:imagemagick 是一個命令行工具,專用於創建和操縱圖片。

它能夠創建GIF動畫,它能夠創建圖片的單元格,它能夠創建分形圖。它是一個非常強大的庫以至於我不想用任何其他語言去重寫它,更不用說 JS。

我們將要以十倍快於 JS 的速度來操縱這些圖片,所以從某種意義上說 JS 本身並不能做到。

它真正強大的地方在於你不用重寫任何代碼就可以通過該工具來完成我們的工作。

讓我們來看看。希望這行得通。

它之前都是好好的所以這次可能就不行了,你知道我意思吧。

好了我攝像頭打開了。我們來選擇一張照片,我要點下面(做鬼臉),照片照出來總是顯得我很蠢,所以我放棄掙扎了。

OK,這些按鈕的意思是……我把它調大一點你們就看得清了我的舌頭和這些按鈕了。

JS 的未來和 Web 多語言開發

我們點右旋,然後在下面你就可以看到右旋的圖片了。這真的真的是很快的了,再左旋一下,你用 CSS 也能快速做到,這好像沒什麼了不起。我們來調個灰度,boom, 灰度,沒有閃屏。我們來加點對比度。去掉對比度呢?去掉對比度了。JS 能這麼快嗎?不可能!

對,這就是我的 Demo,我會在推特上發一下這個 Github 倉庫,這是完全開源的,你想的話可以嘗試一下。

對,這是我的 Demo。

哈謝謝你們

六、關於 Nodejs

但是 Nodejs 呢?等等……關於 Nodejs?

這是瀏覽器的工作,對,這完全是瀏覽器中的技術,我剛剛說的也完全是跟瀏覽器相關的。

但是,為什麼我會提到 Nodejs 呢?

我提及它(Nodejs)的原因是它是模塊本地化的,有誰在跑 npm install 的時候看到過 C 編譯出錯?

大部分人的手都應該舉起來了,因為這實在是太常見了,模塊本地化實在是 Node 中的一個大坑。

這東西真的非常愚蠢,甚至讓你想喊出 Bryan Cranston(絕命毒師男主)嘴裡喊的。你可能能從他的脣語裡讀出來,他喊的是 BLAH,他喊得並不是…額你知道的

為什麼這些模塊如此之坑?原因是它們必須在下載時重新編譯,而且必須為每一個體繫結構重新編譯它們。

就拿樹莓派平臺來說,因為在這個平臺上根本不能正常的工作,就會有人在 Github 上面去提issue ,同時也就意味著你會花很長時間在 Github 上去討論這個問題。

他們要麼會為你的平臺編譯一個版本,要不就直接不支持這個平臺。

的確這也是很棘手的,Github 上面的討論的確讓人感到糟糕。但是我很遺憾的告訴你,這個並不支持 Windows 系統。

首先聲明,我很感激hecc(高等教育協調理事會)在 node-gyp 方面所做的研究,他們完成了這是個似乎不可能完成的任務。因此我很尊重他們。

JS 的未來和 Web 多語言開發

但是 WebAssembly 只能在 Node8.0 以上版本正常工作。記住這個8.0版本,為什麼他可以在 Node8.0 以上的版本運行呢?

因為這個版本的 WebAssembly 模塊已經預編譯了,不需要構建。所以這對於任何平臺都是十分便捷,都

可以通過 Node 來運行。所以對於整個架構,都不會再有下載重編譯這個步驟了。

的確是這樣,我已經試過了,你也可以嘗試一下,這真的太棒了。

引用 Laurie Voss 今天早上說的一句話

JS 的未來和 Web 多語言開發

每個人都不看好 node-gyp,但是 WebAssembly 恰恰讓我們做到了。

這是 Nodejs 的里程碑。在不久的將來,當 Node8 不在維護的時候,Node8 以下的版本將不再兼容。

這並不意味著人們不能使用它,比如 Android3.0 版本。

其它

OK,WebAssembly 正在往 serverless 上進擊。例如,我在 CloudFlare 工作,我們有運行著 V8 引擎的雲平臺,所以你可以在 serverless 上運行 WebAssembly,這很酷!

JS 的未來和 Web 多語言開發

我們現在為現場的聽眾提供了一個免費的 serverless 平臺。

的意思是,假設你們中的某些人正在觀看這段視頻或者直播,但是你們沒有這個平臺的會員,然後還想白嫖。不要誤會我的意思哈,我只是也不喜歡付款而已。

如果你掃描這個二維碼,你可以保留一個 workers 的子域,而不是 dev 環境,它包含了 30 個 worker ,每天能處理 10 萬個請求,在每秒內,比我不使用 JS 做運算要稍微多一點。

這個我之後會再展示,它在我們的展位上也有放。但我會等你們都掃完,我再切到下一個 PPT。放二維碼顯然不是因為我不想讓你們看見我。

我想大家基本都掃完了。

JS 的未來和 Web 多語言開發

這次談話的重點是試著擁抱 WebAssembly ,我個人特別喜歡 Rust。

我學到更多關於 Rust 的知識就像我學到新東西一樣。就好像這不是在 13 天內創造出來的。

我沒有瞧不起 JS。它是有史以來最好的語言之一,但它是在13天內完成的,而 Rust 絕對不是在 13 天內完成的。

它絕對是經過深思熟慮的。

WebAssembly 是 JS 所有形式的未來,儘管我希望能向你展示它將創造更好的瀏覽器體驗。它將棄用 node-gyp。

從現在起的五年裡實際上它並沒有這樣做,請不要引用我的話。

但它可能會棄用 node-gyp。你可以引用我的話。

最後一個問題是,如果你現在是招聘經理,我想讓你做一些非常重要的事,那就是僱傭一個和你不同的人。

他們可能與你有所不同,他們可能會相信你的不同之處,他們可能會有所不同,他們的性別認同可能與你僱傭他們的性別不同。

在你告訴我這很難之前,我會讓你去找 LaBeouf 先生談這件事。

"

特別說明

這是一個由 simviso 團隊對 JSConf.Asia 中關於 WebAssembly 相關話題進行翻譯的文檔,內容並非直譯,其中有一些是譯者自身的思考。分享者是 Kas Perch,Cloudflare 的一名開發人員。現在,讓我們一起來了解下什麼是 WebAssembly。

一、前言

JS 的未來和 Web 多語言開發

大家好,太棒了。就像他們所說,如果我們搞定了 WebAssembly 技術,那麼就搞定了 JS 的未來和 Web 多語言開發。

正如介紹所言,我叫 Kas Perch,現在是 Cloudflare 公司的一名 Avocado 開發人員。同時,我也很痴迷於機器人編程,並且寫過相關書籍。

我已經寫了兩本使用 JS 給機器人編程的書。我週末也會在 twitch 上直播一些硬件和軟件相關的東西。

我養了兩隻貓,它們是我的最愛。左邊的貓叫 Ace,右邊的叫 Aria。它們現在對我很生氣,因為我已經離開它們三個星期了。

JS 的未來和 Web 多語言開發

我可能再過一個星期才回去,它們是真的很生我的氣。

言歸正傳,你們來到這裡就是為了聽一些關於 WebAssembly 的一些東西

二、什麼是 WebAssembly

這項技術已經有五年了,我們還在維護中,我們冷靜下來思考一下,為什麼直到現在還沒有人指出該如何使用它。因為人們很難做到該如何更容易的去理解它(因為它很抽象),這也是為什麼我們要來談下它到底是什麼。

首先,我想說,它不是一個編程語言(注:WebAssembly 是驅動編程語言的存在,此處就相當於一個獵頭,針對後面這句話),就像你曾經去領英上面招聘員工一樣,你說你需要一個有十年開發經驗的 Node.js 程序員。

這個就像是在說,我是一個 WebAssembly 程序員,就好像如果你不會 WebAssembly 編程,你就不會寫 WebAssembly 程序(就好比如果你不會 Nodejs,你就不會使用 Nodejs 編程)。

其次,WebAssembly 不會取代 JS ,同時它可以讓 JS 駕馭任何事。

JS 並不會沒落,更不會被 WebAssembly 打敗,因為它並不是為了打敗 JS 而設計的。

WebAssembly 恰恰是我們無法去忽視的東西,因為它可以讓我們走得更遠

我希望在接下來二十幾分鍾你們能被我征服,因為 WebAssembly 是未來的發展趨勢。

不好意思,按錯了。

那麼 WebAssembly 到底是什麼呢?

JS 的未來和 Web 多語言開發

它為其他語言提供編譯服務,你可以將其他語言編譯成 WebAssembly,它是一種規範(類似於 jvm 支持的 class 字節碼)和要編譯成的目標文件類型。

這對於 JS 來說是一種能力的增強。WebAssembly 根本就不是想要取代 JS ,而是仍然讓 JS 做它所擅長的領域,同時也能讓 JS 也能做它所不擅長的領域,這就是它要做的事情。

但更重要的是,WebAssembly 表面上很神奇,但卻不僅僅只是表面上神奇,我會在後面解釋這點。

WebAssembly 的目標就是將你用其他語言寫的代碼編譯成 wasm 類型文件。

WebAssembly 已經很好的支持了 Rust 語言,C/C++,GO 和 C# 已經可以用 WebAssembly 編譯。

還有很多語言沒有提到,當然我能想到的主要就這四個,尤其是 Rust, WebAssembly 對它進行了相當多的優化,你有機會可以嘗試一下,這絕對是一個非常酷的編程體驗。

JS 的未來和 Web 多語言開發

那麼這裡,你可能會問:為什麼要用其他語言來寫 Web 程序?你為什麼要這麼做?為什麼你會在這裡放上 Laurie Voss(npm 的作者) 的演講照片,然後你使用其他語言來講這些東西?

主要有兩個理由:A,我想要和 Laurie Voss 進行合照。B,讓大家一起擁抱 WebAssembly。

三、下一個 Ajax

對於瀏覽器來說它就像是下一個 Ajax(就好比是下一個喬布斯)。

在這週末,我已經看到了很多有這樣(驚訝)表情了。

OK,就像下一個喬布斯(這裡是 Ajax),聽起來很酷。

但是我的意思是說 Ajax 真的高度可信並且使客戶端層面應用成為可能,所以說,Ajax 是一個變革,而 WebAssembly 將是下一步的一個變革。

這是我今天早上找到的一張超可愛的寶可夢 GIF,我就想著要把它貼上來。

JS 的未來和 Web 多語言開發

為了跟貼圖保持一致我特意選用了“進化”這個詞,不知道你們注沒注意 GIF 周邊我還寫了字的哈。

這時候你可能想著說,行吧,可能這就是下一個 Ajax,但還是抱著幾分遲疑態度。

這幅畫是我早上在 OneNote 上畫的。

JS 的未來和 Web 多語言開發

我把它稱為 “ancient.png.”

讓我們回過來看這張圖,這上面有 HTML,CSS 和 JS。

比如當你打開社交網頁的時候js就會播放煩人的音樂,服務器會返回所有這些東西,所有的東西都在這裡。

請將你的視線隨著我手指移動,當你點擊一個鏈接的時候,它會返回一個頁面,你一直點擊它就一直會給我們返回一個頁面。

每當你想要從服務器獲取新信息的時候,你就需要手動對瀏覽器進行刷新操作。

JS 的未來和 Web 多語言開發

我將這張圖稱之為 then.png,Ajax 不是一個 button 但勝似 button。

Ajax 請求頁面,然後獲取頁面內容,我們通過發送 Ajax 請求,來避免刷新頁面的操作。

我們通過 Ajax 得到返回的結果,Ajax 結果可能會是另外一個頁面的請求。

基於這個,我們得到了一系列的單頁應用程序。

當我們的服務器提供了Restful 風格的 API 的時候,也提供臨時的 HTML CSS 和 JS 文件。

這才是我要說的,請看我用高亮顏色所標記出的 WebAssembly 的內容,這裡突出了它的工作原理。

JS 的未來和 Web 多語言開發

可以看到頁面請求、返回的頁面結果,在這個過程中 WebAssembly 只是做一些計算而已。

我們依然來看兩個圖中左側的 Browser,然後使用 service worker 作為你的第三方模塊。同樣是在這個Browser中,你可以使用一些 Ajax 請求,同時服務器就類似於圖上的 LOL OK。我可能甚至都不是一個真正的服務器,我只是 serverless 服務器上的一個函數而已。

然後返回你的結果。整個過程簡直不可思議!

OK,相信你現在應該有點感覺了。

四、對 JS 進行增強

能夠在瀏覽器中計算內容,不一定非要用 JS 來實現。

這就是一件大事!相當重要!

那為什麼這很重要?為什麼我們要這麼關注?

我們之所以這麼關心是因為我們對 JS 進行增強。

JS 的未來和 Web 多語言開發

我知道,這個話題你也許聽到過很多次,甚至都已經厭倦了。但是這也是事實,JS 在某些方面的確不擅長。

我們並不需要為了使用 WebAssembly 而重寫整個項目代碼,誰也不想重構整個代碼庫,就像五年前那些包含了單元測試的代碼,我想沒人願意來幹這個事情(想重構舉起你們的手,但是沒有)。

挺好

更少的請求調用意味著更少的延遲,也就意味著我們可以為用戶提供更快的 Web 應用。

高性能一直都是很重要的。這樣的話,我們就無需對服務器進行成千上百萬次的請求。

所以,我們來談談該如何對 JS 進行增強。

我相信在你的工作過程中已經看到過很多次這種表達式(0.1 + 0.2 === 0.3 // false)了吧,其實0.1 + 0.2 = 0.30000000000000004(精度運算),所以 0.1 + 0.2 === 0.3 是 false

JS 的未來和 Web 多語言開發

所以如果你正在做的事情對數字精讀有很高的要求,比如:金融應用、股票交易、貨幣兌換。那麼很顯然,這些並不是 JS 的強項。

你需要對那些運行著不同語言的服務器發送一個 Ajax 請求,服務器會返回給你精確的結果,然後你對返回的結果進行了錯誤的轉換(通過 JS 對返回的 JSON包含的數字類型的字符串進行轉換,出現精讀丟失)。

所以通過 WebAssembly,你就可以在瀏覽器中使用正確的工具來完成這項工作,比如:Rust,C,或者其他浮點數超過32位的語言。

JS 的未來和 Web 多語言開發

其它 JS 不太強的地方還有,JS 的類型強制轉換會有一些負面效應,比如:” “ == 0 為 true。我真的很難去理解它,我可以說他們輸入了一個非零的數字。

得到和預想中不一樣的結果,這個結果對我來講完全是出乎意料的,比如你用 1 和通過選擇器(document.getElementById)獲取的 input 的值相加,結果只是連接字符串。但是你使用 Number函數處理 input 元素的值,那就會進行兩個數字相加,即使後者不是一個真正的數字,可能只是一個 NaN,然後 1+ 9可能也是 NaN。

這下知道我的意思了吧,類型強制轉換在這裡會很棘手。

說到類型,typeof 關鍵字是一個迷。就像圖中最後一條一樣,讓人煩躁了很多年(typeof [] === ‘array’ // false)

如果你之前看過我的演講,你就會知道使用了 WebAssembly 也就意味著使用了正確的工具來完成對應的工作。工欲善其事必先利其器。

WebAssembly 使用正確的工具來完成 Web 上的工作。

我們不需要再通過 JS 來做它不擅長的事情。

這對 Web 和瀏覽器應用程序來說都是一件大事。

但是這將會幹掉 JS。

噢, 我們將會使用 WebAssembly 去寫所有的應用程序,WebAssembly 將會…,不,冷靜,冷靜。開個玩笑,它不會幹掉 JS。

它讓 JS 做它擅長的事情,從而使它變得更好。在 DOM 操作上,React 和其他框架會快得離譜,JS 引擎也使 DOM 操作速度更加快。

我不認為 WebAssembly 會很快打敗 JS 和 DOM 操作。也許在遙遠的將來,它可以做到,但是近期看來並不會實現。

並且 JS 也很擅長於操作 CSS 樣式,WebAssembly 也不會取代 JS 去操作 CSS。

所以,WebAssembly 用於增強 JS,同時你也可以在此基礎上使用 JS,這並不矛盾。

並且 WebAssembly 解決了 JS 所不擅長的,這也減輕了 JS 的負擔。

就好像我和我的對象一樣。他是很討厭洗衣服的,真的,特別討厭。而我又特別討厭做菜,所以他做菜我洗衣服,並且這樣搭配非常完美。

但是現在他還是必須洗自己的衣服,因為我要出差三週,而他只有兩週的衣服穿,所以不得不洗。

就像 Ajax 做的那樣,WebAssembly 通過營造更好的瀏覽器體驗來使互聯網變得更好。

當你想到這些影響時,這更好的瀏覽器體驗簡直令人激動。就像 Jeff Goldblum(美國演員)令人激動那樣。

JS 的未來和 Web 多語言開發

五、舉個例子

讓我們通過這個 Demo 來進一步表達我的意思。

JS 的未來和 Web 多語言開發

這個 Demo 使用了 wasm-imagemagick 技術,如果你之前沒有用過 imagemagick 的話我可以解釋一下:imagemagick 是一個命令行工具,專用於創建和操縱圖片。

它能夠創建GIF動畫,它能夠創建圖片的單元格,它能夠創建分形圖。它是一個非常強大的庫以至於我不想用任何其他語言去重寫它,更不用說 JS。

我們將要以十倍快於 JS 的速度來操縱這些圖片,所以從某種意義上說 JS 本身並不能做到。

它真正強大的地方在於你不用重寫任何代碼就可以通過該工具來完成我們的工作。

讓我們來看看。希望這行得通。

它之前都是好好的所以這次可能就不行了,你知道我意思吧。

好了我攝像頭打開了。我們來選擇一張照片,我要點下面(做鬼臉),照片照出來總是顯得我很蠢,所以我放棄掙扎了。

OK,這些按鈕的意思是……我把它調大一點你們就看得清了我的舌頭和這些按鈕了。

JS 的未來和 Web 多語言開發

我們點右旋,然後在下面你就可以看到右旋的圖片了。這真的真的是很快的了,再左旋一下,你用 CSS 也能快速做到,這好像沒什麼了不起。我們來調個灰度,boom, 灰度,沒有閃屏。我們來加點對比度。去掉對比度呢?去掉對比度了。JS 能這麼快嗎?不可能!

對,這就是我的 Demo,我會在推特上發一下這個 Github 倉庫,這是完全開源的,你想的話可以嘗試一下。

對,這是我的 Demo。

哈謝謝你們

六、關於 Nodejs

但是 Nodejs 呢?等等……關於 Nodejs?

這是瀏覽器的工作,對,這完全是瀏覽器中的技術,我剛剛說的也完全是跟瀏覽器相關的。

但是,為什麼我會提到 Nodejs 呢?

我提及它(Nodejs)的原因是它是模塊本地化的,有誰在跑 npm install 的時候看到過 C 編譯出錯?

大部分人的手都應該舉起來了,因為這實在是太常見了,模塊本地化實在是 Node 中的一個大坑。

這東西真的非常愚蠢,甚至讓你想喊出 Bryan Cranston(絕命毒師男主)嘴裡喊的。你可能能從他的脣語裡讀出來,他喊的是 BLAH,他喊得並不是…額你知道的

為什麼這些模塊如此之坑?原因是它們必須在下載時重新編譯,而且必須為每一個體繫結構重新編譯它們。

就拿樹莓派平臺來說,因為在這個平臺上根本不能正常的工作,就會有人在 Github 上面去提issue ,同時也就意味著你會花很長時間在 Github 上去討論這個問題。

他們要麼會為你的平臺編譯一個版本,要不就直接不支持這個平臺。

的確這也是很棘手的,Github 上面的討論的確讓人感到糟糕。但是我很遺憾的告訴你,這個並不支持 Windows 系統。

首先聲明,我很感激hecc(高等教育協調理事會)在 node-gyp 方面所做的研究,他們完成了這是個似乎不可能完成的任務。因此我很尊重他們。

JS 的未來和 Web 多語言開發

但是 WebAssembly 只能在 Node8.0 以上版本正常工作。記住這個8.0版本,為什麼他可以在 Node8.0 以上的版本運行呢?

因為這個版本的 WebAssembly 模塊已經預編譯了,不需要構建。所以這對於任何平臺都是十分便捷,都

可以通過 Node 來運行。所以對於整個架構,都不會再有下載重編譯這個步驟了。

的確是這樣,我已經試過了,你也可以嘗試一下,這真的太棒了。

引用 Laurie Voss 今天早上說的一句話

JS 的未來和 Web 多語言開發

每個人都不看好 node-gyp,但是 WebAssembly 恰恰讓我們做到了。

這是 Nodejs 的里程碑。在不久的將來,當 Node8 不在維護的時候,Node8 以下的版本將不再兼容。

這並不意味著人們不能使用它,比如 Android3.0 版本。

其它

OK,WebAssembly 正在往 serverless 上進擊。例如,我在 CloudFlare 工作,我們有運行著 V8 引擎的雲平臺,所以你可以在 serverless 上運行 WebAssembly,這很酷!

JS 的未來和 Web 多語言開發

我們現在為現場的聽眾提供了一個免費的 serverless 平臺。

的意思是,假設你們中的某些人正在觀看這段視頻或者直播,但是你們沒有這個平臺的會員,然後還想白嫖。不要誤會我的意思哈,我只是也不喜歡付款而已。

如果你掃描這個二維碼,你可以保留一個 workers 的子域,而不是 dev 環境,它包含了 30 個 worker ,每天能處理 10 萬個請求,在每秒內,比我不使用 JS 做運算要稍微多一點。

這個我之後會再展示,它在我們的展位上也有放。但我會等你們都掃完,我再切到下一個 PPT。放二維碼顯然不是因為我不想讓你們看見我。

我想大家基本都掃完了。

JS 的未來和 Web 多語言開發

這次談話的重點是試著擁抱 WebAssembly ,我個人特別喜歡 Rust。

我學到更多關於 Rust 的知識就像我學到新東西一樣。就好像這不是在 13 天內創造出來的。

我沒有瞧不起 JS。它是有史以來最好的語言之一,但它是在13天內完成的,而 Rust 絕對不是在 13 天內完成的。

它絕對是經過深思熟慮的。

WebAssembly 是 JS 所有形式的未來,儘管我希望能向你展示它將創造更好的瀏覽器體驗。它將棄用 node-gyp。

從現在起的五年裡實際上它並沒有這樣做,請不要引用我的話。

但它可能會棄用 node-gyp。你可以引用我的話。

最後一個問題是,如果你現在是招聘經理,我想讓你做一些非常重要的事,那就是僱傭一個和你不同的人。

他們可能與你有所不同,他們可能會相信你的不同之處,他們可能會有所不同,他們的性別認同可能與你僱傭他們的性別不同。

在你告訴我這很難之前,我會讓你去找 LaBeouf 先生談這件事。

JS 的未來和 Web 多語言開發

不難,儘管去做!

有人會以某種方式僱用與你不同的人。

不管怎麼樣,感謝大家的聆聽 ~

好啦,不要慌。雖然看著挺可怕的,但誰不是一點一點學會的,難不成那些技術大牛是編著程出生的?小夥伴們還是要努力學習,努力進取,總有一天你也會成為前端大牛的!

這裡有一份獨家晉升指南:

部分VIP資料:

"

特別說明

這是一個由 simviso 團隊對 JSConf.Asia 中關於 WebAssembly 相關話題進行翻譯的文檔,內容並非直譯,其中有一些是譯者自身的思考。分享者是 Kas Perch,Cloudflare 的一名開發人員。現在,讓我們一起來了解下什麼是 WebAssembly。

一、前言

JS 的未來和 Web 多語言開發

大家好,太棒了。就像他們所說,如果我們搞定了 WebAssembly 技術,那麼就搞定了 JS 的未來和 Web 多語言開發。

正如介紹所言,我叫 Kas Perch,現在是 Cloudflare 公司的一名 Avocado 開發人員。同時,我也很痴迷於機器人編程,並且寫過相關書籍。

我已經寫了兩本使用 JS 給機器人編程的書。我週末也會在 twitch 上直播一些硬件和軟件相關的東西。

我養了兩隻貓,它們是我的最愛。左邊的貓叫 Ace,右邊的叫 Aria。它們現在對我很生氣,因為我已經離開它們三個星期了。

JS 的未來和 Web 多語言開發

我可能再過一個星期才回去,它們是真的很生我的氣。

言歸正傳,你們來到這裡就是為了聽一些關於 WebAssembly 的一些東西

二、什麼是 WebAssembly

這項技術已經有五年了,我們還在維護中,我們冷靜下來思考一下,為什麼直到現在還沒有人指出該如何使用它。因為人們很難做到該如何更容易的去理解它(因為它很抽象),這也是為什麼我們要來談下它到底是什麼。

首先,我想說,它不是一個編程語言(注:WebAssembly 是驅動編程語言的存在,此處就相當於一個獵頭,針對後面這句話),就像你曾經去領英上面招聘員工一樣,你說你需要一個有十年開發經驗的 Node.js 程序員。

這個就像是在說,我是一個 WebAssembly 程序員,就好像如果你不會 WebAssembly 編程,你就不會寫 WebAssembly 程序(就好比如果你不會 Nodejs,你就不會使用 Nodejs 編程)。

其次,WebAssembly 不會取代 JS ,同時它可以讓 JS 駕馭任何事。

JS 並不會沒落,更不會被 WebAssembly 打敗,因為它並不是為了打敗 JS 而設計的。

WebAssembly 恰恰是我們無法去忽視的東西,因為它可以讓我們走得更遠

我希望在接下來二十幾分鍾你們能被我征服,因為 WebAssembly 是未來的發展趨勢。

不好意思,按錯了。

那麼 WebAssembly 到底是什麼呢?

JS 的未來和 Web 多語言開發

它為其他語言提供編譯服務,你可以將其他語言編譯成 WebAssembly,它是一種規範(類似於 jvm 支持的 class 字節碼)和要編譯成的目標文件類型。

這對於 JS 來說是一種能力的增強。WebAssembly 根本就不是想要取代 JS ,而是仍然讓 JS 做它所擅長的領域,同時也能讓 JS 也能做它所不擅長的領域,這就是它要做的事情。

但更重要的是,WebAssembly 表面上很神奇,但卻不僅僅只是表面上神奇,我會在後面解釋這點。

WebAssembly 的目標就是將你用其他語言寫的代碼編譯成 wasm 類型文件。

WebAssembly 已經很好的支持了 Rust 語言,C/C++,GO 和 C# 已經可以用 WebAssembly 編譯。

還有很多語言沒有提到,當然我能想到的主要就這四個,尤其是 Rust, WebAssembly 對它進行了相當多的優化,你有機會可以嘗試一下,這絕對是一個非常酷的編程體驗。

JS 的未來和 Web 多語言開發

那麼這裡,你可能會問:為什麼要用其他語言來寫 Web 程序?你為什麼要這麼做?為什麼你會在這裡放上 Laurie Voss(npm 的作者) 的演講照片,然後你使用其他語言來講這些東西?

主要有兩個理由:A,我想要和 Laurie Voss 進行合照。B,讓大家一起擁抱 WebAssembly。

三、下一個 Ajax

對於瀏覽器來說它就像是下一個 Ajax(就好比是下一個喬布斯)。

在這週末,我已經看到了很多有這樣(驚訝)表情了。

OK,就像下一個喬布斯(這裡是 Ajax),聽起來很酷。

但是我的意思是說 Ajax 真的高度可信並且使客戶端層面應用成為可能,所以說,Ajax 是一個變革,而 WebAssembly 將是下一步的一個變革。

這是我今天早上找到的一張超可愛的寶可夢 GIF,我就想著要把它貼上來。

JS 的未來和 Web 多語言開發

為了跟貼圖保持一致我特意選用了“進化”這個詞,不知道你們注沒注意 GIF 周邊我還寫了字的哈。

這時候你可能想著說,行吧,可能這就是下一個 Ajax,但還是抱著幾分遲疑態度。

這幅畫是我早上在 OneNote 上畫的。

JS 的未來和 Web 多語言開發

我把它稱為 “ancient.png.”

讓我們回過來看這張圖,這上面有 HTML,CSS 和 JS。

比如當你打開社交網頁的時候js就會播放煩人的音樂,服務器會返回所有這些東西,所有的東西都在這裡。

請將你的視線隨著我手指移動,當你點擊一個鏈接的時候,它會返回一個頁面,你一直點擊它就一直會給我們返回一個頁面。

每當你想要從服務器獲取新信息的時候,你就需要手動對瀏覽器進行刷新操作。

JS 的未來和 Web 多語言開發

我將這張圖稱之為 then.png,Ajax 不是一個 button 但勝似 button。

Ajax 請求頁面,然後獲取頁面內容,我們通過發送 Ajax 請求,來避免刷新頁面的操作。

我們通過 Ajax 得到返回的結果,Ajax 結果可能會是另外一個頁面的請求。

基於這個,我們得到了一系列的單頁應用程序。

當我們的服務器提供了Restful 風格的 API 的時候,也提供臨時的 HTML CSS 和 JS 文件。

這才是我要說的,請看我用高亮顏色所標記出的 WebAssembly 的內容,這裡突出了它的工作原理。

JS 的未來和 Web 多語言開發

可以看到頁面請求、返回的頁面結果,在這個過程中 WebAssembly 只是做一些計算而已。

我們依然來看兩個圖中左側的 Browser,然後使用 service worker 作為你的第三方模塊。同樣是在這個Browser中,你可以使用一些 Ajax 請求,同時服務器就類似於圖上的 LOL OK。我可能甚至都不是一個真正的服務器,我只是 serverless 服務器上的一個函數而已。

然後返回你的結果。整個過程簡直不可思議!

OK,相信你現在應該有點感覺了。

四、對 JS 進行增強

能夠在瀏覽器中計算內容,不一定非要用 JS 來實現。

這就是一件大事!相當重要!

那為什麼這很重要?為什麼我們要這麼關注?

我們之所以這麼關心是因為我們對 JS 進行增強。

JS 的未來和 Web 多語言開發

我知道,這個話題你也許聽到過很多次,甚至都已經厭倦了。但是這也是事實,JS 在某些方面的確不擅長。

我們並不需要為了使用 WebAssembly 而重寫整個項目代碼,誰也不想重構整個代碼庫,就像五年前那些包含了單元測試的代碼,我想沒人願意來幹這個事情(想重構舉起你們的手,但是沒有)。

挺好

更少的請求調用意味著更少的延遲,也就意味著我們可以為用戶提供更快的 Web 應用。

高性能一直都是很重要的。這樣的話,我們就無需對服務器進行成千上百萬次的請求。

所以,我們來談談該如何對 JS 進行增強。

我相信在你的工作過程中已經看到過很多次這種表達式(0.1 + 0.2 === 0.3 // false)了吧,其實0.1 + 0.2 = 0.30000000000000004(精度運算),所以 0.1 + 0.2 === 0.3 是 false

JS 的未來和 Web 多語言開發

所以如果你正在做的事情對數字精讀有很高的要求,比如:金融應用、股票交易、貨幣兌換。那麼很顯然,這些並不是 JS 的強項。

你需要對那些運行著不同語言的服務器發送一個 Ajax 請求,服務器會返回給你精確的結果,然後你對返回的結果進行了錯誤的轉換(通過 JS 對返回的 JSON包含的數字類型的字符串進行轉換,出現精讀丟失)。

所以通過 WebAssembly,你就可以在瀏覽器中使用正確的工具來完成這項工作,比如:Rust,C,或者其他浮點數超過32位的語言。

JS 的未來和 Web 多語言開發

其它 JS 不太強的地方還有,JS 的類型強制轉換會有一些負面效應,比如:” “ == 0 為 true。我真的很難去理解它,我可以說他們輸入了一個非零的數字。

得到和預想中不一樣的結果,這個結果對我來講完全是出乎意料的,比如你用 1 和通過選擇器(document.getElementById)獲取的 input 的值相加,結果只是連接字符串。但是你使用 Number函數處理 input 元素的值,那就會進行兩個數字相加,即使後者不是一個真正的數字,可能只是一個 NaN,然後 1+ 9可能也是 NaN。

這下知道我的意思了吧,類型強制轉換在這裡會很棘手。

說到類型,typeof 關鍵字是一個迷。就像圖中最後一條一樣,讓人煩躁了很多年(typeof [] === ‘array’ // false)

如果你之前看過我的演講,你就會知道使用了 WebAssembly 也就意味著使用了正確的工具來完成對應的工作。工欲善其事必先利其器。

WebAssembly 使用正確的工具來完成 Web 上的工作。

我們不需要再通過 JS 來做它不擅長的事情。

這對 Web 和瀏覽器應用程序來說都是一件大事。

但是這將會幹掉 JS。

噢, 我們將會使用 WebAssembly 去寫所有的應用程序,WebAssembly 將會…,不,冷靜,冷靜。開個玩笑,它不會幹掉 JS。

它讓 JS 做它擅長的事情,從而使它變得更好。在 DOM 操作上,React 和其他框架會快得離譜,JS 引擎也使 DOM 操作速度更加快。

我不認為 WebAssembly 會很快打敗 JS 和 DOM 操作。也許在遙遠的將來,它可以做到,但是近期看來並不會實現。

並且 JS 也很擅長於操作 CSS 樣式,WebAssembly 也不會取代 JS 去操作 CSS。

所以,WebAssembly 用於增強 JS,同時你也可以在此基礎上使用 JS,這並不矛盾。

並且 WebAssembly 解決了 JS 所不擅長的,這也減輕了 JS 的負擔。

就好像我和我的對象一樣。他是很討厭洗衣服的,真的,特別討厭。而我又特別討厭做菜,所以他做菜我洗衣服,並且這樣搭配非常完美。

但是現在他還是必須洗自己的衣服,因為我要出差三週,而他只有兩週的衣服穿,所以不得不洗。

就像 Ajax 做的那樣,WebAssembly 通過營造更好的瀏覽器體驗來使互聯網變得更好。

當你想到這些影響時,這更好的瀏覽器體驗簡直令人激動。就像 Jeff Goldblum(美國演員)令人激動那樣。

JS 的未來和 Web 多語言開發

五、舉個例子

讓我們通過這個 Demo 來進一步表達我的意思。

JS 的未來和 Web 多語言開發

這個 Demo 使用了 wasm-imagemagick 技術,如果你之前沒有用過 imagemagick 的話我可以解釋一下:imagemagick 是一個命令行工具,專用於創建和操縱圖片。

它能夠創建GIF動畫,它能夠創建圖片的單元格,它能夠創建分形圖。它是一個非常強大的庫以至於我不想用任何其他語言去重寫它,更不用說 JS。

我們將要以十倍快於 JS 的速度來操縱這些圖片,所以從某種意義上說 JS 本身並不能做到。

它真正強大的地方在於你不用重寫任何代碼就可以通過該工具來完成我們的工作。

讓我們來看看。希望這行得通。

它之前都是好好的所以這次可能就不行了,你知道我意思吧。

好了我攝像頭打開了。我們來選擇一張照片,我要點下面(做鬼臉),照片照出來總是顯得我很蠢,所以我放棄掙扎了。

OK,這些按鈕的意思是……我把它調大一點你們就看得清了我的舌頭和這些按鈕了。

JS 的未來和 Web 多語言開發

我們點右旋,然後在下面你就可以看到右旋的圖片了。這真的真的是很快的了,再左旋一下,你用 CSS 也能快速做到,這好像沒什麼了不起。我們來調個灰度,boom, 灰度,沒有閃屏。我們來加點對比度。去掉對比度呢?去掉對比度了。JS 能這麼快嗎?不可能!

對,這就是我的 Demo,我會在推特上發一下這個 Github 倉庫,這是完全開源的,你想的話可以嘗試一下。

對,這是我的 Demo。

哈謝謝你們

六、關於 Nodejs

但是 Nodejs 呢?等等……關於 Nodejs?

這是瀏覽器的工作,對,這完全是瀏覽器中的技術,我剛剛說的也完全是跟瀏覽器相關的。

但是,為什麼我會提到 Nodejs 呢?

我提及它(Nodejs)的原因是它是模塊本地化的,有誰在跑 npm install 的時候看到過 C 編譯出錯?

大部分人的手都應該舉起來了,因為這實在是太常見了,模塊本地化實在是 Node 中的一個大坑。

這東西真的非常愚蠢,甚至讓你想喊出 Bryan Cranston(絕命毒師男主)嘴裡喊的。你可能能從他的脣語裡讀出來,他喊的是 BLAH,他喊得並不是…額你知道的

為什麼這些模塊如此之坑?原因是它們必須在下載時重新編譯,而且必須為每一個體繫結構重新編譯它們。

就拿樹莓派平臺來說,因為在這個平臺上根本不能正常的工作,就會有人在 Github 上面去提issue ,同時也就意味著你會花很長時間在 Github 上去討論這個問題。

他們要麼會為你的平臺編譯一個版本,要不就直接不支持這個平臺。

的確這也是很棘手的,Github 上面的討論的確讓人感到糟糕。但是我很遺憾的告訴你,這個並不支持 Windows 系統。

首先聲明,我很感激hecc(高等教育協調理事會)在 node-gyp 方面所做的研究,他們完成了這是個似乎不可能完成的任務。因此我很尊重他們。

JS 的未來和 Web 多語言開發

但是 WebAssembly 只能在 Node8.0 以上版本正常工作。記住這個8.0版本,為什麼他可以在 Node8.0 以上的版本運行呢?

因為這個版本的 WebAssembly 模塊已經預編譯了,不需要構建。所以這對於任何平臺都是十分便捷,都

可以通過 Node 來運行。所以對於整個架構,都不會再有下載重編譯這個步驟了。

的確是這樣,我已經試過了,你也可以嘗試一下,這真的太棒了。

引用 Laurie Voss 今天早上說的一句話

JS 的未來和 Web 多語言開發

每個人都不看好 node-gyp,但是 WebAssembly 恰恰讓我們做到了。

這是 Nodejs 的里程碑。在不久的將來,當 Node8 不在維護的時候,Node8 以下的版本將不再兼容。

這並不意味著人們不能使用它,比如 Android3.0 版本。

其它

OK,WebAssembly 正在往 serverless 上進擊。例如,我在 CloudFlare 工作,我們有運行著 V8 引擎的雲平臺,所以你可以在 serverless 上運行 WebAssembly,這很酷!

JS 的未來和 Web 多語言開發

我們現在為現場的聽眾提供了一個免費的 serverless 平臺。

的意思是,假設你們中的某些人正在觀看這段視頻或者直播,但是你們沒有這個平臺的會員,然後還想白嫖。不要誤會我的意思哈,我只是也不喜歡付款而已。

如果你掃描這個二維碼,你可以保留一個 workers 的子域,而不是 dev 環境,它包含了 30 個 worker ,每天能處理 10 萬個請求,在每秒內,比我不使用 JS 做運算要稍微多一點。

這個我之後會再展示,它在我們的展位上也有放。但我會等你們都掃完,我再切到下一個 PPT。放二維碼顯然不是因為我不想讓你們看見我。

我想大家基本都掃完了。

JS 的未來和 Web 多語言開發

這次談話的重點是試著擁抱 WebAssembly ,我個人特別喜歡 Rust。

我學到更多關於 Rust 的知識就像我學到新東西一樣。就好像這不是在 13 天內創造出來的。

我沒有瞧不起 JS。它是有史以來最好的語言之一,但它是在13天內完成的,而 Rust 絕對不是在 13 天內完成的。

它絕對是經過深思熟慮的。

WebAssembly 是 JS 所有形式的未來,儘管我希望能向你展示它將創造更好的瀏覽器體驗。它將棄用 node-gyp。

從現在起的五年裡實際上它並沒有這樣做,請不要引用我的話。

但它可能會棄用 node-gyp。你可以引用我的話。

最後一個問題是,如果你現在是招聘經理,我想讓你做一些非常重要的事,那就是僱傭一個和你不同的人。

他們可能與你有所不同,他們可能會相信你的不同之處,他們可能會有所不同,他們的性別認同可能與你僱傭他們的性別不同。

在你告訴我這很難之前,我會讓你去找 LaBeouf 先生談這件事。

JS 的未來和 Web 多語言開發

不難,儘管去做!

有人會以某種方式僱用與你不同的人。

不管怎麼樣,感謝大家的聆聽 ~

好啦,不要慌。雖然看著挺可怕的,但誰不是一點一點學會的,難不成那些技術大牛是編著程出生的?小夥伴們還是要努力學習,努力進取,總有一天你也會成為前端大牛的!

這裡有一份獨家晉升指南:

部分VIP資料:

JS 的未來和 Web 多語言開發

最後說一下的,也就是以上教程的獲取方式!

領取方法:

還是以往不變的老規矩!

1.評論文章,沒字數限制,一個字都行!然後轉發出去!

2.關注小編,成為小編的粉絲!

3.私信小編:“前端教程”即可!

通過申請後會逐個開通權限,小助手精力有限,手慢無哦

視頻的價值取決於領取後的行動,大家千萬別做收藏黨。和志同道合的人一起深入討論與學習 Web前端技術,也歡迎轉給需要的朋友!

"

相關推薦

推薦中...