Live data from Hacker News

W3C recommends WebAssembly

w3.org

91–100 of 350 posts

Re: W3C recommends WebAssembly

#91
post #81
post #71

Earlier quoted context omitted.

> Does anyone have any good intro resources for WebAssembly for noobs? Wasm proper isn't really a technology for noobs. This is like asking "Does anyone have an introduction to x86_64 machine code, the ELF linker spec and the SysV ABI for noobs?". It's sort of the wrong part of the problem. What you want in that case is "C programming on linux for noobs". So try googling for "emscripten tutorial" or (if you swing clo…

That sounds like the use case would be to insert some WASM component (that is a big heavy application / operation) into traditional web application framework as needed. Less so an entire overhaul of web applications as it is a powerful tool to be deployed for things we don't do in the browser now because there is no way to / it would be a bear to do in JavaScript due to ... JavaScript being JavaScript ;) Of course th…

Really the only available use case is inserting a wasm component into a traditional web application framework. Wasm code can only be loaded from JS, it can only be invoked from JS, and it's only way to affecting the world outside the VM is to call functions in JS that are going to do something to a user-visible DOM.

This is all still traditional web development. It's just a way to target other runtimes to a sandbox in the same environment.

Re: W3C recommends WebAssembly

#92
post #52
post #19

Does anyone have any good intro resources for WebAssembly for noobs? I've read articles here and there seen some in person demos, and honestly struggle to understand what it is / how it would / works relative to the current state of JavaScript frameworks. Often I'm approaching it from a JavaScript framework (React/Vue/Angular) approach as I'm a bit of a noob to the industry and that's generally my day job working on…

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?

Javascript is pretty accessible even when minified and optimised via something like closure.

WASM requires a lot more knowhow to reverse engineer; I've had to do it a few times for CTFs and some blockchain-related tools that use them, and it's a lot trickier compared to JS.

Re: W3C recommends WebAssembly

#93

This 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…

I actually don't believe that the inherent transparency of web pages adds that much. It's nice to have, but I don't think it's integral. If there were legit ways to obfuscate ... I'm doubtful we'd be missing much.

Re: W3C recommends WebAssembly

#94
What's the debugging situation like for developing WASM apps? I'm doing a lot of TypeScript+WebGL work right now, and though TS is fairly nice, my use case requires being aware of not allocating too many new objects frequently, and that kind of control would be easier in something like C++ or Rust. I've been thinking of hacking together a small test project with WASM+WebGL to see what it's like, but I get the sense it might still be more hassle than it's worth to use in production. Currently I can easily set breakpoints in my TS code, I can see how much memory is allocated by which functions, how much time is spent in each function, etc. very easily. If there's a way to do these kinds of things with WASM in another language, that would be fantastic.

Re: W3C recommends WebAssembly

#96
post #13
post #8

This is bad for frontend JavaScript being "open" for review, right? Companies will ask their developers to deliver WASM resources in the name of performance. As a notable side-effect, it will become harder to review how websites work. Yes, I'm sure there will be reverse-compilation tools for WASM, but still.

So much frontend JS has been packed and minified now that I’m not sure it will make that much difference. Reviewing Open Source code is still a far superior way to understand how code works, imo.

Unminified javascript is far easier to understand than disassembled code which originated from compiled C++ or Rust.

It is possible to disable half of the paywalls on the web just by looking at the JS code. I can see why certain parties would push really hard to introduce Webassembly. The performance argument is just a pretext because today's jit compilers for Javascript are really good.

Re: W3C recommends WebAssembly

#97

Whatever 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…

I think about this too. uBlock origin is already running into issues with trackers disguising themselves as first-party, what about when those trackers are genuinely first-party, and bundled with the page's js (which you can't just outright block)? What happens when those trackers are bundled and compiled to wasm along with the sites js? Do we then analyze the wasm and try to guess which parts are necessary for a site to function and which parts are the tracking?

I'm not trying to be overly cynical here, all of these topics remind me of high school when I'd download mildly-sketchy executables, decompile them, and try figure out whether or not they were safe to run. I would love to poke around with reverse engineering wasm, but I'd rather not have to do that every time I visit a new website.

Re: W3C recommends WebAssembly

#98
post #64
post #23

Hopefully this also means that Javascript is going away for good

It doesn't. Browsers will have to continue to support javascript indefinitely, simply because doing otherwise would break most of the web. Also, the use cases for javascript and webassembly don't overlap enough for one to replace the other in most cases. Javascript is a text-based scripting language you can write in any editor (the sprawling morass that is the current js development ecosystem notwithstanding,) but WA…

> It may mean that other languages can be deployed in the browser as easily as javascript, which may or may not be good depending on your point of view.

That's exactly what I hope happens. There are so many good languages out there that having to be stuck with javascript for the modern web is a crime.

Re: W3C recommends WebAssembly

#99

Whatever 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…

Indeed, HTML = World Wide Web

If your "web"site can execute arbitrary code, and/or violates HTML guidelines (required for web crawlers or accessibility software to work, or for browsers to tweak the layout) and/or requires JavaScript / Flash / Java to run properly, then it might be part of the Internet, but it's certainly not part of the World Wide Web!

Re: W3C recommends WebAssembly

#100
post #91
post #81

Earlier quoted context omitted.

That sounds like the use case would be to insert some WASM component (that is a big heavy application / operation) into traditional web application framework as needed. Less so an entire overhaul of web applications as it is a powerful tool to be deployed for things we don't do in the browser now because there is no way to / it would be a bear to do in JavaScript due to ... JavaScript being JavaScript ;) Of course th…

Really the only available use case is inserting a wasm component into a traditional web application framework. Wasm code can only be loaded from JS, it can only be invoked from JS, and it's only way to affecting the world outside the VM is to call functions in JS that are going to do something to a user-visible DOM. This is all still traditional web development. It's just a way to target other runtimes to a sandbox i…

Actually with the WebAssembly System Interface you can interface WebAssembly with any platform, it doesn't need to be a javascript vm. https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webas...
Post reply on HN