Very cool work.
What approach are you using? Been working on a similar in-browser node runtime based on Rust/WASM kernel + Service-Worker HTTP intercept + CJS→ESM transform.
Feature wise, does this compare to StackBlitz webcontainers?
Show HN: Kyushu – A self-hostable WASM sandbox for JavaScript workers
21–30 of 44 posts
Re: Show HN: Kyushu – A self-hostable WASM sandbox for JavaScript workers
#22[dead]
Re: Show HN: Kyushu – A self-hostable WASM sandbox for JavaScript workers
#23Very cool work. What approach are you using? Been working on a similar in-browser node runtime based on Rust/WASM kernel + Service-Worker HTTP intercept + CJS→ESM transform. Feature wise, does this compare to StackBlitz webcontainers?
I had previous experience with QuickJS - respectively using the rquickjs crate (awesome project) - so my approach was first asserting whether it was possible to run a Wasmtime binary that both executes the JS code and handles HTTP requests and responses.
Then, the second part which was really important to me, was figuring out if I could find a way to embed the developer's JS code within the worker without requiring them to install Cargo. (thanks to Wizer it's possible, love it).
Once I had those two, the rest was basically execution (not saying it was straightforward though ;)
I was also a bit lucky: at the same time as I was developing it, Rolldown announced the version 1 of their standalone crate. So it was the perfect timing to use it as well.
As for StackBlitz WebContainers, I actually don't know much about it. They run in the browser as I understand, so fundamentally different but, feature wise I'm sure this project is way more mature and therefore offers way more features.
Re: Show HN: Kyushu – A self-hostable WASM sandbox for JavaScript workers
#24Very cool work. What approach are you using? Been working on a similar in-browser node runtime based on Rust/WASM kernel + Service-Worker HTTP intercept + CJS→ESM transform. Feature wise, does this compare to StackBlitz webcontainers?
I had previous experience with QuickJS - respectively using the rquickjs crate (awesome project) - so my approach was first asserting whether it was possible to run a Wasmtime binary that both executes the JS code and handles HTTP requests and responses. Then, the second part which was really important to me, was figuring out if I could find a way to embed the developer's JS code within the worker without requiring t…
Awesome, thanks for detailing the thought flow and choices that led you here. I chose not to go the QuickJS route for performance reasons but I think it's a solid choice depending on the use case.
> They run in the browser as I understand, so fundamentally different
Yes, runs entirely in the browser, while this is a hosted product. StackBlitz technology is really good but it is closed source.
Re: Show HN: Kyushu – A self-hostable WASM sandbox for JavaScript workers
#25Earlier quoted context omitted.
I had previous experience with QuickJS - respectively using the rquickjs crate (awesome project) - so my approach was first asserting whether it was possible to run a Wasmtime binary that both executes the JS code and handles HTTP requests and responses. Then, the second part which was really important to me, was figuring out if I could find a way to embed the developer's JS code within the worker without requiring t…
Awesome, thanks for detailing the thought flow and choices that led you here. I chose not to go the QuickJS route for performance reasons but I think it's a solid choice depending on the use case. > They run in the browser as I understand, so fundamentally different Yes, runs entirely in the browser, while this is a hosted product. StackBlitz technology is really good but it is closed source.
Yeah I was surprised by this when I opened their website.
Your setup - Rust/WASM kernel + Service worker - sounds really sweet. If already public, please do share the link, else looking forward to your launch!
Re: Show HN: Kyushu – A self-hostable WASM sandbox for JavaScript workers
#26the customer testimonials were enough to earn my github star
I did quite a market research to gather them ;)
Re: Show HN: Kyushu – A self-hostable WASM sandbox for JavaScript workers
#27Loving the customer testimonials :D .. If someone feels like an eli5 - What are the use-cases for something like this?
it is also perfect for running untrusted user code safely, if you want to buld a plugin system or your own edge functions this can be really helpful
Re: Show HN: Kyushu – A self-hostable WASM sandbox for JavaScript workers
#28It raises the interesting question of what is the best isolation for a browser side sandbox.
Running a worker.
Running a worker running a js implementation.
Running a worker running a wasm module running a js implementation (quickjs) running some passed code.
Running a worker running what kyu build runs.
And then of course the possibility of a environment where you pass it an integer n and it geneates n levels of. Nested layers with a randomly chosen implementation at each layer.
Security by obfuscurity, is that a thing?
Might be fun to implent the kyu wasm files as an executable format on my dumb cli idea. https://lerc.neocities.org/
(Kyu seems to fight my autocorrect wanting to turn it into you)
Re: Show HN: Kyushu – A self-hostable WASM sandbox for JavaScript workers
#29Earlier quoted context omitted.
Awesome, thanks for detailing the thought flow and choices that led you here. I chose not to go the QuickJS route for performance reasons but I think it's a solid choice depending on the use case. > They run in the browser as I understand, so fundamentally different Yes, runs entirely in the browser, while this is a hosted product. StackBlitz technology is really good but it is closed source.
Yeah I was surprised by this when I opened their website. Your setup - Rust/WASM kernel + Service worker - sounds really sweet. If already public, please do share the link, else looking forward to your launch!
Will do, thanks!
Re: Show HN: Kyushu – A self-hostable WASM sandbox for JavaScript workers
#30It raises the interesting question of what is the best isolation for a browser side sandbox. Running a worker. Running a worker running a js implementation. Running a worker running a wasm module running a js implementation (quickjs) running some passed code. Running a worker running what kyu build runs. And then of course the possibility of a environment where you pass it an integer n and it geneates n levels of. Ne…
The best isolation is inside a Service Worker, where the script is served with Content-Security-Policy: sandbox header.[1]
[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...