Slashdot Mirror
How Converting A C++ Game to JavaScript Gave Us WebAssembly (ieee.org)
Slashdot reader Beeftopia shares "a detailed history of WebAssembly...from one of the developers." IEEE Spectrum reports that "Like a lot of stories about tech innovation, this one started with video games."
[Mozilla's Alon Zakai] wanted to take a game he had helped write in C++ and convert it to JavaScript code that would run well on the Web. This was in 2010, and back then, converting C++ to JavaScript was unthinkable... so he started working to adapt an open-source tool that could translate C++ code into JavaScript automatically. He called his project Emscripten... we were able to formalize the permitted JavaScript patterns, to make the contract between Emscripten and the browser completely clear. We named the resulting subset of JavaScript asm.js... I would optimize the JavaScript engine in Firefox to run the resulting code even faster...
This brings us to the present... Emscripten can take code written in C++ and convert it directly into WebAssembly. And there will be ways in time to run other languages as well, including Rust, Lua, Python, Java, and C#. With WebAssembly, multimillion-line code bases can now load in a few seconds and then run at 80 percent of the speed of native programs. And both load time and execution speed are expected to improve as the browser engines that run the code are made better.
They'd started with a C++ game because "If we could make games run well on the Web, other computationally intensive applications would soon follow."
The article -- by Mozilla software engineer Luke Wagner -- remembers that the name Emscripten was a "a mash-up of 'script' from JavaScript and 'embiggen' from the TV show The Simpsons."
This brings us to the present... Emscripten can take code written in C++ and convert it directly into WebAssembly. And there will be ways in time to run other languages as well, including Rust, Lua, Python, Java, and C#. With WebAssembly, multimillion-line code bases can now load in a few seconds and then run at 80 percent of the speed of native programs. And both load time and execution speed are expected to improve as the browser engines that run the code are made better.
They'd started with a C++ game because "If we could make games run well on the Web, other computationally intensive applications would soon follow."
The article -- by Mozilla software engineer Luke Wagner -- remembers that the name Emscripten was a "a mash-up of 'script' from JavaScript and 'embiggen' from the TV show The Simpsons."
With WebAssembly, multimillion-line code bases can now load in a few seconds and then run at 80 percent of the speed of native programs.
You appear to believe that is a good thing, in a web browser.
if you are halfway competent in C/C++ you can see at a glance what a steaming pile Javascript is. Especially the 2010 version of Javascript.
I don't like C++ for various reasons, but the only language in a good 40 years of programming I've learned to hate is Javascript.
The... Web?
No systemd joke?
Great, that way you'd be able to run Linux!
It's only a matter of time before TypeScript skips JavaScript and goes straight to WebAssembly. When Python and Ruby can cleanly target WebAssembly and the DOM, it's game over for JavaScript. What'll happen is quite simple. The people who are decent and kinda like JavaScript will jump to TypeScript. Everyone else will write code in something like Python or Ruby. In fact, I'll say right now that I expect that Facebook will rewrite React and GraphQL in TypeScript or one of those languages within no more than a few years of WebAssembly being supported in all browsers.
Pottering has stated that systemd’s web browser won’t be ready until mid-2018 at the earliest.
#DeleteChrome
what an achievement
It is. It's ideal for running emulators for projects like the Internet Archive's MS-DOS software library or their console video game collection.
JavaScript only has 6 commands:
create_message_box_subscribe_to_my_newsetter()
create_message_box_take_our_survey()
create_message_box_our_cookie_policy()
create_message_box_allow_us_to_send_notifications()
create_message_box_behind_browser_advertisement()
create_message_box_behind_browser_clickbait()
-- Knowledge is power. -- Francis Bacon
You failed to address the elephant in the room: Javascript is the language of the web browser platform.
I think the idea is that a lot of people who regularly post comments on Slashdot and SoylentNews don't want the web browser to be an application platform. They see the web as documents, not applications. They point out that much is achievable through link navigation, form submission, and CSS, such as a script-free version of the "Fast Good Cheap" 2-of-3 checkbox demo. If they wanted an application more sophisticated than that, they would download its source code, compile it, and install it.
The lack of indication of tone of voice in text makes it unreliable for a reader to distinguish deadpan sarcasm from sincerity.
Until WebAssembly can do that it is rubbish.
Am I alone in thinking that giving CPU-level access to our browser to ad networks, hackers, scammers, governments* from all around the world with no authentication and no accountability whatsoever** is a bad idea? Haven't we seen what happened in the past with Java and ActiveX***? Moreover, back then at least Java ran "safe" high-level bytecode, whereas this thing will give to honest programmers the joy of buffer-smashing into adjacent variables, and to dishonest programmers the power to mine bitcoins at nearly native speeds! And once the next hip web frameworks start relying on this technology, there's no way we'll be able to disable it if we want to access the Internet as it's intended.
* in no particular order of undesirability.
** the same-origin policy helps but is not enough, we can't make a trust decision every time we click on a URL, especially now that browser authors have made it so difficult to even see what a link points to, or even understand whether something is a link in the first place. Also, web developers tend to include large amounts of third-party code that they do not inspect, and if such code comes in binary form even before they minify it, then they won't be able to audit that code even nominally.
*** I'm not adding JavaScript to the list. See? I'm not an old person. I like new things!
It's kind of a hack, but it gets the job done. Basically you have types like float32x, int32x4 etc. There are methods to add and subtract them using non vector code but if the hardware supports them using vector instructions, those vector instructions get substituted for the non vector code.
https://github.com/tc39/ecmasc...
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
I think we have a linux running javascript based 'VM' in the browser since over ten years.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
It runs perfectly fine for me on an old budget laptop. Movement is smooth, with no stuttering or slowdowns. I expected it to be a total flop once I saw the Unity logo.
I can only assume that you're trying to run this on your Kaypro II.
Still, that demo is a pretty stupid choice. There are many more interesting demos that better showcase the capabilities of modern browsers. That this is what they selected tells me more about the website operators than it does about WebAssembly.
Required reading for internet skeptics
Runs fine on my end, though I'd imagine that there are aspects of Unity that would add at least a little overhead to the mix.
If you believe in privacy, and believe you have "nothing to hide" at the same time, you're a goddammed idiot
The word you should have used was "impossible" but even today it's unthinkable. I mean, key-rist, why the hell would anyone want to work in JavaScript? Blech.
I suspect after several years the games, if unmaintained to the latest whiz-bang JS frameworks, will bitrot and newer browsers will cease supporting older javascript feature. I've seen this happen before when JavaScript was younger. And not much has been done to address the interface and feature stability of the language. We'll still be at the whims of the policies set by the top web browsers.
Maybe a little game isn't worth having 20 years later. But there are plenty of cases where old C/C++ code is brought back to life. And where 10, 20 or even 30 year old binaries are successfully ran in an emulator or in a Win95-compatibilty box. We are not likely to see
Back to the original topic, I think something like Emscripten (which I've used to run some C-based GUI libraries in a web browser). is very valuable for the long term use of a project. Writing things in an ISO standardized language that changes slowly every 10 years seems like a better play than an ECMA standardized language that changes significantly every year. I understand that JavaScript is still new and evolving, but we've had it in one form or another for over 20 years. At what point can I write a piece of software for the Web that will last? Perhaps never?
“Common sense is not so common.” — Voltaire
Their frank opinion about JavaScript::::::: "When Mozilla began its games program, a lot of its engineers focused their efforts, naturally enough, on JavaScript performance. It was an intense and exciting time, with people using cutting-edge academic research and an array of optimization techniques from industry. With these, our team was able to speed up JavaScript so it could deliver something close to a native-software experience, the gold standard.......... The problem was that these performance gains weren’t consistent. Sometimes the code ran really fast, but sometimes it didn’t. The design of JavaScript made it difficult to determine when and where the slowdowns were occurring, and it was almost impossible to predict when they’d crop up."