This is probably hand-waving but : instead of implementing threads directly into the WebAssembly language, would it make sense to compile a known micro-kernel to WebAssembly and then compile the C standard library (which, IIRC, implements threads)?
Bringing the web up to speed with WebAssembly
41–50 of 172 posts
Re: Bringing the web up to speed with WebAssembly
#42Yet, almost one year after its release, nobody makes money directly or indirectly with wasm... despite the beauty of its engineering, I'm starting to worry. Who will continue funding it if nobody uses it?
Re: Bringing the web up to speed with WebAssembly
#43WASM has the potential to change the world... a thought: while WASM will initially appear in compute-intense functions in web apps, it has the potential to be a true "Common Language Runtime". It may become the future platform that native, dekstop apps run on. This could be a good thing, if done correctly: 1. Desktop apps have a common, safe runtime upon which they run, and the packages can be easily distributed (and…
We had that in the 90s. We called it Java.
Re: Bringing the web up to speed with WebAssembly
#44WASM has the potential to change the world... a thought: while WASM will initially appear in compute-intense functions in web apps, it has the potential to be a true "Common Language Runtime". It may become the future platform that native, dekstop apps run on. This could be a good thing, if done correctly: 1. Desktop apps have a common, safe runtime upon which they run, and the packages can be easily distributed (and…
We had that in the 90s. We called it Java.
Re: Bringing the web up to speed with WebAssembly
#45WASM has the potential to change the world... a thought: while WASM will initially appear in compute-intense functions in web apps, it has the potential to be a true "Common Language Runtime". It may become the future platform that native, dekstop apps run on. This could be a good thing, if done correctly: 1. Desktop apps have a common, safe runtime upon which they run, and the packages can be easily distributed (and…
> It may become the future platform that native, dekstop apps run on
So Flash, again?
Re: Bringing the web up to speed with WebAssembly
#46WASM has the potential to change the world... a thought: while WASM will initially appear in compute-intense functions in web apps, it has the potential to be a true "Common Language Runtime". It may become the future platform that native, dekstop apps run on. This could be a good thing, if done correctly: 1. Desktop apps have a common, safe runtime upon which they run, and the packages can be easily distributed (and…
We had that in the 90s. We called it Java.
Java only had one closed source implementation and had many security issues during its life. It wasn't designed for proper sandboxing and for having multiple implementations in the first place. And its communication with the rest of the browser was done through a slow and ugly channel (IIRC everything had to be sent around as strings).
Re: Bringing the web up to speed with WebAssembly
#47WebAssembly is really going to bring some awesome fast processing for binary heavy tasks, like video and gaming, to the web. Essentially, WebAssembly is the new Flash, but it is an open standard, more secure, and language agnostic. Despite this I really get the impression a lot of non-JavaScript developers are really hoping this is some holy grail to allow them to write in their favorite language for the web platform…
> more secure
Is it? How do we know? The attack surface in browsers is huge.
Re: Bringing the web up to speed with WebAssembly
#48I suspect that the use cases for WebAssembly will be something like this:
- - 60% ad and tracking obfuscation
- 20% annoying scrolling and transitions
- 10% hostile code
Re: Bringing the web up to speed with WebAssembly
#49I suspect that the use cases for WebAssembly will be something like this: - - 60% ad and tracking obfuscation - 20% annoying scrolling and transitions - 10% hostile code
That's about the breakdown for Javascript too, right?
Re: Bringing the web up to speed with WebAssembly
#50Earlier quoted context omitted.
We had that in the 90s. We called it Java.
Java only had one closed source implementation and had many security issues during its life. It wasn't designed for proper sandboxing and for having multiple implementations in the first place. And its communication with the rest of the browser was done through a slow and ugly channel (IIRC everything had to be sent around as strings).
And how much of that is true today?