Hacker News new | past | comments | ask | show | jobs | submit login
WebAssembly: a binary format for the web (2ality.com)
216 points by olalonde on Nov 1, 2015 | hide | past | web | favorite | 160 comments



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.


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

Not really. Almost all websites obfuscate/minify their Javascript now, making manually interpreting the code much less than "trivial." I think WebAssembly will be no worse to figure out than obfuscated Javascript.


I think it will be much worse.

Minified Javascript is pretty easy to turn back into something moderately understandable just by "prettifying" it. I do this all the time. It works pretty well because it started as Javascript, so turning it back into Javascript has a relatively clean mapping. WebAssembly will have started as some other language or even as no language at all - there may be no mapping back to anything Javascript could represent. It will be much closer to disassembly of machine code, or Java byte code, which is possible but challenging enough that most ordinary developers never do it.


I think WebAssembly will be much closer to Java byte code than actual machine assembly. And Java byte code can be easily decompiled into readable Java code (at least as readable as minified Javascript).


True, but this is already happening with asm.js. Is webassembly any more objectionable than that? Instead of causing existing applications to further obfuscate their code, it seems to be bringing new types of applications to the browser.


A polyfill to Javascript is already planned.

https://github.com/WebAssembly/design/blob/master/Polyfill.m...


its built into the spec of WASM for it to be able to be "prettified" as well. I imagine it'd do about as good of a job as current prettifying of minified JS.

"The WebAssembly text format, which is designed to be read and written when using tools (e.g., assemblers, debuggers, profilers), is specified as a textual projection of a module's AST."

This is apart of the MVP even. I think the authors of WASM actually agree with your opinions here and are working to a system that satisfies that concern.

BTW taken from, https://github.com/WebAssembly/design/blob/master/MVP.md


> I think the authors of WASM actually agree with your opinions here and are working to a system that satisfies that concern

That's very reassuring - I hope it works out that way.


That's exactly why we have the free software movement.


I don't see how obfuscated javascript is a lot easier to reverse engineer than webassembly binaries will be. You really scrutinize your bank's javascript for security issues? Really? I have a hard time believing that.



I think the argument of "anyone can figure out how it's done" is moot (as pointed out by many). But there is a significant change here: with Javascript or even ASM I can always take parts of someone's code and use it for my purposes. This means that developers are forced to think about security and business models in a specific way. With WebAssembly, we might lose that, as you pointed out. And that is a real issue.


Yet, isn't much of the web already unreadable due to minification of JS source?


If you think minification does anything to prevent anyone from reading it you are mistaken. Is it harder? Yes. Impossible, not even close, just annoying. I've reversed engineer JS libraries with 20K LOC that were minified and uglified in less than a day, hardly what I consider a hurdle.

Now, to have worked with asm.js recently, that's a whole different ball game. That is unreadable, at least without spending copious amounts of time on it and having a deep understanding of asm.js to be able to read it.


WebAssembly will be a lot more readable than asm.js - that's a specific goal, in fact.

It is true that it will still be lower-level than JS. But it remains in a structured AST format which is easy to pretty-print. And many of the worst patterns you see a lot in asm.js just won't be there.


When we are talking about browsing code for the purpose of leisure curiosity and learning, yes it is a real hurdle.


What do you get out of reading some random website's minified javascript?


Sometimes it's just the curiuosity of "how did they do that?" In general, one doesn't go around looking at the code everywhere, but on more than one occassion I've looked into something to figure out how something was done, or why it's broken in my browser (much more common in early Firebird^b^b^b^bfox).

On the one hand, I hope it gives a real build target for Rust and Go... on the other, I hope things don't get too obfuscated in practice.


Aren't there many JS beautification tools that can un-minify JS? It won't unshorten variable names, but the code should still be fairly readable.


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.


We will instantly have tools to decompile this stuff so it will look just as good if not even better than what you get when formatting minified javascript today.

In fact pick any language today that compiles output and you will find decompiling tools made for it, including the original compiled web stuff like Flash and Silverlight.

I'd much rather the web get faster for everyone than save a few people some time when deconstructing.


Fair enough that it's very nice for a tiny portion of web users to be able to reverse engineer code, but WA might increase performance for 100% of web users.


You are assuming that web sites have any meaningfull code done in JavaScript.

