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

WebAssembly: a binary format for the web

2ality.com

Post reply on HN
Print view View original

91–100 of 164 posts

Re: WebAssembly: a binary format for the web

#91

Post by awqrre »

haberman wrote: post #40
Animats wrote: post #12

From Java applets to Java applets in twenty years.

Java applets were slow to load because fast loading was never made a priority. WebAssembly is prioritizing small size and fast loading. Java Applets were completely isolated from the surrounding web page, and vice-versa. I tried writing XEyes as a Java Applet back in the day, but the eyeballs could only follow the cursor while the cursor was directly on top of the applet's rectangle. WebAssembly operates on the singl…

There is no reason to use a binary web format if your only concern is fast web loading...

Re: WebAssembly: a binary format for the web

#92

Post by pinealservo »

kmicklas wrote: post #58

Why does everything about WebAssembly make such a big deal about it being AST based rather than a stack or register machine? Sure this is a meaningful technical difference but I don't see why it's really a "selling point".

Here are some arguments from the guys who did something like this before for Oberon: ftp://ftp.cis.upenn.edu/pub/cis700/public_html/papers/Franz97b.pdf

To summarize:

1. Much smaller representation, which will mean faster download times 2. More control-flow structure retained, which means less needs to be rebuilt by JIT-compilers. 3. As a corollary of #2, we get easier and more helpful 'decompiling' of code blobs 4. Another corollary of #2: easier analysis for safety properties

Re: WebAssembly: a binary format for the web

#93

Post by icebraining »

denniskane wrote: post #8
josteink wrote: post #5

Earlier quoted context omitted.

PNaCl is cancer to the web and requires Google Spyware. No thanks.

PNaCl allows me to run vim and python natively in my browser. Thanks. (Shout out to my boys, Sam Clegg, Brad Nelson and company!)

Finally catching up to Firefox 1.5, eh? :) https://brendaneich.com/2005/09/python-for-xul-scripting/

Re: WebAssembly: a binary format for the web

#94

Post by asdfologist »

wbillingsley wrote: post #70
haberman wrote: post #40

Earlier quoted context omitted.

Java applets were slow to load because fast loading was never made a priority. WebAssembly is prioritizing small size and fast loading. Java Applets were completely isolated from the surrounding web page, and vice-versa. I tried writing XEyes as a Java Applet back in the day, but the eyeballs could only follow the cursor while the cursor was directly on top of the applet's rectangle. WebAssembly operates on the singl…

There was a JavaScript to Java bridge in most browsers -- you could simply write a JS event handler that called a public API in your applet. Before XMLHttpRequest became reliable across browsers, a fairly common trick was to use a 1 pixel Java applet to do the asynchronous calls to the server, and then call back out to JavaScript to manipulate the DOM. Java only "behaved differently" if you wanted your applet to pain…

Why was this downvoted? I found this quite informative.

Re: WebAssembly: a binary format for the web

#95

Post by azakai »

awqrre wrote: post #91
haberman wrote: post #40

Earlier quoted context omitted.

Java applets were slow to load because fast loading was never made a priority. WebAssembly is prioritizing small size and fast loading. Java Applets were completely isolated from the surrounding web page, and vice-versa. I tried writing XEyes as a Java Applet back in the day, but the eyeballs could only follow the cursor while the cursor was directly on top of the applet's rectangle. WebAssembly operates on the singl…

There is no reason to use a binary web format if your only concern is fast web loading...

A binary format can help tremendously with fast web loading:

1. Code size can be significantly smaller, reducing download time (even with gzip; tests show a 30% win).

2. Parse times for a binary format can be much faster than for code as text, by a very large margin.

Re: WebAssembly: a binary format for the web

#96

Post by icebraining »

denniskane wrote: post #42
nicalsilva wrote: post #33

Earlier quoted context omitted.

What? Whether or not a browser matters depends on the amount of people using it, not on whether you can install it on several operating systems.

