41–50 of 54 posts
Earlier quoted context omitted.
WASM isn't more more "modern", it is just being hyped up because it caters to the JS developers.
You have that exactly backwards... WASM allows you to build in whatever language you like and target portable operation that includes a browser.
What is the actual problem this is trying to solve? Are there programming languages it was previously hard to write web apps in? Do people not like setting up nginx? From my understanding the benefit of wasm on the server side is generally that you get the sandboxing inherent in the VM. Why would you want that in the context of Apache? Are people planning on running untrusted code? If mod_wasm is designed to address…
However, the number of languages that support wasm is growing rapidly and this is a language neutral solution that should work for all of them.
One advantage wasm and wasmtime have over containers and vms is that it's a very low latency thing to fire up. It's very fast. That's why it's so popular for edge computing as well. And it also makes it very suitable for use in an apache module. I guess you could do an Apache module that fires up a docker container to execute some code but that sounds like it would have a bit of overhead. It would not surprise me if somebody already built something like that.
Anyway, this gives people more places to run wasm code. Not a bad thing. This might actually become a nice way to implement some way of implementing some kind of self hosted "serverless" type thing to run lambda functions in the form of wasm blobs. Just one of many things you could do with this.
Earlier quoted context omitted.
You have that exactly backwards... WASM allows you to build in whatever language you like and target portable operation that includes a browser.
GoReleaser and Cargo do that already. Cross-compilation is nothing new.
WASM is still too unapproachable. I've looked into how to build things for WASI/WASM and it seems like you're just dropped into this world of tooling and development practices that I'm sure makes tons of sense to people who are already steeped in the WASM ecosystem but is disorienting for someone new. WASM really needs some getting started guides that describe what the hell is going on and what the capabilities and l…
Earlier quoted context omitted.
GoReleaser and Cargo do that already. Cross-compilation is nothing new.
I think there is a difference between "compile once, run everywhere" and "code once, compile (for) everywhere".
WASM is still too unapproachable. I've looked into how to build things for WASI/WASM and it seems like you're just dropped into this world of tooling and development practices that I'm sure makes tons of sense to people who are already steeped in the WASM ecosystem but is disorienting for someone new. WASM really needs some getting started guides that describe what the hell is going on and what the capabilities and l…
All the tooling seems geared to outputting "glue code" as typescript or javascript, and I've yet to find any real documentation on if it's even possible to do so for other languages without massive amounts of manual work.
So my initial elation at finding a warm extension for php (wasmer-php), which would let us bolt in secure, sandboxed scripting languages for customer projects... Is now on the back burner as while it can run some example wasm, anything made with wasi or emscriptem is unusable.
Earlier quoted context omitted.
WASM is basically a way to deliver the old JVM promise of "compiled once, run everywhere, sandbox if needed", with the additional constraint of "close-to-native performance" and "any language can compile down to it". It's a good thing if it delivers on all those promises. And it's especially a good thing if you don't like JS, because it's our best shot at dethroning JS.
I think Cargo and GoReleaser already make this simple enough. Heck, even Alpine Linux has down the process of compiling for multiple architectures for multiple languages. It really isn't that much of a challenge to do so and there are already sandboxing solutions for each operating system. WASM doesn't get rid of JS, it just puts sandboxing into a JS-based engine. The last thing people should want is to run binary bl…
And it's not any more or less transparent than a minified blob of JS.
Earlier quoted context omitted.
Running WebAssembly modules in Apache http server allows devs to run many different languages by targetting Wasm. This includes interpreted languages like the Python example from the article. With the WebAssembly sandboxing capabilities you're getting a high level of isolation without adding overhead to the system. VMs and Containers require to run more complex environment for runnning the code. And even you're runni…
I understand that, but was it really hard to deploy web apps in any of those languages before? Granted, you wouldn’t use Apache to run them, but the current reverse proxy through nginx method seems much better in terms of complexity and performance than wasm + Apache. Am I missing something?
It's true that Wasm lacks of the tooling and ecosystem than other apps have. You can find infinite tutorials about how to deploy a Python app. You will find a few for publishing a Wasm module.
And about performance, you are right. Currently Wasm introduces a performance penalty, although the different runtimes are working hard on it. The other side of this is that you gain an extra isolation layer that improves the security. By default, an application won't be able to access any resources on the system.
Said this, WebAssembly is still in the early stages. mod_wasm is a way to bring this technology to a well-known web server. However, it is not meant to start moving all your workloads now as it's still not mature enough :)
Earlier quoted context omitted.
Now it is the battle of keeping the zillions of JavaScript packages vs PHP packages up … to … date. I think WASM may have bigger problems with external vulnerability assessment team identifying those modules by version that got broken.
WASM is the wrong level of the software stack to check for outdated versions, that's the host language's package manager's job.
It is often the job of vulnerability assessment team to get down to the root of the misbehaving components, WASM or not.
Earlier quoted context omitted.
WASM is the wrong level of the software stack to check for outdated versions, that's the host language's package manager's job.
Wrong? There isn’t a right or wrong about this. It is often the job of vulnerability assessment team to get down to the root of the misbehaving components, WASM or not.