Why was "running CPU intensive games in a browser" a worthwhile goal? The browser was intended to be a way to read and write "documents", not the one and only user interface for everything ever.

Why is this being close-voted as off-topic? The question may seem silly if one knows how the Web came to be, but that doesn’t make it off-topic.

I thought this was a historical question. But I was told there is WebAssembly. I didn't know that so my question is kind of answered.

WebAssembly is pretty new, though the idea of running arbitrary (sandboxed, more or less) code within the browser is much older: JS, ActiveX, Java applets, Flash, NaCl… I think those approaches (and why most of them didn’t take off and/or were much more limited) would actually be on-topic here.

It's not unsafe because "CPUs have vulnerabilities". It's unsafe because sandboxing software has bugs (more often than not). See the gravestones for ActiveX, Java applets, etc. etc.

@another-dave Normal JavaScript can have bugs too.

@javanerd - that one implementation can be buggy is not a reason to have more implementations that are buggy. Besides, the cases are different. Java, for example, is a fully-fleshed programmng language, and running a Java program in a sandbox requires stopping it from having the access it would normally have. Is javascript used outside the web environment to any significant degree?

@another-dave The discussion about whether it's a good idea to allow a web page to execute native machine code is needless. Because today it's already possible and it's called WebAssembly.

"Whether it is a good idea" is orthogonal to "it exists".

@another-dave So in your opinion WebAssembly sucks because it's too buggy and insecure? Can you back this up with any facts?

"Can you back this up with any facts?" It's much better if you edit your question and qualify why it's valuable to run native code...in the browser. Your question is written on the presumption that it is but doesn't explain why. Your comments read as pushing very hard for it so you must have a reason. So: how is it ultimately more profitable to businesses and users to be able to do this, over not having it? A decently long and in-depth explanation with justifications in question that started this discussion is what's needed, it might get reopened. (Not in comments, fragments the question.)

@javanerd "So...". No. Stop putting words in my mouth, please. How do you get "WebAssembly sucks" out of "Whether it is a good idea" is orthogonal to "it exists"? This is a simple statement of fact.

They did add one - it was called ActiveX. It turns out that if the web page and the web browser run the same type of code, then keeping web page code separate from web browser code is a hard problem. You might also be interested in Google's old project, NaCl (short for Native Client; I guess they were SALTY about having to use JavaScript for everything) and then PNaCl which was basically a predecessor to WebAssembly

One could design an efficient sandboxed implementation of a C-subset dialect such as CompCert C, but it's very hard to efficiently "sandbox" a C implementation that supports the use of memcpy to subdivide and recombine blobs of memory that contain pointers. Higher-level languages like Javascript are cheaper to sandbox, because they can uphold stronger invariants regarding pointer referencing than would be possible in C. In many such languages, it may be possible to unambiguously classify every byte of storage as either being part of a valid field of object-reference type, or as being...

...something that will never within its lifetime be interpreted as an object reference. That's not possible in C.

@supercat Even Java had the same problem that if the web page and the web browser run the same type of code, then keeping web page code separate from web browser code is hard (see Trusted Method Chaining CVE-2010-0840). With something like WASM it's easy: all WASM code is untrusted, period.

@user253751: There are a lot of fussy details a Java implementation would have to get right to maintain separation between trusted and untrusted code, but in Java the problem is at least tractable. In a C implementation that allows pointer objects to be synthesized from sequences of byte values, there's no 100% robust way to prevent untrusted code from creating pointers to arbitrary objects within its address space, without regard for whether it should be able to access them.

@supercat then you simply give it its own address space. Problem is, operating systems don't really allow this in a bulletproof way, or didn't until after the web was mainstream. You could probably achieve it on Linux by using seccomp (2005), but you'd have to write your own loader. Windows still doesn't provide this feature, to my knowledge; ProcessSystemCallDisablePolicy only allows a single bit control which disables certain system calls but not others, for attack surface reduction, not sandboxing.