-3

I wonder why they never added an interface to run native code (for example assembly/C/C++/Rust...) to HTML web pages? Because without it CPU intense games will never run in the browser.

Some people might think the reason is of course because native code can take over the machine and infect it. But that's not true. Native code can be run in a sandbox without permission to do anything.

I know one problem might be there are countless (rare) architectures out there. But if someone wants to develop a game and he adds support for i486 and x64 so it will cover 99% of desktop machines. You can't run a normal desktop game on any arch either.

Another problem might be there are CPUs having vulnerabilities like "meltdown/spectre". But Android shows that allowing apps to run native (even without asking for permission) can be safe. To make it even safer the browser could ask the user to run native code before execution. Or the browser could reject native code or emulate it if there is a vulnerability in the CPU. I think not to implement native code because some few CPUs have security vulnerabilities is not the right way. It's like not using PCs at all because they sometimes crash.

So what are the true reasons a native interface was never added to HTML/JS?

Improve this question
1

1 Answer 1

Reset to default
12

They did add support for native code. It's called WebAssembly and it's something you can compile C, C++, Rust, etc. to.

It grew out of Mozilla's asm.js and Google's pNaCl (Portable Native Client) projects.

It works by having your compiler and optimizer output WASM bytecode as if it were any other CPU ISA, and then the browser compiles that to native machine code when it loads it. That way, it's not tied to any one specific architecture.

(That idea was taken from pNaCl, where they literally just split LLVM Clang's compilation process in half and stored the LLVM IR from a specific version of LLVM as their "bytecode" at the stage before it became ISA-specific. The main contribution from the asm.js side of its ancestry was probably the Emscripten compiler toolchain for C and C++.)

What you were probably thinking of was tried. That's how Google's original Native Client worked before they decided that just x86, x86_64, and ARM wasn't enough, and that they didn't want to require people to make and maintain three separate builds for their ChromeOS apps. That one used a specially modified version of GCC's code generator and a special loader for the machine code to statically prove that it couldn't escape its sandbox more easily than ordinary JavaScript.

...or, going back further, there was Internet Explorer's support for downloading ActiveX controls (introduced in 1996)... yes, that infamously regretted feature of Internet Explorer was basically the first attempt at what you were asking about. It was a more naive time.

Improve this answer
9
  • well, TBF (IMO) the downfall of ActiveX was that the SPI was horribly horribly complex and couldn't really be implemented correctly or completely by anyone outside of Microsoft no matter how hard they tried. So: ActiveX controls were necessarily buggy, and, since native code without sandbox, were necessarily dangerous to your environment and your browser (meaning: it crashed or misbehaved often). ActiveX controls were signed and (IIRC) you were asked if you wanted to install one - so if you were careful with that you only had bugs to worry about, not malware too.
    – davidbak
    May 19 at 16:21
  • Also, it was C++ before modern C++ - i.e., before we knew how to properly use smart pointers, etc. etc., to write safe code.
    – davidbak
    May 19 at 16:23
  • 1
    Citation needed on Java applets not coming out until 1997; Wikipedia and my memory say Java applets were basically part of the first public release in 1995 [en.wikipedia.org/wiki/Java_applet]
    – Foon
    May 19 at 16:55
  • 1
    Netscape also had a native plugin API and Chrome supported it (like Java plugin) until 2014.
    – Thorbjørn Ravn Andersen
    May 20 at 13:18
  • 1
    @ThorbjørnRavnAndersen However, Netscape plugins couldn't be automatically downloaded at a website's request. The website had to assume the user would choose what was available to handle a given mimetype. (Speaking of which, KDE's equivalent to ActiveX Controls, KParts, integrated with Konqueror the same way as Netscape plugins and that's why they were never a problem, but also never an analogue to Java/Silverlight/Flash/WebAssembly/etc.)
    – ssokolow
    May 20 at 19:46

Not the answer you're looking for? Browse other questions tagged .