It will end up being a tool of control and surveillance like always.
This guy says it a bit more eloquently than I can:
It's absolutely not a "tool for surveillance". How exactly are you going to surveil anything with it?
It's not even a replacement for js, or at least it shouldn't be used that way. No GC for instance. And if you are doing any of the silly things mentioned in your link you have no one to blame but yourself. Like accepting binary blobs without source from contractors.
The link eventually admits you can't do a lot of stuff with js and should use native code. Great, lets just have everyone download and execute untrusted and unsandboxed code. In a way that is completely incompatible across platforms. Maybe we can maked them locked behind "walled gardens" with a ridiculous tax while we're at it. Future generations will laugh at us from their completely wasm based PCs.
Or we can always go back to the old way of doing anything interesting with a browser. By making proprietary, vulnerability ridden plugins. Don't you just miss the days of flash and java applets? Because surely that was a much better solution than wasm.
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 introduces anything different here (as has been pointed out, wast's inclusion of type information actually makes it slightly more readable than minified JS).
2. Arguing against something that wasm could maybe one day become.
— Right now wasm doesn't enable anything you can't already do with asm.js, so the idea that it somehow kills JavaScript or whatever is wrong; anything that can compile to wasm can compile to asm.js. Sure, maybe one day wasm will gain DOM/GC/etc. functionality, but asm.js could just as easily gain a lot of the same proposed features. (And wasm/asm.js aside, plenty of languages already compile to JS quite successfully; this hypothetical future wasm would just make them faster.)
3. Seeming to have only a vague sense of what wasm actually is. I think arguments like #1 and #2 have led to a set of talking points that don't at all reflect reality but sound correct to developers who don't have direct experience with asm.js/wasm.
— e.g. the argument from the linked Lobsters comment that "It solves problems that we don’t have. ... If performance is the important thing you pull on your big kid pants and write C/C++/D/Rust and if ... performance isn’t important, you just write in JS." neatly summarises exactly the point of wasm while somehow trying to frame it as an argument against it.
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.
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.
We'd have been better off fixing Java applets, instead of reinventing the wheel. So now 20 years later, we're cross compiling C...
Good C# is fantastic
Between the Community Toolkit and Telerik's UWP UI, there are some fantastic open source controls available for reuse.
Bad XAML editing can be frustrating, the visual state setters don't recognize the local properties, which leads to a lot of copy/paste and no help w/errors (e.g. TextBlock.RelativePanel.AlignTopWithPanel is wrong and should be TextBlock.(RelativePanel.AlignTopWithPanel), but intellisense gives no hint).
Using the new x:Bind I couldn't get blend to show design time data, it only showed the property names, which is misleading when you have a long property name holding a small string value.
There are a whole bunch of other little frustrations like those 2 above, the net effect of which is a minor aversion to the XAML side of things.
And ActiveX! you probably repressed the memory of that one, sorry to remind you.
The text form of Wasm looks like it's going to be far easier to read than minified JS.
However I find unsetting how Eich ends up defending WASM by hoping it's not too successful (used only in some hot pathes, not full blob apps.) That's frankly quite ridiculous: I predict a full apps adoption pretty soon. Just wait for more mainstream languages to support it.
The open web in the sense the OP meant has been dead for a while, WASM is just another tombstone.
WASM is not a replacement for javascript, and it's not trying to be. You won't be writing entire applications in whatever you compile to WASM, it's not how it's designed, it's not how it's meant to run, and it's worse in most ways than just compiling your favorite language to javascript (which has been possible for a long time now, but nobody uses it because it's such a leaky abstraction).
The open web is flourishing more than ever, and WASM is keeping that alive with it's "text" mode.
I can also run objdump against Microsoft Office. Does it make it open?
Plus nothing is stopping us from popularizing a trend where everybody puts a publicly discoverable debugging hints file (which would make the disassembly easier to read) with a fixed name next to all wasm files.
By contrast, if in common usage people are only running software compiled to Web Assembly, then:
1. You probably have some work to do to figure out the licensing of the code running in your browser.
2. The ability to look at the program logic for study or reuse is diminished in practice as compared to the early web when you could view source.
2. might be more possible with WASM than it is with minified JS since WASM has a text mode which is very readable.
2. I don't think anyone is claiming minified JS is awesomely transparent. WASM is certainly worse than the unobfuscated, unminified JS, which until not long ago was the norm.
The bigger problem, which is also a problem with web scripts in general, is that browsers and script distributors generally make no effort to inform users about what scripts are running, whether they are proprietary or free software, etc.
Mozilla should fix this!
- Wasm (and JS) should have metadata (loadable before executing the code) declaring the license, and pointing to the source
- Browsers should whether site is open source (per OSI), and allow to block non-open JS. Or fake access to any sensitive APIs for non-open code (can still do DOM interactivity)
The builds should ideally be reproducible, and community-based third-party sites verify the output comes from said source. This would be another badge/warning/setting.
It's really entertaining watching this subthread, let me tell you.