[vlovich123]

Do you see catching up on performance with v8-jitless as a goal or is conformance the primary goal right now? Any plans on doing a JIT? I was always impressed by the idea of Truffle where you implement the language semantics once and you get both interpreter and JIT safely out of it which is a huge source of vulnerabilities in traditional JIT systems

[nekevss]

Hi, I'm another one of the maintainers on the project.

In general, we are shifting more to performance now than conformance. We currently sit at around 94% conformance, so there's not really that much more to go conformance-wise. The remaining conformance gains are a couple of the newer specification features and Intl related features. Our current conformance can be found at https://boajs.dev/conformance.

Regarding performance, we are already making some gains, with hopefully more to come. The best example of this was probably the updates to script-bench-rs with our most recent release (which can be found at this commit https://github.com/khvzak/script-bench-rs/commit/d9635de77d2...). We still obviously have more to improve on, but we have already made some pretty steady progress from where we were.

EDIT: I forgot to answer your question about v8-jitless. Obviously in the future it would be nice to be able to be more competitive with v8-jitless, but at least for me, I'd just like to focus on improving the Boa overall.

[echelon]

Does Boa support `fetch`? And if so, is it built on Reqwest or Wreq [1]?

I immediately have use for this if y'all have async fetch support. I can use JavaScript as an extension language for our app.

I love how supremely easy it looks to embed in normal Rust apps without a complicated build script. That, to me, is a killer feature.

Really awesome work on this!

[1] Wreq is starting to get popular for its ability to bypass Cloudflare and look like a normal browser

[nekevss]

So this is a bit loaded. Short answer: it can.

Long answer: first, `fetch` is a runtime feature, and Boa is first and foremost an engine. So `boa_engine` -- the core project crate -- does not support `fetch` out of the box.

That being said, we do have a `boa_runtime` crate. This crate is not currently a full runtime, but it is a collection of runtime features that have been implemented and can be registered onto the context. `fetch` is one of the features that has an implementation completed in `boa_runtime`, and it does use reqwest if I'm remembering correctly. If you're interested to see some example code of registering features, you can look at our CLI code as an example :)

[echelon]

This sounds really well architected and extensible. I've gotta check this out.

Thank you!

[nekevss]

No problem! If you have any questions, feel free to open an issue / discussion or reach out to us on Matrix / Discord.

[jayflux]

The past year has been huge for conformance for us, not only we caught up with the top engines but we surpassed them when working on Temporal and having all tests pass for that.

We hope to wind down some of the conformance priority now and focus on performance, we need to work on a new GC, refactor some parts of the engine, and improve various areas.

The idea of a JIT has been raised and we’re not against it, but it’s not on our plans right now (because of the above), that being said there is an open discussion.

[andy_ppp]

You might want to look at the way the BEAM guys implemented their JIT in a slightly simplified and less performant (but obviously in way that is easier to reason about and extend and build upon) should you go down this road! Interesting project, I will take a look.

[amelius]

Are existing GCs for Rust (e.g. rsgc) not suitable?

[nekevss]

Right now, we use a forked and modified version of the `gc`. We definitely need to update it. Admittedly, I've been hoping to work on it but got a little distracted with temporal ...

I don't think I've actually heard of rsgc before. It's definitely interesting to see playXE put it together. I know that they'd been working on starlight at one point, so it'd be interesting to see takeaways from it.

To get to your question on the existing GCs, so far the answer is we don't truly know. We really need to do some GC experiments and test different options in Boa with JavaScript. There are not really that many GC crates out there of which I'm aware. There rust-gc's `gc` crate, dumpster, and `arena-gc` (tack on rsgc). But of those, the `gc` crate truly has the best API that we've used in Boa, but the performance is not ideal amongst other optimizations. It would be nice to preserve that API while improving the performance as well. But that remains to be seen.

[amelius]

Here are some gc crates:

https://docs.rs/rsgc/latest/rsgc/

https://docs.rs/ristretto_gc/latest/ristretto_gc/

https://docs.rs/dumpster/latest/dumpster/

https://docs.rs/shredder/latest/shredder/

I have no experience with them. In any case, it would be advisable to make the GC implementation swappable so that the language is gc-implementation-agnostic.

[nekevss]

The hope of the experiments is to hopefully find an API that can be used and allow for the GCs to be more swappable. At least that's my personal hope.

We really have to dig into the experimentation and rewrite before knowing for certain.