4 ms·

What wide and varied legitimate use cases did we honestly expect to see? What wide and varied legitimate uses to we see for JS now?

krapp 7y ago
>What wide and varied legitimate use cases did we honestly expect to see? It's just a bytecode spec, it wasn't created by the mafia or anything. Many people have already used it for porting software to the web, and for math-intensive operations. You can see plenty of such projects by searching HN. >What wide and varied legitimate uses to we see for JS now? Are you implying that most JS is currently used for malicious purposes? I would guess the vast majority of JS is currently used to render content in the browser as part of a frontend framework, or JQuery, which is probably still widely in use in legacy sites. Also for Google Analytics, which I suppose some people might consider malicious. But then half of HN considers javascript illegitimate and malicious by default anyway.
- mooman219 7y ago
  >Are you implying that most JS is currently used for malicious purposes? I classify most ads as malicious, so yes.
_bxg1 7y ago
There admittedly aren't many for "intensive number-crunching that needs to happen in the client even though a server is almost definitely available, and which also can't directly interact with the DOM". Games and cryptography are the only big ones that come to mind right now (for example, services like ProtonMail that do client-side decryption). Hopefully the DOM limitation (and general API limitations) will be lifted over time, in which case there could be a huge use-case for client-side rendering which can be a bottleneck right now. Lifting the API limitations could also allow the web to become truly multi-lingual; you could ditch JS entirely. But other than the above, you still have the question of "what computation really needs to be done in the web client when you have a server on-hand?" Even in Electron, you have the ability to spin up other processes on the host machine. I think WebAssembly is super cool but it still needs a killer-app. Ironically, one of the places it's really getting some interesting traction is on the server. It's like a JVM without a garbage collector. I look forward to seeing where that goes.
nmfisher 7y ago
> What wide and varied legitimate use cases did we honestly expect to see? For one, I'm currently experimenting with compiling Kaldi to WebAssembly for local (in-browser) speech recognition. I'm fully behind WASM - I think it will serve as the backbone for the next generation of web apps for a decade or two. But the downside to its flexibility is that it is far easier to use for nefarious purposes. I don't think that should poison the well for legitimate use-cases though.
jkoudys 7y ago
ML for resource-intensive apps. Client-side word vectorization would be a nice-to-have -- early classificatiton and sentiment analysis happening client-side opens up a ton of use cases. What I'm more excited for, is it also lets you write highly-optimized apps which would use less power, and possibly be served in smaller filesizes. This is great for mobile devices. e.g. managing and comparing 128-bit uints is a big headache in JS, so you rarely see UUIDs handled as anything but strings. There are a few optimizations around that, but ultimately it's going to be a lot easier on memory and run faster matching if you can store it directly as 16-bytes. Trivial in rust compiled to wasm, but not worth your time in JS. There are also still a lot of programs being compiled to windows/osx/linux target binaries, that could run just as well in a browser with wasm. It's easier to picture what you _don't_ run in browser now as a possibility, instead of simply imagining how the current web will look in wasm.

krapp 7y ago

>What wide and varied legitimate use cases did we honestly expect to see? It's just a bytecode spec, it wasn't created by the mafia or anything. Many people have already used it for porting software to the web, and for math-intensive operations. You can see plenty of such projects by searching HN. >What wide and varied legitimate uses to we see for JS now? Are you implying that most JS is currently used for malicious purposes? I would guess the vast majority of JS is currently used to render content in the browser as part of a frontend framework, or JQuery, which is probably still widely in use in legacy sites. Also for Google Analytics, which I suppose some people might consider malicious. But then half of HN considers javascript illegitimate and malicious by default anyway.

mooman219 7y ago
>Are you implying that most JS is currently used for malicious purposes? I classify most ads as malicious, so yes.

_bxg1 7y ago

There admittedly aren't many for "intensive number-crunching that needs to happen in the client even though a server is almost definitely available, and which also can't directly interact with the DOM". Games and cryptography are the only big ones that come to mind right now (for example, services like ProtonMail that do client-side decryption). Hopefully the DOM limitation (and general API limitations) will be lifted over time, in which case there could be a huge use-case for client-side rendering which can be a bottleneck right now. Lifting the API limitations could also allow the web to become truly multi-lingual; you could ditch JS entirely. But other than the above, you still have the question of "what computation really needs to be done in the web client when you have a server on-hand?" Even in Electron, you have the ability to spin up other processes on the host machine. I think WebAssembly is super cool but it still needs a killer-app. Ironically, one of the places it's really getting some interesting traction is on the server. It's like a JVM without a garbage collector. I look forward to seeing where that goes.

nmfisher 7y ago

> What wide and varied legitimate use cases did we honestly expect to see? For one, I'm currently experimenting with compiling Kaldi to WebAssembly for local (in-browser) speech recognition. I'm fully behind WASM - I think it will serve as the backbone for the next generation of web apps for a decade or two. But the downside to its flexibility is that it is far easier to use for nefarious purposes. I don't think that should poison the well for legitimate use-cases though.

jkoudys 7y ago

ML for resource-intensive apps. Client-side word vectorization would be a nice-to-have -- early classificatiton and sentiment analysis happening client-side opens up a ton of use cases. What I'm more excited for, is it also lets you write highly-optimized apps which would use less power, and possibly be served in smaller filesizes. This is great for mobile devices. e.g. managing and comparing 128-bit uints is a big headache in JS, so you rarely see UUIDs handled as anything but strings. There are a few optimizations around that, but ultimately it's going to be a lot easier on memory and run faster matching if you can store it directly as 16-bytes. Trivial in rust compiled to wasm, but not worth your time in JS. There are also still a lot of programs being compiled to windows/osx/linux target binaries, that could run just as well in a browser with wasm. It's easier to picture what you _don't_ run in browser now as a possibility, instead of simply imagining how the current web will look in wasm.