Live data from Hacker News

WebAssembly: a binary format for the web

2ality.com

151–160 of 164 posts

Re: WebAssembly: a binary format for the web

#151
post #149

Earlier quoted context omitted.

When I got into computers there wasn't any view source button. We had to buy magazines and books to view any source. Still lots of us got interested and a few guys managed to build the initial web infrastructure without a view source button.

Back in my day we didn't have compilers, we twiddled the switches until the machines did what we want. Compilers just allow sub-par programmers to write code, we should better abolish them.

That has nothing to do with "view source" button.

I also doubt you are old enough to have used something like the Altair 8800 or have built your own computer from Elektor schematics.

Re: WebAssembly: a binary format for the web

#152
The major flaw in WebAssembly is the byte code itself. We will end up in a compatibility hell, because of course the specification will change. And there will be several implementations of WebAssembly, which will have their own quirks and flaws.

So the WebAssembly future will look like this: You will compile into WebAssembly multiple times, for different versions and implementations and you will need to deliver the correct artifacts to the clients.

The reason, the web still works is that everything is shipped to the client in source. And the client will then interpret and compile everything according to its capabilities.

WebAssembly will probably never gain traction because of this reality.

Re: WebAssembly: a binary format for the web

#154

Earlier quoted context omitted.

> 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. Probably because it is stupidly difficult to do robustly, especially when the language and standard libraries weren't originally designed to do that. Lua is perhaps best positioned for this given how tightly yo…

I'd argue Haskell has the best support for this: http://safehaskell.scs.stanford.edu

Example:

http://tryhaskell.org/

source:

https://github.com/chrisdone/tryhaskell

For those that just want to see the sandboxing part, I think most of the magic is in mueval but I could be wrong:

https://github.com/gwern/mueval

Re: WebAssembly: a binary format for the web

#155
post #61

Earlier quoted context omitted.

A good communicator is careful in his phrasing and keeps 'the human factor' in mind. It's not something that engineers are usually willing to admit or cater to, of course, but doesn't make it less true. As a corollary, this is the same point that people asking 'why aren't engineers paid better' are really asking about, but can't or won't see...

Engineers don't like being talked down too, but if something is outside your field then simplifying is still pragmatic, regardless if you have extensive knowledge in other fields. Let's put it like this, if I was the guy giving the talk, and I knew I'd get this reaction, I would do nothing differently. I'm not going to waste my time pandering to people who would take a tech talk personally. I don't care if managers g…

It's not about pandering, but about being inclusive in an educational setting. You're giving a talk so as to inform people, not imply they are lesser in some way. To concretize, consider replacing "the front-end developers" with "those unfamiliar with the concept":

> I will explain shared memory multi-threading in a bit, especially for those unfamiliar with the concept.

Versus the condescending:

> I will explain shared memory multi-threading in a bit, especially for the front-end developers.

Tiny change, makes all the difference. Be inclusive; don't be condescending.

Re: WebAssembly: a binary format for the web

#156
post #97

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

IMHO there is nothing wrong with hiding the source code. Infact it will save a lot of time for developers who do UI 'builds' in order to obfuscate or minify their js code. Binary webpage code was long due.

Re: WebAssembly: a binary format for the web

#157
post #25
post #2

A good talk from a week ago on WebAssembly: https://www.youtube.com/watch?v=NhAPPQqKCi8

Merits of the contents aside, the guy presenting has a very judgmental and condescending tone making it difficult to appreciate what he's actually saying. Saying things like "this doesn't look anything like a programming language, especially if you're coming from the javascript world" or "I will explain shared memory multi-threading in a bit, especially for the front end developers" really doesn't help. I find statem…

This is a very disturbing trend in the software industry (starting around mid 2000s). A person who knows programming semantics can code in any language, but because of over-reliance on frameworks and the hesitation to try and write deep code, developers are being segregated into frond-end, middleware, db, big data, etc. I don't think it's sustainable in the long term.

Re: WebAssembly: a binary format for the web

#158

What will this mean for blocking ads and certain trackers? If the source of the page isn't viewable, how will users know what the code is doing?

I'm sure you can still inspect the DOM and the network calls made by the page. DOMs, URLs, and HTTP aren't going anywhere.

And the current ad-blockers almost never go through the source code of a script, only the src and the URLs

Re: WebAssembly: a binary format for the web

#159
post #95
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.

not worth the jump from open to close... a large margin when most pages already load almost instantly will go unnoticed by most people.

I think that you would see a much bigger performance increase if websites would not load resources from 10 different domains for serving a single web page (you have a much higher chance of getting some unforeseen delay from one of those hosts).

Re: WebAssembly: a binary format for the web

#160
Hi i have also found one good example here ... http://androidexample.com/Global_Variable_Or_Application_Con... _Variable_-_Android_Example /index.php?view=article_discription&aid=114&aaid=136">http://androidexample.com /Global_Variable_Or _Application_Context_Variable_-_Android_Example/ index.php?view=article_discription&aid=114&aaid=136
Post reply on HN