When to choose Exponential, and when a plain framework
This page is for developers and leads deciding how to build a project. Exponential and general web frameworks are good at different things; the question is which one starts closer to your project. Nothing here says one is better in general.
Contents
- Exponential starts closer when
- A plain framework starts closer when
- Costs on each side
- Questions to answer first
- Both at once
Exponential starts closer when
| Your project has | Exponential gives you without code |
|---|---|
| Content that people edit, review and publish | content classes, drafts, versions, history, an administration |
| Several languages, including right-to-left | translated content, per-language addresses, RTL (Translations) |
| Several sites or brands on one content base | siteaccesses (Siteaccesses) |
| Fine-grained permissions that administrators manage | roles and policies with limitations (Authorization) |
| Approval processes | workflows with approval (Workflows) |
| Pages that editors build | Exponential Layouts (The layouts editor) |
| A shop next to the content | the built-in shop (Shop overview) |
| Many database choices, or none to run | SQLite by default; PostgreSQL, MySQL/MariaDB, Oracle, MongoDB (Database support) |
In these projects a framework team would spend its first months building an admin, revisions, translations and permissions; Exponential has them on day one (Exponential as an application platform).
A plain framework starts closer when
- The core is high-volume transactional data with no editorial life (a ledger, telemetry, a booking engine's inventory).
- The product is an API-only service with a team that wants the framework's container, ORM and tooling end to end.
- The team wants the newest PHP idioms everywhere: attributes, a DI container, PSR-7 and PSR-15 middleware, typed configuration. Exponential's kernel has a long history and its own conventions (Dependency injection).
- Hiring must draw from the largest pool of developers for one framework.
- You need a framework-specific ecosystem package with no counterpart.
Costs on each side
| Exponential | Plain framework | |
|---|---|---|
| Learning | siteaccesses, INI layers, the template language, overrides | the framework plus every package you add for CMS features |
| Building editorial features | mostly configuration | code and maintenance |
| Custom application logic | extensions with modules and classes | native |
| Testing | PHPUnit, no in-process HTTP client (Testing) | usually richer test tooling |
| Upgrades | one product, Composer updates of the kernel and extensions | the framework plus each package |
Questions to answer first
- Who edits the data, and do they need drafts, history, translations and approval?
- How many sites, languages and audiences share the content?
- Who decides permissions: developers in code, or administrators at run time?
- Is most data content or transactions?
- What does the team know, and what will it maintain in five years?
If the answers to 1 to 3 are "editors", "several" and "administrators", Exponential is usually the shorter path. If 4 is "transactions", keep those in your own tables or a separate service, whatever you choose for the rest.
Both at once
You do not have to pick one for everything: keep content in Exponential and a transactional service in a framework, or use the Symfony-based platform products (Mixing Exponential and a framework, The platform products).
Related pages
- Exponential for web framework developers
- What Exponential is: the product family
- Checklists for framework developers
- Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.
Become an Exponential Partner
Partners share their information, provide funding, contribute back and develop the products with us, and that is how Exponential grows. A partner website and dashboard are planned for mid-2027: please become a partner today to speed up our growth rate and land new features faster.