back to article What is WebAssembly? And can you really compile C/C++ to it? And it'll run in browsers? Allow us to explain in this gentle introduction

Like us, you may have heard a lot recently about WebAssembly. Today, freelance software engineer Ben James walks us through its creation, its current state, and the role it will play in the future of cross-platform development. The beginnings of the web To understand the need for WebAssembly, let’s go back to the 1990s. …

  1. Anonymous Coward
    Anonymous Coward

    Just another VM...

    Another reinvention of the wheel, and the user experience which was made miserable by clueless incoherent web UIs will become even messier. And good luck with code downloaded each time having full access to local resources - good only to ensure users can't escape subscriptions models.

    Anyway it's ironic that software languages always follow the workflow "interpreted -> p-compiled -> natively compiled".... in a few years someone will start again to promote natively compiled code again...

    1. Blazde Silver badge

      Re: Just another VM...

      I'll take another VM if it comes without automatic garbage collection. It's over 20 years late but no less welcome.

  2. Anonymous Coward
    Anonymous Coward

    Runs outside the browser

    Sounds like an attack vector to this cynical old git.

    1. Anonymous Coward
      FAIL

      Re: Runs outside the browser

      Absolutely, from another cynical old git.

      Flash, javascript, webassembly, and others have promoted this idea and they've all become security nightmares. The sad fact is that sandboxes can be broken and these sort of applications can get into your system to do nefarious things. Furthermore, even if the browser warns you the vast majority of users will just click the shiny button in search of the app's promised benefits.

      The only good thing to be said about webassemby is it doesn't promise ease of code creation, unlike El Reg's recent article on Electron, so you're probably only going to be compromised by professionals rather than script kiddies.

      1. Anonymous Coward
        Anonymous Coward

        Re: Runs outside the browser

        One of my greatest pleasures on El Reg was having someone reply, to one of my comments, that virtualisation meant that my security concerns were misplaced just a couple of days before break out exploits started to be reported.

    2. DrXym

      Re: Runs outside the browser

      It's no more an attack vector than Javascript when it "runs outside the browser", e.g. in NodeJS. Or any other language for that matter.

      1. ibmalone

        Re: Runs outside the browser

        Yes, it's a red herring, the existence of a run-time separate to the browser is not an attack vector. If you've won the ability to start arbitrary separate programs then you've already broken through security.

    3. Robert Helpmann??
      Childcatcher

      Re: Runs outside the browser

      I would even go so far posit Cross Platform = Greater Attack Surface.

      Caveat: It's Monday and I am dealing with a worse-than-normal event today, so this may be coloring my outlook a bit.

      1. teknopaul

        Re: Runs outside the browser

        Can any grey beard name _one_ attack vector of wasm code you write running outside of a browser that is not significantly less of a risk than _any_ other mechanism for running code you have in 2020?

        I cant think of one. Perhaps its "new" therefor it has to be evil. Old people are more resistant to new than young people and actually prefer to shoot themselves in the foot a few times before trying out these new fangled guns with saftey catches, when they do convert grumble about how fiddly the catches are.

        In this case I dont think there _is_ a downside. Except its newness. Granpa, you can still write wasm in C of you want to make life hard for yourself.

        All code has bug potential but does have _more_ bug potential?

        1. Charles 9

          Re: Runs outside the browser

          "Can any grey beard name _one_ attack vector of wasm code you write running outside of a browser that is not significantly less of a risk than _any_ other mechanism for running code you have in 2020?"

          Yes, actually: the same attack vectors that existed before. If you're going to do anything new, why not make it have fewer potential vulnerabilities? And if you say that's the price of admission, I contend the price is too high and a new approach is needed: Joe Stupid be damned.

          1. ibmalone

            Re: Runs outside the browser

            I feel people are confusing two things here. Code running in a browser, and having a separate runtime that will let you run code without a browser is not an additional vulnerability. Got an exploit that can break containment in the browser and let you run something arbitrary? Yes, it could run WASM, or something compiled in C++ or .net or Python, hey your payload could be a different browser and use that to run some malicious javascript instead.

            It's not really up to a language to enforce that kind of security, if you really want you can have an OS that only allows signed code to run instead.

            If you're talking about making a language more robust (along Rust lines) that's good, but so long as it can make system calls then security is ultimately up to the OS. And the available interfaces for something running in a browser are different to those available to the same language on an OS-hosted runtime.

  3. john.jones.name
    Go

    security security security

    choose one...

    they are going to end up fighting about path formats the same way libc implementations have...

    call me when they figure out how to load resources via HTTPS with DNSSEC and a SRI hash

  4. A.P. Veening Silver badge

    Is this another case of "compile once, debug everywhere"?

  5. Lee D Silver badge

    Dummies guide:

    What is WebAssembly?

    Javascript. Or thereabouts.

    And can you really compile C/C++ to it?

    Yes. Same as Javascript. It's just a "virtual machine" / "state engine" in effect. Have been able to do this for years, this is just slightly more standardised than asmjs etc.

    And it'll run in browsers?

    Yes. In the browser security DOM. So when you "open file", it has to be preloaded into the browser by a specific action, you can't access the hard drive or download stuff willy-nilly, or anything stupid. You can't talk out on arbitrary network ports (but you can set up a WebSockets server on your end if you wish to "talk" to the same server as the code was downloaded from over HTTP/HTTPS). Audio works (subject to browser control), video and GL works, keyboard input, etc. work. You can do everything that a normal website can do, and everything else is emulated. Libraries like SDL have supported it for years (so you can convert SDL games to the web relatively easily).

    If you want to have a play, download Emscripten, and use it to compile some C code and see what happens. Everything from Hello World to full OpenGL games can work if you know what you're doing and cut out the stuff you're not allowed to do (e.g. convert networking code to use Websockets). You might even want to look at websockify, which can turn a normal program into a web-socked version (e.g. run Client in the browser, via WebAssembly, communicating with Server at your end running websockify... the two will talk as if they were connected via normal networking, but it will all go over secure Websockets).

    Honestly, try it. It's fun if you're a coder to see 20-year-old SDL C99 code load up in a browser and run as fast as you remember it.

    1. martinusher Silver badge

      Re: Dummies guide:

      I can guarantee that none of the 'C' code I wrote 20 years ago would run in a web assembler environment. That's because the code was designed for jobs that live under a user environment There's also the vague definition of 'user' --- not everything using a computer is typing at a keyboard or manipulating a GUI.

      1. Lee D Silver badge

        Re: Dummies guide:

        Emscripten literally has a console - and can feed into either a separate frame on the HTML page, or into the browser's console itself.

        printf() and scanf() work as expected.

        The only thing that wouldn't work at all would be in-line assembly.

        Maybe play about with it before you comment?

        1. Dagg Silver badge

          Re: Dummies guide:

          Maybe play about with it before you comment?

          So it will support all of my MFC UI code, my ProC Oracle database access code and other such UI and DAL interfaces?

          Over the last 30 years very little of the C/C++ code I have written has been 'pure', for it to work under WebAssembly it would have to have the UI and the DAL rewritten.

  6. theOtherJT Silver badge

    WSAI sounds like something that needs to be VERY off by default.

    I want very copious details on exactly how the following is prevented in this model:

    1: Visit webpage.

    2: WSAI code gets it's hooks straight into your filesystem.

    3: You're totally screwed.

    We could go on with:

    4: WSAI gets direct access to your network device and starts probing for known vulnerabilities around the local area network thus allowing you to infect machines with god knows what without even having a traceable point of entry, since the malicious code simply vanishes when the browser on the first machine is closed.

    From a first glance this sounds like an absolute security nightmare.

    1. DrXym

      Re: WSAI sounds like something that needs to be VERY off by default.

      Sure thing. 2: doesn't happen.

      1. Anonymous Coward
        Anonymous Coward

        Re: WSAI sounds like something that needs to be VERY off by default.

        I'm sure Spectre, Rowhammer and so on were also impossible till they weren't.

        1. DrXym

          Re: WSAI sounds like something that needs to be VERY off by default.

          Wait so you think that because a previous exploit happened (and was rapidly mitigated against) that implies wasm (or any other technology) is broken by design? That's just odd logic quite frankly.

          1. Charles 9

            Re: WSAI sounds like something that needs to be VERY off by default.

            Nope, it makes a lot of sense. It's called DTA Mode, because we're MUCH more likely to screw it up, by accident or otherwise.

    2. ibmalone

      Re: WSAI sounds like something that needs to be VERY off by default.

      Javascript is already a thing, as is Turing-completeness. 2 and 4. require access to corresponding interfaces, if the VM doesn't provide those then it can't be done, except for attacks that attempt to exploit vulnerabilities in the VM or underlying platform to break out, but you can do that with plain HTML too.

      1. Charles 9

        Re: WSAI sounds like something that needs to be VERY off by default.

        You can't exploit a VM that isn't there, and with VMs, Red Pills are all the rage these days. The question should REALLY be, "Do we REALLY need this?" To reduce the chance of an exploit, reducing the surface area helps.

        1. ibmalone

          Re: WSAI sounds like something that needs to be VERY off by default.

          But the VM is already there. It's the Javascript VM that's built into most browsers[1], and if you're going to complain about that, then sorry, that ship sailed over a decade ago. Unless you are running it standalone, but if you're running standalone then presumably you actually meant to run that program, and caviling about being able to do so on the grounds of browser security is irrelevant.

          [1] Incidentally, this is the reason this has a better chance than silverlight or Java applets, it's built on a technology that's already widespread, rather than a new technology fighting for its place.

          1. Charles 9

            Re: WSAI sounds like something that needs to be VERY off by default.

            Sorry my butt! No one knew that ship was full of poison. Call the ship back to port before it sinks and pollutes all our water! I'd much rather such things be either standalone apps or thin clients presented by protocols such as VNC. It's the simplest way to make most of the Internet much safer and more secure. This is one time we MUST stop stupid before he takes the rest of us with them.

  7. Anonymous Coward
    Anonymous Coward

    Heard all these promises before.. about 25 years ago...

    Above is pretty much all the same "advantages" that were trotted out when the first Java plugin was rolled out for Netscape Navigator. Never worked. For the same reasons Web Assembly wont either.

    Web browsers are for browsing data. Standalone applications are for creating and editing data. Low complexity content creation and editing tools can be cobbled together inside a web browser. Been doing it for 25 years. If you want a heavy duty content creation / editing application which is were performance becomes important you will end up writing a stand alone application. One way or another. Trying to write it in a web browser just wastes man years of dev time.

    Because you see, the thing about web browsers is that they are designed from the ground up to browse. Not support heavy duty content creation / editing applications. If they were their architecture would be completely different. So if you need the functionality of a heavy duty application you still do in C/C++ with a cross platform library like QT. Or roll your own. Which is how we have done it for the last 30 / 35 years. Aint nothing new under the sun. Want it small / fast and stable then do it the old fashioned way. Want it slow, huge cumbersome and buggy, then go ahead and try and write it to run in a browser environment.

    You do know you can mix and match by sticking a Webkit type view inside a standalone application window. Where you can do webby stuff to your hearts content. Leaving all the heavy lifting to the real code written in C/C++.

    I chuckled at the mention of Autocad. Remembering the great R13 fiasco. Another example of someone buying into an inappropriate technology that those of us who had been at the work-face for years knew was inappropriate. Some people just got to learn the hard way. All over again.

    1. chronicdashedgehog

      Re: Heard all these promises before.. about 25 years ago...

      Yawn

    2. JDX Gold badge

      Re: Heard all these promises before.. about 25 years ago...

      Browsers WERE designed from the ground up to browse. Then the people who make browsers (well mainly Google but others followed) decided to prioritise all the other stuff... WebGL, HTML5, Canvas, etc. All designed so you don't have to hack HTML to do such application-ary patterns.

      The idea that your browser is only able/designed for browsing HTML/CSS is really only showing that you are out of date.

      Comparing Java plugins from decades ago is really not a valid comparison either.

      >>Some people just got to learn the hard way. All over again.

      And some people learn something once and refuse to ever accept anything else.

      1. Martin-73 Silver badge

        Re: Heard all these promises before.. about 25 years ago...

        If a browser being for browsing makes one out of date, get the hell off my lawn

        1. JDX Gold badge

          Re: Heard all these promises before.. about 25 years ago...

          It is for browsing but that is not all it's for. I doubt anyone puts much work into that aspect because it's basically been solved for some years. Sure work continues on CSS but HTML5 and JS and all these APIs like WebGL are really focused on interactivity and rich content.

          Even basic stuff like streaming video via the browser is totally apart from "browsing" it is using the browser in a totally different way than originally designed.

          You can put your fingers in your ears and run NoScript if you so choose but that doesn't change the fact that the people who make the browsers disagree, and so do the vast majority of those using them.

          1. Charles 9

            Re: Heard all these promises before.. about 25 years ago...

            Just because it's popular doesn't mean it's right. Shoe x-rays? Thalidomide? Just remember the amygdala hijack: humans can be suckered easily by appealing to their emotions, and ad men have become masters of this.

      2. Anonymous Coward
        Anonymous Coward

        Re: Heard all these promises before.. about 25 years ago...

        Some of us have actually written web browsers. In C/C++. So are talking from experience. You know, taking Webkit code and libraries like, I go all the way back to the Mosaic era so I have seen a lot of them, and rolling our own custom browsers. Even browsers for running custom VM based JS application environment stacks with incremental compilers. Or completely locked down browsers for high security browsers. (Hint, you thave to turn off and shutdown all those gee whizzy features added in the last 15 /20 years). So yes, some of us do actually know the complete plumbing involved all the way down to the bare iron. By bare iron I mean JS op native codegens.

        So you might think its OK to have a memory footprint of 100MB to 300MB per *page* that you get from the current generation of browsers but to people like me, who have been dealing with rendering HTML since 1994 and executing JS since '1995 it just shows the most amazing level of technical incompetence.

        And you want to build a stable, efficient and response large feature set application on top of that pile of excreta? Good luck with that. Because after a few years it will be people like me who will be digging you out of a hole and rewrite it in a proper real heavy duty language.

        Us old timers are never out of date,. We just dont fall for every software fad that comes along. Because we have seen many many fads come and go over the years. Standards schmandards. Read about the debacle that was SGML 1.0, or even better X500, to see why most standards, W3C/IETF, ISO, RFC etc etc never amount to anything. Every now and then something novel and useful does come along. And us old timers jump on it pretty quickly. But they are very few and far between. And this aint one of them.

        .

        1. teknopaul

          Re: Heard all these promises before.. about 25 years ago...

          "And you want to build a stable, efficient and response large feature set application on top of that pile of excreta? Good luck with that. "

          Do you think google and facebook could do with a rewrite in C++?

          I would guess most apps are webapps and would not benefit from C++ rewites.

          However a fair few will benefit from running parts as wasm.

    3. Bruce Ordway

      Re: Heard all these promises before.. about 25 years ago...

      >> AutoCad....the great R13

      Yeah, what a beast.

      Of course I'm biased, having never really liked any version of AutoCad. Much prefer SolidWorks these days and before that, was a fan of Cadkey.

      As for WebAssembly, my attitude remains "wait & see". I have not seen any applications running in the browser that would compel me to show more interest yet. When/if I ever do...?

      1. JDX Gold badge

        Re: Heard all these promises before.. about 25 years ago...

        >As for WebAssembly, my attitude remains "wait & see". I have not seen any applications running in the browser that would compel me to show more interest yet. When/if I ever do...?

        I think this is reasonable. I've worked in this area (though my background is much more traditional app-dev and server-dev) and what CAN be done in the browser these days is really astonishing. However that still doesn't mean the browser is the BEST way. As a nerd it's really interesting just to play with but there are substantial hurdles, in our experience more related to content delivery since offline storage is VERY limited.

      2. Anonymous Coward
        Anonymous Coward

        Re: Heard all these promises before.. about 25 years ago...

        The story of R13 is pretty simple. New head honcho with little understanding of exiting codebase but big cutting-edge ideas decides to throw it all out and rewrite it in MFC. I am not joking, MFC. He also decides to throw out the existing really good C/C++ compiler from Watcom and replace it with the very buggy C/C++ compiler from Microsoft. The one that still had the serious linker bugs. And codegen bugs. And all the other bugs too. Now admittedly the existing Autocad codebase was a bit squirrelly but it did work. And new feature could be adding without too many sleepless nights.

        A complete fiasco does not even come close to describing the R13 dev cycle. After truly immense resources were thrown at the problem R14 staggered out the door and sort of worked. It was about this time that Parametric came out of nowhere and almost wiped them out. But PTC imploded because of self inflicted problems and ADSK survived to ship another day. By the skin of their teeth.

      3. teknopaul

        Re: Heard all these promises before.. about 25 years ago...

        How will you know if an app is running wasm?

    4. katrinab Silver badge
      Flame

      Re: Heard all these promises before.. about 25 years ago...

      Well I can now run Windows 95 in my browser at almost the same speed as I could natively on the 25 year old computer I first installed it on, so we are making some progress.

  8. Anonymous Coward
    Happy

    Source code

    Consequently, executing WebAssembly code is much easier for the browser than executing JavaScript, since the translation distance from source code to machine code is greatly reduced.

    I enjoyed the article, but isn't this argument a bit like saying that it is better to travel from California to New York via Florida, because the journey from Florida to New York isn't so far.

    If WebAssembly is a low-level language, then coding directly in it will result in poor programmer productivity. So WebAssembly isn't typically going to be the source code, the source code is the high level language used instead of JavaScript that is compiled to WebAssembly, which in turn is converted to machine code instructions.

    1. swissrobin

      Re: Source code

      Js has the problem that the language is very unruly. Optimising js by JIT compilation is challenging as a result. If you write your application in C/C++ or Rust then the compiler knows very much what your source code means and can do much better optimisations.

      Then the browser doesn't need to contain a JIT for webasm because it can know exactly what each opcode means at browser compile time and so can be optimised at that stage.

      At least that's what I understood the article to mean.

    2. DrBed
      Facepalm

      Re: Source code

      > "If WebAssembly is a low-level language, then coding directly in it will result in poor programmer productivity. So WebAssembly isn't typically going to be the source code"

      OMFG you have clearly written in article: "There’s a binary format for distribution (.wasm), as well as a human-readable text format (.wat). The .wat and .wasm formats represent exactly the same thing." - heck, you have a screenshot proof of WasmExplorer!

    3. Anonymous Coward
      Anonymous Coward

      Re: Source code

      I've had similar thoughts, but I think the point is that the code that actually ends up running on the CPU ain't so very different to that if it were compiled natively. And that given that WebAssembly can be assembled as it's downloaded from the web server, the time taken to do that is hidden from the user (assuming the network is slower than the assembler).

      The thing that concerns me more is that it's just another step on the way to turning web browsers into operating systems, but OSes that are not as flexible to the end user. Want to open "files" created in one website with a webapp from another? Well that can be prohibitted. For companies like Autodesk this is good; sure you can create and edit content within the web version of Autocad, but they can then stop you exporting that to another CAD package because your data lives in their cloud, and they may not give you an export mechanism. I hasten to add that I don't know if Autodesk does that, just using that as an example where previously taken-for-granted interoperability can be taken away.

      The other issue with Browsers becoming OSes is that, what is there to guarantee that they're "correct"? Not a lot. All this new stuff is simply creating a vast pool of potential flaws that have, over the decades, gradually been worked out of OSes. And what's the betting that CPU manufacturers start adding WASM execution cores to their chips so that browsers don't have to bother themselves? Then we're back to square one, aren't we?

      1. DrBed

        Re: Source code

        So much FUD here.

        1) swissrobin is talking primarly about complexity - non-productivity of Wasm coding. Then he concluded (wrong) about need of "high-level languages" LOL...

        Please, just take a look at https://mbebenita.github.io/WasmExplorer/

        Pick e.g. "testFunction" from C/C++ "EXAMPLES" on menu, left. Now check it.

        According to swissrobin: C/C++ are so-high-level languages? "Wat" is less-productive because it's so-much-less-readable then JS (btw you can code for Wasm in JS too)? What is e.g. Forth then: ultra-high-level or ultra-low-level language? Btw, did anyone see 6502/Z80 ASM/MC (and it is 8-bit!)? Please, check it and compare to .wat/.wasm is it more/less complex.

        NOW you're concerned about "Browsers becoming OSes ... what is there to guarantee that they're "correct"" - but what is your garantee that OSes are correct right now (whatever "correctness" means)?

        > "CPU manufacturers start adding WASM execution cores to their chips so that browsers don't have to bother themselves? Then we're back to square one, aren't we?" - You're oversimplifying; this is philosophical, rethoric question. Yes, at that time browsers (as we know) will be useless middle step, because browsers will become OSes (> Chrome OS). Now spot the difference: CPUs asm will be multi-compatible through the web-asm. Now you just have to turn-off the humanity (as useless middle step) and you are at square zero. ;)

    4. teknopaul

      Re: Source code

      You travel analogy is a bit strange . If you work in New York its better to live close to New York rather than commute from California.

      You dont have to go back to California until you change the code.

  9. Christian Berger

    Of course it completely ignores the main problem of any program code in the browser...

    ... that it's a gigantic security nightmare. Even if your sandbox is somehow "secure" it still can be used to suck your battery empty or mine $crypocurrency without your consent.

    Then again the need for a platform independent "bytecode" for programs might have existed in the 1990s, but today we have moved on to distributing software in source form. Why turn back the time to where software was distributed in opaque binary files you had to disassemble in order to adapt to your needs?

    1. JDX Gold badge

      Re: Of course it completely ignores the main problem of any program code in the browser...

      I fail to see how this argument is any different from JS. That can suck your battery too.

      1. Charles 9

        Re: Of course it completely ignores the main problem of any program code in the browser...

        There IS no difference. The real question should be, "Do we REALLY need ANY of this?" If these people really want to stop fapping about cross-compiling and compatibility, why not come up with the One OS to Rule Them All so they don't have to keep jumping hoops everyday?

      2. Christian Berger

        Re: Of course it completely ignores the main problem of any program code in the browser...

        "I fail to see how this argument is any different from JS. That can suck your battery too."

        It is in no way different than JS, but that's my point. WebAssembly is essentially like JS, but you don't even get the (potentially obfuscated) source code.

        If we want to have server-dependent "Apps", we should perhaps ditch any kind of code executing locally and instead define a sort of "terminal". This doesn't need to be based on character terminals, but could instead be a DOM-tree controlled via Web sockets.

        1. Charles 9

          Re: Of course it completely ignores the main problem of any program code in the browser...

          Or better yet, just use something already out there, like VNC?

    2. DrXym

      Re: Of course it completely ignores the main problem of any program code in the browser...

      If you're worried about your battery being sucked dry then advocating for a slower, more CPU intensive language doesn't seem sensible. As for crypto miners, I suggest you look at the sites you're visiting. I'm sure they've been quite happily serving JS crypto miners up until now.

      1. Christian Berger

        Re: Of course it completely ignores the main problem of any program code in the browser...

        Most of the JS from other domains is malware by now. Usually it's code that manages ad providers to do things like holding an auction to determine what ad will be displayed to you. I can accept advertisements, but I do not accept such behaviour.

      2. Charles 9

        Re: Of course it completely ignores the main problem of any program code in the browser...

        "As for crypto miners, I suggest you look at the sites you're visiting."

        I suggest you look up a Drive-By Attack and see why that doesn't always work.

    3. ibmalone

      Re: Of course it completely ignores the main problem of any program code in the browser...

      Per-tab "nice" level controls, approved sites and other such things can be used.

      Personally, we've got some uses for this that are hard to solve otherwise. Want to transfer DICOM and make sure it's anonymised, but is properly coded, before it reaches the server? Well, Java is no longer an option. Some people have written libraries in JS to process it, would you rather use that or some halfway sane language? WASM lets you use the existing C++ tools.

    4. Christian Berger

      I should add that...

      ...we now have a new pre-fetching attack that works with WebAssembly.

  10. stiine Silver badge
    FAIL

    Wasm is evolving extremely rapidly, and new information and changes occur weekly

    If its changing doesn't that mean that each change will require the entire crap-sandwitch be put through the approval process again? Or is today's version going to be the IE6 of today's web?

    1. Adrian 4

      Re: Wasm is evolving extremely rapidly, and new information and changes occur weekly

      It'll be like Python : extended every month and the devs writing for public consumption use all the latest features. So we'll end up installing a new wasm byte-code interpreter every time we load a web page.

  11. Anonymous Coward
    Anonymous Coward

    I disable all JS and only use Lynx. The 'web' died with Gopher

    1. Throatwarbler Mangrove Silver badge
      Joke

      Bah!

      I only browse from within emacs, which doubtless will support WebAssembly soon enough.

      1. Nick Ryan Silver badge
        Stop

        Re: Bah!

        I only browse using telnet. Gerrof my lawn

  12. Chris Gray 1
    WTF?

    Also want more security info

    Amused to see a LISP-like syntax for the WebAssembly "source". Well, it is pretty much the simplest form of "source" anyone has come up with. Better than a Forth-like syntax!

    I see it supports pointer creation, casting and dereferencing. The created X86 code includes no checking of values. I want to know much much much more about what is going on. Otherwise this is the equivalent of letting J Random Hacker run any C code he wants on my machine without me having any choice. Sure, I do that with the OS and all the other native stuff that's part of the distribution I run, but that isn't coming from a random web page, which, if I don't block JavaScript, can force run stuff in my browser. BBAADD!!

    1. Phil Endecott

      Re: Also want more security info

      > I see it supports pointer creation, casting and dereferencing. The

      > created X86 code includes no checking of values

      What “created x86 code”?

      If your source C code dereferences an invalid pointer, IIUC the corresponding Wasm Javascript will access outside an array; this is trapped by the JS runtime.

      1. DrBed

        Re: Also want more security info

        but he wants to know much much much more about what is going on... pointless.

      2. Charles 9

        Re: Also want more security info

        Funny thing about traps: some nutters are clever enough to escape them, so I don't necessarily trust the runtime.

  13. a_yank_lurker

    Better fix, maybe

    Instead of WebAssembly which just adds another layer to the mess why not write JS code in Typescript or Elm for example and not directly in JS? It seems one of the major complaints is JackAss Script is a badly designed language. And code written in a badly designed language is likely to have some nasty bugs that are hard to track down no matter how good the programmer is.

  14. Anonymous Coward
    Anonymous Coward

    "[...] only one codebase to maintain for all platforms,[...}"

    Is that was true? Until the way page controls work in a uniform way in various browsers then there will have to be tweaking to find the best programming compromises.

    1. Charles 9

      As that's language-dependent, I don't see how such a thing is possible. For example, can you really make a uniform UI that's capable of handling both RTL and LTR languages?

  15. Mike 137 Silver badge

    "if you’re a company developing a new application, why make it native?"

    Because that's what many users actually need - a stable, secure, reliably available, durable and familiar application for doing real work with, not some ephemeral, unverifiable beast that consumes huge bandwidth resources just to start up and stores all your work perforce in the "cloud" where you can lose it at the drop of a hat. And don't get me started about JavaScript and security...

    The entire IT industry now exclusively gazes at its own navel, and has forgotten that customers exist with needs and wants of their own.

    1. Charles 9

      Re: "if you’re a company developing a new application, why make it native?"

      Well, there are two opinions about this. Native code means porting if you have more than one target, which in itself can be imperfect and can result in bugs. Sound to me like it's a kind of Trolley Problem in that no matter what approach you take you're going to end up with potentially nasty bugs: either through your "bytecode-to-native" translator or through the refactoring inherent with porting between architectures.

      1. Christian Berger

        Re: "if you’re a company developing a new application, why make it native?"

        "Native code means porting if you have more than one target, which in itself can be imperfect and can result in bugs."

        Yes, but if you choose one of the sensible ways to do this, porting is easy and reliable. I maintained a large-ish software package and there were something like 3 lines of code with ifdefs around them to handle differences in platforms. The platforms were Linux, Windows and MacOSX.

        1. Charles 9

          Re: "if you’re a company developing a new application, why make it native?"

          Did your code also take into consideration RTL languages? Different filesystems and other logistical differences? Was it smart enough to recognize different architectural limitations (like the <256-char and >256-char limit depending on whether or not you were using Unicode in Windows)?

  16. Barracoder
    Devil

    Silverlight rears its mishapen head above the churned, corrupted earth

    I think I can safely miss this wave.

  17. JohnFen

    Becasue they're better

    > And why wouldn’t you – if you’re a company developing a new application, why make it native?

    Because properly programmed native apps are always far better than properly programmed web apps.

    1. SealTeam6

      Re: Becasue they're better

      Isn't the web app more portable?

      The native app will need to be re-compiled for each CPU type.

      1. JohnFen

        Re: Becasue they're better

        Yes. I was talking about usability and performance, not "write once, run everywhere". As both a user and a developer, I think that the facilities to "write once, run everywhere" are highly insufficient and lead to poor programs.

  18. SeanEllis

    Seems familiar

    - Compiled offline

    - Delivered binary

    - Stack-based VM

    - Sandbox execution environment

    - Standardised runtime

    It's Java again! Hooray!

    1. DrXym

      Re: Seems familiar

      Wasm doesn't have a standardised runtime or any runtime per se except for what the embedder (e.g. a browser) exposes to it. If you look at emscripten for example, one of things it does is provide a C, C++ and SDL compatible libs that map through onto the DOM / canvas / webaudio / OpenGL in a browser.

      1. Richard 12 Silver badge

        Re: Seems familiar

        So yep, it's Java Applets again. Or Silverlight. Or Flash. There is a runtime, what do you think the browser is doing?

        We've definitely been here before many times.

        At least it's better than ActiveX, and the published spec with two implementations (Chromium/Mozilla) does make it slightly more secure as most sandbox breakouts will only work on one or the other, and not both.

        I suppose it's not a totally terrible idea, as it's not really any worse than minified Javascript.

        Just so long as I can block it by default and enable when I want to.

        An explicit click-to-run would be ok.

        1. DrXym

          Re: Seems familiar

          No, it's nothing like those things. It's not native code and there is no NPAPI or ActiveX.

          1. Charles 9

            Re: Seems familiar

            If it doesn't become native code at some point, what good is it? And without some means of accessing the outside, what good is it?

            Both are potential exploits AND sandbox escape routed.

            1. DrXym

              Re: Seems familiar

              Wasm's "means of accessing the outside" is whatever the embedder chooses to expose. In a browser that means exactly the same access to the outside world as JavaScript - the DOM, canvas, web audio etc. with all the same cross origin & security model checks. Anything that a browser stops you doing in JS it would also stop you doing in wasm.

              Not even sure what to make of the "native code" comment. The point is the specification describes a low-level instruction set and binary / text format without dictating how the implementation should run it, or whether it uses JIT, AOT or neither.

              This is as opposed to an plugin / activex control which *was* a native DLL with same privilege to do anything in the OS as the process running it.

              1. Charles 9

                Re: Seems familiar

                "Wasm's "means of accessing the outside" is whatever the embedder chooses to expose. In a browser that means exactly the same access to the outside world as JavaScript - the DOM, canvas, web audio etc. with all the same cross origin & security model checks. Anything that a browser stops you doing in JS it would also stop you doing in wasm."

                And IIRC some scripts were able to escape those security measures, and the risk will always be there, meaning the ONLY way to keep the browser safe is to ignore Joe Stupid's demands and not offer the feature at all.

              2. JohnFen

                Re: Seems familiar

                > In a browser that means exactly the same access to the outside world as JavaScript - the DOM, canvas, web audio etc. with all the same cross origin & security model checks.

                That doesn't give any comfort. I consider JS to be too risky to allow.

  19. Anonymous Coward
    Anonymous Coward

    About those browsers......

    ......why does anyone think that a "browser front end" builds a better application than something built in QT or GTK?

    Just saying!

    1. Nick Ryan Silver badge

      Re: About those browsers......

      Probably the same "anyone" who thinks that using JavaScript to (badly) re-create standard browser functionality in JavaScript is anything but a really stupid idea - HTML and CSS are there for a reason. Similarly the same "anyone" who thinks to vomit out yet another barely usable, incredibly low accsssibilty, zero SEO and buggy Single Page Application (SPA) is a good way to take advantage of modern browser functionality and the browser platform as a whole. It's not that the technology doesn't have a use, but pretending that the browser page is a modal client application demonstrates an utter lack of comprehension. JavaScript and so on should be used to enhance a web page, not to build a web page. See the historical train wrecks of single page Flash websites for how well this works when this is forgotten.

  20. John Smith 19 Gold badge
    FAIL

    What could possibly go wrong with such a cunning plan?

    I'd have to say "Lots."

  21. ecofeco Silver badge

    Good enough for AutoCAD?

    Sorry but that's not a very good reference.

  22. Anonymous Coward
    Anonymous Coward

    Oh Jesus Christ

    Not again.

    This will be a security nightmare, the functional and aesthetic equivalent of anorexia, and will be retired in 6 months when the child coders at M$ get bored of it.

    It'll also have a whole new scrollbar style because that's the #1 law at Microsoft.

    1. Dinsdale247

      Re: Oh Jesus Christ

      Jesus has nothing to do with this, it's our own mess.

  23. Nebra

    Obvs. Race condition exploits would be an avenue on investigation, if it runs significantly faster...

  24. Dinsdale247

    New High Priests

    Web browser engineers seeking to become the new High Priests of the Internet so they re-invent Assembly in the browser. Sigh.

    Ted Nelson on the history of computers...

    https://www.youtube.com/watch?v=KdnGPQaICjk

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon