3 ms·

Bullshit. Wasm can't do anything js can't. Especially with asm.js. Don't try to argue that minified or transpiled js is somehow more readable than wasm. At leas

Bullshit. Wasm can't do anything js can't. Especially with asm.js. Don't try to argue that minified or transpiled js is somehow more readable than wasm. At least it's easier to decompile in theory. 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.

icedchai 9y ago
I hope future generations are going to laugh at what a what a kluge "web app" development was... but I'm not so sure. We'd have been better off fixing Java applets, instead of reinventing the wheel. So now 20 years later, we're cross compiling C...
- snomad 9y ago
  After 20 years of web dev, I gave native development (UWP) a shot. I kinda assumed that after so much time Microsoft would have windows development dialed in and it would be sane. Ha!
  - infinityplus1 9y ago
    How was your experience with UWP?
    - snomad 9y ago
      Overall, not sure, part frustrated, part liking it. 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.
MrPatan 9y ago
> flash and java applets And ActiveX! you probably repressed the memory of that one, sorry to remind you.
buu700 9y ago
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 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.
- angersock 9y ago
  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.

icedchai 9y ago

I hope future generations are going to laugh at what a what a kluge "web app" development was... but I'm not so sure. We'd have been better off fixing Java applets, instead of reinventing the wheel. So now 20 years later, we're cross compiling C...

snomad 9y ago
After 20 years of web dev, I gave native development (UWP) a shot. I kinda assumed that after so much time Microsoft would have windows development dialed in and it would be sane. Ha!
- infinityplus1 9y ago
  How was your experience with UWP?
  - snomad 9y ago
    Overall, not sure, part frustrated, part liking it. 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.

MrPatan 9y ago

> flash and java applets And ActiveX! you probably repressed the memory of that one, sorry to remind you.

buu700 9y ago

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 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.

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