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

Compiling to WebAssembly: It’s Happening

hacks.mozilla.org

Post reply on HN
Print view View original

211–220 of 225 posts

Re: Compiling to WebAssembly: It’s Happening

#211

Post by kuschku »

modeless wrote: post #176
kuschku wrote: post #82

Earlier quoted context omitted.

That now we can’t read the source of webpages at all anymore? The whole "anyone can look at it, learn from it" part is gone? We’re steering towards more proprietary code. Say, for example, if I want to run Google’s "Star Wars" easter egg in Firefox. With JS, I could grep through the de-uglified and de-obfuscated code quickly, and find that its useragent detection would work if I’d just append "AppleWebKit Chrome/45.0…

You can't read the obfuscated code directly. You have to use tools to deobfuscate it. With Web Assembly it will be the same. There will be tools to help you read the code. You may proclaim that they won't work as well but I think it's premature to say that. Web Assembly is not machine code.

Web assembly is very generic byte code.

I fear I’d end up spending ages in IDA breaking a DRM scheme implemented in WebAssembly, just like I did with NaCl.

That’s not neat.

Re: Compiling to WebAssembly: It’s Happening

#212

Post by wtetzner »

1ris wrote: post #185
wtetzner wrote: post #124

Earlier quoted context omitted.

> scheme is not powerfull either In what sense is Scheme not powerful? It has TCO, syntax-rules, call/cc, etc. Of course, all of those are things scheme has that JavaScript doesn't.

No types, a very minimal syntax, a standard library so slim that everything interesting is a implementation-detail. And, as I a said, javascript has less. Javascript even lacks integer variables, while scheme has the numeric tower. (Although that is not required by rsr4/rsr5 and that what most implementations care about)

> No types, a very minimal syntax

I don't see how these make the language less powerful. Especially the syntax part, which plays a big part in Scheme's power, as an enabler for macros.

> a standard library so slim

I agree with this though.

Re: Compiling to WebAssembly: It’s Happening

#213

Post by mozumder »

jcfrei wrote: post #65
mozumder wrote: post #36

Earlier quoted context omitted.

If they wanted to do it right, then an HTTP requests itself should serve a compiled HTML binary based on an AST. The binary version of HTML.

