Webassembly is incredibly hard to debug in the browser. Source maps give you a decent stack trace, but you can't evaluate variables. I'm hoping this situation improves.
Bringing the web up to speed with WebAssembly
131–140 of 172 posts
Re: Bringing the web up to speed with WebAssembly
#132I wonder how this will affect Java in the long term. In the comments about the JDK9 release, there was discussion about the JVM becoming a sort of language-agnostic platform where Java is a small part. It seems WebAssembly is occupying a lot of the same space, but from a sort of opposite direction (in the sense of providing the compilation target first). Java and the JVM obviously aren't going anywhere soon, but the…
Java is a language. It comes with a standard VM, compile mechanism, and bytecode. Fortunately, the Java platform is well segmented so that the language is a separate technology from those other pieces. Scala, for example, is a language different from Java, but still targets the compile mechanism and JVM. WebAssembly, by contrast, is not a language. It is only a bytecode and conforming container. Java could compile to…
I was a little unclear about this, but I meant Java in the broad sense of the Java ecosystem, including the JVM and the language. I was mostly wondering if languages will move toward WebAssembly as a target instead of the JVM, and what consequences that will have.
On the other hand, maybe I had Java the language in mind unconsciously at some level. You're right that you could have Java targeting WebAssembly instead of its standard bytecode, which I hadn't thought about.
At least now, it seems like the JVM offers some stuff that WebAssembly doesn't, but I have a hunch it won't stay that way in the long run.
There's been a lot of good discussion here about WebAssembly versus the JVM; it seems like lots of people have similar thoughts about this topic.
Re: Bringing the web up to speed with WebAssembly
#133I wonder how this will affect Java in the long term. In the comments about the JDK9 release, there was discussion about the JVM becoming a sort of language-agnostic platform where Java is a small part. It seems WebAssembly is occupying a lot of the same space, but from a sort of opposite direction (in the sense of providing the compilation target first). Java and the JVM obviously aren't going anywhere soon, but the…
In many ways, the JVM bytecode is a superset of WASM. That's why I wrote https://github.com/cretz/asmble .
Interesting--this seems forward-thinking and useful.
Re: Bringing the web up to speed with WebAssembly
#134Earlier quoted context omitted.
That doesn’t help, as the browser vendors ignore the W3C entirely anyway, and just do stuff in the WHATWG. And we already have a bluetooth stack for the web, USB drivers in JS, etc.
That is entirely incorrect for the WebAssembly CG and WG.
The WebAssembly grouo may be different, but in every other group I've seen, the browsers simply didn't care about what everyone else was doing.
To the point that they redefined the URL spec and then complained that cURL didn't fulfill it.
Re: Bringing the web up to speed with WebAssembly
#135Earlier quoted context omitted.
I hope not as HTML has accessibility built in while canvas doesn’t. No need to take a step backwards on this. I’m okay with rendering to canvas but long as accessibility is taken into account. (Hint: most of the time it is not.)
I've said the same, but you just know somebody comes along and says "If we render our entire site into a it'll make ad blocking more difficult," and then poof there goes the last 20 years of work on accessibility.
Most ad blocking is about intercepting specific urls, which can work at a layer below javascript.
They can also do server side ads and make the url indistinguishable from another image asset. They haven't, so it isn't 'dire' enough yet.
Re: Bringing the web up to speed with WebAssembly
#136Yet, 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?
Figma is using it (though I'm not sure how much money they're making at this point): https://blog.figma.com/webassembly-cut-figmas-load-time-by-3...
Re: Bringing the web up to speed with WebAssembly
#137We spent a long time wishing for a VM for the web that could be targetted by any language and being told that wasn't possible. WebAssembly will finally deliver that and it seems to be done by the same people/organizations. What changed?
>We spent a long time wishing for a VM for the web that could be targetted by any language and being told that wasn't possible. Technologically speaking, this has been possible since the days of p-code. The browser vendors have only just decided that it's something that's actually beneficial
It's also been possible since Javascript.
Re: Bringing the web up to speed with WebAssembly
#138> nothing in its design depends on the Web or a JavaScript environment. It is an open standard specifically designed for embedding in multiple contexts, and we expect that stand-alone implementations will become available in the future.
I did not realize that the design was this ambitious! I wonder how lightweight a standalone implementation could be, while still getting competitive performance.
Re: Bringing the web up to speed with WebAssembly
#139I 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
Add DRM to the 60% and I'd agree.
Re: Bringing the web up to speed with WebAssembly
#140Earlier quoted context omitted.
HTML is also much a more convenient encoding for content than writing on the canvas. It's fully declarative¹ and everything. Yet, plenty of people already prefer to send you a black page and manually write everything on the DOM's document. I certainly do not understand them, but they are way too common. 1 - You just write your content, and it's there. There isn't more declarative than that.
HTML isn't great for application code. That's the issue, and anyone targeting WASM and canvas would be looking to recreate desktop apps on the web, not traditional websites.
Yes, it's bad for applications. But that does not explain why people send their text based pages as javascript.