Live data from Hacker News

Instant 1.0, a backend for AI-coded apps

instantdb.com

31–40 of 133 posts

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

#31
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.

A few reasons:

1. Unlimited projects: when you spin up traditional backends, you usually use VMs. It's expensive to start many of them. With Instant, you create unlimited projects

2. User experience: traditional CRUD apps work, but they don't feel delightful. I you want to support features like multiplayer, offline mode, or optimistic updates, you'll have to write a lot more custom infra. Instant gives you these out of the box, and the agents find it easier to write than CRUD code

3. Richer features: sometimes you'll want to add more than just a backend. For example, maybe you want to store files, or share cursors, or stream tokens across machines. These often need more bespoke systems (S3, Redis, etc). Instant already comes with these out of the box, and the agents know how to use them.

There are a few demo sections in the post that show this off. For example, you can click button and you'll get a backend, without needing to sign up. And in about 25 lines of code, you'll make a real-time todo app.

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

#33

Seems like a supabase competitor?

That's a fair statement! I would say we are similar to supabase in that we offer a relational backend. We are different in two ways:

1. Supabase runs on VMs, so only supports 2 free projects. We built the backend to be multi-tenant, so we can give you unlimited free projects.

2. Supabase doesn't support offline mode or optimistic updates. Instant gives you a sync engine which does.

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

#34
Thanks, this might be exactly what I'm looking for.

I see you have support for vanilla js and svelte, but it's unclear whether you can get all the same functionality if you don't use React. Is React the only first class citizen in this stack?

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

#37
post #34

Thanks, this might be exactly what I'm looking for. I see you have support for vanilla js and svelte, but it's unclear whether you can get all the same functionality if you don't use React. Is React the only first class citizen in this stack?

Thank you.

> Is React the only first class citizen in this stack?

Each system gets the same functionality. We centralize the critical logic for the client SDK in "@instantdb/core". React, Svelte, Tanstack, React Native et al are wrappers around that core library.

The one place where it's lacking a bit is the docs. We have specific docs for each library, but a lot of other examples assume React.

We are improving this as we speak. For now, the assumption on React is quite light in the docs, so it's relatively straightforward to figure out what needs to happen for the library of your choice.

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

#38
Moose here, congrats! This is the real "firebase alternative", not Supabase. Supabase is good, but it's just hosted Postgres + user login. People who are asking "why would I need this" don't get how difficult scalable data storage is with user permissions. Would absolutely recommend this if it's good. Been in this space for ~7 years, and made a high-perf realtime DB as well. Will contact you guys directly. Some concerns for everyone's benefit:

1) Transparency on pricing: This builds confidence. Need to know exactly what I pay for additional egress/ops (read/write). "unlimited" is not sustainable for the provider (you). For example, Firestore has detailed pricing that makes scaling sustainable for them. see https://cloud.google.com/firestore/pricing.

2) Transparency on limits: Req/s, max atrributes, max value length, etc. What about querying non-local non-indexed data (e.g. via server-side call), that's costly for you guys. So, what's the limit?

3) Simpler code in the docs/examples overall. Currently, they're not bad, but not great. For example, change the "i" used everywhere to "inst" or "idb". Assume dev is a noob!

4) Change simplify/terminology used. This is probably the most important, but hardest thing. Internally, keep the same triple structure. But dev just cares about tables/key/val. Or tables+rows. Namespaces/entities are confusing. Also, be consistent/clear. For example: "Namespaces are equivalent to "tables" in relational databases"..Perhaps you meant "namespaces are just a list of tables/entities"..slighly different, but far clearer I think? "Attributes are properties associated with namespaces"...I though attributes are associated with entities? Please keep in mind, I am completely new to InstantDB, so need to study the architecture more.

5) Simplify docs BIG TIME. And add an API REFERENCE (super important). Right now, you have: Tutorials, Examples, Recipes, Docs, Essays. These are all essentially "docs".

6) Simplify the "About" section. Should be 1/10th the size. Right now, it's like a fruit salad of docs, and re-iterating the features/benefits. Instead, put pics of both founders. Maybe investor list. Pics of your office?

Post reply on HN