11–20 of 66 posts
Looks like we're well on our way to a somewhat overly complicated reimplementation of thin binaries[1] [1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.108...
We had that already with the JVM and CIL. They never caught on in the browser.
I actually enjoy creating plain server side rendered web applications with just a dusting of client side Javascript where it makes sense. The development flow is simple and debugging is easy.
Earlier quoted context omitted.
I don't see how you would "debug directly the rust code" without debugging the wasm binaries. Wasm is a compilation target for rust. To be clear: You compile rust directly to wasm, it's not like you compile your rust to a binary and then convert that to wasm. I do not believe there is an intermediate artifact. As for your second question... there's motion towards making wasm runtimes other environments, like devices…
> I don't see how you would "debug directly the rust code" I think the intention of OP is that you compile the same Rust code to a native x86 or ARM binary and debug that. Most bugs are ISA-agnostic so that approach totally makes sense in many situations. That's how I'm debugging my WASM code compiled from C/C++, and that also works automatically with IDE debuggers that don't know about WASM (like Xcode's or Visual S…
I'm not sure if I like where this whole WebAssemby thing is going. On one hand I'm thrilled to the prospect of Python in the browser, on the other this seems like a huge layered mess just waiting to trouble those poor devs. I actually enjoy creating plain server side rendered web applications with just a dusting of client side Javascript where it makes sense. The development flow is simple and debugging is easy.
But well, I guess people will do it anyway, let's see how this plays out in the long run.
Looks interesting, but why would I need to debug wasm binaries when I could debug directly the rust code? And why would I want to convert it to wasm? In order to run it in the browser, right?
So there's effectively another layer of sandboxing versus a native binary, and you might need to track down how your program behaves in that sandbox.
Similarly, if you're working with a program that imports several WebAssembly modules, you'll need a way to debug the combined system, versus any single module in isolation.
Looks interesting, but why would I need to debug wasm binaries when I could debug directly the rust code? And why would I want to convert it to wasm? In order to run it in the browser, right?
What if your code is browser specific and uses the javascript based API? You'll need to run it in the browser to debug it right?
This post is specifically "Debugging WebAssembly Outside of the Browser," but the title on HN was unfortunately truncated.
I'm not sure if I like where this whole WebAssemby thing is going. On one hand I'm thrilled to the prospect of Python in the browser, on the other this seems like a huge layered mess just waiting to trouble those poor devs. I actually enjoy creating plain server side rendered web applications with just a dusting of client side Javascript where it makes sense. The development flow is simple and debugging is easy.
It probably won't replace solutions that already work well, but it might be an option for the things that currently don't work.
I'm not sure if I like where this whole WebAssemby thing is going. On one hand I'm thrilled to the prospect of Python in the browser, on the other this seems like a huge layered mess just waiting to trouble those poor devs. I actually enjoy creating plain server side rendered web applications with just a dusting of client side Javascript where it makes sense. The development flow is simple and debugging is easy.
I think the plan was to get high performance stuff into the browser, with languages like C/C++ and Rust and not to replace JS with Python, C# or Java. But well, I guess people will do it anyway, let's see how this plays out in the long run.
On the contrary, for many people performance isn’t a factor, but they find the idea of using the same language (and thus code) client-side and server-side appealing.
This was one of the key features and benefits of NodeJS, and I won’t be surprised when I see others trying to replicate the experience via web-assembly.
Earlier quoted context omitted.
I think the plan was to get high performance stuff into the browser, with languages like C/C++ and Rust and not to replace JS with Python, C# or Java. But well, I guess people will do it anyway, let's see how this plays out in the long run.
> I think the plan was to get high performance stuff into the browser, with languages like C/C++ and Rust and not to replace JS with Python, C# or Java. On the contrary, for many people performance isn’t a factor, but they find the idea of using the same language (and thus code) client-side and server-side appealing. This was one of the key features and benefits of NodeJS, and I won’t be surprised when I see others t…
What I want to say is, I question the premise that there are as many backend devs who just don't do frontent stuff because of JS as there were frontend devs who didn't do backend because JS wasn't an option.
On the other hand the industry gets bigger by the day, maybe even a small percentage of devs doing Python frontends will be thousands of people :)
Earlier quoted context omitted.
We had that already with the JVM and CIL. They never caught on in the browser.
No, we had a VM / runtime environment with those. Now it's much closer to the metal.
The sandboxing story also seems to be much stronger with WASM than either of those (where sandboxing felt more like an afterthought at best).
In other words: WASM still relies on a runtime/VM, but the difference is that the runtime/VM is astronomically better for the intended use case (and also, incidentally, a presumably-unintended use case) than most existing runtimes/VMs.