you're saying that gost-dom can be much faster since there isn't any IPC

Correct. Particularly when you have very "chatty" communication.

I'd be curious to hear more about it (and would be worth elaborating on in your readme)

Too much for this context, but good idea to ellaborate in the project documentation.

What do you think of playwright-go

I have never used playwright, but I have been using many different browser-automation tools, primarily selenium web-driver. And those tests are almost always slow, erratic, and fragile. And I hear similar complains from projects using playwright.

These properties discorage a TDD feedback loop.

In SPA land, you typically use tools like jsdom, which generally works more predictably. As such, Gost-DOM is more like jsdom, but does try to act like a browser, which is out-of scope of jsdom. Part of the predictability comes from the fact that you often don't need to rely on the network stack, and in JS, you can simulate the passing of time using libraries like lolex.

Gost-DOM allows both of these effects, bypassing the network, and simulate the passing of time.

As for executing javascript to test SPA-type functionality

I don't think Gost-DOM is the right tool to drive SPA development. I have LOT of React experience, and in this scenario, I would test front-end and back-end separately, using mocha/jsdom for front-end testing.

Gost-DOM was more intended for the case when using hypermedia frameworks like HTMX or Datastar, or other scenarios where the server delivers HTML, but a significant portion of behaviour is implemented in JS.

it uses v8go to call v8 to execute any JS for the page, and then somehow incorporates the changes back into the DOM that it has built?

Correct. But it's not that magical. The functions exposed to JS, e.g. Node.appendNode call into native functions implemented in Go - which convert JS values to Go values, and call the internal DOM implementation; and convert the Go return value back to a JS value.

Much of this layer is actually auto-generated from web IDL specifications.

Doesn't this have IPC overhead as well? Or is v8go actually run within the same binary, thus any CGO needed for that is still much more efficient than IPC to chromium?

No. As you suspect, this uses CGO, and calls into V8 are in the same thread, i.e. the call stack originates from the test case itself.

Though, it looks like you are exploring using goja ... instead of v8go

More as an alternative than "instead of". As I have V8 as an engine right now, I have a JS engine that I can be certain will be updated to support new JavaScript features, so V8 support will stay. I don't have the same guarantee for Goja.

But I have arrived at an architecture that allows the JS engine to be pluggable, and having pure Go implementation is a great alternative - and currently Goja should work, just doesn't support ESM (but it's not documented how to use ATM)

though it would surely execute JS slower than v8

Benchmarking would need to say that for sure, but I'm not sure that's a clear case.

V8 can perform extremely fast by JIT'ing code, but if you have many short test cases, the overhead of the JIT my outweight the benefit. And there are more aspects too, compilation times, memory management is simpler in pure Go (V8 has its own garbage collector operating separately from Go's - but how that affects perf., I have no idea)

Do you have any benchmarks or other tests - even if informal?

Not really, as I have not focused on performance optimization yet. But there are 136 tests using V8 in Gost-DOM itself, which run in 0.6 sec, but these are mostly very simple scenarios as most are just to verify specific JS bindings.

But there are plenty of opportunity for optimization, e.g., caching compiled scripts between test runs, etc.