Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

W3C recommends WebAssembly

w3.org

Post reply on HN
Print view View original

121–130 of 350 posts

Re: W3C recommends WebAssembly

#121

Post by reificator »

mdszy wrote: post #114
reificator wrote: post #110

Earlier quoted context omitted.

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.

I'm not arguing openness. Merely that minified js can be understood with some effort.

Re: W3C recommends WebAssembly

#122

Post by krapp »

BlueTemplar wrote: post #99
6gvONxR4sf7o wrote: post #69

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!

> Indeed, HTML = World Wide Web

The WWW is a network built on a set of protocols. HTML is a markup language that allows for (indeed, that is is designed to facilitate) embedding and linking binary and executable content, including javascript, flash, java, audio, video, as well as marking up text. HTML is one, but not the only, content-type which can be distributed across the WWW. This is fundamental to the design of HTTP and the intent of HTML and the web itself.

By your rationale, no site created after the addition of the , or tags in HTML could be considered a part of the WWW, which would exclude the entirety of the web after HTML 3.2. This is "not even wrong" levels of ridiculousness.

Re: W3C recommends WebAssembly

#123

Post by throwGuardian »

dmvinson wrote: post #14

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…

Why should someone else's website code forced to be "free"?

Re: W3C recommends WebAssembly

#124

Post by mbrock »

re-actor wrote: post #25
mbrock wrote: post #18

Earlier quoted context omitted.

Doesn’t that reasoning also imply that GNU and Linux are awfully opaque and not free nor open, since they are typically distributed as binaries?

If the binaries were the only way to access GNU or Linux then yes, obviously. That's not the case now is it.

Right, because when you distribute free software in binary form, you make sure to make the source code available with a copyright license disclaimer allowing redistribution. This applies exactly to WebAssembly software just as it does with Java software. Software freedom is compatible with binary distribution.

Re: W3C recommends WebAssembly

#125

Post by iudqnolq »

voxic11 wrote: post #108
bogwog wrote: post #84

Earlier quoted context omitted.

So are you saying that reverse engineering javascript is easy? Or that it's easier than reverse engineering wasm? I don't know much about web assembly, but x86, which is much more complicated with thousands of instructions, has been successfully reverse engineered basically since forever. There are decompilers that can automatically reconstruct source code in C or C++ from a binary blob. Compared to javascript, the b…

But if the WASM was compiled from javascript or some other language that isn't very C-like then the de-compiled C or C++ code is going to be very difficult to follow. At the very least with obfuscated javascript you are going from js => js => js. Rather then from js => WASM => C++.

But going to c instead of js is an implentation technicality. If WASM becomes commonplace I'd be shocked if some group of kind souls doesn't open source a decompiler to minified js .

Re: W3C recommends WebAssembly

#126

Post by maeln »

kick wrote: post #65
maeln wrote: post #34

Earlier 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.

"RISC-V is open, you can't compile proprietary binaries for RISC-V."

That is not what I said, don't try to create a fake argument.

You real sentence should be "RISC-V instruction set is open, therefor I can see whatever a binaries is doing via the instruction it is executing." Doesn't mean its free, doesn't mean its easy to reverse engineer whatever the binary is doing, but you have everything to do it.

Re: W3C recommends WebAssembly

#127

Post by bhaak »

asdfman123 wrote: post #73
k__ wrote: post #43

Earlier quoted context omitted.

I think people starting to pump giant binaries to the browser will lead to JavaScript leveraging its strengths and getting even better.

I don't get why binaries should be more bandwidth-intensive than JS. I guess in a sense you already have the JS engine installed with, say, Chrome, which is essentially a runtime. Why can't other runtimes come prepackaged? What am I missing here?

Nobody wants another fat runtime that is as entangled with the browser engine as the JS engine is.

Getting the JS engine to be fast was a tremendous trouble and you wouldn't want to sink as much engineering power into another runtime that will have a smaller reach than the JS engine.

Rather use that skills to make WASM faster.

Re: W3C recommends WebAssembly

#128

Post by mbrock »

mtrower wrote: post #33
mbrock wrote: post #18

Earlier quoted context omitted.

Doesn’t that reasoning also imply that GNU and Linux are awfully opaque and not free nor open, since they are typically distributed as binaries?

Well, for one thing, mature debuggers exist (the equivalent to the tooling he inquired about for .wasm). More importantly, however, anything GPL must make source available and reasonably accessible. There is no such guarantee or even expectation for random programs on the web.

Indeed, huge amounts of JavaScript that’s already out there does not come with a free software license. The FSF has been complaining about this for years.

As for debugging, this is not a particularly hard or fundamental problem. It’s basically solved already.

https://developers.google.com/web/updates/2019/12/webassembl...

Re: W3C recommends WebAssembly

#129

Post by EvanAnderson »

6gvONxR4sf7o wrote: post #69

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…

Even if we don't lose the HTML-centered model, we are probably going to lose control of our browsers. Eventually somebody is going to ship a product that's nothing more than a browser implemented in WASM that runs inside your browser. The "inner browser" won't have content filtering, privacy controls, DOM inspector, or a Javascript debugger (for the Javascript engine running on the "inner browser") that you can interact with. You'll have to agree to let them run arbitrary code on your machine to even view the "website". There will be no "browse w/o Javascript" option in that future.

The kind of jerks who liked adding Javascript to block right-clicking, blocking "Paste" into password fields, etc, are going to absolutely love using the browser-in-a-browser product to deliver their "website".

For the inevitable replies: Yes-- you can already do this with minified Javascript. WASM, being targeted for performance, is just going to make this kind of asshattery faster.

Re: W3C recommends WebAssembly

#130

Post by adev_ »

6gvONxR4sf7o wrote: post #58
dmvinson wrote: post #14

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…

Meanwhile here I am running around with js off by default. Most of the internet still works. More sites work better with js off than work worse. I hope webassembly doesn't change that into a world where the "js off" analogy is "running my OS without the ability to execute programs."

> Meanwhile here I am running around with js off by default. Most of the internet still works.

Just wait 5 more years that 80% of the web switch to React / Vue / TheNewHypeSPAFramework and with or without WASM, you will be unable to browse "js off".

The blame here is not on WASM but on the abuse of client side rendering and "everything as an App" when most page are just barely interactive documents.

The Web succeeded where Flash / ActiveX / JavaApplet / Sliverlight failed because:

- it was open

- it was document oriented.

And that we tend to forget a bit too easily about it.

Post reply on HN