Dependency on the original bolt.new repo

This might be a blessing in disguise. The fact that Bolt sends data out to Cloudflare or another external entity means that Bolt.new can’t really be used for any serious/confidential/proprietary project. We just need to implement a more secure/private solution for oTToDev.

2 Likes

Curiously enough, https://webcontainer.new/ brings you to a barebones starter project in stackblitz that stands up webcontainers and runs this extremely light express server project:

Github repo is here, might start to poke around at swapping WCs out for one of the alternatives.

2 Likes

Just so we’re clear what we’re dealing with here, Eric Simons, the CEO of stackblitz has very limited entrepreneurial experience, with his only previous exit being an aquihire of an education platform which apparently he’s committed to integrating with stackblitz. They managed to seed round of $7.9 mill but with that need to service a payroll of at least 25mil annually. This gives them a runway of no more than 4 months before they need to raise more Capital or bring the hammer down on the paywall. Granted, seed investors include greylock and Google ventures, but that doesn’t mean much in the grand scheme of things. Companies like this are a dime a dozen. They’ll grab up some open source project, throw paywall around it and hope they can grow fast enough, building a user base impressive enough that they can sell the venture before someone catches on. The greater fool theory can only get you so far.

With this in mind, there is certainly an opportunity to be had wherein we deploy our own infrastructure, providing a competing platform to web containers and a more robust and flexible framework for building front ends for it.

UPDATE: my math was off, as to they’re available runway. They only have 4 months worth of funding

2 Likes

I have a feeling that conversation is running away a bit.
I would wait for StackBlitz answer a bit before investing heavily in replacing it.

Here is to summarise and answer some things in the thread

1. WebContainers & Its Uniqueness
WebContainers, developed by StackBlitz, is a highly optimized web-based container specifically designed for running Node.js in WebAssembly, making it fast and efficient. It’s a purpose-built solution that loads quickly, even on mobile devices. Unlike broader solutions, it doesn’t support binaries or languages beyond Node.js, maintaining lightweight performance.

In comparison, WebVM offers a more extensive environment with Linux capabilities, but requires a TailScale VPN for networking, adding complexity. Although we could bundle our own VPN/proxy to address this, it’s a substantial effort and likely not a top priority at the moment. Not that we are stating running commercial offerings on Bolt.New and getting in to the issues with StackBlitz, at least there is path forward if it gets to that.


2. License & Commercial Use Concerns
StackBlitz has released two MIT-licensed repositories related to WebContainers, but these contain only APIs and documentation, not the full WebContainers source code. This raises questions about commercial usage rights for Bolt.New. I’ve reached out to StackBlitz on Discord to clarify, and if no response is received by tomorrow, I’ll follow up on Twitter.


3. Unique Advantages of WebContainers for Bolt.New from infrastructure perspective
WebContainers operate entirely client-side, reducing server infrastructure needs – no Docker or Linux dependencies are required, making it ideal for serverless environments. This server emulation on the client side is a major advantage over alternatives that need server-side virtualization, such as e2b. Bolt.New’s unique serverless architecture aligns well with this model, and it’s a critical aspect of what makes Bolt.New truly special.

In summary, while WebVM shows potential as an alternative, it’s a heavier and slower option. If WebContainers prove to be a barrier to widespread adoption, we could explore alternatives further. But for now, Bolt.New’s client-side execution model is a unique asset we should leverage fully.

4 Likes

Good points. I agree we should wait to hear from Stackblitz to inform next steps.

2 Likes

Agreed, and the more I started to look the more that I realized this is a fairly large undertaking/overengineering up front.

1 Like

Great thoughts guys, I agree as well!

So, no answer yet in Discord
I pinged them in twitter

Like, repost, create some more visibility and interest for them to be more inclined to answer. But be polite. In the end they did share original tech and its better to have mutually beneficial relationship with them.

We just need to clarify this and find path forward.

5 Likes

Still no answer on Twitter, will give them more time till Tuesday and I found one more venue to pursue to get answers here:

Its possible to book a meeting with them to discuss the commercial use case

