Live data from Hacker News

Debugging WebAssembly outside of the browser

hacks.mozilla.org

21–30 of 66 posts

Re: Debugging WebAssembly outside of the browser

#21
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…

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 the world. Just like all other resources, in aggregate, waste is harmful.

Even on the spectrum of "developer productivity", you have to seriously consider if the operational cost of needing beefier servers to run slow-language-X is less than the operational cost of hiring fast-language-Y developers.

I doubt anyone has done a serious study of the issue. Say C++ is 15x faster than Python. You might be able to say that a C++ dev is 2x the cost of a Python dev. Is the ratio of development cost to server cost more than 7.5x? What about other languages that aren't quite so fast, but aren't quite so expensive? You might find that C# is 10x faster than Python, but devs are only 1.25x the cost. Now your ratio of dev cost to server cost needs to be at least 8x to come ahead.

And honestly, good developers are expensive, no matter what language they're working in. Choosing a programming language to be able to optimize for cheap developers could be optimizing for bad developers who can't create the features you need. They might be half the price, but can they get the job done--after all the reworks and defect fixes and other learning curves--in less than 2x the time? I've never seen a programming language on its own have that kind of impact on development.

The point is not that "Language X is universally better than language Y". My point is more that "some languages are so incredibly wasteful that you seriously have to start considering whether or not you're saving money".

Re: Debugging WebAssembly outside of the browser

#22

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.

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 the browser"

Re: Debugging WebAssembly outside of the browser

#24
post #19

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…

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?

Re: Debugging WebAssembly outside of the browser

#25
post #19

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…

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…

I work in a company that currently has 2/3 of the teams using Blazor because they aren't comfortable/familiar enough with JS. My team being C# backend and React/Redux/Material-UI front end (using node scripts for all orchestration and ci/cd).

It's a mostly MS shop and you'd be surprised how many developers in orgs really just don't do front end work because of JS.

Re: Debugging WebAssembly outside of the browser

#26
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?

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.

Re: Debugging WebAssembly outside of the browser

#27

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.

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 practice is going to come down to how good the tooling is.

Re: Debugging WebAssembly outside of the browser

#28

Earlier quoted context omitted.

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

While that can work with self-contained libs, quite often Rust WASM code uses wasm-bindgen/web-sys to talk to JS/DOM which makes in-browser debugging the only reasonable way.

Flash and Java allowed you to run the code in the browser, but still debug using the source code and not the VM bytecode.

Re: Debugging WebAssembly outside of the browser

#29

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.

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/

Re: Debugging WebAssembly outside of the browser

#30
post #29

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/

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.

Post reply on HN