71–80 of 160 posts
I cant help but think of the post about stealing password credentials from the site you build by surreptitiously inserting extra code into the published NPM package. Except wasm packages seem like they'd be even harder to detect. https://hackernoon.com/im-harvesting-credit-card-numbers-and...
I cant help but think of the post about stealing password credentials from the site you build by surreptitiously inserting extra code into the published NPM package. Except wasm packages seem like they'd be even harder to detect. https://hackernoon.com/im-harvesting-credit-card-numbers-and...
Since wasm (currently) requires js to interact with the DOM, you could still read the js code to see if it's passing any sensitive data into wasm.
>> the goal of WebAssembly is not to replace JavaScript, but to be an awesome tool to use with JavaScript. Let's hope exactly the other way around will happen. I would rather like to see better interop between different languages using wasm than wasm + js.
Earlier quoted context omitted.
We’re focusing on the unknown target for basically all future work; this stuff can work with the emacripten target, but it might take some PRs to configure it, etc. We’d be open to people hacking on such a thing, but it’s not where the team is putting in any effort.
Got it. I assume the unknown target will never be able to link against native libraries beyond those provided by Rust's core itself? I assume the answer is no, but a few years ago I assumed I wouldn't ever be able to do what wasm is letting me now, so I don't want to hold too tightly to those assumptions. :)
If so, then that’s correct, as rustc can’t compile C code. You need a C -> wasm compiler, and that’s emscripten.
Hopefully we’ll have built the ecosystem enough that you won’t need to rely on those libraries :)
Earlier quoted context omitted.
> It seems only logical that wasm interpreters will be optimizing JITs. Webassembly was designed not to do this, and I really hope it stays that way forever. Optimizing JITs are useful for highly dynamic languages like Javascript; Webassembly's fast startup times and predictable performance are a much better solution for languages like Rust. > I guess I don't understand what Wasm is doing that is so much different th…
> Webassembly was designed not to do this, and I really hope it stays that way forever. Optimizing JITs are useful for highly dynamic languages like Javascript; Webassembly's fast startup times and predictable performance are a much better solution for languages like Rust. WebAssembly is a VM bytecode for a stack-based VM. Unless you want things to run very, very slowly you still need a JIT to emit native code, rathe…
I think the VM is going to need to be just like every other VM (once inlining is introduced, why even bother with trying to optimize wasm before the JIT).
If wasm is going to be so good, then you could retart java to it? I know a lot of high performance java shops that would love to get rid of the GC in Java. But Hotspot can be an optimizing beast.
>> the goal of WebAssembly is not to replace JavaScript, but to be an awesome tool to use with JavaScript. Let's hope exactly the other way around will happen. I would rather like to see better interop between different languages using wasm than wasm + js.
If there are no competitors, JavaScript wins by default, just like C ffi did on server and desktop.
Earlier quoted context omitted.
Since wasm (currently) requires js to interact with the DOM, you could still read the js code to see if it's passing any sensitive data into wasm.
Js code is sufficiently dynamic where I wouldn’t be confident in anyone using this defense, even with a debugger open.
Does anyone have a good sense of the current performance impact of crossing the boundary between JS and WASM? I've often thought it'd be great to be able to expose high-performance data structures (and other infrastructure-level stuff) via WASM and then make use of them from JavaScript, but I seem to recall that the interop performance cost is currently too high to make it worth doing, which leaves WASM mainly only u…
V8 generates little wrappers for these, with inline conversions. It does not currently inline the little wrapper functions, nor use ICs for the conversions inside, since branches are generally enough to get the interesting fast cases.
The idea of a super-expensive call is therefore a bit of a myth. You can try to measure the cost yourself, but be careful! Most microbenchmarks will end up comparing the difference between an inlined JS call (as low as zero overhead) versus a non-inlined WASM->JS or JS->WASM call. The proper comparison would be instead with a non-inlined JS->JS call. Defeating inlining for JS->JS calls is tricky. You can do it with cross-realm calls, or by trying manipulating polymorphism. In either case, it's pretty tricky, so good luck.
>> the goal of WebAssembly is not to replace JavaScript, but to be an awesome tool to use with JavaScript. Let's hope exactly the other way around will happen. I would rather like to see better interop between different languages using wasm than wasm + js.
Let's be real, the goal of WebAssembly is to replace JavaScript, but providing alternatives to it. The whole "WASM doesn't replace JS!" thing is pretty much just to placate the "But what's wrong with Javascript?!" crowd.
The WASM will replace JavaScript argument exists not for any valid technology reasoning, because people desperately need it to (only for personal reasons) and don't understand how web technologies work on the front end.
The goal of WASM was never to replace JavaScript, but to replace Flash (before Adobe announced the death of Flash) in a language agnostic way.
Earlier quoted context omitted.
The original runtime was about 60kb in size, that's still unreasonable to add to a library. Imagine a small library like Redux (2kb, including dependencies) having to ship with a runtime that's 60kb (or more). Now imagine a project that depends on multiple libraries of the same size or larger... This is why a language that has no runtime (such as Rust) makes more sense for developing wasm packages that can be used si…
> The original runtime was about 60kb in size, that's still unreasonable to add to a library. In which planet? Not only will most frameworks and standard JS libs dwarf this, but the average web page size has upped to ~ 3MB these days...
The original runtime that was used by Blazor was already a compact .NET runtime, and no matter how much you minify it (or any other runtime, such as the JVM), it will always have a considerable size.
>the average web page size has upped to ~ 3MB these days...
This is not an excuse to make web pages' sizes even larger :).
Btw, I'm not against the idea of using a managed language that targets WebAssembly for front-end development. On the contrary, I'm very excited about Blazor and I'm following its development, and I would love to see similar frameworks for other languages such as Kotlin or Swift.
But while I think the size of a runtime won't be an issue for web applications that use such frameworks, I don't like the idea of shipping large runtimes with wasm packages that might be used with other languages.