Many outside the HN web bubble are still plain HTML/CSS sites with almost everything done server side.


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 single unified DOM and its event model.

Because it uses the DOM, the text and widgets are real. The text is selectable, looks like regular text, etc. Java Applets had their own GUI/widgeting system that looked bad and behaved differently.


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 paint a square of the screen. Which was more about the problem that browsers also didn't support SVG, so if you wanted an interactive diagram you had to isolate yourself from HTML.


Why was this downvoted? I found this quite informative.


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.


It's not an increase in obscurity though: https://github.com/WebAssembly/design/blob/master/TextFormat...

The format is intentionally being built in a way that you can look at the source, in the same way you would look at minified Javascript currently.

If you're worried about obscurity, look at what is generated by asm.js. WebAssembly won't be any worse than that (and is, in fact, more or less a more efficient/correct equivalent to asm.js).


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


Parse time is basically free with WebAssembly


Smaller than JS, faster, uses Abstract Syntax Trees... sounds like the Juice project. Oh, how much better web apps could've been.

https://web.archive.org/web/20000830093908/http://caesar.ics...


Wow, I never heard of Juice before. It sounds really interesting. Sort of a shame how things turned out in hindsight.


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


That doesn't sound like an improvement.


Well, considering it was:

- isolated (outside of DOM) - non standard (not everywhere) - third party (proprietary) - alien (uncanny value of different UI style) - bloated (even compared to the web stack, Spring was an over-engineered badly designed mess of a GUI API) - insecure (full of exploits to this very day, tons of them closed just last year)

it does sound as a great improvement. Except in case you weren't there and can't remember.


I was very much there, and I'd sooner eat my cat than go back to that era of Java. But C++? Is that really the best we can do? Everyone's so afraid of breaking backwards compatibility but I don't see any other way out of the never-ending accretion of hacks Eich left us with.


Not C++ per se, but anything that can compile to WebAssembly, which should right away include anything with an LLVM toolchain, and should down the line include any compiled language for which someone puts the work in to add WebAssembly as a compile target.

I’m also hoping it winds up being friendly enough to hand write WebAssembly for small chunks of numerical code. With asm.js, that’s currently kind of a pain.


Rust in the browser?


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.


Java runtimes generate machine code just like V8 does, and there's no functional difference between "built-in" code and a plugin. A plugin is just a shared library.


At the time Java was being used in browsers, it had a lot of problems with that machine code generation. It took a long time for the JIT to kick in. The JITed x86 code it produced was poor. The startup time to load in the various libraries required by the applet tech was incredibly slow. It only started downloading the actual java code to run after the applet itself had finished loading everything. And more issues.

There problems were never truly about the idea being bad: it was the implementation that was terrible and was hindered even further by the Sun-Microsoft lawsuits, etc.

If everyone is on board with a technology and work to make it usable instead of 'feature complete', then it is very easy to make this work where Java applets failed. It's actually easy to make Java applets work where Java applets failed if you were to re-implement the idea with the correct focus and buy-in.

It's not technology - it is politics.


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?)


There are definitely reasons for manual memory management to still be a thing, but if a GC disposes of memory "too soon", i.e. when there are still live references to the memory, then it is a bug in the GC or in some FFI code that didn't manage interaction with the GC correctly.

GC is generally a good thing precisely because it prevents use-after-free errors and enables programming at a higher level without worrying about memory management. There is often a performance cost to this, it's true, but for large classes of programs it's a cost that's worth paying.


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.


Deterministic object disposal is quite easy to do in GC languages, provided they support higer order functions.

It is no different than imposing a programming pattern like RAII.


WebAssembly is about as close to Java applets as Flash. I can recommend the video that was linked by corysama to get a fuller picture of the WebAssembly design.


Posted some time ago, a .NET implementation and discussion:

https://github.com/WebAssembly/ilwasm

https://news.ycombinator.com/item?id=10162793

