Stream: general

Topic: wasm-bindgen article

Jakob Meier (jakmeier) (Nov 19 2024 at 10:01):

Hello! Not sure if this is the best place for this but I found nothing more specific for wasm-bindgen... So, I'm asking here, where I guess most people involved with wasm hang around.

Last week at a Rust meetup in Zurich, I gave a talk about my experiences with wasm-bindgen. Once the video is uploaded by the organizers, I will publish a written blog post on the same topic, too.

I wondered if any contributors of wasm-bindgen would want to check my draft for mistakes before I publish it. The current draft is available as an unlisted post on my blog: Rust and JS is the perfect pairing with no issues at all

I speak and write about wasm-bindgen because I love using it. However, this article is a bit cynical, so I want to ensure I am not misrepresenting anything.

daxpedda (Nov 19 2024 at 11:05):

Hey, wasm-bindgen maintainer here!
Will manage to take a look tomorrow probably.
Thank you!

bjorn3 (Nov 21 2024 at 11:42):

Looks like you have a broken video tag after

A quick recompilation and a reload of the page later, I now see the number increase as I move the cursor. But somehow, it is stuck at 2 events. This time, there is no error in the console. What is the issue?

It gets rendered as regular text. Likely because of a missing space.

Edit: Same issue in a couple of other places.

Jakob Meier (jakmeier) (Nov 21 2024 at 12:53):

Thank you @bjorn3, it should be fixed now.

daxpedda (Nov 23 2024 at 08:16):

Just gave it a quick rundown:

• "Javascript" should be written "JavaScript" (see e.g. Wikipedia).
• Don't use event handler attributes. Use EventTarget.addEventListener() instead.
• You should probably not use Data.now(), which is a. more accurate (f64) and b. not susceptible to local time changes, e.g. summer/winter time or simply time corrections by the system. Instead use Performance.now(). However, you can simply use Event.timeStamp, which even more accurately represents exactly when this event happend.

Its interesting to see such a somber review of the interaction between WBG and JS, I basically never use that side of WBG. Especially the getter part hit bad. One would think that there should a sort of of non-Copy getter, that actually gives you a reference. But the lifetime issues around that would be absolutely abysmal.

Jakob Meier (jakmeier) (Nov 28 2024 at 14:54):

Thank you @daxpedda ! I have incorporated your feedback in my post. Still waiting for the meetup organizer to upload the video, though. I will post here again when I publish the post.

Jakob Meier (jakmeier) (Nov 28 2024 at 14:56):

daxpedda said:

Its interesting to see such a somber review of the interaction between WBG and JS, I basically never use that side of WBG. Especially the getter part hit bad. One would think that there should a sort of of non-Copy getter, that actually gives you a reference. But the lifetime issues around that would be absolutely abysmal.

I hope it's not too somber. I mean, the article is directed to point our problems specifically but I still want it to be fair.

And yeah, regarding the lifetimes, I think I can see exactly what you mean.

daxpedda (Nov 28 2024 at 14:57):

Its absolutely fair. Thank you for putting in the work and sharing!
It is truly appreciated!

Jakob Meier (jakmeier) (Nov 28 2024 at 15:02):

Regrading the lifetime issues, I initially looked at https://github.com/rustwasm/wasm-bindgen/issues/19
I believe this could be a first step towards non-copy getters.

Do you perhaps know, has there been more work or ideas in the direction of allowing references to Rust owned values on the JS side?

daxpedda (Nov 28 2024 at 15:59):

While https://github.com/rustwasm/wasm-bindgen/issues/19 would be simple to implement, and the checks are in place already, it would be a major footgun to use in JS. But yes, we already knew this could work.

Just vaguely remembered https://github.com/rustwasm/wasm-bindgen/pull/4118 and the corresponding ECMAScript explicit resource management proposal. I started digging a bit and found https://github.com/tc39/proposal-explicit-resource-management/issues/195. So the current proposal can't enforce the using scope. But apparently there is a workaround: https://github.com/tc39/proposal-explicit-resource-management/issues/159#issuecomment-1630532470.

So maybe this could be used to solve this issue?

Jakob Meier (jakmeier) (Nov 28 2024 at 17:49):

Thanks for gathering the links! Very interesting, I had no idea about the using proposal. I can see how this could help with a much cleaner solution to provide non-copy getters, especially with the work-around to enforce proper usage.

I'll need to think about it some more but I might come back to this topic later. For now, just one last question. Without promising anything, yet, would there be a base level of interest for contributions to wasm-bindgen regarding non-copy getter implementations?

daxpedda (Nov 28 2024 at 17:50):

You mean for reviewing? Yes.
But it needs a good proposal and probably a lot of explaining, I'm definitely no expert with JS.

Jakob Meier (jakmeier) (Nov 28 2024 at 17:53):

Ok, yeah sounds good :thumbs_up:

Last updated: Dec 23 2024 at 12:05 UTC