Why Shilpi stores every page as HTML, CSS and JavaScript
Page builders solved the wrong problem. They made building easy and leaving expensive. Here is the argument for storing the web platform instead, and what it costs us to hold that line.
Ask a WordPress freelancer what they dread and you will rarely hear “designing the homepage”. You will hear about the site they inherited: a theme nobody can update, a builder licence that lapsed, and a layout stored in a format that only one plugin can read.
That is not an accident of any particular product. It is the predictable result of a design decision that almost every page builder made, store the layout in our own format: and it is the decision Shilpi refuses.
The trade the industry made
Proprietary storage buys real things. It lets a builder guarantee that a widget renders identically everywhere, ship a settings UI that maps cleanly onto stored fields, and change the renderer without breaking old pages. Those are genuine engineering wins, and it would be dishonest to pretend the people who chose that path were careless.
But it also means the page is only meaningful inside the tool. Export it and you get a blob. Migrate and you rebuild. The switching cost is not a bug the vendor forgot to fix, it is structural, and it grows with every page you add.
A format you cannot read is a decision you cannot revisit.
For a hobby site that is a fair price. For a studio maintaining forty client sites, it is a liability that compounds quietly for years and then arrives all at once.
What we store instead
A Shilpi page is three fields: the body HTML, a real stylesheet, and focused JavaScript. There is no fourth field where the interesting stuff hides. The visual canvas is a view onto those three, not a separate source of truth that gets compiled into them.
When you drag an element, you are editing the markup. When you change a padding value, you are editing a class in the stylesheet. That equivalence is the whole product.
What it costs us
Three things get harder when you refuse proprietary storage:
- We cannot silently reshape old pages. A builder that owns the format can re-render every historical page with a new engine. We cannot, your markup is yours, and we do not rewrite it behind your back. New capabilities have to be additive.
- Bad input stays bad. If you paste sloppy markup, you get a page built on sloppy markup. A widget system would have normalised it for you. We surface it instead, which is more useful and less comfortable.
- The settings UI has to be honest. Every control maps to a CSS declaration you can go and read. That rules out the reassuring-but-vague toggles that competitors can offer, because ours have to correspond to something real.
Where the AI argument comes in
This decision was made before agents were part of the workflow, and then agents made it look considerably smarter than it was.
An agent working on a proprietary layout tree has to be taught that tree, guess at its invariants, and hope the vendor does not change them. An agent working on HTML and CSS already knows the format, it has read more of it than any of us. Point it at a Shilpi site and the hard part is not syntax; it is understanding the conventions of this site, which is exactly what a design system and a skill file are for.
That is why the MCP layer exposes abilities rather than a filesystem. The agent does not need raw access to write good markup. It needs to know what classes exist, what variables are defined, and what the house rules are, and then it needs a human to read the diff.
The maintainability argument, stated plainly
Most of a website’s cost is not its first build. It is the eight years afterwards: the plugin conflict, the redesign, the developer who inherits it, the migration nobody budgeted for.
Storing readable source does not make any of that free. It makes it possible to estimate, which for anyone who has quoted a rescue job is the more valuable property.
You should still be able to leave. If Shilpi stops being the right tool, copy the markup, keep the stylesheet, and go. We would rather compete on whether the product is good than on how expensive it is to escape.
Disagree? That is reasonable, the proprietary-format argument has real merit for teams who value guaranteed rendering over portability. Tell us where this reasoning breaks down; we publish the good objections.
