What I'm thrilled to see is an optimization of binary sizes in compilers and libraries. Maybe <1MB native apps will become common (or few MB of code for single webpage will become standard)
W3C recommends WebAssembly
111–120 of 350 posts
Re: W3C recommends WebAssembly
#112Does anybody know the state of the art for wasm tooling? I have used emscripten but are there any excellent 'higher level' tools? The worst part was writing the interface between the wasm and JS.
Re: W3C recommends WebAssembly
#113This sounds interesting, but personally, I am worried that this will just turn into yet another browser technology that will be used to abuse and track users. I really hope I am wrong.
Re: W3C recommends WebAssembly
#114Earlier quoted context omitted.
When was the last time you were able to unminify a javascript file that you wanted to investigate and were able to make sense out of it?
Within the last month or two, certainly. You have to be willing to edit it, start renaming variables to describe what they hold, rename them again if they get something unexpected assigned, rename functions once you have a good idea of what they're trying to do, and repeat until everything has a name.
So it sounds like you're having to reverse engineer it, similar to any "binary blob".
Sounds very "open" to me.
Re: W3C recommends WebAssembly
#115Earlier quoted context omitted.
Please, can we stop having this argument every time there is an article about webassembly ? WASM not any more obfuscated than any minified JS. Being a bytecode doesn't make you "unfree". You have access to the same tool to debug JS and WASM. And the WASM specification is open. There is literally no difference between running JS or running WASM.
Maybe I’m misunderstanding something but WASM is meant to be compiled from other languages and that source is lost, unlike minified javascript, isn’t it?
Minifying JavaScript is as destructive as compiling from any language to WASM. The original source are also lost when minifying JS. The fact that the transpilation/compilation target is the same langage doesn't mean its any less destructive.
Re: W3C recommends WebAssembly
#116Whatever you think about javascript, I love the historic separation between content and interactivity. I dislike that so many static pages won't load without JS and that we're moving further in that direction. I hope the evolution towards "browser as OS" doesn't hurt the content vs interactivity separation. Could we ever lose the HTML centered model? That could mean we lose hackability and the ability to write extens…
> Could we ever lose the HTML centered model?
This is what people should be worried about, not replacing JS. It became a kind of popular hot-take for a while to say that separation of concerns was a mistake, and that's not how apps get built in the real world, and what we really need is a way to encapsulate all of our DOM and CSS in JS. We need to start pushing back against that idea and keep emphasizing that separation of concerns is really important for end users.
HTML is the interface you write to. It's not a document layout language for authoring, it is a render target that is understandable and manipulable by the end-user. It's a fantastic idea that enables a lot of user-land innovation, and it's one of the biggest reasons why the web is still a relatively good platform to interact with as an end-user.
A lot of architecture decisions on the web haven't aged well, but separating content, styling, and logic was a fantastic architecture decision that is still as relevant today as it ever was. And the rise of the web as an application platform has only made it more important, not less.
Re: W3C recommends WebAssembly
#117This feels like another step away from the free and open web many people are clamoring for. Distributing opaque binaries with websites instead of Javascript is a step past even the obfuscated minified javascript files meant to be confusing. At least those can still be debugged, stepped through, and explored freely by the end user if they want to learn or reverse engineer. Is there any tool or standard being worked on…
Please, can we stop having this argument every time there is an article about webassembly ? WASM not any more obfuscated than any minified JS. Being a bytecode doesn't make you "unfree". You have access to the same tool to debug JS and WASM. And the WASM specification is open. There is literally no difference between running JS or running WASM.
This is a valid concern. Among many things it is much easier to audit higher level code than bytecode.
Re: W3C recommends WebAssembly
#118Earlier quoted context omitted.
Please, can we stop having this argument every time there is an article about webassembly ? WASM not any more obfuscated than any minified JS. Being a bytecode doesn't make you "unfree". You have access to the same tool to debug JS and WASM. And the WASM specification is open. There is literally no difference between running JS or running WASM.
A binary format is no more obfuscated than minified JS? What now? Going to need some clarification on how that's the case.
WASM is a binary and a text format. You can turn any WASM binary to the text format and have a readable version of the blob. Firefox can automatically show you the text version of a WASM blob.
So no, there is no difference with a minified JS. Just because there are in a text format don't make them any more easy to reverse engineer.
Re: W3C recommends WebAssembly
#119Earlier quoted context omitted.
Please, can we stop having this argument every time there is an article about webassembly ? WASM not any more obfuscated than any minified JS. Being a bytecode doesn't make you "unfree". You have access to the same tool to debug JS and WASM. And the WASM specification is open. There is literally no difference between running JS or running WASM.
This is a valid concern. Among many things it is much easier to audit higher level code than bytecode.
What can't you do? How is it any easier to audit minified JS than a WASM blob ? Everytime this argument is raised there is no valid argument to explain why WASM would be much worse than the current state of JS.
Re: W3C recommends WebAssembly
#120Earlier quoted context omitted.
> and pretend no distinction exists between the two. What's the distinction then? That obfuscated javascript can be looked at by people who don't know how to use a hex editor?
Javascript-as-bytecode is a metaphor, not a technical description. Javascript is not actually bytecode in the same way that a .java file is not java bytecode.
Okay. Thanks for that.