commercetools Frontend vs. Alokai vs. FMP: The Composable Frontend Options
commercetools Frontend vs. Alokai vs. FMP: The Composable Frontend Options
If you are running commercetools as your backend and weighing how to build the frontend, you have three real options, not two: commercetools Frontend (formerly Frontastic, the vendor's own frontend tool), Alokai (formerly Vue Storefront, a Vue and React composable frontend framework), or a managed Frontend Management Platform (FMP) that treats the frontend as an operated service rather than a codebase you own. Each option answers "who owns the render layer" differently, and that answer decides your Vue Storefront commercetools setup for years, not months.
Why commercetools ships without a frontend
commercetools is API-first and cloud-native by design, GraphQL and REST APIs, no default storefront. That is the point of a composable, MACH architecture: you choose every layer. But it means every commercetools implementation starts with the same conversation: who builds and owns the frontend? Three answers exist in the market today, and each has a real trade-off.
Option 1: commercetools Frontend (Frontastic)
commercetools acquired Frontastic in 2021 and rebranded it as commercetools Frontend, a JavaScript-based frontend tool tightly integrated with the commercetools API. It ships pre-built storefront components and connectors, which shortens initial setup compared with a from-scratch build.
The trade-off: it is a vendor-owned tool inside a vendor-owned backend. Teams that later want to change frontend tooling, agency, marketing stack, or design system, find themselves as deep inside commercetools Frontend's conventions as they were inside the API itself. It is composable at the backend layer and single-vendor at the frontend layer, which is the exact tension commercetools customers raise most often.
Option 2: Alokai (Vue and React storefront framework)
Alokai, rebranded from Vue Storefront, is a composable frontend framework built primarily around Vue.js, with React support, designed to sit in front of commercetools and other MACH backends through its own connector library. It is a legitimate composable-frontend answer: open architecture, active community, no commercetools-specific lock-in.
The trade-off shifts rather than disappears. Alokai's connector library and hosting model become the new dependency. Teams building on Alokai still need a dedicated frontend engineering team to build, maintain, and extend the storefront, the same team-cost question that applies to any custom-build option, just with Alokai's scaffolding instead of a blank Next.js project.
Option 3: a managed Frontend Management Platform
The third option treats the frontend as an operated service. An FMP connects to commercetools' GraphQL API as a standard integration and delivers the storefront, editing surface, and component library as a managed platform rather than a codebase your team owns and patches. Marketing teams publish pages through a visual editor, engineering focuses on backend-specific logic instead of frontend plumbing, and multi-brand or multi-market rollouts run on one component library instead of one codebase fork per brand.
The three options compared
| Dimension | commercetools Frontend | Alokai | FMP (Laioutr) |
|---|---|---|---|
| Frontend lock-in | Vendor-owned (commercetools) | Tool-owned (Alokai connectors and hosting) | None, frontend is swappable independent of backend |
| Team required | Frontend team using CT Frontend conventions | Dedicated frontend engineering team | FMP-managed, engineering focuses on backend logic |
| Time-to-launch | Faster than from-scratch, still an engineering project | Engineering project, framework-accelerated | Studio editor, landing pages in hours |
| Multi-brand scaling | Per-brand implementation | Per-brand implementation | One component library, token-based |
| Marketing self-service | Limited, engineering-dependent | Limited, engineering-dependent | Visual editor, no developer ticket |
| Typical setup time | Weeks to months | Months | Weeks, GraphQL connector, no custom build |
What this actually costs
Composable commerce promises that every layer is swappable. In practice, most commercetools implementations end up composable in the backend and locked in the frontend, whichever of the three options they picked. The number that gets skipped in vendor comparisons is the frontend team cost: a dedicated frontend engineering team, whether working against commercetools Frontend, Alokai, or a from-scratch Next.js or Nuxt build, typically runs well into six figures annually once you count maintenance, on-call, and the engineering time a marketing team's page requests consume.
That cost is the actual decision, more than the framework choice. If your team already has committed frontend engineers who want ownership of the codebase, Alokai is a legitimate composable-frontend answer. If you want to stay inside commercetools' own tooling and accept the trade-off, commercetools Frontend does the job. If you want the frontend decoupled from both the backend vendor and from a dedicated frontend team's roadmap, that is the case a managed FMP makes.
Where Laioutr fits
Laioutr's Agentic Frontend Management Platform connects to commercetools through a standard GraphQL integration, the headless frontend for commercetools, and keeps the frontend independent of both the backend vendor and a dedicated frontend codebase. Multi-brand and multi-market rollouts run through composability and orchestration on one component library instead of a per-brand fork, which is where teams on commercetools Frontend or Alokai usually rebuild work they already did once.
This is not an argument against commercetools. commercetools now sells core commerce and product catalog as standalone modules, which only sharpens the frontend-decoupling question further. It is an argument that the frontend decision deserves the same scrutiny as the backend decision, and that "composable" should apply to both layers, not just the one commercetools controls. Teams evaluating who owns the experience layer for commercetools builders are asking exactly this question, just from the API-first-builder angle rather than the frontend-tooling angle.
For a closer look at how Laioutr specifically compares to Alokai on architecture and operating model, see Laioutr vs. Alokai.
FAQ
Is Alokai the same as Vue Storefront? Yes, Alokai is the rebranded name for what was previously Vue Storefront, a composable frontend framework built primarily on Vue.js with React support.
Do we have to migrate off commercetools to use an FMP? No. commercetools stays as the backend in all three options described here. The frontend layer connects through commercetools' standard GraphQL API regardless of which of the three you choose.
Which option is fastest to launch? A managed FMP is typically fastest for landing pages and ongoing marketing publishing because they run through a visual editor. Initial storefront setup across all three options is comparable at the GraphQL-connector stage, the difference shows up in ongoing maintenance and publishing speed.
Can we switch from Frontastic or Alokai to an FMP later without a backend migration? Yes. Since all three options connect to commercetools through the same GraphQL API, replacing the frontend layer does not require touching the backend, only remapping components and content to the new layer.
Next steps
If you are choosing a frontend for commercetools and want the composable promise to actually apply to both layers, talk to us about what a commercetools GraphQL connection through a managed frontend layer looks like for your team, or start with the commercetools frontend page.
About the author: Marcel Thiesies is Co-Founder of Laioutr.