AI gives us the chance to bring software to every corner of the earth. For most of its history, custom software was something only large companies could pay for. Now a person and an AI agent can build an app in an afternoon, so the optometrist can have their own scheduling, the coffee roaster their own store, the studio class packs that work the way it does, and the school, the clinic and the family business on the other side of the world can have software made for them, too.
All of that software needs somewhere to be built, tested and run. Elements is that environment, from the first prompt on your laptop to the servers it runs on. It is built for the people who will make that software, and for the agents they work with.
One coherent system
A web app usually means a framework, a bundler, a package manager, a test runner, a database, a migration tool, a job queue, an email service and a deploy pipeline, each with its own config, its own versions and its own seams. Keeping those parts working together is a job of its own.
Elements brings them together as one coherent system: a project server that runs while you work, and a default framework that just works. They were designed together, so a new app has a database, tests, jobs, email and live reload before you write a line of code.
Built for people and their agents
The project server knows the state of your app at every moment and answers in microseconds. Your terminal, your editor and your agent all connect to the same server. They see the same errors, and the server runs their commands one after another, so they never step on each other. An agent that can check its work after every edit stops guessing. That is why you and your agent can build a store with Stripe checkout, or a chess site with clocks and ratings, and hand it over with its tests passing.
The right thing by default
Elements gets the details right without configuration:
- Every page has an ETag computed from its source, its data and the session, so an unchanged page answers in a few bytes.
- Every asset has a hash in its file name, so browsers and any CDN in between cache it forever, and a new release changes only the urls that changed.
- A page for a signed-in visitor is marked private, so no shared cache or CDN stores it.
- A query cannot reach the browser: calling
sql()from browser code is a build error. Secrets in config stay on the server unless you tag them for the browser. - A release goes live only when every test passes.
No lock-in
You pay for the tooling: the project server, the build, the test runner and
deploy. The packages your app imports are MIT licensed. @elements/app
includes the runtime your Elements HTML runs on, which is where you write most
of your app, and @elements/style is MIT licensed too. A built app runs on
plain Node.js, on servers you choose, with your data in your own Postgres
database (licenses (opens in a new tab)).
The languages are the standards your agent already knows. Elements HTML is standard HTML plus TypeScript expressions and a few attributes. Logic is TypeScript, queries and migrations are SQL on Postgres, and styles are CSS. Agents have read more of these languages than any framework's own, so they write them well.
So try Elements on a real app and keep going only if it earns its place. An Elements app is written in standard languages, so an AI agent can convert it to another framework any time.