Yep, that’s where I drew the line. It only models behavior of a single thread. Essentially we just treat the
@compute
fn main(...){}
As a function, where we are free to supply input parameters.
Memory barriers and other cooperative constructs would only make sense if I was emulating this at instruction level to have parallelism constructs. Since I don’t - those things wouldn’t even make sense, not in JS anyway.
I opted for being closer to JS, rather than emulating the SIMT execution model, but it’s a real limitation.
I thought about it, the “right” fix would be to just pull in a full WASM emulator, but then we’d lose ease of debugging and making WGSL look like JS.
My code base is highly modular, I have something like 700 individual WGSL modules in Shade, which in turn import from one another where that makes sense. The point is - it’s highly suitable to unit-testing.
In a project where you only have monolithic shaders it would be a lot less useful I imagine 
Not to say that I don’t miss having such functionality for myself. I have a lot of barriers in my code, and a lot of subgroup ops. Barriers I don’t actually find hard to understand, but debugging subgroup operations would be incredibly useful.
Sorry to disappoint - but no, Shade is all proprietary and generally treated as closed-source. But I’m completely open to licensing.
As for the point about speed. It’s fast. I added support for fragment shaders recently. Here are sample timings for RCAS (sharpening post process) shader:
1ms is cold-start of the suite and WGSL → JS compilation