Windows Support ?

[Shabinder]

Whats the status on windows compatibility, I am aware, quickJS had some issues with it earlier,
but there have been recent changes in bellard's QuickJS upstream.

there are also forks like QuickJS-NG which are more actively maintained,

thoughts ?

[JakeWharton]

We can't really update the version of QuickJS because we ship the bytecode which is not stable. We can apply patches to the build locally, however. Windows support is not needed for our usage, so it would have to be contributed.

Any effort from our side is likely to be with the goal of moving to Wasm as the runtime which fixes so many problems (stable bytecode, Windows support, performance, etc.)

[Shabinder]

I do understand that end goal is to move to WASM,

• Is there any clarity when that might be ? or if we are waiting on which WASM engine specifically ?

we ship the bytecode which is not stable

If I understand this correctly, updating quickJS will lead to a different bytecode, which will be breaking for all the users which are on any other quickJS engine.

Correct ?

If a developer wanted they could pull in updated quickJS in a fork while also limiting at client side as well which published service version they can use so basically a force update kind of situation whenever they ship new service manifests and the client app.

r8?

[JakeWharton]

I do understand that end goal is to move to WASM,

* Is there any clarity when that might be ? or if we are waiting on which WASM engine specifically ?

I would say no sooner than 2025, but more realistically probably still a year away.

I've been keeping track of https://github.com/wasm3/wasm3 and https://github.com/FastVM/Web49, but we recently noticed that https://github.com/bytecodealliance/wasm-micro-runtime/ is quite promising so it's probably the leading candidate.

we ship the bytecode which is not stable

If I understand this correctly, updating quickJS will lead to a different bytecode, which will be breaking for all the users which are on any other quickJS engine.

Correct ?

Yes

If a developer wanted they could pull in updated quickJS in a fork while also limiting at client side as well which published service version they can use so basically a force update kind of situation whenever they ship new service manifests and the client app.

r8?

We have the ability to force client updates, but it's not a level we like to pull. There are some very appealing updates to QuickJS, but unless it's something we really need (like a new backend for string concatenation), the effort of doing this isn't worth it for us.

You are, of course, welcome to do this in a fork.

However, if someone wants to get Windows working with the current version of QuickJS that we use, that would be welcomed here.