Live data from Hacker News

Instant 1.0, a backend for AI-coded apps

instantdb.com

111–120 of 133 posts

Re: Instant 1.0, a backend for AI-coded apps

#111
post #28

An honest question - why would we need any frameworks at all for vibe coded apps? I can just tell the coding agent to use pure HTML5/Vanilla JS/CSS on the frontend and pure whatever on the backend and it would do it. No need for hundreds/thousands dependencies. For deployment I can ask the coding agent to do the same.

validation -- you're using already validated components instead of relying on the LLM to create them and ensure they are validated

Re: Instant 1.0, a backend for AI-coded apps

#113
post #64

Earlier quoted context omitted.

You don't necessarily, but each token costs money for the AI to spit out. And probably more money when that output is used as input later. Delegating to a library makes sense financially.

With local inference on pretty decent local models we have nowadays (Qwen-3.5 and better) it's not much of a concern anymore.

Sure it is - there's still an opportunity cost of spending tokens(time/energy) creating a library from scratch vs using a preexisting well understood API.

Re: Instant 1.0, a backend for AI-coded apps

#114
This seems really cool, I've used Pocketbase before for similar purposes, the only thing it doesn't offer is local-first (which is a bit of a bummer). But one very valuable feature it has is server extensibility. You can write server hooks in JS and Go (it's embeddable as a Go module) to add features you need. For example, in a previous project, I added functionality to send push notifications based on certain user actions. Is this kind of thing possible in InstantDB? Or, would I need to build a worker that listens for those events and fires off the notification on its own?

Also, are there plans to release SDKs in other languages (namely, Dart)?

Re: Instant 1.0, a backend for AI-coded apps

#115

This seems really cool, I've used Pocketbase before for similar purposes, the only thing it doesn't offer is local-first (which is a bit of a bummer). But one very valuable feature it has is server extensibility. You can write server hooks in JS and Go (it's embeddable as a Go module) to add features you need. For example, in a previous project, I added functionality to send push notifications based on certain user a…

You can use `db.subscribeQuery` on the server to react to react to changes. We plan to add webhooks soon to make this even easier. And yes eventually we'd love to support SDKs in other languages too!

Re: Instant 1.0, a backend for AI-coded apps

#116
post #88
post #28

An honest question - why would we need any frameworks at all for vibe coded apps? I can just tell the coding agent to use pure HTML5/Vanilla JS/CSS on the frontend and pure whatever on the backend and it would do it. No need for hundreds/thousands dependencies. For deployment I can ask the coding agent to do the same.

Its build in guard rails. Its potentially also reduced context it has to know. Its also a very good way to scale. Lets build a very small and well tested library for x, llm uses x for case y. it doesn't have to worry about x, its content, its security.

Security is questionable - if there is a framework hack available or supply-chain attack, you are in danger. However, if you have everything coded from scratch, then good luck to any attacker wasting time on your custom code instead of just exploiting something at scale running on computers everywhere.

Re: Instant 1.0, a backend for AI-coded apps

#120
post #72
post #28

An honest question - why would we need any frameworks at all for vibe coded apps? I can just tell the coding agent to use pure HTML5/Vanilla JS/CSS on the frontend and pure whatever on the backend and it would do it. No need for hundreds/thousands dependencies. For deployment I can ask the coding agent to do the same.

My experience with actually trying this is that current LLMs benefit greatly from having a framework to build on. More code in the context window doesn't just increase the cost, it also degrades the overall performance of the LLM. It will start making more mistakes, cause more bugs, add more unnecessary abstractions, and write less efficient code overall. You'll end up having to spend a significant amount of time gui…

Yes. Intent and patterns will be much clearer for future sessions. If you have a WORN situation (write once read never (modify never, including by the AI)) perhaps you can skip layering and just big ball of mud your system. I doubt many people want that.
Post reply on HN