Forem: Ayomide Onigbinde

WebAssembly and the frontend: End of JavaScript?

Ayomide Onigbinde — Thu, 10 Dec 2020 14:28:36 +0000

Frontend development is awesome. JavaScript has gotten faster, we can now write code that run in the browser that run on the GPU. But what if we can do more? What if we want to really run backend code in the browser?

Before we go on, let me clarify that WebAssembly is not going to replace JavaScript. As it stands right now, you actually still need JavaScript to access the DOM from WebAssembly because wasm cannot access the DOM directly (at least right now).

What is WebAssembly (briefly)?

WebAssembly is a binary format that essentially lets you compile code and run this compiled code both on the client and the server – well, ANYWHERE really. It bears similarities with the JVM because they're both "RUN ANYWHERE". Please check out my (brief) article on the differences between the JVM and wasm. Also, check this stackoverflow link.

So how does it fit into the frontend

Lets say you have a image compression algorithm you've written in Rust and using it on the server, when you compile it to wasm, it lets you run this same code in the browser thus eliminating need to go through a server while still providing near native speed.

(source: https://blog.logrocket.com)

The implication here is that more powerful code can be run on the client. Not only does it let you run such code in the client, it does so securely too while maintaining near native speed! Wasm apps run in a sandbox – they cannot access another process on the machine so whatever they're doing is restricted to that specific sandbox.

Don't I need to be able to write Go, Rust, C and other systems language before I can do wasm?

WebAssembly is an "official web language" like JavaScript – its now HTML, CSS, JavaScript and WebAssembly.

In my opinion, you don't need to know a backend or systems language to use wasm. All you need is the WebAssembly binary and you can get to work. In the case where you need to debug the wasm code, you can simply use WAT format – WebAssembly Text; a human readable text representation of your wasm file. Just knowing the functions and similar things the wasm binary exposes is also all that is needed. Once you know the function to call and what parameters to pass, you can just go ahead and do your thing.

Sure, it'd be nice to have an idea how the code that was compiled to wasm works but you can do just fine using just the wasm file compiled for you.

Remember, same way you don't necessarily need to understand how the server returns data when you consume an API, same way you don't need to know a systems/backend language to use WebAssembly in the browser.

Are there people using WebAssembly in the browser already?

Sure! There are a few products already using wasm in production in a browser. Figma uses it in production, Google Earth, Squoosh and self plug: me too! This list is not exhaustive, there are more people adopting WebAssembly.

Conclusion

The sky is limit when you can run more performance intensive code in the browser. WebAssembly lets you save more developer time because one code can run anywhere its needed instead of porting to another language that the target platform supports. It guarantees safety too without sacrificing performance. Its a good day to hop on the wasm train 😊🤙🏾

WebAssembly files used by Figma in their web app
(source: brave dev tools; figma)

In my next article, we're going to look at building an app that runs fully in the browser using WebAssembly.

WebAssembly: another JVM?

Ayomide Onigbinde — Wed, 23 Sep 2020 14:18:58 +0000

WebAssembly has been gaining popularity in recent times. It's fast, it's "hip" and my God, C/C++ and Rust developers seem to mention it a lot these days. There are several articles already written for Wasm (as I'll keep calling WebAssembly in this article). Go here for my article on using WebAssembly, Go and React. There is also a Rust port here. The Rust port is up and running at this URL.

Java is a language that needs no introduction. The JVM is simply a virtual machine that takes in Java bytecode and then spit out the machine code of the CPU the code is running on. That way, you can write any language that is supported by the JVM (e.g Scala) and run it on any CPU/platform. This forms the basis of Java's Write Once, Run Anywehere. Enter Wasm.

Wasm basically is a format that allows you compile code you've written in various languages on any hardware/platform in a safe environment.

So how does Wasm differ from the JVM?

Speed. Wasm runs at near native speed (even in the browser).
Security. WebAssembly lets you run code you don't trust. It runs in its own sandbox.
In the frontend, there are JS bindings from your host language. This means you can write your app in a language like Rust. You can manipulate the DOM directly, compile to Wasm and have JS bindings generated for you.
WebAssembly can be loaded "lazily" loaded. What does this mean? You can actually run the WASM code before its been fully dowloaded. The browser can run the WASM as its being downloaded using the WebAssembly.instantiateStreaming() function provided in JavaScript.

Personally, my biggest takeaway from the differences between JVM and WebAssembly is that Wasm is platform-independent and provides near native speed for whatever architecture you're running on all with support for many languages, guaranteed security and the fact that you can stream the Wasm binary in the browser. Another takeaway is the fact that it supports a lot of languages — Rust, Go, AssemblyScript all support Wasm. I think its pretty obvious that Wasm is not just another JVM. WebAssembly is WebAssembly.

Create a WebAssembly app with React and Go

Ayomide Onigbinde — Fri, 06 Sep 2019 01:16:19 +0000

Getting started with WASM, React and Go

WebAssembly is awesome --barely a news, but how can you use it with React and Go? Well, honestly there are materials out there that are good to help to figure this out. But personally, it wasnt a smooth experience. I wanted a straightforward, up-to-date article. For one, I was looking for a solution that used Create-React-App because who wants to mess with Webpack? 🙃🙃

The aim of this short and simple tutorial is to show you how I pieced everything together and have a React based Go program compiled to WebAssembly up and running. I'd assume the following:

You have Go installed (1.11 and above).
Npm/Yarn installed.

So lets get to it.

In this tutorial, we'll enter a value into the input box in react and then use WebAssembly to render this value. Simple and interesting, right?

Clone the repo here. The repo contains the ejected app. I am trying to make this article as brief as possible so I might (unintentionally) miss some things.

In the root, we have main.go that contains the following code:

package main

import (
    "fmt"
    "syscall/js"
)

var c chan bool

// init is called even before main is called. This ensures that as soon as our WebAssembly module is ready in the browser, it runs and prints "Hello, webAssembly!" to the console. It then proceeds to create a new channel. The aim of this channel is to keep our Go app running until we tell it to abort.
func init() {
    fmt.Println("Hello, WebAssembly!")
    c = make(chan bool)
}

func main() {
    // here, we are simply declaring the our function `sayHelloJS` as a global JS function. That means we can call it just like any other JS function.
    js.Global().Set("sayHelloJS", js.FuncOf(SayHello))
    println("Done.. done.. done...")

    // tells the channel we created in init() to "stop".
    <-c
}

// SayHello simply set the textContent of our element based on the value it receives (i.e the value from the input box)
// the element MUST exist else it'd throw an exception
func SayHello(jsV js.Value, inputs []js.Value) interface{} {
    message := inputs[0].String()
    h := js.Global().Get("document").Call("getElementById", "message")
    h.Set("textContent", message)
    return nil
}

Our function sayHello takes two arguments. We're more concerned with the second. What the second does essentially is that it takes an array of js.Value. This is because we can pass as many argument as we want from JavaScript. To get the values, we simply use the index. So, in our case, we want to get the value entered in the input box.

message := inputs[0].String()

Like I said earlier, we use the index of the array to get the value of whatever we want.

h := js.Global().Get("document").Call("getElementById", "message")
h.Set("textContent", message)

the above code is similar to:

let h = document.getElementById("message")
h.textContent = message

So what we're doing is that we're changing the text of our element with the id "message" with the input value.

Run the following to compile the main.go:

GOOS=js GOARCH=wasm go build -o ../client/public/main.wasm

Client side of things

In the App.js, we have this in the componentDidMount():

async componentDidMount() {
    let { instance, module } = await WebAssembly.instantiateStreaming(fetch("main.wasm"), window.go.importObject)
    await window.go.run(instance)
    this.setState({
      mod: module,
      inst: instance
    })
  }

We're instantiating our main.wasm and running the instance. That means we can now go ahead and call our WASM functions in our app. Also, setting the module and instance to state incase we need them later on. Also, you'd notice that we're doing window.go.run(instance). Where did it come from? Well, its already handled in the React app. You'd notice there is a wasmjs folder which contains an init_js file. This and the wasm_exec.js file needed to use our WASM file with JS have been created and bundled with our React App using webpack. So it binds the Go() instance to the global window. Therefore instead of declaring a new instance of Go(), it exists as a window object variable

 handleSubmit = async (e) => {
    e.preventDefault()
    window.sayHelloJS(this.state.message)
  }

and this is us calling our function sayHelloJS that we registered in our Go code earlier! Notice we're accessing as a window object property. This is because we're calling it from React. It's going to be undefined if we called it as sayHelloJS.

<span id="message">
    Ayomide Onigbinde wrote this!!😉...💕 from WebAssembly and Golang
</span>

We have this HTML element. Note that it has an id "message". This element was the one we manipulated in our Go code which we compiled to WebAssembly! So this element must exist else it'd throw an exception. This is what will change into whatever value we enter in the input box! And its WebAssembly (compiled from Go) doing this! 🎉🎉

I tried to explain as best as I could! Please if there's something not clear, comment and we'd figure it out together 😉😉.

Huge props to Aaron for his tutorial and big big thanks to Chris at LogRocket. It was a huuuggeee help! This Dev.to article also helped to get an understanding about React with WASM.