Mentioned it on our 4 people meeting on Friday and multiple people expressed that they want to participate.

By Tuesday will prepare to make are a request.
Please write here if you want to participate, will mention that multiple open source contributors are interested.

2 Likes

Yeah I would certainly be interested in being in that meeting @wonderwhy.er !

2 Likes

Any updates on this @wonderwhy.er?

Had rough week and did not get to asking for a call with them.
In X/Twitter and Discord they did not answer.

@ColeMedin has a call with StackBlitz founder(founder reached out himself), I hope he will ask him there.

1 Like

This was my concern long back in one of git issue,

yes webcontainer is proprietery. all the wasm stuff are pulled from there server.

I also dont think its a fully containerised wasm but a node compatible runtime with browser bindings, there are wasm parts to it but not the whole container.

I would like to start a repo to replicate the webcontainer and work on it, but I need help from some smart people here

I have done small amount of work on creating the runtime. but i am stuck at bundling npm into a single js, so that it can be easily imported into the runtime (stripping out all the node native apis, as those will be automatically provided by the runtime)

here is what is working

2 Likes

Hah, hello fellow youtuber :slight_smile:
Nice to see your face, subscribed :slight_smile:

About bundling, not sure how I can help and what kinds of problems you have, can you share the repo to see what you did so far?

Ahh… those videos were recorded way back, :sweat_smile:

I just uploaded the project… its all over the place. currently I am just experimenting on a prototype runtime

abount bundling npm, I need to bundle the npm pure js parts and where ever its trying to call native stuff just shim them so that the runtime can provide a compatible module to it on the fly.

i can see the webcontainer version of the npm is also bundled into 2 file one is the code npm cli file another one is a module hotload object to load modules on the fly by the cli.js

3 Likes

In another reply on a different thread I said that I’m busy building software for my own business right now, otherwise I’d be much more focused on contributing to this project. As soon as that is completed, I’m going to focus all of my time on this WebContainers replacement instead of enhancements (besides the one voice issue currently a WiP because of hiccups I’m experiencing). No ETA on when I can do that, though.

@thecodacus Two things - first, please create some sort of README.md on your repository that includes information on how you would like to have PRs conducted - maybe model it after oTToDev’s? That would make it much easier for others to contribute to. Additionally, consider putting it in pre-release (v0.1.0) so that, when the core problem is solved, there can be a full release and inheriting applications can depend on the artifact properly. Secondly, I don’t know the extent to which you’ve searched for an already existing alternative, but I strongly recommend doing some deep digging before we go full boar on this. Don’t reinvent the wheel, yada yada.

@wonderwhy.er @ColeMedin, if either of you find enough value in this, please spread the word about this implementation to increase the visibility of it. If not, I think it’s really important to update the documentation to make it clear that this project is not to be adopted in businesses because of the legally murky waters people tread by using an Open Source repository in a proprietary context that uses closed source, licensed packages. I just put a PR up for that documentation change, since I think if this isn’t confronted it risks the reputation of this implementation in the long term.

2 Likes

Yeah, we probably should include this as “risk” in readme.
Though from Cole communication with StackBlitz, they do not care about people using it in commercial setting unless they grow, and at that point license if 200$ a month. But its still a dependency and risk if adopting oTToDev for commercial projects.

I would put adding WebContainer alternatives as long term goal of a project and link to explorations around it like @thecodacus one.

1 Like

As @wonderwhy.er said we could realistically use the webcontainer long term but I agree it’s fantastic to have a replacement in the long term roadmap for oTToDev.

Thank you so much @thecodacus for starting this, I am certainly on board and I will definitely spread the word on this as a project to go alongside oTToDev if this gets up and running @navyseal4000!

Hello, I know I’m late to this conversation but I am active active in the StackBlitz Discord and have DMs open with 3 of their employees. If it’s helpful I can ask them about the WebContainers dependency and at what point they look at charging people. I do know they have said they are ok with people forking bolt.new and making a competitor but I don’t think anything came up in that convo regarding the WebContainers dependency.

3 Likes