4 ms·

Hopefully this also means that Javascript is going away for good

by bogwog 7y ago

k__ 7y ago
I think people starting to pump giant binaries to the browser will lead to JavaScript leveraging its strengths and getting even better.
- bogwog 7y ago
  > I think people starting to pump giant binaries to the browser As if that's not already happening today with obfuscated and minified javascript
  - krapp 7y ago
    Those aren't technically binaries, as much as people want to cling to the metaphor of javascript as "bytecode" and pretend no distinction exists between the two.
    - bogwog 7y ago
      > and pretend no distinction exists between the two. What's the distinction then? That obfuscated javascript can be looked at by people who don't know how to use a hex editor?
      - krapp 7y ago
        Javascript-as-bytecode is a metaphor, not a technical description. Javascript is not actually bytecode in the same way that a .java file is not java bytecode.
        bogwog 7y ago
        Okay. Thanks for that.
  - k__ 7y ago
    That's what I meant. JS can do better, and it will if other languages can do things it does now.
- asdfman123 7y ago
  I don't get why binaries should be more bandwidth-intensive than JS. I guess in a sense you already have the JS engine installed with, say, Chrome, which is essentially a runtime. Why can't other runtimes come prepackaged? What am I missing here?
  - bhaak 7y ago
    Nobody wants another fat runtime that is as entangled with the browser engine as the JS engine is. Getting the JS engine to be fast was a tremendous trouble and you wouldn't want to sink as much engineering power into another runtime that will have a smaller reach than the JS engine. Rather use that skills to make WASM faster.
    - krapp 7y ago
      > Nobody wants another fat runtime that is as entangled with the browser engine as the JS engine is. Why would it need to be? There's no reason to assume the architectural decisions for javascript have to be repeated for WASM. The runtimes themselves could be WASM binaries cached like any other resource, or managed like packages. Javascript could be disentangled from the browser by doing the same - just treating it as a resource that ships by default with the browser. I don't know if that's feasible - maybe not - but I bet there are possibilities other than "ship the entire runtime with each script" that can be considered.
      - bhaak 7y ago
        I thought you meant adding other scripting languages to the browser. Not a WASM runtime. That's likely still not a good idea. A specific runtime is likely to be outdated fast. That's like asking why the JQuery library wasn't shipped with the browsers themselves. For runtime with a significant size, it's probably going the same way as JQuery. Have a CDN host it so different websites can use it and leverage the browser's cache.
krapp 7y ago
It doesn't. Browsers will have to continue to support javascript indefinitely, simply because doing otherwise would break most of the web. Also, the use cases for javascript and webassembly don't overlap enough for one to replace the other in most cases. Javascript is a text-based scripting language you can write in any editor (the sprawling morass that is the current js development ecosystem notwithstanding,) but WASM requires knowing another language and having a compile step, which adds friction and complexity. You can't really replace a language with a bytecode. It may mean that other languages can be deployed in the browser as easily as javascript, which may or may not be good depending on your point of view. I personally look forward to the day when Hacker News embeds the Arc runtime as WASM and replaces all of their javascript with Arc code.
- bogwog 7y ago
  > It may mean that other languages can be deployed in the browser as easily as javascript, which may or may not be good depending on your point of view. That's exactly what I hope happens. There are so many good languages out there that having to be stuck with javascript for the modern web is a crime.
- MaxBarraclough 7y ago
  Also, WebAssembly doesn't have everything JavaScript has. Garbage collection and support for older browsers, for instance. > WASM requires knowing another language and having a compile step, which adds friction and complexity. You can't really replace a language with a bytecode. I'm not sure that requiring a build step is a real problem, for web 'applications' at least. Plenty of JavaScript frameworks use a build step anyway.
siempreme 7y ago
Indeed, and it's entire spaghetti/duck-taped eco system including: babel, react, vue, angular, typescript, name it. Can't wait for that day..
zelly 7y ago
It's not the end of JavaScript. It's the end of every language that "compiles to" JavaScript.

