A close-up portrait of a man with a salt-and-pepper beard wearing a white collared shirt against a textured beige background.
A close-up portrait of a man with a salt-and-pepper beard wearing a white collared shirt against a textured beige background.

The block editor came before the AI

Jesse James Richard
|
Jan 11, 2026
|
7 min read
#Signature
#Architecture

Giant Context is being built as an AI that makes websites. None of that came first. What came first was a tool a person uses with no model in the room, a block editor for building a page by hand. Everything I build from here starts on top of it.

The builder exists because I wanted Elementor without WordPress and could not buy it. Elementor is WordPress's drag-and-drop page builder, and it is how most of the web without a developer gets made. So the first thing I made was not marketing and not a model. It was the builder Elementor would have been if it were born in React and owned end to end.

A page is a list of blocks

The idea under the builder fits in a sentence. A page is a list of blocks. A block is a typed unit with its own settings, a heading, an image, a button, a gallery, a call to action. You add blocks, order them, and set their options. The list is the page.

A page, as a list of blocks

[  { type: "hero",   heading: "Open by Friday", cta: { text: "Book", href: "/book" } },  { type: "image",  src: "storefront.jpg", caption: "The new room" },  { type: "text",   content: <rich text> },  { type: "button", text: "See the menu", href: "/menu", variant: "contained" }]

That is a page. Not a document, not a canvas of elements dropped at pixel coordinates, not an HTML file edited by hand. A sequence of known units, each one configured. It is structured on purpose, because structure is what you can build tools on. Every capability the builder has, and every capability it will carry later, rests on a page being a list of typed blocks and not freeform markup.

What makes a block editor hard

A block editor sounds simple and is not. The parts that make it usable are the parts that are expensive to build, which is why the React page builders that existed were not good enough to adopt.

Blocks reorder by dragging. Not a crude move-up and move-down, but a proper sortable list with drop indicators that show where a block will land before you release it, the placeholder shifting and the layout reflowing under the cursor. That is the interaction a person coming from Elementor expects and rarely gets from a builder someone rolled themselves, because doing it well in a browser is genuinely hard.

Every block has a settings panel, organized as accordions, so that a block with a dozen options is a set of labeled sections instead of an unreadable stack of controls. Color, spacing, shadow, alignment, link, each in its place, each editing the one block selected and nothing else.

What renders in the editor is the page itself. Every block draws with the same component the public site uses to draw it. What is being edited and what will ship are one and the same, edited in place, at full size.

And there are a lot of blocks. Not a starter set of five, but a library already deep and still growing, searchable because there are too many to scroll. It runs from the obvious ones, a hero, a heading, an image, a gallery, a button, a quote, a link, out to a long tail of more specific pieces a page turns out to need. Each is a typed block with its own settings. Even text is a block, edited as a structure and not as raw tags. Building the editor was half the work. Building enough blocks to make a real page with is the other half. That work does not end. It was built to be used, not to be shown once.

Building a page

Building a page in it is what Elementor should have been. A person starts with a blank page and adds a block, a hero. The heading is typed straight into it, going bold or linked as it is formatted, because the editor knows it is editing a heading and not a paragraph of markup. An image block goes in below. It lands in the wrong spot. When it is dragged, a line shows where it will go, moving with it over the other blocks. It drops where the line was.

The builder mid-drag: a block being moved, with a drop-indicator line showing where it will land between two other blocks.
A block mid-drag. The line is where it lands.

The image is selected and its settings open to the side, a stack of accordions. Open one and its controls appear, the rest stay shut. Each control changes the one selected block, live, in front of the person building it.

A block's settings panel: labelled accordion sections, one expanded to show its controls, the rest collapsed.
One block's settings. Open a section, the rest stay shut.

None of this is remarkable to describe. All of it is hard to build. It is the difference between a page builder a person will use and a form with a preview pane. The bar was Elementor. Meeting it was the point.

Built for a person first

None of this was built for an AI. It was built for a person, because when it was built there was no AI, and a person had to be able to make a page.

When the model arrives, it will not get its own private way to make pages. It will write into the same blocks a person does, dropping a hero block a person can open and rewrite, revising a page a person laid out. One editor, one definition of what a page is, because the editor was there first and the model will be taught to speak its language. The common alternative, an AI that emits HTML a person then has to wrangle, is the worse one.

The builder is also the last gate before anything ships, and it is where the person stays in charge. Even once the AI can draft a whole page, that draft is a starting point and not the finished one. A person opens the builder to make the small changes, the fine-tuning, the adjustments a model will not think to make, because the page is theirs and they can see what it should be. The AI will do the heavy work of generating a page. What it finally becomes stays with the person.

The same holds downstream. The block model the builder writes is the one that will render a page to both a website and an email. Whatever gets built on top will work on these same blocks. There is no second content system beside the first. There is the builder, and then there is whatever gets built to run through it.

Why the editor is the harder half

The builder is the part that will end up least visible. The pitch will be the AI. What the AI will stand on is a hand-built block editor that came before it.

The AI will be the reason people look. The builder is the reason it will have somewhere to write, and the reason a person is never stuck with a page they cannot change.

A competitor can buy a model. Everyone is renting the same few. What takes months is the editor underneath, and whoever skips it ships HTML a person has to wrangle. Replacing Elementor was the whole idea.

Postgres after six years of Firebase

#Data
#Architecture

Firebase gets reactivity and scale right, and neither is why you leave. The schema-history case for relational, and how to rebuild the reactive loop o...

Jesse James Richard

|

Jan 10, 2026
Read previous

Building something like this

I'm Jesse. I build platforms end to end, and I'm open to work. If this is the kind of engineering you need, get in touch.

Contact Jesse
Home
About
Contact
Sitemap
Privacy Policy
Terms of Service
Cookie Policy

Some posts on this site may be updated on occasion.

The block editor came before the AI | Jesse James Richard