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

41–50 of 66 posts

Re: Debugging WebAssembly outside of the browser

#41

Post by k__ »

tracker1 wrote: post #25
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…

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.

Can you show some apps using Blazor?

Re: Debugging WebAssembly outside of the browser

#42

Post by moron4hire »

flmontpetit wrote: post #37
moron4hire wrote: post #21

Earlier quoted context omitted.

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

Though I didn't call it out specifically, I wasn't ignoring it, hence the mention of C#.

Again, some languages are unnecessarily wasteful of cycles.

Re: Debugging WebAssembly outside of the browser

#43

Post by tracker1 »

k__ wrote: post #41
tracker1 wrote: post #25

Earlier quoted context omitted.

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.

Can you show some apps using Blazor?

Nothing is public/demoable at this point, sorry. They're using Bootstrap with a Material Design theme applied, nothing too special (CRUD). The app I'm working on has a more complex UI.

Re: Debugging WebAssembly outside of the browser

#44

Post by AgentME »

ScottFree wrote: post #28
kodablah wrote: post #13

Earlier quoted context omitted.

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.

A good wasm debugger would let you see the source code too, just like how regular native debuggers show you the source code instead of x86 assembly.

Re: Debugging WebAssembly outside of the browser

#45

Post by buckminster »

ScottFree wrote: post #27
michaelanckaert wrote: post #12

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…

> Do you remember trying to debug Javascript before the creation of the in-browser debugger?

Yes, I used visual studio. You could debug the server in the same session. It was pretty sweet.

Re: Debugging WebAssembly outside of the browser

#46

Post by michaelanckaert »

ScottFree wrote: post #27
michaelanckaert wrote: post #12

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…

True, without tooling most platforms/languages would suck to work with.

But I believe that the more tooling a stack needs, the more wobbly the stack gets. The more wobble the more error prone and less fun to work with.

Re: Debugging WebAssembly outside of the browser

#47

Post by s_y_n_t_a_x »

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…

Some people may feel that way, but the general plan is not to replace JS. It's mentioned multiple times in official docs and blog posts.

https://webassembly.org/docs/faq/#is-webassembly-trying-to-r...

Re: Debugging WebAssembly outside of the browser

#48

Post by flohofwoe »

MuffinFlavored wrote: post #38
flohofwoe wrote: post #33

Earlier quoted context omitted.

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

Think of plugins for applications like Autodesk Maya. Currently these are either cross-platform, but very slow Python plugins, or fast native DLLs which need to be compiled for each app-version/OS/CPU combination.

If Maya had an embedded WASM runtime it could support plugins which are fast (at least much closer to native speed than Python scripts), and you only need to distribute a single WASM blob.

Re: Debugging WebAssembly outside of the browser

#49

Post by [deleted] »

ScottFree wrote: post #32
aidos wrote: post #31

Earlier quoted context omitted.

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.

[deleted]

Re: Debugging WebAssembly outside of the browser

#50

Post by blaisio »

I'm not a fan of seeing web assembly spread outside the browser. If you want to sandbox binary code, there are many much more efficient options, eg. Linux containers (especially with tools like gvisor) or VMs. Vendors that only allow use of WebAssembly are leaving performance and compatibility on the table.
Post reply on HN