Joomla Template Frameworks Compared : Which One to Build On [2026]
What a framework gives you, what it costs you in lock-in, and when a plain child template is the correct professional choice.
If you build Joomla sites for a living, the framework you standardise on determines how fast you deliver, how much you can charge, and — the part nobody budgets for — how expensive it will be to leave. That last cost is the one this article is really about, because framework lock-in is the single largest long-term expense in agency Joomla work and it is invisible at the point of decision.
This is a comparison for developers and agencies choosing what to build on for current Joomla in 2026 — the 6.x line, current since October 2025, and the still-supported 5.x line, for which the considerations below are identical. It covers what a framework gives you, what it takes from you, the well-known options, and the case for using no framework at all — which is a serious professional position, not a fallback.
What a template framework actually is
A Joomla template is a directory containing an index.php, a manifest, some CSS and a set of module positions. It renders a page. That is the whole contract.
A framework sits between Joomla and that template and provides four things a plain template does not:
- A layout system. Rather than fixed positions hardcoded in
index.php, you compose rows and columns in an admin interface, define different layouts per page, and assign them by menu item. This is the reason most people adopt a framework. - An override architecture. A structured way to override core layouts, module chromes and framework particles, usually with more granularity than Joomla’s own
html/mechanism. - An admin UI for template settings. Colour, typography, logo, header behaviour, per-page overrides — exposed as fields rather than as CSS you write.
- An asset pipeline. Compilation of SCSS or LESS, concatenation, conditional loading of assets per layout, and a cache layer over the result.
Some frameworks add a fifth: a front-end or visual page builder, where layout is composed by dragging elements onto a canvas. This is the highest-value and highest-risk feature in the category, for reasons the lock-in section covers.
What it costs you
The pitch is always about what you gain. The costs are real, largely unrecoverable, and worth stating plainly before any comparison.
| Cost | What it looks like in practice |
|---|---|
| Lock-in | Sites cannot move off the framework without a rebuild. Every client site you build is a permanent dependency on one vendor. |
| Learning curve | Weeks, not days, to be genuinely productive — layout model, particle or element system, override paths, build tooling. |
| Upgrade dependency | When Joomla ships a major version, you cannot upgrade until your framework vendor does. You are on their timetable. |
| Licensing cost, indefinitely | Renewals do not stop while the sites exist. Twenty client sites means twenty ongoing obligations, whoever pays. |
| Performance overhead | A framework runtime and its assets on every page, whether the page uses them or not. |
| Hiring and handover | A developer who knows Joomla does not necessarily know your framework. Handing a site to another agency means handing over a dependency they may not have. |
Ask what happens to your client sites if the framework vendor stops publishing updates. For a framework that only builds templates, the answer is manageable: existing sites keep rendering and you migrate at your own pace. For a framework whose page builder stores layout in its own database tables, the answer is that your clients’ page content is trapped in a format only that vendor’s code can read. Those are different orders of risk and they deserve different levels of caution.
The frameworks worth knowing about
Three names dominate professional Joomla template work, and each represents a distinct philosophy rather than a different feature count.
Gantry is the long-standing framework option, and the most explicitly engineering-oriented. Its layout manager composes pages from particles arranged in a grid, configuration is file-based YAML which means it is version-controllable and deployable, and it is cross-platform — the same framework runs on other CMSs, which matters if your agency is not Joomla-exclusive. The learning curve is the steepest of the three and the payoff is the most durable.
Helix Ultimate is the framework behind a large proportion of commercially sold Joomla templates. It is free, widely deployed, and its ubiquity is its main practical advantage: the chance that a developer you hire has used it is high, and the chance that an inherited client site is built on it is also high. It is more conventional than Gantry — closer to a well-organised template with a settings panel than to a full layout engine.
Astroid is the more recent entrant of the three, built for Joomla 4 and 5 rather than carried forward from Joomla 3. Its architecture reflects that: modern admin UI, a free tier that is genuinely usable, and fewer legacy compromises. Being newer, it has a smaller body of accumulated community knowledge to draw on when something goes wrong.
Separately, Yootheme Pro occupies a different category and is worth naming precisely because the distinction matters. It is a visual page builder with a template attached, not a framework in the Gantry sense. It is genuinely excellent at what it does and it is the most complete lock-in in Joomla, because page content built in it lives in its own format. Both statements are true simultaneously and choosing it means accepting both.
| Consideration | Gantry | Helix Ultimate | Astroid | Cassiopeia child |
|---|---|---|---|---|
| Lock-in risk | Moderate — layout in YAML, portable in principle | Moderate — template-level, content stays clean | Moderate | None |
| Learning curve | Steep | Gentle | Moderate | Joomla knowledge only |
| Current-line support | Yes | Yes | Yes — built for J4/J5 | Core |
| Licensing model | Framework free; commercial templates and support paid | Free framework, commercial templates | Free tier plus commercial | Free |
| Version control friendly | Yes — file-based config | Partially | Partially | Fully |
| Best suited to | Agencies with a build process | Fast delivery, broad hiring pool | New projects on a current line | Long-lived sites, low churn |
Assessments in that table are of architecture and posture, not of feature parity, and licensing models change — check current terms before committing budget.
The no-framework option, taken seriously
A child template of Cassiopeia, with a stylesheet and a set of layout overrides, is a legitimate professional deliverable. It is not the beginner’s option; on the right project it is the most defensible engineering choice available.
What you get:
- Zero vendor dependency. The template’s maintenance is Joomla’s maintenance. Nothing can go quiet.
- Upgrade on Joomla’s schedule. When Joomla 6 arrives, you are not waiting for anyone.
- Minimal payload. You ship exactly the CSS you wrote and nothing else.
- Full version control. The whole template is files. It diffs, branches, merges and deploys like any other code.
- Any developer can maintain it. It is standard Joomla with standard overrides.
What you give up: the admin layout UI, per-page layout assignment without code, and the speed of composing a page visually. If your client needs to rearrange their own homepage, this is the wrong answer. If the layout is designed once and then maintained, it is the right one.
Create the child template
In System → Site Templates, select Cassiopeia and choose Create Child Template. Joomla generates the directory and manifest. Rename it in the manifest to something client-specific before you commit it to a repository.
Establish the CSS architecture up front
Cassiopeia exposes custom properties for colour, spacing and typography. Redefine those in your own stylesheet rather than overriding component rules — it is a fraction of the code and it survives parent updates cleanly.
/* media/templates/site/clientname/css/user.css */
:root {
--cassiopeia-color-primary: #1d4ed8;
--cassiopeia-color-hover: #1e40af;
--cassiopeia-color-link: #1d4ed8;
--cassiopeia-font-family-body: "Source Sans 3", system-ui, sans-serif;
--cassiopeia-font-weight-headings: 600;
}Only reach for component-level selectors once the tokens are exhausted. A codebase that redefines tokens is readable; one that fights Cassiopeia’s cascade with specificity wars is not.
Add the layout overrides you actually need
Copy only the layouts you are changing into the child’s html/ directory, preserving paths. Common targets:
html/com_content/article/default.php # single article
html/com_content/category/blog_item.php # blog item teaser
html/layouts/joomla/content/info_block/ # article metadata
html/mod_menu/default.php # menu markup
html/layouts/chromes/ # module wrappersKeep a note in the repository of why each override exists. In two years, an override with no explanation is indistinguishable from a file someone copied and forgot, and nobody will dare delete it.
The override architecture is the real differentiator
Every framework advertises its layout builder. What determines whether you can still ship on a Friday in year three is its override architecture, and that is barely marketed at all.
Joomla gives you one override mechanism: drop a file into templates/yourtemplate/html/ matching a core layout path and Joomla loads yours instead. Frameworks add a layer on top, and those layers differ in ways that matter:
| Question to ask | Good answer | Bad answer |
|---|---|---|
Do standard Joomla html/ overrides still work? |
Yes, unchanged | Framework intercepts rendering and ignores them |
| Can I override the framework’s own components? | Yes, in a documented directory | Edit the framework’s files and lose it on update |
| Do overrides survive a framework update? | Yes, they live outside its directory | They live inside it and are overwritten |
| Is there a child-template equivalent? | Yes, with a documented inheritance model | Duplicate the whole template and diverge |
| Where do custom SCSS or CSS files go? | A designated user file compiled after the framework’s | Edit the framework’s source stylesheets |
Watch for a framework that renders module and article output through its own code path rather than Joomla’s, because standard overrides then silently stop applying. You discover this at the worst moment — when a client asks for a small markup change and the documented Joomla answer does not work.
Choosing: a decision table
| Situation | Recommendation | Reasoning |
|---|---|---|
| One long-lived site, design changes rarely | Cassiopeia child | No dependency, no renewal, no upgrade blocker |
| Agency, 20+ similar sites a year | Standardise on one framework | Delivery speed compounds; one thing to learn and patch |
| Client will edit page layouts themselves | A framework with a visual builder | This is the only requirement that genuinely demands one |
| You have a build pipeline and version control | Gantry, or a Cassiopeia child | File-based configuration deploys; database-stored layout does not |
| Site must outlive your relationship with the client | Cassiopeia child | Handover to any Joomla developer with no licence transfer |
| Public sector or accessibility-regulated | Cassiopeia child, audited | Core accessibility work lands here first; less generated markup to defend |
| Fast turnaround, tight budget, conventional brochure site | Free framework tier | Time saved exceeds the dependency cost at this scale |
Lock-in has degrees, and the difference is measurable
Not all lock-in is equal. The useful question is not “am I locked in” but “what exactly would I have to rebuild”.
Ask this: if I disable the framework tomorrow, what remains?
| Level | Where structure is stored | Cost of leaving |
|---|---|---|
| None | Joomla articles, modules, menu items only | New template, reassign positions. A day. |
| Presentational | Framework layout config; content in Joomla | Rebuild layouts, content intact. Days. |
| Structural | Page structure in framework tables; content in Joomla | Rebuild every page’s layout by hand. Weeks. |
| Content-level | Page content itself in the builder’s format | Content migration per page. Effectively a rebuild. |
Visual page builders sit at content-level almost by definition — that is what makes them powerful. If you adopt one, adopt it knowingly, and be honest with clients that the site is now built on that product rather than on Joomla generically.
Whatever you build on, keep article bodies free of framework-specific syntax. Use the framework for page layout — headers, footers, section arrangement — and keep the words in Joomla articles as clean HTML. That single rule moves you from content-level lock-in to structural lock-in, which is the difference between a rebuild and a fortnight.
Total cost over five years
Framework decisions are usually made on licence price, the smallest component. Here is the fuller shape of the cost for an agency running fifteen client sites over five years. The bands are illustrative rather than quotes; the proportions are the point.
| Cost component | Framework route | Cassiopeia child route |
|---|---|---|
| Licensing | Annual developer subscription, typically low hundreds per year | Nil |
| Initial learning | Weeks of unbilled time, once | Nil beyond Joomla knowledge |
| Per-site build time | Lower after the learning curve | Higher, especially on complex layouts |
| Major Joomla upgrade | Blocked until the vendor ships; then usually smooth | Proceed immediately; fix your own CSS |
| Handover or exit | Rebuild, or transfer a licence dependency | Hand over files |
| Risk of forced rebuild | Real, if the vendor stops | Effectively nil |
The framework wins clearly on per-site build time, and at fifteen sites that dominates everything else. At two or three sites it does not, and the calculation inverts. The volume at which a framework starts paying for itself is lower than most solo developers assume and higher than most agencies assume — somewhere around five similar sites a year is a reasonable rule of thumb.
Evaluating a framework before you commit
Adopting a framework is a multi-year decision and deserves more than a demo site. Build one real page.
Build a realistic page, not the demo
Take an actual client design and reproduce a page of it: a header with a real menu, a hero, a three-column section, a footer with modules. Time it. Then reproduce a second page that differs slightly and see whether the framework helps you share structure or makes you duplicate it.
Test the deployment story
Build on staging, then move it to production. Does the layout configuration travel with the files, or is it in the database? Database-stored configuration means your deployment involves a database sync, which means staging and production content can never be independent. This one question separates frameworks that fit a professional workflow from those that do not.
Check the update record against Joomla releases
Look at how quickly the vendor shipped compatibility when Joomla 5 and then Joomla 6 arrived. A framework that lagged a major release by many months will lag the next one too, and that lag is time your clients spend on an unpatched Joomla because you cannot upgrade.
A framework is code executing on every page load of every site you have built on it. A vulnerability in it is a vulnerability in your entire portfolio at once — that is the concentration risk of standardising. It is still the right trade for most agencies, because the alternative is patching six different products, but it means the vendor’s security posture is a procurement criterion. Check they have a published disclosure route and a history of shipping fixes promptly, not just features.
Performance considerations
Frameworks add weight. How much depends far more on configuration than on which framework you picked, but the pattern is consistent: framework runtime, an icon set, a grid system and often a JavaScript library, loaded on every page whether the page uses them or not.
The controls that actually matter, in order of effect:
- Disable particles and features you do not use in template settings. This is where the largest savings are and it is almost always underused.
- Check whether assets load conditionally. A well-built framework loads a slider’s JavaScript only on pages containing a slider. A poorly built one loads everything everywhere.
- Look at what icon set ships. A full icon font for six icons is common and wasteful; inline SVG for the icons you use is a large, cheap win.
- Enable the framework’s own compilation and caching before adding a third-party optimiser. Stacking JCH Optimize on top of an unconfigured framework treats the symptom.
A Cassiopeia child ships whatever you wrote, which is why it is the performance baseline every framework should be measured against on your own pages rather than on a vendor demo.
A migration path that keeps your options open
If you are currently on a framework and uneasy about the dependency, you do not have to choose between staying forever and rebuilding everything now. There is a middle route that reduces exposure incrementally.
Stop the bleeding first. New sites go on the target architecture. Existing sites stay where they are. This alone caps your exposure at today’s number rather than compounding it.
Then de-risk the existing estate, cheapest first. Move any page content out of framework-specific storage and into Joomla articles. Replace framework particles that only render a module with an actual Joomla module. Each step moves a site down a level on the lock-in table, and each is independently useful even if you never migrate.
Migrate only on a redesign. Rebuilding a site’s template for its own sake is unbillable work. Rebuilding it during a redesign the client is already paying for costs a fraction, because you were changing the layout anyway.
Sites that reach end of life before their turn comes never need migrating at all — a legitimate outcome, not a failure of the plan.
Frequently asked questions
Do I need a template framework at all?
Only if you need an admin layout system, per-page layout assignment without code, or a client who edits their own page structure. If none of those apply, a Cassiopeia child template does everything else a framework does with no dependency and no renewal. Most single-site owners do not need a framework and are sold one anyway.
Can I move a site from one framework to another?
You can move the content; you cannot move the layout. Articles, categories, modules and menu items are Joomla data and survive any template change. Layout configuration, particles and any page built in a visual builder do not transfer and must be rebuilt, which is why the switch is usually costed as a redesign rather than a migration.
Is Yootheme Pro a framework or a page builder?
Functionally a page builder with a template attached, and that distinction determines your exit cost rather than your daily experience. It builds pages quickly and well, and page content built in it is stored in its own format, so leaving means rebuilding those pages. Choose it for what it does well, with that trade understood at the outset.
What happens to my sites if a framework vendor disappears?
Existing sites keep working — the code is on your server and does not phone home. What stops is security patches and Joomla-version compatibility, so the practical deadline is the next major Joomla release rather than the day the vendor goes quiet. That gives you a planning window measured in years, provided you notice the vendor has gone quiet.
Should an agency standardise on one framework?
Yes, in nearly all cases. The efficiency of one layout model, one override structure and one update process across the portfolio outweighs the flexibility of choosing per project. The exception is a client who arrives with a site already built on something else — inherit it, maintain it, and quote the migration honestly rather than doing it for free.
Is Cassiopeia a framework?
No. It is a template with a well-organised stylesheet, a set of custom properties and native child template support. That is enough for a great many sites, but it has no layout manager, no particle system and no admin design UI, so calling it a framework would overstate what it does.
How long does it take to become productive on a new framework?
Expect a week to build something acceptable and roughly a month before you are as fast as you were on whatever you used previously. Budget the first project on a new framework at significantly more hours than you would quote normally, and do it on an internal site rather than a client’s.