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

41–50 of 164 posts

Re: WebAssembly: a binary format for the web

#41

Post by ZenoArrow »

mstade wrote: post #25
corysama wrote: 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…

So you're a full stack developer. Some coders are only familiar with their domain. For example, most of my coding experience has been backend database scripting stuff, I have very little familiarity with the front end.

I don't see why you would get offended, he was talking to the specialists, not the generalists. You have to understand there's no shame in not knowing something outside your domain. For example, if you've never done AI programming before, would you be offended if an experienced AI coder skipped over some details in order to provide a more friendly introduction? It's not meant as an insult, it's not a reflection on your capability to learn about it, but rather it could be based on a consideration that you may not have taken the time to learn about it yet.

Re: WebAssembly: a binary format for the web

#42

Post by denniskane »

nicalsilva wrote: post #33
denniskane wrote: post #18

Earlier quoted context omitted.

Okay, so let's examine the remaining browsers, shall we? Safari and IE/Edge automatically don't matter because they are exclusive to their respective [proprietary] host operating systems. That leaves Firefox. Does anyone really think there is legitimate competition between Chrome and Firefox anymore? I mean don't get me wrong, Firefox was a godsend in the bad old days of M$IE domination... But this is 2015, and Googl…

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 replied that PNaCl is only supported by a single vendor. Then I said that was a factually incorrect assertion, with the response being that I was engaged in hair splitting.

So then, I suggested that we should examine the rest of the vendors. In the morals based context of this entire subthread, I think it is plainly obvious that Safari and IE/Edge don't have any place here, when it comes to the question of whether PNaCl is a "good" technology, based simply on the question of the proportion of vendors that happen to support it.

If you are instead talking in a purely pragmatic, capitalist sense... then of course all that matters is brute numbers. But then there is no real discussion to be had, because in the cold, hard business world, whoever wins is just whoever wins. A equals A. It's a mere tautology.

Re: WebAssembly: a binary format for the web

#43

Post by userbinator »

RussianCow wrote: post #24
rasz_pl wrote: post #23

can you go back to source code from WebAssembly binary? I dont want a web that serves me obfuscated binary blobs.

No, but one of the goals of WebAssembly is to have a textual representation, so in theory you could still View Source. Not sure how that'll work out in practice, though.

In practice, I think most browsers won't include a "disassembler", under the justification that most users won't need it; I can see "View Source" unfortunately going that way too.

What's wrong with that argument is the fact that although most users don't need it, it's an excellent way for those interested to explore into and find out how things work, and essentially get into web development with nearly no effort. If this trend continues, in the future when browsers become nothing more than dumbed-down interactive TVs, I think there will be very few, if any, web developers who started out of their own interest and exploration instead of solely thinking of it as a profession, and that's a really bad thing. (For the corporations who want to take control, this could be viewed as a good thing - why would they want to encourage independent thought and exploration when they could have dogmatic obedience?)

Computing systems are becoming more closed and proprietary, and this will be a big step backwards in terms of openness of the Web that lead to its growth and freedom in the first place.

Re: WebAssembly: a binary format for the web

#44

Post by pmelendez »

niccaluim wrote: post #32
bobajeff wrote: post #15

Earlier quoted context omitted.

Except with C++ instead of Java and the DOM instead of Java API's.

That doesn't sound like an improvement.

It is actually... It is going straight to native and built in on the browser instead of a call to a plugin and then a VM and finally to native.

Re: WebAssembly: a binary format for the web

#45

Post by pmelendez »

toyg wrote: post #38
bobajeff wrote: post #15

Earlier quoted context omitted.

Except with C++ instead of Java and the DOM instead of Java API's.

Not sure if serious... This comment translates to "except without garbage-collection, and with a loose set of inconsistent and constantly-changing interfaces instead of One Sanctioned Spec."

Not sure why you think a GC is a good thing. Deterministic object disposal is to me way more convenient and safe than a GC (haven't you ever experienced a race when the GC dispose your memory too soon or not soon enough?)

Re: WebAssembly: a binary format for the web

#46

Post by mrec »

pmelendez wrote: post #45
toyg wrote: post #38

Earlier quoted context omitted.

Not sure if serious... This comment translates to "except without garbage-collection, and with a loose set of inconsistent and constantly-changing interfaces instead of One Sanctioned Spec."

Not sure why you think a GC is a good thing. Deterministic object disposal is to me way more convenient and safe than a GC (haven't you ever experienced a race when the GC dispose your memory too soon or not soon enough?)

If you're hitting race conditions based on when GC runs, I'm pretty sure you're doing it wrong. Java does deterministic destruction of resource-holding objects via try-with-resources, not GC.

Re: WebAssembly: a binary format for the web

#47

Post by networked »

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

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

Tcl has a feature for this purpose called "safe interpreters". It is production-quality and works with command-level granularity, the command being the basic building block of the language: http://tcl-lang.org/man/tcl8.6/TclCmd/safe.htm. The security section has some considerations that are relevant if you want to make a "safe" interpreter for any Turing-complete language.

Re: WebAssembly: a binary format for the web

#48

Post by MichaelGG »

corysama wrote: post #31
yjgyhj wrote: post #28

What does this mean for compile-to-js languages, like Clojurescript, Elm (and ES2015 one might argue)?

So far, not much. Clojurescript, Elm and most others assume that JS is taking care of garbage collection for them. Meanwhile, WebAssembly so far does not include GC support. If someone were to implement a custom GC for Elm on top of wasm's "here's a big array of bytes" memory model, it would be very interesting indeed. But, at the moment wasm is primarily a target for C/C++.

That's rather weak. How do you interop with the DOM? Explicit FFI? Are there plans to make WebAssembly catch up with the last several decades? There's no reason we can't have a proper IL like .Net or even Java at worst.

Re: WebAssembly: a binary format for the web

#49

Post by mrec »

jgalt212 wrote: post #29

If the new way forward allows everyone distribute unreadable binary instead of readable, or de-obfuscatable, JavaScript, I think this definitely bad for open source and bad for innovation which depends upon stuff like: "oh, now I see how that did that. I think I can apply that technique to something else". Of course, people can release their js, python, java, et al that compiles down to WebAssembly, but because you a…

How is this any worse than minified Javascript? Without meaningful names or comments you're not much better off than you would be with WASM+disassembler.

Re: WebAssembly: a binary format for the web

#50

Post by dbpokorny »

toyg wrote: post #36
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,…

Because they shackle implementations too much. Every time you increase restriction glanularity, you make someone else's life harder. With every restriction or policy you introduce, you've actually increased the implementation's own attack space: you can't stop worrying about validation mechanisms further down the stack, but you now also have to maintain a new set of validations. That's a lot of extra work; given that…

> Because they shackle implementations too much

I disagree on one count, and on the other count I don't understand, so I'm requesting clarification.

First, the current fashion in programming languages is to allow an implementation to do anything (in Python, "import" takes no arguments, neither "require" in node.js)

I think life could, in fact, get easier.

Today applications do not regulate the code they load. It just has to work. Saying that any effort to regulate the source code of loaded extensions amounts to "shackling" is throwing FUD on the whole idea that an application should handle some (not all) of the responsibility for investigating the code it loads and not rely 100% on the underlying implementation.

With respect to your remarks about validation mechanisms, you'll have to explain the claim that this would "increase the implementation's own attack space" because I don't see how that is possible (unless we're talking about two different things: I'm talking about a combination of (A) static verification and (B) static transformations that instrument code with calls to runtime handler for certain sensitive operations (such as accessing a global variable and accessing a member of an object)

Post reply on HN