Slashdot Mirror
WebAssembly and the Future of JavaScript
Nerval's Lobster writes: WebAssembly is the next stage in the evolution of client-side scripting. In theory, it will improve on JavaScript's speed. That's not to say that JavaScript is a slowpoke: Incremental speed improvements have included the rollout of asm.js (an optimized subset) in 2013. But WebAssembly—while not a replacement for JavaScript—is intended as a "cure" for a variety of issues where JavaScript isn't always a perfect fit, including video editing, encryption, peer-to-peer, and more. (Here's a full list of the Web applications that WebAssembly could maybe improve.) If WebAssembly is not there to replace JavaScript but to complement it, the key to the integration rests with the DOM and Garbage Collected Objects such as JavaScript strings, functions (as callable closures), Typed Arrays and Typed objects. The bigger question is, will WebAssembly actually become something big, or is it ultimately doomed to suffer the fate of other hyped JavaScript-related platforms such as Dart (a Google-only venture), which attracted buzz ahead of a Minimum Viable Product release, only to quickly fade away afterward?
You can write asm.js by hand, no so sure about WebAssembly, although there could be rare corner cases where this is warranted.
But in almost all cases this is not the expected deployment scenario. Rather, you'll write your web app in one of many different high-level languages, and it will get compiled to WebAssembly. Interestingly enough, one of these languages is C++, which has a vastly different thread and memory model compared to JavaScript. This has always been a big stumbling block as there is existing C++ code that people would like to run in browsers, but up to now there was no good solution that works across browsers.
The roadmap suggests that JavaScript will retain its robust memory and thread model, but gain enough features to support the less robust but higher-performant model used by C++. We truly live in interesting times.
This will also address the problem that JavaScript could never effectively take advantage of multiple cores, but CPUs tend to add more performance by adding cores rather than by improving single-thread throughput.
It's time to rework the web presentation and GUI (non) standards. There are too many layers in the current stack, and it relies on fat clients where large GUI libraries and GUI-related code have to be potentially downloaded for every site. It's very poor factoring of tools, libraries, and bandwidth. The bulk of GUI libraries should be part of the browser.
I suggest we start over with 2 new standards: one for a practical work-oriented CRUD & down-to-business browser (or browser mode); and one "eye-candy" browser (or browser mode) for store-fronts, visually gimmicky pages, style fads, and games.
New markup languages with common GUI idioms built in would be designed, reducing the amount of custom client-side code and client-side GUI's libraries needed or downloaded.
The eye-candy standard would be allowed to change faster. If your toys crash, it matters less than if your bank forms crash. Think of it kind of like an open-source Flash competitor.
There would be some overlap between the practical browser standard and the eye-candy standard where appropriate, but we don't want to hold one back to cater to the other.
CRUD-oriented GUI idioms mostly settled by the late 1980's and don't need to be redone every 3 years. By separating eye-candy from practical UI standards, the practical side doesn't have to be bumped around by web/style fads, and the styly side doesn't have to worry about crashing real work.
Call this new standards kit "The Mullet": Business in the front, party in the back. Well, actually it's the reverse for most sites: Party in the front (main page is the attention-getter) and business the back: the details once you subscribed and start doing your stuff. Thus, "Tellum", mullet in reverse.
Forget the job security of the current arcane stack: let's feel the joy of being altruistic, and blow it up and do it right. Let's build Tellum! We'll put half us of out of work, but at least feel the joy of refactoring the web world. (Bots & H1B's will replace us all soon anyhow.)
Table-ized A.I.