Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Firefox Mozilla The Internet

How Converting A C++ Game to JavaScript Gave Us WebAssembly (ieee.org) 139

Posted by EditorDavid from the turbocharging-the-web dept.
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 discussion has been archived. No new comments can be posted.

How Converting A C++ Game to JavaScript Gave Us WebAssembly More

How Converting A C++ Game to JavaScript Gave Us WebAssembly

Comments Filter:

  • I see the problem. (Score:2, Insightful)

    by Anonymous Coward

    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.

    • Re:I see the problem. (Score:5, Insightful)

      by Gavagai80 ( 1275204 ) on Saturday December 02, 2017 @08:08PM (#55665957) Homepage

      It is a good thing, for a handful of uses, which you might run into once a year. Unfortunately the other 99.99999% of the time it'll be used to create monstrosities which every website will shove down your throat.

  • Sounds like a dumb ass (Score:5, Insightful)

    by Snotnose ( 212196 ) on Saturday December 02, 2017 @07:59PM (#55665907)
    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.

    • Re: (Score:1)

      by Ultra64 ( 318705 )

      You forgot to yell "Get off my lawn!" while waving your cane.

      • Re:Sounds like a dumb ass (Score:5, Funny)

        by Snotnose ( 212196 ) on Saturday December 02, 2017 @09:34PM (#55666251)
        I've got some C++ on a microcontroller that detects kids on my lawn and does the yelling for me. Had I written it in Javascript it would activate twice as often for no good reason, and miss real issues 50% of the time.

        • Until WebAssembly can do that it is rubbish.

          • You can take code with pointers and compile it to WebAssembly

            https://stackoverflow.com/ques... [stackoverflow.com]

            Now you may start shouting "All of this is ungodly! All of you are impure!" upon reading this and chant the operator precedence mantra from The Bible [amazon.com] until you calm down and you'd be totally justified in doing so. Still it works.

            • Pointer arithmetic is adding numbers to pointers. It is why

              int x;...
              myOutput("The Answer is " + x)

              produces a core dump (if you are lucky). It is what makes C/++ what it is today.

              JavaScript is all about pointers, and also has closures, so that is not the issue. It I the unconstrained arithmetic.

              Incidentally, 30 years ago Lisp machines used a Lisp-ish assembler that looked a bit like this.

        • Re: (Score:1)

          by Anonymous Coward

          But it's so easy with Javascript if you use jQuery.

          $('kids').on('myLawn').yell("Get off!")

          • Re: (Score:1)

            by Anonymous Coward

            argh, come on man, CALLBACKS!
            var kids_on_lawn=function(o,c){
            if(o.onLawn===true){
            c(null,'GET OFF MY LAWN');
            }else{ c(null,true); }
            };

            you can also do it asynchronously to take advantage of modern multi core CPU's

            var yell=function(o,c){ alert('get off my lawn '+o.name); if(c){c(null,true);}else{return true;} };
            var kids=['andy','jane','tod'];
            var operations=[];
            kids.forEach(function(name){ operations.push(async.apply(yell,{name:name})); });
            async.parallel(operations,function(err,res){}

          • surely
            $(""#my street" house[lawn]").on("change", ".kids", function() { yell ("get off my lawn") ) });

            (so that's in the area of my street identified, the lawn attribute as part of the house element has an event handler attached that looks for changes to it from items of class "kids" and calls a function to do some yelling. Frankly, its starting to make perl look sane.

            and the whole thing has to be placed well away from the lawn, in order to use security measures like content security policy that prevents inli

        • But it would yell in a very deep monster voice!

    • So what's up next . . . ? Erlang . . . ? There's still probably a pretty big pile of FOTRAN waiting around to be WebAssembled.

      Hey, and what about all that IBM 360 mainframe code that's been running since the 60's . . . ? Although, IBM probably has that code wrapped up in some legal shackles, so you can't do anything with it, except run it on a newer mainframe.

      Maybe we could start WebAssembling JavaScript code . . . ?

    • Re: (Score:2, Interesting)

      by Anonymous Coward

      This "dumb ass" basically did what Google's NaCl engineers couldn't do, and helped find an agreeable migration path for web browsers to alter their existing VMs to support other languages. Thanks to him, contrarian fogeys may finally be able to shut the fuck up about JS in a few years. And I consider that a MAJOR win for everyone's sanity.

      • Re: (Score:1)

        by epyT-R ( 613989 )

        no. javascript is still a piece of shit and the concept of the scriptable browser continues to be a security nightmare. The only thing web 'assembly' does is make the malware/bitcoin miner run faster for the attacker.

    • Re:Sounds like a dumb ass (Score:4, Interesting)

      by Anonymous Coward on Saturday December 02, 2017 @08:53PM (#55666119)

      Wow, modern /.ers really like to dump on people doing fun projects, never mind completely missing the point of the article. Did you even read TFS before making up your knee-jerk response?

      • It's all fun and games until someone gets hurt. If someone had done this and just showed it off on their blog it would be a "fun project", but as it stands it has affected us all, so we have every right to criticize it if we don't like the impact it is having.

    • Woosh

      Let's ignore software distribution, access rights to your own computer (if this is a school or work PC), phones, tablets, other platforms, etc.

      If C++ was all in why don't we see these win32 apps on Linux or MacOSX if it was so easy and portable?

    • I couldn't disagree more. Javascript is an excellent language, elegant and simple, and a joy to write code in. Building UIs in HTML and CSS is a bit of a pain, and websites that use excessive javascript where none might be necessary are certainly annoying, but neither of those things are anything to do with the language itself.

      It's quite different to C++ obviously, but differences in languages encourage you to think differently about problems, which is normally a good thing. WebAssembly, on the other hand,

  • And this is how JavaScript dies (Score:5, Insightful)

    by DeplorableCodeMonkey ( 4828467 ) on Saturday December 02, 2017 @08:29PM (#55666047)

    And there will be ways in time to run other languages as well, including Rust, Lua, Python, Java, and C#

    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.

    • Pray pray pray.

      I think you're wrong.

      pray pray pray pray pray pray

      Javescript/Ecmascript (giving it a real name, a spec, and a couple books doesn't make it better) really needs to die.
    • There's no need for that. You can write it in any version of javascript you want and transpile it to any other version when you deploy.

  • How hard can this be? (Score:5, Funny)

    by Blackeneth ( 210087 ) on Saturday December 02, 2017 @09:45PM (#55666283)

    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()

  • What could possibly go wrong? (Score:5, Insightful)

    by peppepz ( 1311345 ) on Sunday December 03, 2017 @03:29AM (#55667041)
    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!

    • Re:What could possibly go wrong? (Score:4, Insightful)

      by roca ( 43122 ) on Sunday December 03, 2017 @05:58AM (#55667259) Homepage

      WebAssembly programs have access to exactly the same set of APIs that JS programs do. They just run some things faster. There is no change in security (except slightly more attack surface in the form of the WebAssembly compiler, and even that's minimized since browser WebAssembly implementations reuse existing JS compiler backends).

      WebAssembly is no more obfuscated than minified Javascript.

      • But JavaScript programs cannot smash a buffer and write into another variable, as is required by the C memory model, and JavaScript libraries are not distributed in minified form (before development).

    • 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?

      Nope, you are just one of many people. The bad news is that this outcome was inevitable but the good news is that this isn't the final outcome. After a drawn out tug-of-war, a new incarnation of HTML will come to being and it will have limited scripted CSS events that cannot be abused. Ads as we know them will cease to exist and will instead be replaced by a crediting system which will effectively pay sites for content based on various metrics. Credit can be purchased or earned through various means (e.

    • Re: (Score:1)

      by Ace17 ( 3804065 )
      I think the comparison is unfair ; Javascript/asmjs/WASM can't address the host memory the way an ActiveX component could.
      It's easy for an ActiveX component to crash almost any host, simply access a NULL pointer from your code. Doing this from a Javascript/asmjs/WASM program is several orders of magnitude harder, and generally needs to be specially tailored for one specific version of one specific browser.
      • Java and ActionScript couldn't access the host memory, too, but that didn't prevent the Java plugin and Flash from becoming the preferred carriers for browser malware. And those ran type- and memory- safe languages, not C. In order to reach an awful lot of people, an exploit needn't work on every machine, it's enough for it to target the most commonly used platform. Given that the browser landscape has been converging towards a monoculture lately, this could become even easier than it was in the past.

        • Re: (Score:1)

          by Ace17 ( 3804065 )
          What you say makes sense ; but then, the issue comes from the browser monoculture (which allows exploit scaling). Or from the precompiled plugin monoculture, which applies to Java and Flash, who were only distributed as precompiled binaries.

          Exploits as well exist in almost any code that parses complex data coming from outside (loaders for PNG, JPG, HTML, WEBM...) ... why make a special case for WASM?

  • 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... [github.com]

    • Re: (Score:2)

      by abies ( 607076 )

      Is it implemented anywhere? From what I was able to quickly find, it is an _idea_ that somebody in future might be bothered by replacing it by true vector instructions, but nobody yet implemented it, so currently it will always fallback to polyfill. It would be great if you could point to changeset which implements it in natvely in one of major browsers.

      • They're working on it it Chromium

        https://bugs.chromium.org/p/v8... [chromium.org]

        However this page

        https://peterjensen.github.io/... [github.io]

        Complains that SIMD isn't implemented in Chrome 62, and unfortunately it's not implemented in Firefox 57 either.

        So the answer is probably no, not yet.

        Last time I used SIMD I used the Intel intrinsics in C++. Which are OK, but Visual Studio's C compiler didn't do a particularly good job at generating efficient assembler. Mind you, a vectorizable algorithm will still run faster using the intrins

  • 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

  • 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

Slashdot Top Deals

If you aren't rich you should always look useful. -- Louis-Ferdinand Celine

Close