The big advantage for web assembly is that is really language agnostic (besides the performance).
WebAssembly: a binary format for the web
131–140 of 164 posts
Re: WebAssembly: a binary format for the web
#132As 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,…
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...)
Re: WebAssembly: a binary format for the web
#133Earlier quoted context omitted.
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…
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.
Re: WebAssembly: a binary format for the web
#134Earlier quoted context omitted.
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.
Re: WebAssembly: a binary format for the web
#135Earlier quoted context omitted.
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…
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.
Re: WebAssembly: a binary format for the web
#136Hm – 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.)
Re: WebAssembly: a binary format for the web
#137What 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?
Re: WebAssembly: a binary format for the web
#138As 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…
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.
Re: WebAssembly: a binary format for the web
#139Earlier quoted context omitted.
> 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 Ja…
That's exactly why we have the free software movement.
Re: WebAssembly: a binary format for the web
#140Earlier quoted context omitted.
> 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 Ja…
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