I would consider that the worst scenario. If each website was its own binary application it would undo the open source aspect of websites (even though that's only partly true today due to all the obscured javascript). But maybe that would actually be desirable for all companies which rely on advertising revenue and want to prevent any modification of their web content (such as removal of ads). It'll be interesting to…

Just because it's a binary AST doesn't mean it's closed.

Re: Compiling to WebAssembly: It’s Happening

#214

Post by KirinDave »

1ris wrote: post #69
PuercoPop wrote: post #56

Earlier quoted context omitted.

> "walled gardens" that were Lisp machines back in the day, that force you to write code in Lisp, Lisp machines come with Fortran and C compilers.

I never used it, but allergly they where not only comming with a Fortran, but the best Fortan IDE.

The idea that UNIX is somehow the "open" and "inclusive" variant of computing is a good example of "The victors write history."

It's really frustrating to see people parrot it. UNIX succeeded for a lot of reasons, but not because of these. In fact, at the time it was the more restrictive and closed option. It also put a lot of burdens on the developer in the name of time-to-market.

The entire "worse-is-better" mythology is essentially a story of how market velocity is a powerful force in the face of "doing it well."

Re: Compiling to WebAssembly: It’s Happening

#215

Post by Arelius »

icebraining wrote: post #139
_cbsz wrote: post #12

Earlier quoted context omitted.

What would the GC scan? What do pointers look like? At the assembly layer, you have the flexibility to not have a C runtime (and therefore no C stack), and you might be doing fun things like having tagged pointers that the GC would have to know about. In short, the WASM layer is IMO the wrong layer for GC. I think the closest-layered applicable solution is caching & pinning guarantees for common libraries, which may…

The GC would scan whatever the program told it to scan, by using its API, like the Boehm GC library: https://en.wikipedia.org/wiki/Boehm_garbage_collector I think it only makes sense, seeing as interaction with the native JS VM will be inevitable for a long time.

Perhaps then you should just use the Boehm GC library then.

Re: Compiling to WebAssembly: It’s Happening

#216

Post by nly »

fulafel wrote: post #205
heinrich5991 wrote: post #204

Earlier quoted context omitted.

Can you explain that one? Does it have something to do with parseInt being able to take more than parameter?

Array.map does not work like map in other languages. They decided that map shall receive the array index as the second argument, and there's also a third argument that does something else. JS happily mashes these 3 arguments into parseInt's argument list of (stringValue, radix) without error. Hilarity ensues. (This code also sins against "never call parseInt without the radix argument", see point about too many minef…

Seems to me the answer here would be to bind the radix argument of parseInt with a wrapper before applying map

Re: Compiling to WebAssembly: It’s Happening

#217

Post by Arnavion »

jacobolus wrote: post #97
bromuro wrote: post #94

Earlier quoted context omitted.

> I'm clearly in the minority, but I had qualms about uglify and other source manglers [...]: they break the benefits of view source Not really: we have source maps for this.

“View source” is a tool for outside end-users who want to understand or reverse-engineer code on websites they don’t control. “Source maps” is a tool for inside developers trying to debug their own code. Whether or not the browser supports source maps is irrelevant if you don’t have access to the original code, but only the minified/mangled version with all single-character variable names.

>Whether or not the browser supports source maps is irrelevant if you don’t have access to the original code

Sourcemaps can embed the original source inline, though of course that is a decision made by the author and they can decide not to make sourcemaps that way. It is more likely that the end-user doesn't have access to the source maps anyway.

Re: Compiling to WebAssembly: It’s Happening

#218

Post by aboodman »

pjmlp wrote: post #181
aboodman wrote: post #165

Earlier quoted context omitted.

Your current (desktop) operating system allows these binaries to run with your full user privileges. Any software you download and run has complete access to all of the data from your user account, no matter which software created it. Software can interfere with other software (spyware), can affect anything on the account (malware), and can even harm the system itself (e.g., by consuming resources). Worst of all, bec…

> Your current (desktop) operating system allows these binaries to run with your full user privileges. Actually it can sandbox them already.

But doesn't, by default. And that's crucial. On the web I can just run any random program from anyone and there's a very strict limit on what it can do to me and to other software.

Re: Compiling to WebAssembly: It’s Happening

#219

Post by aboodman »

mdavidn wrote: post #187
aboodman wrote: post #165

Earlier quoted context omitted.

Your current (desktop) operating system allows these binaries to run with your full user privileges. Any software you download and run has complete access to all of the data from your user account, no matter which software created it. Software can interfere with other software (spyware), can affect anything on the account (malware), and can even harm the system itself (e.g., by consuming resources). Worst of all, bec…

The process model is a sandbox. Every process runs as if alone, with seemingly continuous processor time and memory addresses starting at zero. The ailments you described are all system calls, special access granted by the kernel. So the process model is not fundamentally different than the browser model, but WebAssembly enjoys two advantages: 1. The browser security model sagely segmented privileges by origin rather…

Totally agree. The process model is actually a better sandbox than, e.g., Firefox per-origin one (because it sandboxes CPU time and memory as well). But the shape of the sandbox is incorrect for the modern era.

Re: Compiling to WebAssembly: It’s Happening

#220

Post by bigger_cheese »

icebraining wrote: post #208
bigger_cheese wrote: post #160

Earlier quoted context omitted.

I learnt to write HTML files in the early 90's (The Geocities era as you refer to it - forget tables back then everything was frames). I learnt exactly how you surmised by using view source on existing websites. As a 13 year old kid who was mildly curious I was able to build a web site for my high school by hand in 'pure' html code. It looked laughably simple compared to the web pages of today but it was easy. I can…

In some ways, the recent HTML specs allows the dev to go back to that old-school handwriting. For example, instead of bringing in a JS framework, you could now just replace the input type with "date", and a modern browser would show the date picker.

That doesn't work in Firefox or IE - unfortunately my work has standardised around IE
Post reply on HN