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

Web Assembly

github.com

Post reply on HN
Print view View original

21–30 of 70 posts

Re: Web Assembly

#21

Post by s3th »

spicyj wrote: post #18
s3th wrote: post #11

Earlier quoted context omitted.

We're working hard to make sure that WebAssembly is a first-class citizen in the open web platform in ways that other native execution environments didn't accomplish. For example, it's a goal to have WebAssembly modules interopt with the ES6 module system, and as soon as GC is supported, you'll be able to access the DOM and the JavaScript context in WebAssembly [0]. Both of these are huge steps towards ensuring that…

> As soon as GC is supported, you'll be able to access the DOM and the JavaScript context in WebAssembly. Do you have any anticipated timeline for this? For React, at least, we're eagerly looking forward to the opportunity to write at a lower level while maintaining the same JS-facing API.

We'll start tackling GC as soon as we finish the MVP [0]. No timeline yet, but we consider it essential to the high level goal of integrating well into the existing platform.

[0]: https://github.com/WebAssembly/design/blob/master/GC.md

Re: Web Assembly

#22

Post by pdkl95 »

s3th wrote: post #10
dccoolgai wrote: post #6

With the adoption of wasm, won't the web become inherently less hackable? Right now i can pretty-print some minified js and at least have a basic idea of what APIs are getting called. Difficult to see how one could do the same with wasm. Not saying wasm is a bad idea (i think it's good), I'm just concerned about what this will look like in terms of keeping the nuts and bolts of the web semi-readable.

It's definitely a goal to make sure that wasm is as readable as possible. The binary format will be able to be "pretty-printed" into a textual format [0]. We haven't finalized the exact format yet, but it will be much more readable than current asm.js javascript [1]. [0]: https://github.com/WebAssembly/design/blob/master/TextFormat... [1]: https://twitter.com/BrendanEich/status/643828456631857152 (Disclaimer: I'm a G…

The existence of a "readable" parse tree doesn't provide the same level of "hackability" or openness as a DOM. You're comparing it to asm.js, but that isn't particularly relevant as asm.js that widely used (emscripten is cool, but the lack of readability you mentioned is a barrier to wider adoption in the general case).

WebAssembly will impact a lot more than just the pages currently using asm.js, and I fear it will introduce the Halting Problem in to a lot more areas. The concern isn't asm.js - it's frameworks like angular (no-content-without-js websites are already a problem). The availability of a parse tree doesn't help if I have to run it to access the structure that is current available in the DOM. With the current drama over adblopcking, I expect advertisers will jump at a technology that lets them treat clients as something they control. (compile an obfuscated version of freetype into small WebAssembly download will be be the key features).

Re: Web Assembly

#23

Post by ossreality »

dccoolgai wrote: post #6

With the adoption of wasm, won't the web become inherently less hackable? Right now i can pretty-print some minified js and at least have a basic idea of what APIs are getting called. Difficult to see how one could do the same with wasm. Not saying wasm is a bad idea (i think it's good), I'm just concerned about what this will look like in terms of keeping the nuts and bolts of the web semi-readable.

No, just like every other person who thought they were the first to notice the most obvious drawback of a binary format. Except that it's IL and that they've already planned for that. Why do people always ask these questions as if they're the first person to ever thing about them.

I dunno, it just seems like once a week something WASM comes up and this same exact question gets asked

Re: Web Assembly

#24

Post by dorfsmay »

cauterize wrote: post #4

As someone who works in the web space, albeit on the back-end, can anyone explain why a project like this is desired over a better language / run-time?

The idea of a good language evolves over time, and varies among people. Look at how many languages transpile to JavaScript today. If you ask the users of those languages, they'll tell that their language is the "better language" you're looking for.

Re: Web Assembly

#25

Post by hn1234 »

s3th wrote: post #10
dccoolgai wrote: post #6

With the adoption of wasm, won't the web become inherently less hackable? Right now i can pretty-print some minified js and at least have a basic idea of what APIs are getting called. Difficult to see how one could do the same with wasm. Not saying wasm is a bad idea (i think it's good), I'm just concerned about what this will look like in terms of keeping the nuts and bolts of the web semi-readable.

It's definitely a goal to make sure that wasm is as readable as possible. The binary format will be able to be "pretty-printed" into a textual format [0]. We haven't finalized the exact format yet, but it will be much more readable than current asm.js javascript [1]. [0]: https://github.com/WebAssembly/design/blob/master/TextFormat... [1]: https://twitter.com/BrendanEich/status/643828456631857152 (Disclaimer: I'm a G…

Seth, the wasm "Text Format" doc at [1] says one of its purposes is "Presentation in browser development tools when source maps aren't present (which is necessarily the case with the Minimum Viable Product (MVP))" and that "Debuggers and profilers will present binary code using this textual format."

However, bugs like [2] suggest to me that the Chrome and Firefox teams do not place an especially high priority on readability and debuggability with source maps in plain old JavaScript. Basically, it's impossible to use Chrome Devtools to see original variable names from the source file (e.g. 'jquery.js') instead of the minified file (e.g. 'jquery.min.js') mapped by the source-map file. This essentially makes source maps useless for debugging complex code and has been a known issue for almost two years.

The most recent comment in that ticket notes work is blocked until a new version of the sourcemap spec is shipped, but the linked resources indicate there hasn't been any public activity on them in three weeks with the Sterland proposal [3] and three months with the Fitzgerald proposal [4].

If keeping the web open source is indeed a priority of Google and Mozilla, then why haven't more resources been allocated to develop those specifications?