If someone is trying to turn this into a moral discussion about the positive value of the so-called "open web" to humanity, then the question of whether the actual codebase is open-source, and runs on every platform is of primary importance. My original reply was to a part of the article that talked about the "evil" non-open nature of web-technologies that are not humanly readable, textual HTML/CSS/JS. Then someone r…

If the measure is moral rectitude, how is Firefox a "fuzzy memory", while Chrome isn't despite Google being "basically Skynet"?

Your whole line of argument is confusing.

Re: WebAssembly: a binary format for the web

#97

Post by zmmmmm »

As laudable as the goal of improving performance is, I hope this never takes off. Why? Because it will take about 5 minutes from 90% of the web to go from open, transparent, easily reverse engineerable source code to essentially giant blobs of secret binary code. People will pay lip service to performance but 99% of the reason that web sites will implement this will be to cover up their code, keep secret their implementation techniques and technologies, hide poor code and poor security.

I honestly think that one of the key ingredients to the success of the web is that just about any web page you can see, just about anyone with modest knowledge can trivially work out how it was done. It is only an accident of history that it worked out that way. But the effect has been to spread knowledge far and wide and it has greatly contributed to the success of web technologies. Furthermore, I can easily look at the source code for my bank web site or any web site I want to trust and get a good idea of how solid their implementation is. Yes I can't inspect the back end, but a whole slice of front-end security issues are easy for me to check for myself. This kind of scrutiny will get a good bit harder if web assembly becomes adopted.

Re: WebAssembly: a binary format for the web

#98

Post by pippy »

haberman wrote: post #40
Animats wrote: post #12

From Java applets to Java applets in twenty years.

Java applets were slow to load because fast loading was never made a priority. WebAssembly is prioritizing small size and fast loading. Java Applets were completely isolated from the surrounding web page, and vice-versa. I tried writing XEyes as a Java Applet back in the day, but the eyeballs could only follow the cursor while the cursor was directly on top of the applet's rectangle. WebAssembly operates on the singl…

The example in article had went from a GZIPed size of 4.1 MB to 3.0 MB. For the massive increase of obscurity the transferal optimization trade off isn't that great. But it's a double edged sword, I'd also wager obscurity would entice larger AAA game developers to start targeting web.

Re: WebAssembly: a binary format for the web

#99

Post by azakai »

dbpokorny wrote: post #34

As far as the intersection of (innovation in web technology) and (innovation in programming languages) is concerned, I think the focus on performance is like going backwards in time, perhaps to the mid 90s. I feel like these innovations are being turned into a kind of "social media spectacle" with relatively little discussion of what innovation really means in this context. For example: I don't understand why Python,…

> For example: I don't understand why Python, JavaScript, Java, Ruby, and so on have not delivered tools that ease the path for those who wish to write applications designed to run code from untrusted sources. I think this would make the web a lot more competitive and overall healthier as an independent institution.

You would have to ask the Python, Ruby etc. people why they don't work on it more, but from the side of the web, there is plenty of effort. First, several languages like those have been ported to the web, by porting their VMs:

http://kripken.github.io/lua.vm.js/lua.vm.js.html

http://ruby.dj/

https://github.com/replit/empythoned

Instead of each language needing to devise a sandboxing mechanism, by porting them to the web, they can be run safely there. This is also much safer for the web: just one sandbox, instead of many.

WebAssembly will improve those ports, by reducing code size and download times and so forth.

Re: WebAssembly: a binary format for the web

#100

Post by hackcasual »

azakai wrote: post #95
awqrre wrote: post #91

Earlier quoted context omitted.

There is no reason to use a binary web format if your only concern is fast web loading...

A binary format can help tremendously with fast web loading: 1. Code size can be significantly smaller, reducing download time (even with gzip; tests show a 30% win). 2. Parse times for a binary format can be much faster than for code as text, by a very large margin.

Parse time is basically free with WebAssembly
Post reply on HN