4 ms·
> It was basically like downloading and running a random exe from any site you visited. which is pretty much where we are today, especially with wasm and bund
by jerrysievert 8y ago
> It was basically like downloading and running a random exe from any site you visited.
which is pretty much where we are today, especially with wasm and bundles. we just went around the virtual machine and byte code before coming back.
from Javascript's start, it was embedded, but Java applets were pretty early as well. The core problem was direct interactivity with the browser, which Javascript had a small amount of initially, and Flash/Java tried to subsume. The difference was how the browser itself was treated.
- ChrisSD 8y agoThe key difference is in the context. "Embedded" Java and Flash still required an external runtime, but the browser provided them a surface to paint on. Later on browsers like Chrome tried sandboxing the Flash process but the trouble is Flash was built under the assumption it would have full user access, so that could only go so far. There's a reason news of Flash exploits used to regularly appear in the tech press. Wasm was built from the ground up to be run in the context of a browser. It's also implemented by browser vendors so they can take responsibility for security. In essence, the difference is that it's made to be sandboxed from the rest of the system.
- goatlover 8y ago> The key difference is in the context. "Embedded" Java and Flash still required an external runtime, But that was Netscape's initial decision. There was nothing stopping a browser vendor from embedding Java into the browser the same way. Microsoft ended up doing that for VBScript in IE. Lotus Notes was embedding Java on their clients in the mid 90s alongside LotusScript. In addition to that, you could even copy/paste a Java applet from the web into Lotus email, and it would run, although that was different from having Java embedded as a language.