In brief, the lack of urgency for bugs like [2] suggests to me that Google and Mozilla don't take "The JavaScript Trip" described by Stallman [5] seriously. I fear that wasm could make it much worse.

-

1. https://github.com/WebAssembly/design/blob/master/TextFormat...

2. https://code.google.com/p/chromium/issues/detail?id=327092

3. https://gist.github.com/asterland/edf028ed7947c8c258d1

4. https://github.com/fitzgen/source-map-rfc/blob/scopes-and-bi...

5. http://www.gnu.org/philosophy/javascript-trap.en.html

Re: Web Assembly

#26

Post by pdkl95 »

jacobolus wrote: post #12
ino wrote: post #9

Earlier quoted context omitted.

Big regression in accessibility, copy/paste, automatic translation, everything that makes the web uniquely great.

The #1 thing that makes the web uniquely great is that all you need to do to access a program is to paste a short string into a box, and your browser takes care of the rest. Anyone can slap a website onto a server they control, and anyone in the world can then access it. Outside that one advantage, web applications (not talking about simple documents here) are worse in almost every way than native applications. (It’s…

> web applications are inherently second-class citizens on every platform.

Yes. By design. If a webpage can impersonate a local app, you have a serious security problem.

> They make it hard for users to load/save local data

There are good reasons for a lot of that, from denial-of-service protections, limiting stealth cookies, etc.

> They don’t interoperate with other applications on the system.

That's a feature.

> They flagrantly violate UI design conventions on every platform.

The user agent can render the page however it wants. This is a feature.

> They can’t access most local hardware devices.

Are you trying to introduce even more security problems?

> They are difficult or impossible to build proper cryptographic primitives on top of.

That's not the place you should be implementing crypo.

> Accidentally pressing the back button can destroy hours of user work.

Ok, that one would be nicer to fix, but that's a problem for the browser, and shouldn't impact the page at all.

--

If you want to develop software that uses more than the web can provide, you should choose a platform that actually provides those features. There is a trade-off, of course, but making that kind of decision is a an important part of software engineering.

While many people have been ignoring some or all of the security aspects of programming, it is important to remember that anything connected (even indirectly) to a network is under attack, so security must be considered first.

Re: Web Assembly

#27

Post by pdkl95 »

eosrei wrote: post #16
dccoolgai wrote: post #6

With the adoption of wasm, won't the web become inherently less hackable? Right now i can pretty-print some minified js and at least have a basic idea of what APIs are getting called. Difficult to see how one could do the same with wasm. Not saying wasm is a bad idea (i think it's good), I'm just concerned about what this will look like in terms of keeping the nuts and bolts of the web semi-readable.

You'll be able to reverse engineer. Interpreting JS is a massive waste of CPU/battery for the majority of users. The savings is worth a slight increase in complexity for developers.

The solution to high CPU/battery usage is to send a static page. Invoking a new type of VM may help slightly, but it probably just moves the problem around.

Re: Web Assembly

#28

Post by s3th »

hn1234 wrote: post #25
s3th wrote: post #10

Earlier quoted context omitted.

It's definitely a goal to make sure that wasm is as readable as possible. The binary format will be able to be "pretty-printed" into a textual format [0]. We haven't finalized the exact format yet, but it will be much more readable than current asm.js javascript [1]. [0]: https://github.com/WebAssembly/design/blob/master/TextFormat... [1]: https://twitter.com/BrendanEich/status/643828456631857152 (Disclaimer: I'm a G…

Seth, the wasm "Text Format" doc at [1] says one of its purposes is "Presentation in browser development tools when source maps aren't present (which is necessarily the case with the Minimum Viable Product (MVP))" and that "Debuggers and profilers will present binary code using this textual format." However, bugs like [2] suggest to me that the Chrome and Firefox teams do not place an especially high priority on read…

It's easy to overlook bugs in a tracker the size of Chromium's--even important ones. Thanks for raising the issue again.

Re: Web Assembly

#29

Post by [deleted] »

pdkl95 wrote: post #26
jacobolus wrote: post #12

Earlier quoted context omitted.

The #1 thing that makes the web uniquely great is that all you need to do to access a program is to paste a short string into a box, and your browser takes care of the rest. Anyone can slap a website onto a server they control, and anyone in the world can then access it. Outside that one advantage, web applications (not talking about simple documents here) are worse in almost every way than native applications. (It’s…

> web applications are inherently second-class citizens on every platform. Yes. By design. If a webpage can impersonate a local app, you have a serious security problem. > They make it hard for users to load/save local data There are good reasons for a lot of that, from denial-of-service protections, limiting stealth cookies, etc. > They don’t interoperate with other applications on the system. That's a feature. > Th…

[deleted]

Re: Web Assembly

#30

Post by placeybordeaux »

pdkl95 wrote: post #22
s3th wrote: post #10

Earlier quoted context omitted.

It's definitely a goal to make sure that wasm is as readable as possible. The binary format will be able to be "pretty-printed" into a textual format [0]. We haven't finalized the exact format yet, but it will be much more readable than current asm.js javascript [1]. [0]: https://github.com/WebAssembly/design/blob/master/TextFormat... [1]: https://twitter.com/BrendanEich/status/643828456631857152 (Disclaimer: I'm a G…

The existence of a "readable" parse tree doesn't provide the same level of "hackability" or openness as a DOM. You're comparing it to asm.js, but that isn't particularly relevant as asm.js that widely used (emscripten is cool, but the lack of readability you mentioned is a barrier to wider adoption in the general case). WebAssembly will impact a lot more than just the pages currently using asm.js, and I fear it will…

Why are you concered that it will "introduce the Halting Problem in to a lot more areas."?
Post reply on HN