4 ms·

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/l

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--especially when you see crazy shit like "-O 3" would make. tl,dr; compilation != minification, and acting like they are is at best incorrect. Your (2) fails to address the entire complaint about wasm (aka asm.js) leading to bad things and ecosystem bloat. You just say "well we can kinda already do it", but fail to address any of the substance of the actual argument I made. Your (3) misses the point completely about "write in native code" and not "write in something that gets run in an interpreter". Like, you've missed the whole point that if you need performance, you need to be writing something outside the browser, and if you don't need performance existing JS is sufficient.

buu700 9y ago
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.

buu700 9y ago

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.