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 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.
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.
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.
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.
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: ...)
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?
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.
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.
>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.
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.
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...
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
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 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++.
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.
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!
[+] [-] zmmmmm|10 years ago|reply
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.
[+] [-] luhn|10 years ago|reply
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.
[+] [-] robbrown451|10 years ago|reply
[+] [-] asdfologist|10 years ago|reply
[+] [-] xixixao|10 years ago|reply
[+] [-] 13years|10 years ago|reply
[+] [-] jitix|10 years ago|reply
[+] [-] manigandham|10 years ago|reply
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.
[+] [-] yummybear|10 years ago|reply
[+] [-] pjmlp|10 years ago|reply
Many outside the HN web bubble are still plain HTML/CSS sites with almost everything done server side.
[+] [-] Animats|10 years ago|reply
[+] [-] haberman|10 years ago|reply
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.
[+] [-] nickpsecurity|10 years ago|reply
https://web.archive.org/web/20000830093908/http://caesar.ics...
[+] [-] bobajeff|10 years ago|reply
[+] [-] ZenoArrow|10 years ago|reply
[+] [-] huuu|10 years ago|reply
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.
[+] [-] dbpokorny|10 years ago|reply
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?
[+] [-] corysama|10 years ago|reply
[+] [-] mstade|10 years ago|reply
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.
[+] [-] omphalos|10 years ago|reply
[+] [-] jgalt212|10 years ago|reply
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.
[+] [-] mrec|10 years ago|reply
[+] [-] coldtea|10 years ago|reply
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.
[+] [-] rasz_pl|10 years ago|reply
[+] [-] RussianCow|10 years ago|reply
[+] [-] roel_v|10 years ago|reply
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...
[+] [-] kmicklas|10 years ago|reply
[+] [-] pinealservo|10 years ago|reply
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
[+] [-] jacquesm|10 years ago|reply
[+] [-] androi|10 years ago|reply
[+] [-] masswerk|10 years ago|reply
(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.)
[+] [-] no1youknowz|10 years ago|reply
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.
[+] [-] nv-vn|10 years ago|reply
[+] [-] JoshMnem|10 years ago|reply
[+] [-] pritambaral|10 years ago|reply
And the current ad-blockers almost never go through the source code of a script, only the src and the URLs
[+] [-] yjgyhj|10 years ago|reply
[+] [-] corysama|10 years ago|reply
[+] [-] ilaksh|10 years ago|reply
[+] [-] spo81rty|10 years ago|reply
[+] [-] elcritch|10 years ago|reply
[+] [-] zobzu|10 years ago|reply
[+] [-] pekk|10 years ago|reply
[+] [-] alkonaut|10 years ago|reply
[+] [-] denniskane|10 years ago|reply
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!