I recently wrote a post about Facebook being a needy sonofabitch. They desperately try to get you there, and once they have you they do all they can to keep you there. It’s like a restaurant that bombards your doorstep with flyers until you finally pay it a visit. Once you go there, they lock the doors from the outside and begin force-feeding you from the buffet.

But ultimately, Facebook is a place you go to. You can decide whether you want to visit the restaurant, or just continue throwing their flyers in the recycling bin alongside the coupon-stuffed weekly circulars and junk mail.

Google is equally needy, but feels a lot more insidious than Facebook.

Over the past few years, I’ve increasingly seen articles with headlines that run something like, “New Feature Coming To the Web”—followed by content which described how Chrome had implemented an experimental new feature. “You’ll be able to use this soon!” has been the promise.

The reality is a bit more complicated. Sometimes, ideas the Chrome team pioneers make their way out to the rest of the browsers and become tools we can all use. Sometimes… they get shelved because none of the other browsers decide to implement them.

Many times, when this latter tack happens, developers grouse about the other browser makers who are “holding the web back.” But there is a fundamental problem in this way of looking at things:

Since starting our work on Test262, the official test suite for the ECMAScript programming language, we’ve seen our fair share of strange tests. For nerds like us, every test has the promise to teach us something new, make us laugh, or bury our head in our hands. But unlike choosing between movies, books, or 18th century shoe makers, I’ve never had trouble picking a favorite JavaScript test.

WebAssembly is fast. You’ve probably heard this. But what is it that makes WebAssembly fast?

In this series, I want to explain to you why WebAssembly is fast.

Wait, so what is WebAssembly?

WebAssembly is a way of taking code written in programming languages other than JavaScript and running that code in the browser. So when people say that WebAssembly is fast, what they are comparing it to is JavaScript.

Now, I don’t want to imply that it’s an either/or situation — that you’re either using WebAssembly or using JavaScript. In fact, we expect that developers will use both WebAssembly and JavaScript in the same application.