5 ms·

I think within a few years WASM will finally be in a place where it becomes usable without relying on JavaScript for interfacing with the web browser and people

I think within a few years WASM will finally be in a place where it becomes usable without relying on JavaScript for interfacing with the web browser and people will be able to develop high-performance, isomorphic web applications in other programming languages. This will definitely start to eat into it as it makes gains elsewhere. As such, I don't really see JavaScript reaching the level of dominance implied in this article - and to be honest, I wouldn't want it to when Oracle has gone after developers for naming it as something they support on trademark grounds. https://www.theregister.co.uk/2018/04/18/oracle_ios_app_takedown_javascript/ https://www.theregister.co.uk/2018/04/18/oracle_ios_app_take... Honestly, I think JavaScript at some point - not in the near future - will see its 'Flash' moment where a large organisation stops supporting it entirely if Oracle keeps up stuff like this.

abritinthebay 8y ago
> it becomes usable [...] for interfacing with the web browser As soon as you add DOM integration... all the things people hate about JS in terms of architecture and compromises will show up in WASM.
- jpfed 8y ago
  This is a common sentiment but it certainly doesn't cover "all the things" people hate. I hate dynamic types, I hate imperatively constructing "types" through prototypal inheritance, I hate "this", and none of that has anything to do with the DOM.
  - abritinthebay 8y ago
    > I hate imperatively constructing "types" through prototypal inheritance You hate objects... basically?
    - jpfed 8y ago
      While objects are overrated, that's not what I'm talking about here. I didn't say "imperatively constructing objects of a type", I said "imperatively constructing types". This has likely changed since I last used javascript, but in the bad old days, if you wanted to specify a "type" (in the structural sense- a common set of fields that you might construct instances of), you build that type with statements rather than declarations. That feels icky. Also, that means that any potential IDE has to interpret your code (rather than simply parsing declarations) to provide any real support for you, which meant it took forever for IDEs to provide things like autocomplete (let alone foolproof renaming).
      - abritinthebay 8y ago
        Likely you'd like the modern class syntax then. You declaratively specific the "class" (it's just an Object under the hood, it's mostly sugar for prototypes) and then you could just to instanceOf to test if it's your "type". I mean in JS basically everything is an object so if you're constructing a "type" you're constructing an object no matter what.
- danield9tqh 8y ago
  I think that's fine because WASM isn't meant to write code in. It's just a source language for other compiled languages. I'm assuming the javascript complaints you're talking about are because people actually have to write javascript code?
  - captainbland 8y ago
    Even then I don't think they would tie it to the WASM definition that tightly as they intend it to be used on other platforms than just web browsers. It seems to me that you could just have the DOM be expressed as a kind of interface which the browser implements, and then each language just has a DOM library which exposes that interface to the programmer.
  - abritinthebay 8y ago
    Right, I agree but every time someone talks about tighter integration with the browser it really, under the hood, requires DOM access. Because it does basically everything else (or is spec'd to).

abritinthebay 8y ago

> it becomes usable [...] for interfacing with the web browser As soon as you add DOM integration... all the things people hate about JS in terms of architecture and compromises will show up in WASM.

jpfed 8y ago
This is a common sentiment but it certainly doesn't cover "all the things" people hate. I hate dynamic types, I hate imperatively constructing "types" through prototypal inheritance, I hate "this", and none of that has anything to do with the DOM.
- abritinthebay 8y ago
  > I hate imperatively constructing "types" through prototypal inheritance You hate objects... basically?
  - jpfed 8y ago
    While objects are overrated, that's not what I'm talking about here. I didn't say "imperatively constructing objects of a type", I said "imperatively constructing types". This has likely changed since I last used javascript, but in the bad old days, if you wanted to specify a "type" (in the structural sense- a common set of fields that you might construct instances of), you build that type with statements rather than declarations. That feels icky. Also, that means that any potential IDE has to interpret your code (rather than simply parsing declarations) to provide any real support for you, which meant it took forever for IDEs to provide things like autocomplete (let alone foolproof renaming).
    - abritinthebay 8y ago
      Likely you'd like the modern class syntax then. You declaratively specific the "class" (it's just an Object under the hood, it's mostly sugar for prototypes) and then you could just to instanceOf to test if it's your "type". I mean in JS basically everything is an object so if you're constructing a "type" you're constructing an object no matter what.
danield9tqh 8y ago
I think that's fine because WASM isn't meant to write code in. It's just a source language for other compiled languages. I'm assuming the javascript complaints you're talking about are because people actually have to write javascript code?
- captainbland 8y ago
  Even then I don't think they would tie it to the WASM definition that tightly as they intend it to be used on other platforms than just web browsers. It seems to me that you could just have the DOM be expressed as a kind of interface which the browser implements, and then each language just has a DOM library which exposes that interface to the programmer.
- abritinthebay 8y ago
  Right, I agree but every time someone talks about tighter integration with the browser it really, under the hood, requires DOM access. Because it does basically everything else (or is spec'd to).