4 ms·

> In the right timeline, a deeply flawed language like JavaScript would never have been successful but in that same timeline, we had Java, which was touted to

> In the right timeline, a deeply flawed language like JavaScript would never have been successful but in that same timeline, we had Java, which was touted to solve all of those problems, vs Javascript which was touted to add slight interactivity. We took a step sideways, instead, with Java offering a lousy user experience for what it promised, and Javascript getting progressively better, while promising nothing in the early days. The other competitor, Flash, ended up flawed in its own right. And here we are.

ChrisSD 8y ago
The trouble with Java in the browser wasn't the language per se; it was the external runtime. This was also the problem with Flash. It was basically like downloading and running a random exe from any site you visited. From the start Javascript was built in to browsers and even as it grew it was running in the context of a web page. By the time Javascript had grown large enough that people were looking for other languages it had become too entrenched. Besides, Javascript is good enough for most websites. It's only larger web apps where it becomes more of a problem.
- 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 ago
    The 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.
- goatlover 8y ago
  Sun wanted Netscape to embed Java in the browser. Netscape wanted to make their own language. The plan was actually to embed both along with a canvas component, but there wasn't enough time to do anything more than JS for that release, and so Sun went with Java applets and canvas would have to wait until HTML 5.
- ss 8y ago
  森

ChrisSD 8y ago

The trouble with Java in the browser wasn't the language per se; it was the external runtime. This was also the problem with Flash. It was basically like downloading and running a random exe from any site you visited. From the start Javascript was built in to browsers and even as it grew it was running in the context of a web page. By the time Javascript had grown large enough that people were looking for other languages it had become too entrenched. Besides, Javascript is good enough for most websites. It's only larger web apps where it becomes more of a problem.

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 ago
  The 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.
goatlover 8y ago
Sun wanted Netscape to embed Java in the browser. Netscape wanted to make their own language. The plan was actually to embed both along with a canvas component, but there wasn't enough time to do anything more than JS for that release, and so Sun went with Java applets and canvas would have to wait until HTML 5.
ss 8y ago
森