What if JavaScript wins?

Re:What if JavaScript wins? by captainbland on Wednesday May 16, 2018 @12:13PM (#17083545)

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_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.

[ Parent | on HN ]

Re:What if JavaScript wins? by abritinthebay on Wednesday May 16, 2018 @01:08PM (#17084160)

> 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.

[ Parent | on HN ]

Re:What if JavaScript wins? by jpfed on Wednesday May 16, 2018 @01:39PM (#17084505)

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.

[ Parent | on HN ]

Re:What if JavaScript wins? by abritinthebay on Wednesday May 16, 2018 @04:52PM (#17086379)

> I hate imperatively constructing "types" through prototypal inheritance

You hate objects... basically?

[ Parent | on HN ]

Re:What if JavaScript wins? by jpfed on Wednesday May 16, 2018 @10:34PM (#17088278)

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).

[ Parent | on HN ]

Re:What if JavaScript wins? by abritinthebay on Thursday May 17, 2018 @05:18PM (#17095971)

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.

[ Parent | on HN ]

Re:What if JavaScript wins? by danield9tqh on Wednesday May 16, 2018 @01:53PM (#17084684)

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?

[ Parent | on HN ]

Re:What if JavaScript wins? by captainbland on Wednesday May 16, 2018 @02:28PM (#17085095)

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.

[ Parent | on HN ]

Re:What if JavaScript wins? by abritinthebay on Wednesday May 16, 2018 @04:53PM (#17086390)

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).

[ Parent | on HN ]