Building a visual website builder looks simple from the outside.
Users drag a section, change some text, upload an image, click save, and expect a website to appear.
The reality is much harder.
A website builder is not just a frontend editor. It is a system that needs to store layouts, manage components, handle responsive behavior, support different business types, and render thousands of possible combinations reliably.
While building Webruno, one of our biggest engineering challenges was creating a flexible page builder architecture.
The problem with storing raw HTML
The simplest approach would be saving generated HTML.
For example:
<section>
<h1>Build your business online</h1>
<button>Start Now</button>
</section>
But this creates many problems:
- Editing becomes difficult
- Components cannot be reused
- Responsive changes become complicated
- AI generation becomes harder
- Maintaining old pages becomes risky
A website builder needs a more structured approach.
Component-based page structure
Instead of storing HTML, we store a representation of the page.
A simplified example:
{
"type": "section",
"props": {
"background": "white"
},
"children": [
{
"type": "heading",
"props": {
"text": "Create your website"
}
},
{
"type": "button",
"props": {
"label": "Get Started"
}
}
]
}
The editor modifies this data.
The renderer converts it into a real website.
The page becomes a structured application state instead of a static document.
The component registry
A key part of the system is the component registry.
Each component has:
- A unique identifier
- Default properties
- Editable settings
- Rendering logic
- Responsive rules
Example:
const components = {
heading: HeadingComponent,
image: ImageComponent,
button: ButtonComponent,
productGrid: ProductGridComponent
};
When a page loads, the renderer reads the structure and maps each component to its React implementation.
This allows us to add new components without changing existing websites.
Handling responsive design
Responsive websites create another challenge.
A user expects the same design to work on:
- Desktop
- Tablet
- Mobile
But every component can behave differently.
A heading may need:
- Different font sizes
- Different spacing
- Different alignment
An image may need:
- Different dimensions
- Different cropping
- Different positioning
We handle responsive settings as part of the component configuration rather than manually writing CSS for every page.
Drag and drop is the easy part
Many people think the hardest part of a website builder is drag and drop.
It is not.
Moving a block from one position to another is relatively simple.
The difficult parts are:
- Keeping the page structure valid
- Managing nested components
- Preventing broken layouts
- Supporting old versions
- Keeping rendering consistent
A good editor needs rules.
Without rules, users can create layouts that cannot be rendered correctly.
Versioning and data migration
SaaS products evolve.
A component created today may not have the same structure two years later.
For example:
Old:
{
"type": "button",
"text": "Buy"
}
New:
{
"type": "button",
"label": "Buy",
"style": {
"variant": "primary"
}
}
Changing data structures requires migration strategies.
Otherwise, old customer websites can break after platform updates.
AI and structured websites
One advantage of having structured pages is that AI can work with them.
Instead of asking AI to generate thousands of lines of HTML and CSS, we can ask it to generate a website structure using available components.
Example:
Business:
Restaurant
AI output:
Hero Section
Menu Section
Gallery
Reservation Form
Contact Section
The platform then builds the actual page using validated components.
The AI suggests the structure.
The application controls the result.
Lessons learned
Building a website builder taught us that flexibility and control must be balanced.
Too much freedom creates unstable websites.
Too many restrictions create a frustrating editor.
The best systems provide users with creative freedom while maintaining technical boundaries.
Final thoughts
A visual website builder is closer to building an operating system for websites than building a simple page editor.
The difficult engineering problems are not visible to users.
They are hidden in data models, rendering systems, component architecture, migrations, and scalability.
That is where most of the work happens.
Webruno:
https://webruno.com
Top comments (0)