Wow, I can't believe this hit the front page! Its past midnight here in the UK and I have to be up early for GCSEs, so I'm heading to sleep. I'll read and reply to all your comments and questions first thing in the morning! Thank you all so much for the amazing feedback and stars so far.
You're gonna smash it. Regardless of what your GCSE results are, stuff like this is what will take you far in life. All the best for your exams, but don't lose any sleep over them either.
Is there any other editor that comes close to JetBrain's Git integration? All I see is forks of forks of VSCode, and I'm wondering what the incremental gain of yet another does-the-basic-text-editing editors we need. This is in no way directed at OP, but it seems like a lot of wheels spinning around the world and surprisingly little progress at the Pareto limit.
Funnily enough, I actually prefer the VSCode model for git. On the occasions I use IntelliJ, I find the git actions spread across multiple panels or dropdowns. In VSCode, it's all in one place and the current state clearly visible. YMMV ofc.
Just to clarify on the vscode point, this actually isn't a vscode fork at all! It's built entirely from scratch in plain HTML/CSS/vanilla JS. But I completely agree about git UI, getting a really clean intuitive git integration working with the WebContainer filesystem is a huge priority for the roadmap.
But with the source being so light, it should hypothetically be very easy to implement features such as this nicely, without the massive overhead of navigating a HUGE codebase.
When you properly fork vscode, you have to wrestle with millions of lines of TS, strict extension APIs, complex IPC layers, and deep dependency injection trees just to change core UI behaviors.
(I googled that)
With OpenGravity, because it's just DOM manipulation and straightforward JS, adding custom native UI for Git would be way way simpler to wire up!
If you want to take a stab at implementing it, PRs are definitely welcome!
Edit: A mod suggested I add in how I actually use this! Right now, its honestly just a massive side project that serves as a fun distraction from my GCSE revision. But I mainly use it to test out quick HTML/CSS/JS ideas in my browser when I get an idea, without needing to boot up a full dev environment or worry about rate limits.
I completely agree! Its so frustrating that providers (google, openai, anthropic) silo their $20/month consumer subscriptions away from their API access. It would be amazing if paying that flat fee gave you a 'personal API key' to use in open source UIs like this.
Unfortunately, we're stuck with standard API keys for now. Though I believe that google aistudio has decent free limits on gemini 3 flash with the free api keys? If you're just doing personal coding, you can easily plug a free api key into OpenGravity and basically use it as much as you want without paying a dime!
This isn’t some temporary problem. Flat rate subscriptions include a hidden term that you dont pay out of pocket. Its the LTV of their speculation on the product surface and the belief they will retain you due to laziness and muscle memory
I personally don't like antigravity very much, because in some hallucinations the AI ends up removing important parts of your code. It doesn't have a continuous learning engine for your project; if you switch users you may experience problems due to loss of context when reloading the session.
haha, definitely not! That was one of my main motivations for the BYOK approach. In OpenGravity, your API key stays on local storage the whole time, nothing to do with a server!
Just realised, I was worried that the logo I made (see README) wouldnt work with this name, but then I realised it could actually go quite well being a "0"!
(And yes, I know, it looks a bit like an avocado...)
Nice project. For the agent loop, the two UX pieces I'd make impossible to miss are: 1) a plan/checkpoint before file writes, and 2) a diff/revert view after each tool run.
WebContainer is great for "run it and see", but state can get fuzzy fast. The more the UI shows exactly what changed and why, the safer it feels to trust the agent.
This is very helpful feedback. You're totally right, when WebContainers run a real environment, the state gets fuzzy fast. A diff/revert view before the agent executes would be a good idea to implement into the UI to build trust. I'm going to open a github issue for this right now so hopefully someone in the community can pick it up while I'm revising!
Wow, I can't believe this hit the front page! Its past midnight here in the UK and I have to be up early for GCSEs, so I'm heading to sleep. I'll read and reply to all your comments and questions first thing in the morning! Thank you all so much for the amazing feedback and stars so far.
You're gonna smash it. Regardless of what your GCSE results are, stuff like this is what will take you far in life. All the best for your exams, but don't lose any sleep over them either.
Thank you so much! I really appreciate it!
Best of luck to you! My son is doing them too. This is a great project btw. Doing this sort of stuff teaches you far better than endless lessons.
Is there any other editor that comes close to JetBrain's Git integration? All I see is forks of forks of VSCode, and I'm wondering what the incremental gain of yet another does-the-basic-text-editing editors we need. This is in no way directed at OP, but it seems like a lot of wheels spinning around the world and surprisingly little progress at the Pareto limit.
Funnily enough, I actually prefer the VSCode model for git. On the occasions I use IntelliJ, I find the git actions spread across multiple panels or dropdowns. In VSCode, it's all in one place and the current state clearly visible. YMMV ofc.
Just to clarify on the vscode point, this actually isn't a vscode fork at all! It's built entirely from scratch in plain HTML/CSS/vanilla JS. But I completely agree about git UI, getting a really clean intuitive git integration working with the WebContainer filesystem is a huge priority for the roadmap.
But with the source being so light, it should hypothetically be very easy to implement features such as this nicely, without the massive overhead of navigating a HUGE codebase.
When you properly fork vscode, you have to wrestle with millions of lines of TS, strict extension APIs, complex IPC layers, and deep dependency injection trees just to change core UI behaviors.
(I googled that)
With OpenGravity, because it's just DOM manipulation and straightforward JS, adding custom native UI for Git would be way way simpler to wire up!
If you want to take a stab at implementing it, PRs are definitely welcome!
Edit: A mod suggested I add in how I actually use this! Right now, its honestly just a massive side project that serves as a fun distraction from my GCSE revision. But I mainly use it to test out quick HTML/CSS/JS ideas in my browser when I get an idea, without needing to boot up a full dev environment or worry about rate limits.
I wish this could work with your monthly subscription where you get a flat quota in Antigravity with a free account / $20.
edit:
Is this not built out of VSCode? Isn't Antigravity based on VSCode? VSCodium has a Web build https://github.com/VSCodium/vscodium
UI wise it might be good to make it clearer you don't need to put in an API key to try it.
I completely agree! Its so frustrating that providers (google, openai, anthropic) silo their $20/month consumer subscriptions away from their API access. It would be amazing if paying that flat fee gave you a 'personal API key' to use in open source UIs like this.
Unfortunately, we're stuck with standard API keys for now. Though I believe that google aistudio has decent free limits on gemini 3 flash with the free api keys? If you're just doing personal coding, you can easily plug a free api key into OpenGravity and basically use it as much as you want without paying a dime!
(I think its like 250 requests per day maybe?)
This isn’t some temporary problem. Flat rate subscriptions include a hidden term that you dont pay out of pocket. Its the LTV of their speculation on the product surface and the belief they will retain you due to laziness and muscle memory
pretty sure i believe it violates ToS and will revoke your any Gemini/Antigravity access from your account.
Cool, seems a bit niche? Antigravity is ok but not so ok as to want to clone it, might just be me.
I personally don't like antigravity very much, because in some hallucinations the AI ends up removing important parts of your code. It doesn't have a continuous learning engine for your project; if you switch users you may experience problems due to loss of context when reloading the session.
But... does it clone Antigravity's commitment to storing keys at well known locations on disk in plain text?
haha, definitely not! That was one of my main motivations for the BYOK approach. In OpenGravity, your API key stays on local storage the whole time, nothing to do with a server!
Even if it did, its OSS now, open a PR! :P Note: It's not actually the same app, just a clone/reproduction so it's built from scratch essentially.
GCSEs, I was disallowed from taking my IT GCSE because I "hacked the school".
Should've named it ZeroGravity to stay true to its design goals.
that... is a way better name. I might honestly have to rename the repo to that after I finish my exams!
Good luck for your exams!
Thanks so much! Going to need it haha.
Just realised, I was worried that the logo I made (see README) wouldnt work with this name, but then I realised it could actually go quite well being a "0"! (And yes, I know, it looks a bit like an avocado...)
Experiencing A Significant Gravity Shortfall
would be inclined to use it just to flex that name "yeah I built this in Zero Gravity..."
Haha exactly! 'yeah, no IDE installed, just coding in zero gravity.' I might actually have to rebrand it this weekend then.
"So good, you can't put it down"
If you are just a high schooler working on this, that's freaking amazing!
Nice project. For the agent loop, the two UX pieces I'd make impossible to miss are: 1) a plan/checkpoint before file writes, and 2) a diff/revert view after each tool run.
WebContainer is great for "run it and see", but state can get fuzzy fast. The more the UI shows exactly what changed and why, the safer it feels to trust the agent.
This is very helpful feedback. You're totally right, when WebContainers run a real environment, the state gets fuzzy fast. A diff/revert view before the agent executes would be a good idea to implement into the UI to build trust. I'm going to open a github issue for this right now so hopefully someone in the community can pick it up while I'm revising!