Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Debugging WebAssembly outside of the browser

hacks.mozilla.org

Post reply on HN
Print view View original

31–40 of 66 posts

Re: Debugging WebAssembly outside of the browser

#31

Post by aidos »

ScottFree wrote: post #30
aidos wrote: post #29

Earlier quoted context omitted.

Minor nitpick. WebKit created a debugger a couple of years before chrome existed. https://webkit.org/blog/61/introducing-drosera/

Yes, the bike shed should definitely be green. I knew somebody was going to object to that little factoid despite its irrelevance to the point at hand. I've updated my comment to remove any reference to any specific in-browser debugger.

Apologies, didn’t intend to detract from your point. I thought people might be interested in the history of it since very few people even at the time seemed to know of its existence.

Re: Debugging WebAssembly outside of the browser

#32

Post by ScottFree »

aidos wrote: post #31
ScottFree wrote: post #30

Earlier quoted context omitted.

Yes, the bike shed should definitely be green. I knew somebody was going to object to that little factoid despite its irrelevance to the point at hand. I've updated my comment to remove any reference to any specific in-browser debugger.

Apologies, didn’t intend to detract from your point. I thought people might be interested in the history of it since very few people even at the time seemed to know of its existence.

No worries. I should have chosen my words more carefully. And, to be fair, I didn't know webkit was the first to create an in-browser debugger either. I always thought it was either Chrome or Firefox.

Re: Debugging WebAssembly outside of the browser

#33

Post by flohofwoe »

MuffinFlavored wrote: post #22
flohofwoe wrote: post #17

Earlier quoted context omitted.

A good use case for WASM outside the browser is application plugins, or tools where it's better to distribute "WASM binaries" because client-side compilation from C, C++ or Rust might take too long or is too much hassle for the user. It probably won't replace solutions that already work well, but it might be an option for the things that currently don't work.

Until you find out WebAssembly can't call any native functions (for example: to create a GUI, to call a .so / .dll export, etc.) There was discussion to add `dl_open` + `dl_sym` to WASI but it got shot down. WebAssembly seems to be in a weird state of "look, I can run in and out of the browser, but I can't actually do anything useful out of the browser, and I can't access the DOM without going through JavaScript in t…

WASM embeddings like https://github.com/wasmerio/wasmer-c-api should allow that, at least calling from the embedder into WASM, and from WASM into the embedder.

(e.g. see https://github.com/wasmerio/wasmer-c-api/blob/master/wasmer-...)

There's similar embeddings for other languages here (python, go, ruby etc...):

https://github.com/wasmerio

Re: Debugging WebAssembly outside of the browser

#34

Post by papito »

MuffinFlavored wrote: post #24
k__ wrote: post #19

Earlier quoted context omitted.

I think the USP of Node.js was that the majority of devs already knew JS. 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 p…

How long until the industry doesn't get bigger by the day, and frontend devs + backend devs alike get automated away when AI can generate maintainable + readable code for 95% of the "API + UI plumbing" that is out there?

This AI needs to understand first - in minor detail, what it is that it's actually building. Even two people can't understand each other sometimes, and what they are actually building.

I installed RationalRose once, and... that was it. Code generation tools suck.

Re: Debugging WebAssembly outside of the browser

#36

Post by glandium »

aidos wrote: post #29
ScottFree wrote: post #27

Earlier quoted context omitted.

WASM is still young. The tooling around it hasn't gained maturity yet. Do you remember trying to debug Javascript before the creation of the in-browser debugger? Desktop application developers back then probably felt the same way you do now. > this seems like a huge layered mess just waiting to trouble those poor devs. WASM is a VM. It's less complicated than a javascript engine. How complicated it seems in daily pra…

Minor nitpick. WebKit created a debugger a couple of years before chrome existed. https://webkit.org/blog/61/introducing-drosera/

The Mozilla Suite had a javascript debugger (https://www-archive.mozilla.org/projects/venkman/) before either Webkit or Firefox existed. I won't claim it's the first, although it might as well be.

Re: Debugging WebAssembly outside of the browser

#37

Post by flmontpetit »

moron4hire wrote: post #21
josteink wrote: post #18

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

Contrary to popular belief, performance is always a factor. Every cycle your app wastes is a cycle another app can't use. It's a fraction of a watt that adds up over time, draining batteries faster, drawing electricity from the power grid and burning carbon fuels. Each individual cycle may be cheap, but when we have a culture of development that doesn't respect performance, the waste adds up and has a real impact on…

It's simply not possible to quantify performance in this way, when comparing language implementations. Performance can also be constrained by environment and/or context on top of the expensive abstractions the compiler or interpreter are required to make. But I'm honestly just being pedantic.

You make a good argument about the potential costs abstractions when they are applied at a very large scale. You are however ignoring the cost of things that may be prevented with high-level language features, like for instance errors in memory management which in my opinion are far worse than wasted cycles. I'd wager most would choose a marginally higher power bill over Heartbleed.

Re: Debugging WebAssembly outside of the browser

#38

Post by MuffinFlavored »

flohofwoe wrote: post #33
MuffinFlavored wrote: post #22

Earlier quoted context omitted.

Until you find out WebAssembly can't call any native functions (for example: to create a GUI, to call a .so / .dll export, etc.) There was discussion to add `dl_open` + `dl_sym` to WASI but it got shot down. WebAssembly seems to be in a weird state of "look, I can run in and out of the browser, but I can't actually do anything useful out of the browser, and I can't access the DOM without going through JavaScript in t…

WASM embeddings like https://github.com/wasmerio/wasmer-c-api should allow that, at least calling from the embedder into WASM, and from WASM into the embedder. (e.g. see https://github.com/wasmerio/wasmer-c-api/blob/master/wasmer-... ) There's similar embeddings for other languages here (python, go, ruby etc...): https://github.com/wasmerio

I can't think of any good use cases for loading WebAssembly modules into native code. I also think it's bad out of the gates that the WebAssembly community is so fragmented across the different runtimes (each offering different functionality at the moment).

Re: Debugging WebAssembly outside of the browser

#39

Post by MuffinFlavored »

tracker1 wrote: post #26
MuffinFlavored wrote: post #24

Earlier quoted context omitted.

How long until the industry doesn't get bigger by the day, and frontend devs + backend devs alike get automated away when AI can generate maintainable + readable code for 95% of the "API + UI plumbing" that is out there?

Judging from every time someone has advertised "don't need programmers" services/software has actually worked, I doubt it will ever really happen in practice, at least not in the coming century or more.

I think high level business analysts could write some Markdown-like human readable syntax for things like:

`apiRequest(method, url, requestParameters, headers, body)`

`databaseQuery(credentials, sql, bindings)`

The past 3-5 years of my professional career have just been shuffling data around from one point to another.

Re: Debugging WebAssembly outside of the browser

#40

Post by macspoofing »

josteink wrote: post #18
k__ wrote: post #14

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…

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

Transpilation is a better option if you just care about using the same language because you have better control over the DOM and you can use HTML and CSS markup (which is the best widget set across any platform).

Post reply on HN