Hopefully this also means that Javascript is going away for good

by bogwog 7y ago

Hopefully this also means that Javascript is going away for good

k__ 7y ago

I think people starting to pump giant binaries to the browser will lead to JavaScript leveraging its strengths and getting even better.

bogwog 7y ago
> I think people starting to pump giant binaries to the browser As if that's not already happening today with obfuscated and minified javascript
- krapp 7y ago
  Those aren't technically binaries, as much as people want to cling to the metaphor of javascript as "bytecode" and pretend no distinction exists between the two.
  - bogwog 7y ago
    > and pretend no distinction exists between the two. What's the distinction then? That obfuscated javascript can be looked at by people who don't know how to use a hex editor?
    - krapp 7y ago
      Javascript-as-bytecode is a metaphor, not a technical description. Javascript is not actually bytecode in the same way that a .java file is not java bytecode.
      - bogwog 7y ago
        Okay. Thanks for that.
- k__ 7y ago
  That's what I meant. JS can do better, and it will if other languages can do things it does now.
asdfman123 7y ago
I don't get why binaries should be more bandwidth-intensive than JS. I guess in a sense you already have the JS engine installed with, say, Chrome, which is essentially a runtime. Why can't other runtimes come prepackaged? What am I missing here?
- bhaak 7y ago
  Nobody wants another fat runtime that is as entangled with the browser engine as the JS engine is. Getting the JS engine to be fast was a tremendous trouble and you wouldn't want to sink as much engineering power into another runtime that will have a smaller reach than the JS engine. Rather use that skills to make WASM faster.
  - krapp 7y ago
    > Nobody wants another fat runtime that is as entangled with the browser engine as the JS engine is. Why would it need to be? There's no reason to assume the architectural decisions for javascript have to be repeated for WASM. The runtimes themselves could be WASM binaries cached like any other resource, or managed like packages. Javascript could be disentangled from the browser by doing the same - just treating it as a resource that ships by default with the browser. I don't know if that's feasible - maybe not - but I bet there are possibilities other than "ship the entire runtime with each script" that can be considered.
    - bhaak 7y ago
      I thought you meant adding other scripting languages to the browser. Not a WASM runtime. That's likely still not a good idea. A specific runtime is likely to be outdated fast. That's like asking why the JQuery library wasn't shipped with the browsers themselves. For runtime with a significant size, it's probably going the same way as JQuery. Have a CDN host it so different websites can use it and leverage the browser's cache.

krapp 7y ago

It doesn't. Browsers will have to continue to support javascript indefinitely, simply because doing otherwise would break most of the web. Also, the use cases for javascript and webassembly don't overlap enough for one to replace the other in most cases. Javascript is a text-based scripting language you can write in any editor (the sprawling morass that is the current js development ecosystem notwithstanding,) but WASM requires knowing another language and having a compile step, which adds friction and complexity. You can't really replace a language with a bytecode. It may mean that other languages can be deployed in the browser as easily as javascript, which may or may not be good depending on your point of view. I personally look forward to the day when Hacker News embeds the Arc runtime as WASM and replaces all of their javascript with Arc code.

bogwog 7y ago
> It may mean that other languages can be deployed in the browser as easily as javascript, which may or may not be good depending on your point of view. That's exactly what I hope happens. There are so many good languages out there that having to be stuck with javascript for the modern web is a crime.
MaxBarraclough 7y ago
Also, WebAssembly doesn't have everything JavaScript has. Garbage collection and support for older browsers, for instance. > WASM requires knowing another language and having a compile step, which adds friction and complexity. You can't really replace a language with a bytecode. I'm not sure that requiring a build step is a real problem, for web 'applications' at least. Plenty of JavaScript frameworks use a build step anyway.

siempreme 7y ago

Indeed, and it's entire spaghetti/duck-taped eco system including: babel, react, vue, angular, typescript, name it. Can't wait for that day..

zelly 7y ago

It's not the end of JavaScript. It's the end of every language that "compiles to" JavaScript.