51–60 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'm dreaming of seeing a wasm DOM api that directly binds to the browser's apis, without passing through javascript. Is this even a possibility?
when we can make web pages, and entire sites without once actually using something a human can disassemble and reverse engineer ... this will be the end of the open web. truly the complete dead end of it. Unless maybe I'm missing something. Is a disassembler for WASM a thing yet?
Earlier quoted context omitted.
> more than ever, it's being taken up by people with no passion or desire to program solely so they can make what they think is going to be "The Next [WebCompany]," See, that's why you were encouraged to stop before you dug yourself deeper. Now you've doubled down on disparaging an entire class of people based on their choice of programming language because of some assumed greed you think they think they have. Perhap…
A great comment, and I couldn't agree more. If the family computer in the early 90s didn't have QBasic - I wouldn't be a developer today. > more than ever, it's being taken up by people with no passion or desire to program solely so they can make what they think is going to be "The Next [WebCompany]," I feel like kbenson forgets that the point of programming to the vast majority of people, is typically the end result…
Sure it is. I just think most people don't start out thinking "I'm going to make the next Facebook", or at least not seriously. A lot of the time it's just tinkering. I mean, that's the reason the code produced isn't high quality, because the people really are complete amateurs screwing around. In that respect, I think the end result is "I want to learn this or to make something cool".
> As Lin Clark emphasizes in her article about Rust and WebAssembly: the goal of WebAssembly is not to replace JavaScript, but to be an awesome tool to use with JavaScript. Please no. JavaScript's a bit cancerous - we should be erring away from it rather than encouraging it.
You are living in the past tbh. There are tools which make augment the language and it is literally taking over the world now!
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 have a package on NPM which is only partially implemented, using it in a production app is a bad idea, a quick glance at the source code or the todo section of the readme makes it pretty obvious. I still gets bug reports and npm says it has hundreds of download every month. For anything serious, read the source code, at the very least check your dependencies.
To do that well, it would be someone's fulltime job to read and do security audits on all those dependencies.
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 have a package on NPM which is only partially implemented, using it in a production app is a bad idea, a quick glance at the source code or the todo section of the readme makes it pretty obvious. I still gets bug reports and npm says it has hundreds of download every month. For anything serious, read the source code, at the very least check your dependencies.
>> 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.
I think that misses the point. Since WASM is a compile target you don't need JS to achieve interop between different languages if they are all compiled to WASM. The JS + WASM combo is to do things that WASM container cannot do on its own.
I'm kind of curious how wasm is going to work out. It seems only logical that wasm interpreters will be optimizing JITs. Wasm will essentially be an intermediate language similar to JVM bytecode. At that point why not just use the JVM stripped of the useless stuff as a base and add the remaining small pieces that might be needed. Or Graal. I guess I don't understand what Wasm is doing that is so much different that c…
> 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 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, rather than loop dispatching each WebAssembly instruction in a bytecode interpreter.
WebKit, for example, has a two-tier JIT for WebAssembly just like JS, but WebAssembly has already had all the high level language related optimizations performed and looks a bit like an intermediate representation anyway so the first pass is very fast.
I'm dreaming of seeing a wasm DOM api that directly binds to the browser's apis, without passing through javascript. Is this even a possibility?
Adding it to WASM will not be the amazing experience many think it will be.
It seems like cargo-web has lots of this ground covered already. I'm wondering why build these other tools in that case? I don't have a dog in this fight, I'm just working on a wasm-based app that I'm hoping will serve me for quite some time, and seeing what appears to be duplicated effort at such an early stage worries me a bit.
Either way, thanks for building this!