I started writing about the shiny new wasm-y not quite open source tech called webcontainers by stackblitz, but having hacked the crap out them I reckon right now they aren't quite mature enough for production use.
Here's some of the rough edges you might hit...
- They are on a private server, your project, firewall or company might block this hard depencie *.webcontainers.io and https://nr.staticblitz.com to name a couple I see.
- For all the hype they do not seem able to actually listen to any request outside the webpage like a POST (more in a sec)
- They are behind AWS Cloudfront (fine) but you can't edit the headers or CORs policies at all
- they work around iframes which can be a basket of worms with permissions and policies like CSP.
and lastly I think it's worth having a look at the open issues of any library or project; that alone isn't the end all and be all of decision making. It is expected a new library get a surge of issues that need to be triaged.
The last indicator this isn't ready for prime time is if they are ignoring or don't have capacity to review PRs they might not be fully invested. Of course it's my duty to open PR's and contribute where I can.
I had a whole doc around embedded webview in a Rust lang context and my coo workaround. To summarise it was how WKWebview does not at all support navigator.credentials web api or the shiny new "Passkeys" not so quick read if you got a weekend to play here
Top comments (1)
Found another quick read on why, by design I reckon, you couldn't have say a REST API accept requests from cross-origins. Read this I believe it's possible with some work like specifcying in advance the remote urls that will access your hypothetical server API blog.stackblitz.com/posts/cross-br...