Near native performance - what a joke.
You do get near-native performance, though. There are benchmarks. You can run them yourself.
In some microbenchmark, for some large value of 'near'.
WebAssembly 101: A developer’s first steps
131–140 of 153 posts
Re: WebAssembly 101: A developer’s first steps
#132Earlier quoted context omitted.
Anything? You're carting around an entire browser, it's so far from native that it's completely laughable. As a point of reference: In 1984: MacPaint, 5,822 lines of Apple Pascal, 3583 lines of assembly QuickDraw (dependency): 17,101 lines, all assembly Compiled Size: 0.05MB Today, Chrome: Number of lines of code: 16 MILLION Webkit (alone): 10.3 MILLION Install size: ~200MB We have a bunch of people who aren't skille…
Well I'm in favor of things running in a sandbox, especially random code delivered over the internet and run automatically in my browser. But aside from that, WebASM has a flat memory model and (so far) no built-in garbage collection. It has very few features, it's very fast to parse and it runs fast too. Even the asm.js version was fast back in 2013 https://hacks.mozilla.org/2013/12/gap-between-asm-js-and-nat... As…
We used to have that back in the day. It was called...installing, I think it was? Then the app...'program'? That was It! Program! Ran at native speed.
Amazing how we ever got anything done without carting around an entire browser as an attack surface.
Re: WebAssembly 101: A developer’s first steps
#133Earlier quoted context omitted.
Yep. WebAssembly today is literally just a better/faster asm.js. The argument against it linked above is nonsense. Most arguments like this that I see tend to fall into one of these boxes: 1. Using wasm as springboard to argue against something else they don't like. — e.g. disliking closed source code / source obfuscation / minification is a fair position, but it's not helpful to anyone to pretend that wasm introduce…
And asm.js wasn't the correct answer either. Nor is minification, as is pointed out in my original comment. On (1), you're ignoring the fact that asm.js/wasm/low-level languages are in general harder to reverse than uglified high-level stuff. You can see the details perfectly, sure, but emitted compiled code (say, from Duff's device or something) is a lot harder to back out of than the equivalent minified source code…
1. Yeah, sorry, I was really speaking in general terms here and should've been more clear about that, as your argument was explicitly that it's just another step in a pre-existing wrong direction, not a big horrible thing all its own. re: wast vs minified JS, the specific comparison I had in mind was with asm.js code, which (minified or not) is from what I've seen less readable than wast.
Generally speaking, my point here was that I think some arguments against wasm conflate a pre-existing state of affairs that aren't liked with the delta that wasm introduces.
2. Hm, yeah, fair enough. In my mind this all boiled down to "the only significant direct effect of wasm is to make what we're already doing faster", which in itself is obviously good; but that was coming from my bias of being a fan of asm.js, and ignored the other long-term impacts that would inherently come with enshrining all that extra machinery — even just politically blessing what asm.js already accomplishes in most browsers as the officially sanctioned new normal in all browsers isn't nothing if you think it will at least politically help in pushing things further in a bad direction.
I'll have to reread your and other arguments against wasm with a more open mind less stuck on the immediate delta.
And yeah, actual harmfulness or lack thereof aside, it wouldn't help anyone for all this effort and API surface expansion to go into building out a feature that didn't add value ("ecosystem bloat"), so that's a fair point.
3. I got what you meant by that, although on the first read it also sounded like there was some sort of misunderstanding (mostly combined with the "bad vendor incentives" section — it wasn't clear why a vendee would be more likely to accept compiled wasm without source code than minified/obfuscated JS). In any case, I don't see why being required to leave the browser for performance-sensitive code should be considered a feature and not a bug. Wasm presents a very convenient method of sandboxing untrusted code with a high performance requirement.
Agreed that this isn't a concern for typical CRUD apps or documents (although I imagine CRUD apps will ultimately benefit in the form of frontend JS frameworks incorporating wasm in critical paths), and I know I'm definitely in the minority being a beneficiary of asm.js/wasm. However, it's a bit late at this point to unmake all the more complicated applications we've built on the web, and all wasm does is improve a subset of those applications that already exist (as opposed to enabling entirely new applications), so I don't think this is a good argument against it.
Re: WebAssembly 101: A developer’s first steps
#134Earlier quoted context omitted.
You may like browsing through comments by @nickpsecurity (e.g. https://news.ycombinator.com/threads?id=nickpsecurity&next=1... , etc.). He's really knowledgeable about this stuff, and tries to popularize it as much as he can.
On display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”, is this mailing list: https://groups.google.com/forum/#!forum/cap-talk
There is a trove of very interesting information here. Thanks
akavel and thingification :)
Re: WebAssembly 101: A developer’s first steps
#135I wonder where the world is going with this. At first glance it looks like webassembly is a potential faster replacement for javascript in the browser. However, javascript is an increasingly popular language everywhere. I'm not sure people will want to move away from it for most development. The part that is actually causing performance problems with web application is the HTML/CSS/DOM layer which was not designed as…
> I'm not sure people will want to move away from it for most development. x = 1 + '2' //12 x = 1 - '2' //-1 Oh yes, yes we do.
I've been writing JavaScript in a professional context for years, and I have never added an integer to a string. I have never debugged code accidentally doing so, and I've never seen functions written that casually swap between such different return types.
Yet here we are, over and over, reading the obligatory complaint in every JS thread about its type coercion and corner cases. Who are all these programmers who can't go a day without tripping over and subtracting booleans from objects, or multiplying arrays by strings, or dividing functions by nulls? Do they suffer this affliction in other languages too? Do they divide by error codes and subtract function pointers from charcodes?
Re: WebAssembly 101: A developer’s first steps
#136Earlier quoted context omitted.
For me the main potential of asm.js/WebAssembly does not lie in the fact that it is faster, but in that it provides us with a way to run native C/C++ code inside the browser without adapting it (much), and doing this at a speed which is not (much) worse than the speed of the original code. This in turn makes functionality that was traditionally very hard to get in a browser/JS environment suddenly very easy to get: -…
I thought the problem with client side crypto wasn't so much performance but the fact that it can't really be trusted?
That's right. If you have no HTTPS, I can strip the JS/WASM that does encryption and fetch your cleartext password when you POST it back.
If there is HTTPS I cannot strip the JS/WASM that does crypto... but you don't need user-side crypto any more.
Re: WebAssembly 101: A developer’s first steps
#137Earlier quoted context omitted.
I thought the problem with client side crypto wasn't so much performance but the fact that it can't really be trusted?
That's right. If you have no HTTPS, I can strip the JS/WASM that does encryption and fetch your cleartext password when you POST it back. If there is HTTPS I cannot strip the JS/WASM that does crypto... but you don't need user-side crypto any more.
There might be situations when you want client-side crypto not for sending data over the network, but to securely encrypt a document that you want to send / use in a different context. Using an emscripten-compiled crypto library would allow you to do this in your browser without sending any of the data over the wire.
Re: WebAssembly 101: A developer’s first steps
#138Earlier quoted context omitted.
That's right. If you have no HTTPS, I can strip the JS/WASM that does encryption and fetch your cleartext password when you POST it back. If there is HTTPS I cannot strip the JS/WASM that does crypto... but you don't need user-side crypto any more.
There might be situations when you want client-side crypto not for sending data over the network, but to securely encrypt a document that you want to send / use in a different context. Using an emscripten-compiled crypto library would allow you to do this in your browser without sending any of the data over the wire.
Alright, but everything can still be tampered. At best, you can cause a denial of service, at worst modify a document that a user signs has its own.
Re: WebAssembly 101: A developer’s first steps
#139Earlier quoted context omitted.
Got a specific benchmark or task you think will be much slower than native?
Anything? You're carting around an entire browser, it's so far from native that it's completely laughable. As a point of reference: In 1984: MacPaint, 5,822 lines of Apple Pascal, 3583 lines of assembly QuickDraw (dependency): 17,101 lines, all assembly Compiled Size: 0.05MB Today, Chrome: Number of lines of code: 16 MILLION Webkit (alone): 10.3 MILLION Install size: ~200MB We have a bunch of people who aren't skille…
I totally agree. However, it is to be expected, when we first abstract up to get convenience and then using that platform, abstract back down to get performance.
We end up with a FrankenMonster of an application, that has a cobbled together persona, built by people who do not appreciate what the machine is actually doing.
Re: WebAssembly 101: A developer’s first steps
#140I recommend anyone wanting to experiment with WASM to check out https://github.com/dcodeIO/webassembly which takes a lot of pain out of setting up the toolchain and lets you produce much leaner binaries as well. Also keep an eye on https://github.com/dcodeIO/AssemblyScript :)
Is is wasm and not WASM. Source: http://webassembly.org/