I also have to think about the new image file format posted some time ago: FLIF (http://flif.info/). With WebAssembly you could implement this in the browser by just embedding a lib. No need to wait for the vendors to support it.


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

(Yes I understand JavaScript is code from an untrusted source that runs in a sandbox on your computer, the browser client; in this context I'm referring to the ability of a JavaScript web app to load objects (from a JavaScript source code file hosted on ANY domain, in defiance of XSS dogma) which the browser client guarantees does not exceed the bounds of a specified "sandbox" built to spec, a "security envelope" for loading and evaluating code. For example the ability to tell the client, "execute procedure P with arguments A, but kill it if it runs for more than 0.5 seconds of CPU time or allocates more than 500 MB of memory" or "only load this source code as long as the global variables it uses is on this list: ..., the names of properties is uses is on this list: ..., and it refrains from using the following syntactic keywords: ...)

Python put up a warning against its own "restricted execution" a long time ago: https://docs.python.org/2/library/restricted.html

In the age of GitHub, why is there no interest in building infrastructure that allows programmers to define such "security envelopes" for JavaScript, Python, C, and so on and create systems which are composed of mutually distrusting modules which would, I think, simplify reasoning about their security characteristics?


> 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 you can lock it down (you can remove the 'require' function that loads other modules). But even this is considered not robustly secure against untrusted code.

http://lua-users.org/wiki/SandBoxes


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


Difficult, yes. There was an attempt by Google at a capability-secure JavaScript called Caja <http://www.links.org/?p=271>. I think it failed mainly because taming the standard library and DOM was too hard - there were too many leaks of ambient authority.


In Lua, you can set the allocation function (for memory limits) and I think you can set time limits by using coroutines.


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 security is a trade-off, the trade-off in this case is likely not worth it.


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


> Saying that any effort to regulate the source code of loaded extensions amounts to "shackling" is throwing FUD on the whole idea

No amount of vitriolic words or technical nitpicking will change the fact that there will be more work to be done, both by application developers enforcing policies and by extensions having to oblige them.

> the current fashion in programming languages is to allow an implementation to do anything... I think life could, in fact, get easier.

Easier for whom? Not for the lib developer, who will have to follow more rules ("import" mechanisms already have some, by the way), nor for the runtime developer, who will have to enforce them. Easier for the final user who executes runtime and lib? Maybe, but then you cannot expect any serious traction from developers (whose life you're making harder). Trade-offs and all that.


First of all, I didn't mean my FUD remark to be vitriolic.

I disagree that it is more work in total; I don't think you're taking into account the work that will no longer have to be done, namely work spent searching for cross-module bugs introduced when a security proof for one module relies on a condition which cannot be expressed in the underlying language.

I agree that it is a new type of work though.

Edit: easier for the mathematician who wants to prove that system X has security characteristic Y


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


> Safe Tcl does not attempt to completely prevent annoyance and denial of service attacks. These forms of attack prevent the application or user from temporarily using the computer to perform useful work, for example by consuming all available CPU time or all available screen real estate

So in other words it wouldn't be a good idea to encourage people to post and run demoscene Tcl programs on 4chan. That's the kind of safety and security I'm talking about.


You might be interested in looking at Gabriel Gonzalez' Morte ( http://begriffs.com/posts/2015-10-16-internet-of-code.html ), which started off as a supercompiler project, but seems to be moving somewhat in that direction.


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


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

I don't understand what you mean. Can you elaborate?


I think running code from an untrusted source or semi-trusted source is an underdeveloped area that will bear fruit in the future, but I think the gains will be long-term rather than short-term.

Today we live in a world where the source code that runs our advanced industrial society is owned and maintained in secret. And the business climate is highly competitive so a lot of people cut corners in terms of security. This means that instead of actually proving that their systems are secure system designers do something else.

If, instead, all of the source code of an advanced industrial society were maintained in an online library (like github) and anyone could submit a pull request to anything, then systems would have to have some way of protecting themselves from the introduction of exploits (either intentional or accidental).

So I am asking why practical infrastructure for such protection mechanisms (in terms of static analyzers and transformers) has not been built into Python, JavaScript, and C yet in order to see what people think about developing these kinds of language features.


The code that runs on the web runs in sandboxes, you do get XSS attacks which we should guard against but for the most part web security doesn't rely on trusted sources.

As for native, I believe there's some work being done in some fields to make it easier for users to reliably compile from source, which would give them the opportunity to scan the source (using whatever tools make sense, even MD5 hashes or similar) before compilation. IIRC the Debian project was working on improving the reproducibility of builds, you may find more of what you're looking for by searching for that project.


Doesn't web assembly prevent the idea? More and more wall-gardening. Then you'll see, you'll only be able to run licenced assemblies, because now, it's not transparent. And I bet it'll cost something, the licence. And I bet it won't be open source, so we can't learn from what they do. Another barrier to entry... "Google, Microsoft, Mozilla, and a few other people have been secretly toiling away in a new W3C WebAssembly". Another loss of freedom for the user, which isn't able to modify the website anymore, is he? We could have imagined extension which include best deals from competitors, but we can't imagine them anymore, because we need this speed so very much. I am again impressed by such demonstration of altruism.


dbpokorny, I think you'd be interested in http://erights.org/. Basically the answer was that yes, this is an important direction, and it's possible to tame JavaScript, at least with many years of work on the standards committee by someone brilliant and dedicated to making that happen. (http://programmers.stackexchange.com/questions/81118/has-any...)


You can run untrusted code in an iframe (possibly with the sandbox attribute set). I think this would be what you're looking for.


Go to http://www.html5rocks.com/static/demos/evalbox/index.html

type in

    console.log("foo")
and click either button. It has access to the console even from the sandbox. Is there a way to say: I want this iframe to run a script, but don't give the script access to the console?


No, but I'd still recommend looking into content security policy (CSP), iframes, and the sandboxed attribute. Even though you seem to have developed your own notion of what isolation/security should look like, the HTML spec authors have thought very carefully about this and CSP has its own internal logic. Even if you still prefer your model, at least you will be able to explain how your model differs from CSP and why it's better.


That seems a contrived example. The console is invisible to the end-user, why does it matter if an application can output to it?


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 statements like that offensive, and detrimental to getting good conversations going. I've not finished watching that presentation on these grounds, and I'm not sure I will. It's not out of principle either, but simply because I get too annoyed to continue.

For the record, I identify myself as a software engineer. These days I mostly do front end development, but I have written code in many languages and contexts (asm, javascript, c, python, vb, whatever fits) and been well remunerated for it. I find the front/back/native/whatever splits to be silly, probably fueled by trying to make more efficient job listings. Fine that HR folks do this, but as engineers we should know better.


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.


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 get paid more, if they want to water down their words to ensure no offence to anyone, they're welcome to take that burden.


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.


I'm really sensitive to the issue you mention, and I appreciate your bringing it up.

It annoys me no end when someone talks down to me, or maybe even worse, asks about my skill level in a particular area when the implication is that they will then know how to dumb down what they're saying to a level that even I may understand.

But after watching the first 15 minutes of the video, I'm not seeing any kind of judgmental or condescending tone. Was it something in the remaining half hour?

He did ask for a show of hands of front end vs. native developers, but you have to admit that front end developers who've only done front end may never have been exposed to the concept of threads with shared memory - his topic for the next few minutes.

So my suggestion is to give it another shot. Based on the first 15 minutes, it seems like a fairly interesting and insightful talk.


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.


It would be nice if the ability to reason about execution timings were one of the design goals of WebAssembly, because this could make it safer to port to crypto to the web.


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 are not forced too, I do not think most will.


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.


It's the difference between a 'java decompiler' and a 'c++ decompiler'. Which is significant enough for there to be a market for commercial 'java obfuscators', but not for 'c++ obfuscators'.


>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

What "open source"? Open Source is dead in web services, because everybody can just hide the source behind the server. Even with SPAs, you could have 90% of the actual functionality on the server side, behind REST APIs and the like.


Sure, but you at least you have the ability to inspect the code which is running on your machine. A FOSS client to a proprietary service is still meaningful.


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.


> 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

If that were the case, why do people get interested in programming in any non-interpreted language without thinking about it as a profession? I have trouble seeing this as a big step backwards in this regard since there are plenty of non-interpreted languages that kids in high school have gotten interested in themselves, even when there wasn't nearly as many good resources for learning them online.

I also don't see a huge difference between Web Assembly and minified javascript. Sure, with the later you could in theory piece through it without a disassembler, but if that is your introduction into the language I doubt you'll learn much at all (or want to). The gap grows even smaller when you take into the account the fact that Web Assembly is desired to replace asm.js, which was already incredibly obfuscated.

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

Web assembly was developed publicly from pretty much the very beginning on GitHub. We live in a world where the biggest closed-source players have open sourced implementations of their programming languages/platforms, compilers and all (e.g. OpenJDK, .NET Core, Roslyn, Swift). There are no popular languages around now where the leading implementations aren't open source. If this is what "becoming more closed and proprietary" looks like, then I can't say I'm opposed.


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

Thankfully for the openness of the Web, developer tools have been a source of intense competition among browsers. I see no reason why this will not continue to be true for introspection of Web Assembly.


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.


doesnt need to be the original source, as long as every browser has some form of decompiler to high level language (C like) Im good. But I cant imagine a future where we are served blobs with no way of knowing whats inside.


Have you seen the source of google.com? x86 assembly is more readable than the current minified JS.


I don't see how but the OP mentions 'something similar to map files' for debugging. So the map files are like pdb for (msvc) C++.

I wonder if it hadn't been easier if we'd just gone with sandboxed, auto-updated native applications rather than taking a 15-year detour through html, dhtml, 'ajax' web 2.0, spi w/ 'compiled js' and now this...


I fail to see how obfuscated textual blobs are any better. It's not like I can get any useful information from thousands of lines of gibberish JavaScript. As a sibling pointed out, WA supports textual representation.


WebAssembly binary will be syntactically (almost) identical to asm.js, which is a subset of JS. So all are equally transparent/opaque.


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


Write once, run anywhere.


Hi i have also found one good example here ... <a href="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</a>


Hm – Client-side web programming is all about resource management. I can't see, how cross-compiled C++ code that originated for a completely other platform with object code in the MBs range will do a decent job. And even, if this is not the original idea of WebAssembly, this is sure to come.

(We've seen similar with emscripten: As much as I love it as an experiment, it's highly problematic in production.)

And of course, as others have already pointed out, it's likely to ruin the vision of the web as a mosaic of just a few trivial technologies that can be investigated with modest knowledge. (Compare the comment by zmmmmm.)


I am someone who makes a living having a SaaS that clients use.

I've had clients who have tried to "clone" my work, but eventually come back because they couldn't figure out the backend code or scale.

I would love something that is the equivalent of installing an app on a phone, that is using a compiled app in a browser. Where the source can't be viewed.

Even better, if I can give a rich UX. By having access to the system.

Yes, I believe in some very small cases this will be welcomed. Otherwise, I think for everyone like 95% of the web, html, js, css, etc, will see be the way to go.


So even though they can't succeed at 'stealing' your job by copying the code you still don't want them to have access?


I don't have a job. I offer a service to clients. I get paid when they use my software.

If they created their own software, they would not have to pay me any money. So without money, I have to go on welfare.

You get my point?

No, I don't want any of my clients to get access to my source code. I am not a giant corporation like redhat, google, oracle or other company that open sources it's software and then sells support or other services.

I'm a small company, who with more clients. Is hoping to them employ a small workforce and grow the company.


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


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.


Yep, FFI. GC/DOM/Web API integration is in the eventual plans. https://github.com/WebAssembly/design/blob/master/GC.md

You want .NET on bare metal? Implement it on x64, ARM, MIPs and maybe PPC. You want .NET in the browser, implement it on wasm. You want Java in the browser, implement it on wasm. You want BEAM in the browser, implement it on wasm. You want Parrot in the browser, implement it on wasm. What you are not going to do is to get Google, Apple, Mozilla and Microsoft to all agree on any of those ILs.


The big advantage for web assembly is that is really language agnostic (besides the performance).


So could someone theoretically make flash or silverlight work via this?


Theoretically you can make those work in JavaScript. The performance might even be ok, but the limitations would still be the huge effort in reverse engineering flash or silver light code and features and secondly the browser sandbox policies which AFAIK aren't changed for WASM.


It's not just a theory, Mozilla has already implemented Flash in JS: https://github.com/mozilla/shumway


The future! serve binaries instead of web pages!


Web pages are already a far cry from human-readable semantic markup. That's not a hill worth dying on.


careful what you wish for


I see a future in which I write apps that run JS for the DOM, but I need to worry about neither JS nor the DOM. Glorious.


Okay, seriously.

The only possible benefit that this technology could have for the planet is to give Brendan Eich a reason to run yet another one of those video-game-inside-of-a-video-game demos at another one of those JS conferences that frontend devs go so nuts about.

Except this time, there will be yet another video game inside of that inner video game!


Awesome, I would love to see an helloworld application hosted in github


I hope to see so the developers that don't like JavaScript stop writing bad JavaScript and just write it in whatever class based type based system they want instead of adding classes and types to Javascript.


But adding type system to JavaScript - as Facebook has done with Flow - and class system - as in ES6 - actually makes complex JavaScript better and easier...


I have literally heard the argument that React basically doesn't count as OOP anymore because they are now emphasizing 'functional' Javascript, even though they still rely on the main base class.


I don't really know. I use Flow, but I don't use React.


Binary blobs on the web? Have we learnt nothing from ActiveX?


ActiveX had full access to the user's system.


"Why should WebAssembly succeed where previous attempts (such as Adobe Flash and Google Portable Native Client) have failed?"

Failed????

Excuse me, I haven't even BEGUN to scratch the surface of the awesomeness that is pnacl in my own project!


The failure of pnacl isn't primarily technical, it's political. I think the core tech (verifiable secure native code) is awesome. Many people in high places in non-Google browsers object to pnacl on several fronts. The crux of which seems to be that there is not a smooth transition story from JS->PNaCL. Getting JS and PNaCL to inter-operate, share implementation/memory/APIs is a problem. A bigger problem is the need to get all of the browser vendors (including IE and Safari) in agreement and on board synchronously to avoid years of "works only in Chrome and X".

Asm.js "cheated" by creating a path forward that did not require consensus. Mozilla used it to innovate without needing to argue with anyone else. For other vendors, asm.js would technically "work" without other vendors putting in any technical or political investment. But, the hook was that if they didn't get on board eventually, their browsers would start to look bad if they ran asm.js sites poorly.

WebAssembly is the outcome of Mozilla's trick. Now that all of the vendors have slowly become convinced over a period of years that there is a smooth, gradual path forward over the next several years that does not involve any technical or political chasms to cross, they are starting to work together to make it happen.


I think the main issue was it's reliance on the Pepper Plugin API. Which several people have said was mapped closely to Chrome's software architecture.

Technically it was a plugin for Pepper and the only difference between it and Flash was that it was open source and only available to Chrome.


In discussions of objections, Pepper comes up a lot. I don't understand the situation well enough, but that always seemed to me like throwing the baby out with the bathwater. The secure, native, binary executable is the big deal. The fact that people who are currently writing secure native binary executables are using an unpopular API seemed incidental and eminently fixable. Not "flip a switch" fixable, but "Let's work together to figure out a better API" fixable. But, the idea that the huge, Chrome-specific API would be required to be incorporated into every other browser as-is and could not have been replaced in the last six years seems to be assumed as a fact of life.


> The fact that people who are currently writing secure native binary executables are using an unpopular API seemed incidental and eminently fixable

Agreed. Web Assembly is the solution :)


Portable Native Client is a really huge project that takes a lot of PhD-level talent to implement correctly, and it requires a very specific type of organization that has the requisite "will" and "way" to make it happen.

Even if Mozilla had the will, they really don't have any way to contribute very significantly to the development effort, because it sort of requires a lot of very talented people getting paid large sums of money for long periods of time... which is obviously something that Google can afford to do.

I think everyone has always known that NPAPI was eventually going to have to be completely overhauled or even replaced. For anyone to constantly harp on the idea that "all that matters is the open web" when they come from the very same organization -- although going by a different name -- for which the original binary plugin architecture was named (Netscape Plugin API) is just patently absurd.

There is so much quality, freely available C/C++ code in this world that it is pretty mind boggling, and the purely technical achievement of allowing this code to be efficiently used by end users through the web platform is, again, a fairly mind boggling idea.

I'm not saying that this web assembly concept won't have any use cases whatsoever in the future, but I am saying that the proven PNaCl technology that exists right now is way, way too powerful for any web-based applications developer worth his or her soul to pass up very easily.


> Even if Mozilla had the will, they really don't have any way to contribute very significantly to the development effort, because it sort of requires a lot of very talented people getting paid large sums of money for long periods of time... which is obviously something that Google can afford to do.

And implementing a modern JS engine isn't? Or developing Rust? Come on.

The objections that many other browser vendors have to integrating PNaCl into the Web platform have been detailed repeatedly and have nothing to do with "X browser vendor doesn't have the talent on staff to implement the technology".


If Adobe Flash was a failure, I only hope I can fail as well and as strongly in my life...


Yeah, I was referring to pnacl (as in Portable Native Client), but that is a very good point about a technology that is obviously still going strong all these years later.


Either he's mixing narratives here or he's using standard web development practices as the context of it failing.

Today using Ajax is better practice because it integrates better with the browser and it'll work on mobile.


Supported by a single browser and based on a single (and the same) vendor's spec, which needlessly duplicates about half a web browser's functionality using a brand new API, and with no support due for other browsers any time soon


False.

From the Native Client wikipedia page:

As of 13 May 2010, Google's open source browser, Chromium, was the only web browser to utilize the new browser plug-in model.[28] Mozilla has announced that they are "not interested in or working on Pepper at this time."[29] As of 2015, Pepper is supported by Chrome, Chromium and Opera.


All of which are functionally the same Blink-based browser, so you're splitting a really fine hair.


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 Google is basically Skynet, while Firefox is not much more than a warm, fuzzy memory.

Seriously... does anyone really want to turn this into a battle between Google and Mozilla?


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.


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.


And we used to think x86 was a bad design of native code.


[flagged]


PNaCl is no more a Google-proprietary feature than XMLHttpRequest is a Microsoft-proprietary feature. Anyone else is free to implement it, and then Google would have no more control over the "spec" of PNaCl than Microsoft has control over the evolution of AJAX.


Last I looked into this, the (P)NaCl codebase was heavily enmeshed with Chromium. Documentation on how any of it fit together was spread out across a multitude of wiki sites and mailing list archives, with conflicting descriptions of the exposed interfaces in varying states of obsolescence. The "spec" was, effectively, this big tangled ball of code in the Chromium tree.

The one method of running NaCl programs on their own relied on thousands of lines of Python code spread across a nested hierarchy of frameworks just to generate command line arguments to pass to the main runner binary -- and this used completely different interfaces into NaCl from Chromium's implementation. And all of this, being tightly integrated into the Chromium codebase, was subject to change at any point with no guarantee of API stability.

Maybe things have changed since then, but at the point when (P)NaCl was receiving the most attention I found it entirely impenetrable. Though the code may have been open source, the knowledge needed to integrate it with a new system was entirely proprietary. And anyone doing so would have ended up with an implementation bound to the evolution of the Chromium internals.


Note that I'm not talking about integrating "Google's PNaCl" into another browser (that code is Google-proprietary, for your listed too-much-of-a-mess reasons if nothing else.) Mozilla et al wouldn't use Google's NaCl engine in Firefox any more than they would use Google's Javascript engine, or any more than they would have integrated ActiveX into Firefox just to call XMLHttpRequest.

I'm instead talking about implementing one's own LLVM-bitcode-compiling zero-install plugin architecture with safety guarantees derived from static analysis (i.e. what you get by implementing the whitepaper[1]), providing a similar API to plugins to NaCl's PPAPI.

The result would just be an ecosystem of "Native-binary Sandbox engines" and an API working group that is to {portable LLVM IR ISA, PPAPI} as the ECMA is to {Javascript, the browser DOM}.

[1] http://static.googleusercontent.com/media/research.google.co...


For a feature to not be proprietary in the modern browser landscape, it has to have multiple parties able to participate in the design. Including the core design decisions of "should we use JS as a basis" (the consensus solution) vs. "should we use LLVM as a basis" (the PNaCl solution).


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/


I haven't looked at WebAssembly in Detail, but my feeling and worry is that this is a can of worms for security issues.

Javascript wasn't designed with security in mind and it has taken us decades to understand what implications that had (and we haven't really fixed them yet). The security implications for WebAssembly will be different, but I'm almost certain there will be a lot. (pnacl already introduced some quite unexpected issues, e.g. allowing control over cache flushes and thus making rowhammer attacks easier.)

Given that neither the linked text nor the FAQ they have does even mention and discuss that I'm even more worried.


> The security implications for WebAssembly will be different, but I'm almost certain there will be a lot.

What can you do today in Web Assembly that you can't already do in asm.js?


Nothing. WebAssembly in its current implementation is basically a binary representation of asm.js.


With all the lessons learned, I would think that a completely new implementation would have less security issues.


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.




Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: