At the end of 2022, the entire frontend community was surprised by an unexpected announcement: [Shopify acquired Remix](https://shopify.engineering/remix-joins-shopify). At first glance, this news offers little information; after all, Shopify is famous for investing many resources into open-source projects. However, after further research, the reason for this merger became clear: Remix is deeply aligned with Shopify’s new framework: Hydrogen.

Shortly after the big news, the dev team behind Hydrogen [made another announcement](https://hydrogen.shopify.dev/roadmap/): the entire framework was being re-created from scratch using Remix, thus giving birth to Hydrogen v2. While the upgrade path will likely be a struggle for existing Hydrogen v1 users, Hydrogen v2 offers several benefits over its predecessor.

In this article, we’ll look at some of the most significant enhancements Hydrogen v2 brings to the developer experience, what they mean for your user experience, and how you can start adopting them in your storefront.

## A Brief Primer on Remix

To fully comprehend Hydrogen’s latest changes, we must first understand Remix.

For those unfamiliar with it, Remix is an up-and-coming Javascript framework based on React. It was developed by Kent C. Dodds, Ryan Florence, and Michael Jackson, all well-known contributors to the Javascript open-source community.

Unlike the previous generation of React frameworks such as Next.js, Remix is full-stack, monolithic, and fully server-side-rendered, and it will feel like a breath of fresh air to all the Ruby on Rails and Laravel lovers. In fact, Remix’s primary goal is to merge the benefits of the “old Web” with the smooth developer experience React offers. This way, developers get higher productivity, simpler code, better SEO, less backend-frontend communication overhead, smaller client bundles, and near-instantaneous page transitions.

![](https://cdn.sanity.io/images/kqgmf0g2/production/030082583dd37bf225378d98322d8b1993cf3e0b-2960x2400.png?fit=clip)

When developing the first version of Hydrogen, Shopify created a framework very similar to Remix in spirit: it was React-based, but it was also rendered on the server. This was a surprising choice back in the early days of Hydrogen, but it did make a lot of sense in retrospect: anyone who has tried to implement an eCommerce storefront quickly found that the dynamic nature of eCommerce doesn’t play well with static site generation and client-side rendering.

In October 2022, Remix announced that Shopify was acquiring it. As part of the deal, Shopify will offer continuous support to Remix’s authors to continue developing the framework, and Remix is becoming the React framework powering Hydrogen. On their side, Hydrogen’s development team can now delegate most of the core framework functionality to Remix, focusing only on Hydrogen-specific functionality.

## The Main Changes in Shopify Hydrogen v2

Even though the Shopify developer community (and Shopify themselves, [in some places](https://github.com/Shopify/hydrogen/blob/2023-04/packages/hydrogen/CHANGELOG.md#202317)) dubbed this release “Hydrogen v2”, this isn’t technically correct: Hydrogen simply follows calendar versioning, with each version number being a combination of the date and month of the release (e.g., v2023.1.0). However, for the sake of simplicity, we will refer to “Hydrogen v2” as the version of Hydrogen that uses Remix.

As you might expect, this release introduces _a lot_ of changes. In fact, pretty much everything in the framework has changed, meaning developers with an existing Hydrogen storefront have a whole bunch of rewriting to do.

### Retrieving Data with Loaders

The most significant change–which will affect pretty much every route in your project–is the introduction of Remix’s `loader` function.

The `loader` function is where all of your data retrieval logic is stored. The `useShopQuery` and `useQuery` hooks from Hydrogen v1, responsible for querying the Shopify Storefront API, have been replaced with `loader` in Hydrogen v2.

For example, imagine building a product detail page with a product options selector. In a typical React storefront, you would need to store the selected options in a state entry:

![](https://cdn.sanity.io/images/kqgmf0g2/production/e553a7b7b1f1e0d77e3cd95a9ecef7a1893b29c9-1200x520.png?fit=clip)

The problem with this implementation is that this component also needs to change the URL whenever a new variant is selected, so that users can easily bookmark or share the URL to the correct product variant. Unfortunately, there is no “native” way of achieving this with React. You would need to create a function that alters the URL when the user changes their selection.

With Remix, just like Ruby on Rails or Laravel, you can solve this by simply taking advantage of Web fundamentals. In this case, whenever the user selects a new product option, you simply direct them to a new URL, and the `loader` function gets executed again, querying the desired product variant from the Storefront API.

![](https://cdn.sanity.io/images/kqgmf0g2/production/3217fe54a31e57a20a6240808dd00e4937c4f7eb-1200x856.png?fit=clip)

The benefits of this new implementation are clear: we achieve the same outcome with less code and fewer abstractions to learn.

This approach was used to refactor all the major components in Hydrogen: the cart, analytics, SEO, and session management were rebuilt from scratch, resulting in a much more straightforward developer experience and a less steep learning curve!

[Learn more about the `loader` function in the Remix guides.](https://remix.run/docs/en/1.16.1/route/loader)

### Mutating Data with Actions

While the `loader` is used to _retrieve_ data, the `action` function is to _mutate_ data. As a consequence of segregating business logic into loaders and actions, you can now remove a bunch of code, especially client-side logic and state.

As an example, take a look at what the default `AddToCart` component looks like in the Hydrogen v1 demo store:

![](https://cdn.sanity.io/images/kqgmf0g2/production/253be981f9a0861351e4e2bcba39e77df56fec53-1374x2904.png?fit=clip)

And now, look at the same component in the Hydrogen v2 demo store:

![](https://cdn.sanity.io/images/kqgmf0g2/production/5c38c039f5c5132d9b9ba34c6d19d0b0075b7f0b-1424x1786.png?fit=clip)

As you can see, a lot of state management and querying logic has been removed in favor of a more straightforward implementation that relies on Web fundamentals such as... Web forms! This simplifies your code and makes your online store more resilient to network issues and more accessible to screen readers and old devices.

[Learn more about the `action` function in the Remix guides.](https://remix.run/docs/en/1.16.1/route/action)

### Handling Errors with Error Boundaries

A common and annoying problem with React applications is isolating errors. Typically, when you get any error on the frontend, the whole UI breaks, and the website becomes unusable. This is obviously not a desirable experience for our customers.

By taking advantage of Remix’s [nested routes](https://remix.run/docs/en/1.16.1/guides/routing#what-is-nested-routing), you can use [nested error boundaries](https://remix.run/docs/en/v1/guides/errors#nested-error-boundaries). If you export an error boundary function from a nested route and an error occurs, the error will be isolated, and the rest of your application will remain usable. This allows you to offer the best possible UX, even when things go wrong:

![](https://cdn.sanity.io/images/kqgmf0g2/production/e73f3849c1e52c9a44c721ff4b43976455174ab8-1207x1685.png?fit=clip)

[Learn more about error handling in the Remix guides.](https://remix.run/docs/en/1.16.1/guides/errors)

### Speeding Up Page Loads with Streaming

By using Remix’s [defer](https://remix.run/docs/en/1.16.1/guides/streaming#using-defer) function, you can easily decide which parts of your page should be rendered right away and which parts can be streamed after the page has loaded:

![](https://cdn.sanity.io/images/kqgmf0g2/production/d1fc77778b2760be478d391326acc7ede28f1abe-1207x1685.png?fit=clip)

This technique allows you to easily defer the loading of lower-priority parts of your UI, such as a “Related products” section on your PDP, making for a better user experience and faster loading times.

[Learn more about streaming in the Remix guides.](https://remix.run/docs/en/1.16.1/guides/streaming)

### Speeding Up User Interactions with Optimistic UI

Optimistic UI is a powerful technique that lets you completely hide loading states from the end user. For instance, when a user clicks on your Add to Cart button, rather than waiting for the cart to be updated on the server, you might immediately display the new item in the user’s cart. Then, if an error occurs, you can revert the state and display an error to the user:

![](https://cdn.sanity.io/images/kqgmf0g2/production/1cdb09cad49d184358eb840920173250a2061bc1-1250x800.png?fit=clip)

While not available yet, Hydrogen’s development team plans to adopt optimistic UI in all the standard components. Because Hydrogen is powered by Remix, you will also have the opportunity to use the same pattern in any custom user interactions you offer on your storefront.

[Learn more about optimistic UI in the Remix guides.](https://remix.run/docs/en/1.16.1/tutorials/jokes#optimistic-ui)

### Oxygen Is now Available to All Shopify Plans!

Although there was no official announcement, this is massive news for all Shopify developers! Hydrogen’s official deployment platform, [Oxygen](https://shopify.dev/docs/custom-storefronts/oxygen), which was only available to Shopify Plus users, is now available to all Shopify plans.

Oxygen is an excellent tool for engineers who want a seamless deployment and hosting experience. By keeping your storefront within Oxygen, you can not only reduce your infrastructure costs, but also have access to a fantastic developer experience that includes:

* Preview environments for testing changes in isolation.
* Custom environments (e.g., if you want a staging area).
* Version control and GitOps for your storefront.
* A Content Delivery Network (CDN) powered by Shopify.
* Support for both backend and frontend code.
* CI/CD via GitHub Actions and the Hydrogen channel.

If you’re familiar with Vercel, you’ll find that Oxygen offers a very similar development experience, but more accurately tailored to the needs of Shopify developers.

## Migrating from Hydrogen v1 to Hydrogen v2

If you are using Hydrogen v1 today, there’s a [handy migration guide](https://shopify.dev/docs/custom-storefronts/hydrogen/migrate-hydrogen-remix) in the Hydrogen docs that you can follow to upgrade your storefront.

The process takes a lot of effort, but the guide is comprehensive and accurate, so you should be able to upgrade your Hydrogen app by simply following the steps outlined.

## Is Hydrogen Ready for Production Use Yet?

That depends on your risk tolerance!

On a technical level, both Hydrogen and Oxygen are most definitely production-grade products, and they are being used successfully in the wild by large Shopify stores such as [Allbirds](https://hydrogen.shopify.dev/case-studies/allbirds). The developer experience is pleasant and powerful, and Shopify’s hosting infrastructure will easily handle any production load you throw at it.

On the other hand, it’s unclear whether Hydrogen will see any more extensive refactorings, such as the one we’ve just witnessed. As an example, [Remix v2](https://remix.run/docs/en/main/pages/v2) will be released soon, bringing many improvements over its predecessor, but also requiring developers to upgrade to a new API and file naming convention. These changes will most likely affect Hydrogen users as well. It’s also unclear what synergies Shopify will create between Hydrogen and [Commerce Components](https://www.shopify.com/commerce-components), but we expect some movement there.

![](https://cdn.sanity.io/images/kqgmf0g2/production/e038f0246b07a894d83a8ae5cb1d3fe545d2bc6a-2960x2335.png?fit=clip)

Another factor to consider is how long it will take for the Shopify app ecosystem to catch up to Hydrogen’s philosophy. While some Shopify apps don’t need to worry about the frontend at all, others will have to expose an API or JavaScript SDK of some sort to be usable with a headless commerce architecture. We expect the situation to improve over the coming years, but there’s still a long way to go, and many Shopify apps today cannot be used with Hydrogen.

Overall, Hydrogen is well worth a try if you have the engineering firepower. It solves a significant number of problems for Shopify developers and gives brands unmatched flexibility in building a custom storefront, allowing them to create shopping experiences that would be very hard to replicate with Liquid themes.

However, if you’re a small brand and don’t have the resources to invest in experimental technology, you’re probably better off sticking with Liquid themes until Hydrogen becomes a true first-class citizen in the Shopify ecosystem.

Shopify Just Released Hydrogen v2. What’s In It for You?

While the total penetration of headless commerce in the US is still low, we have witnessed an increase in headless builds in recent years. And even though [we don’t believe headless is the end-all solution to all eCommerce problems](https://nebulab.com/blog/headless-commerce), we think it’s about time the industry realized the power of this architecture and started using it responsibly.

The only way for Shopify users to go headless for a long time was to implement their own single-page application from scratch, using a JavaScript library such as React (and hopefully a framework, such as Next.js). Shopify does provide SDKs to make the API integration work slightly more manageable, but that was about it: until recently, there was very little being done for performance, state management, personalization, or SEO.

In November 2021, Shopify released a developer preview of [Hydrogen](https://hydrogen.shopify.dev/), their new framework meant to address precisely these problems. Here at Nebulab, we’ve recently had the chance to take Hydrogen for a spin, and we want to share our learnings.

## What is Hydrogen?

Hydrogen is an open-source, React-based framework that can be used to build custom storefronts on the Shopify platform. It provides a lot of useful functionality:

* A sensible structure for your application code.

* eCommerce-specific components and pages.

* An SDK and hooks to interact with Shopify’s GraphQL-based [Storefront API](https://shopify.dev/api/storefront).

* It uses [Tailwind CSS](https://tailwindcss.com/) for styling.

* It’s optimized for high-performance builds.

Combined, these features almost entirely eliminate the amount of boilerplate code engineers need to write to build their storefronts and allow engineers to spend most of their time on functionality that truly moves the needle.

![Shopify Hydrogen website](https://cdn.sanity.io/images/kqgmf0g2/production/9865cb4da04e7cd861e38c97cc7015d8ea7a1e22-2560x2512.png?fit=clip)

## What are the pros of using Hydrogen?

For Shopify stores that want to go headless, Hydrogen is a huge help. As we’ve mentioned, it abstracts away all the complexity of integrating with the Shopify API and developing your storefront’s skeleton: all you need to do is clone the Hydrogen [demo store](https://shopify.dev/custom-storefronts/hydrogen/getting-started/templates#demo-store-template), configure it, then focus on styling and custom functionality. This alone is a huge productivity boost, and the developer experience has been outstanding in our experiments.

It’s also important to note that Hydrogen is officially developed and supported by Shopify, which should provide peace of mind to brands looking for a stable, robust solution that’s not going anywhere. While some Shopify-specific Next.js templates already existed before Hydrogen, they were mostly small, community-sponsored projects, which made them unsuitable for enterprise use.

## What are the cons of using Hydrogen?

Seasoned developers know that productivity comes with a hidden cost: the more a tool tries to abstract away technical complexity, the more opinionated it is. When it comes to Hydrogen, it’s exceptionally opinionated:

* It uses React server components.

* It uses streaming server-side rendering (SSR).

* It has built-in components, hooks, and caching mechanisms.

* It’s heavily coupled with Shopify’s Storefront API.

* If you need complete control over your React application, Hydrogen is most likely not a good candidate for you.

You should also know that some of these features are bleeding edge in the React ecosystem, and because Hydrogen is tightly coupled with Shopify, the community around it is still relatively small. Hydrogen brands can expect to have a harder time finding online resources and support, and they will have to tap into a smaller pool of agencies and engineers than if they used a more popular framework. That said, much of that will likely change as Hydrogen gains popularity.

Finally, most Shopify Apps and plugins were built to integrate with Liquid templates and won’t be compatible with Hydrogen (or other headless architectures, for that matter). If you rely heavily on specific apps and your app doesn’t provide an API your engineers can integrate with, you’ll need to switch to a headless-friendly alternative or build the functionality yourself.

## Can Hydrogen be used without Shopify Plus?

It’s complicated. The official answer is yes: since Hydrogen is an open-source project whose source code is available to anyone, and because none of the API endpoints it uses are restricted to Shopify Plus customers, at first glance, the framework can be used without Shopify Plus.

In reality, things are more nuanced.

![Shopify Oxygen documentation](https://cdn.sanity.io/images/kqgmf0g2/production/a893aabf4ed6f21f992598100837e4856353c79f-2560x1620.png?fit=clip)

First of all, there’s the matter of hosting your Hydrogen application. Plus users can host their Hydrogen app on [Shopify Oxygen](https://shopify.dev/custom-storefronts/oxygenhttps://shopify.dev/custom-storefronts/oxygen), Shopify’s proprietary hosting solution, which provides native support for directing users who visit your Shopify domain to your Hydrogen storefront.

If you don’t use Shopify Plus, you should still be able to deploy your Hydrogen app to other platforms, but it won’t be a painless experience. For example, Vercel has published a blog post announcing the availability of a [zero-configuration deployment for Hydrogen](https://vercel.com/changelog/hydrogen-projects-can-now-be-deployed-with-zero-configuration). But when we tested it, we had to manually tweak the environment variables used by Hydrogen to match the names used by Oxygen. This was a minor inconvenience overall, but it shows how support for Hydrogen is still in its infancy.

Once you’ve figured out the hosting, it’s time to deal with domains and DNS records. If you manage your domains through Shopify, Shopify will attempt to redirect any requests to your [myshopify.com](http://myshopify.com/) domain to your Hydrogen storefront, which will completely break the checkout. This could be easily solved by using a [routing domain](https://help.shopify.com/en/manual/domains/domain-type/routing-domain) which, ironically, is only available to Shopify Plus customers. (When we reached out to Shopify engineering about this catch-22-esque paradox, they seemed utterly taken aback by this realization.) The current solution is to set up your Liquid storefront to redirect to your Hydrogen storefront via JavaScript, which is far from ideal.

Another aspect to consider is support: in our experience, if you’re not a Shopify Plus customer, you’re only going to get extremely limited technical support from Shopify, with most requests being redirected to Shopify’s Discord community. No one in the Discord community seems to have much experience with Hydrogen, except for Shopify’s own employees, whose presence in the community is very erratic.

To be fair, Shopify did tell us that they are working to address these challenges and make Hydrogen truly available to non-Plus customers. However, _when_ this will happen exactly is unknown.

To sum it up, if you’re not on Shopify Plus and don’t have an experienced engineering team or agency backing you up, we would advise against using Hydrogen right now: you run the risk of spending weeks or months of development only to run into deal-breaking roadblocks.

![Shopify Discord](https://cdn.sanity.io/images/kqgmf0g2/production/ce5f2c4f4565702286b8a1df6cd0d17d418c8538-2560x2068.png?w=450)

## Who should be using Hydrogen?

Shopify’s Hydrogen framework is the perfect solution for online stores that are already running headless, or are planning to go headless, can count on a robust engineering team, and want to lean into a powerful, officially-supported solution that will spare them from boilerplate work. The developer experience is enjoyable, and most React engineers will be more than happy to work on a Hydrogen app.

If, on the other hand, you don’t have an experienced engineering team or don’t want to deal with the complexity that comes with a headless solution, Hydrogen is not a good choice: as much as it simplifies things, it will still require much more upkeep than a Liquid-based Shopify build.

At this point, Hydrogen is also a less-than-ideal solution for brands not on Shopify Plus due to missing functionality and limited support from Shopify. That is likely to change as the framework matures and becomes more widely available, so keep an eye out for any announcements from Shopify (and from us!).

If you’re considering going headless with Hydrogen or other frameworks, and are unsure of the implications, [feel free to reach out](https://nebulab.com/contact-us)! Our team has extensive experience and will help you make the choice that best supports your digital strategy.

Everything You Need to Know About Shopify Hydrogen

With unlimited digital estate, DTC brands can tell their stories, announce, entertain, educate, and keep their name front and center in customers’ minds, all of which is very hard to do in the limited shelf space afforded by wholesale partners. Now that even die-hard digitally-native brands are going omnichannel in pursuit of reach and profitability, **it’s paramount to double down on the exclusive capabilities of each channel to create complementary experiences—for DTC, content is one of the most obvious levers to pull**.

A slew of platforms has emerged over the past decade that promise to offer the definitive solution to all content management pains. These solutions provide functionality that covers the entire content management lifecycle, from writing to publishing, presentation, and SEO, but they do it in very different ways. In fact, we’ve seen at least four generations of content management tooling emerge in these years, all of which coexist today, serving different use cases and market segments.

For eCommerce operators, finding a North star to follow in this vastness can be tricky, and engineering teams are usually not much better off. If you haven’t been exposed to all these tools and understand the nuances of each, it’s easy to get lured in by the promise of unlimited flexibility and endless automation, only to find yourself stuck with a complex piece of software that requires weeks of integration work, or doesn’t play nice with your editorial workflow.

In this article, we will provide an overview of the content management space, as seen from the perspective of an eCommerce brand. You will learn the different types of tools you can use, their advantages and limitations, and some practical recommendations about which tool to adopt depending on your goal, use case, and growth stage. The goal is to equip you with all the knowledge you need to make an informed decision for your eCommerce brand.

## The four generations of content management

Different content management solutions have been launched in the last twenty years. While there’s no universal taxonomy, we can classify them under four categories: monolithic CMSs, headless CMSs, site builders, and page builders. In the following paragraphs, we’ll explore these different solutions, their pros and cons, and the leading players in each space.

### Monolithic CMSs

Monolithic CMSs were the first content management solution to emerge in the market. **These tools take over your entire content experience by handling every single aspect**: they provide an interface that allows you to edit and publish your content and present the content to your audience via a public-facing website.

You’ve probably heard about [WordPress](https://wordpress.org/), arguably the most popular CMS in the world. Initially built for blogging, WordPress has been expanded over the years to encompass an incredible number of use cases, allowing you to publish blogs, entire websites, and even online stores. It’s estimated that WordPress powers over 43% of all websites.

![WordPress website](https://cdn.sanity.io/images/kqgmf0g2/production/908b2d57d03ec193412387c8af8d151b6df2393b-2560x2136.png?fit=clip)

**Monolithic CMSs have been around for over fifteen years, and they’ve stood the test of time**. They offer a user-friendly, streamlined content editing experience and many plugins and apps that make them easy to repurpose for different use cases. Since they have a considerable market share, they also boast rich ecosystems of system integrators.

However, they also come with some limitations: th**ese content management systems are meant for content-centric websites, not for eCommerce brands.** They usually take over your entire website and don’t play nice with other parts of your tech stack. This makes them a less-than-ideal choice for a DTC brand, which needs to present the content on their storefront or even enrich it with dynamic data such as product information.

### Headless CMSs

Headless CMSs were built to solve precisely these limitations. **Compared to monolithic solutions, headless CMSs are much more nimble**: a headless CMS only provides an interface to define your content structure and manage your content. Presenting your content is up to you, and typically requires a design and engineering team to integrate the headless CMS into your existing frontend.

[Contentful](https://contentful.com/) has long been the primary contender in the headless CMS space, but many competitors have launched their solutions over the years: [Prismic](https://prismic.app/), [DatoCMS](https://datocms.com/), and [Sanity](https://sanity.io/) are among the most popular alternatives, offering slightly different functionality such as custom editorial workflows/UIs and internationalization, and wildly different price points.

![Contentful homepage](https://cdn.sanity.io/images/kqgmf0g2/production/551c31bc9b5a60be3f663151ba0172e06f790da5-2560x1810.png?fit=fill)

**Headless CMSs enable brands to treat content as data, making it fully portable and allowing them to present their content wherever they want**. Most headless CMSs also connect to your backend: for instance, an eCommerce brand will be able to pull product and pricing information from Shopify and include it right in the middle of an editorial piece. Such functionality allows you to blur the lines between content and commerce, making for a much richer customer experience.

Headless CMSs are still very popular thanks to their flexibility, but they come with their own limitations: mainly, **they require design and engineering work when marketers want to integrate new types of content into a company’s existing digital properties, or whenever they want to make visual changes to the existing experience**. This may be problematic for brands operating with low budgets or in high-velocity environments.

### Site builders

While site builders are not technically new (Webflow was born in 2012, one year before Contentful), they’ve seen a recent surge in popularity. You can think of site builders as a modern take on monolithic CMSs: like monolithic solutions, site builders also take over your entire website. However, **they offer more modern and advanced functionality**, such as support for drag-and-drop editing across your entire website, responsive design, custom code, API access, and integrations with popular third-party design and development tools. Almost all site builders also include a native headless CMS, or will optionally integrate with a third-party headless CMS.

The most popular site builder is [Webflow](https://webflow.com/), which is often used by SaaS companies to manage their marketing websites, or by eCommerce brands to spin up self-contained editorial experiences. Webflow also allows creating gated content and building Zapier-esque workflow automation. A recent competitor is [Framer](https://framer.com/), which allows designers to build, test and publish websites straight from Figma wireframes.

![Webflow homepage](https://cdn.sanity.io/images/kqgmf0g2/production/0082e34207f075b05269676c871a8d0d49b1601a-2560x2034.png?fit=fill)

**If your team has limited technical experience or you don’t want to use your engineering bandwidth, using a site builder can be an excellent way to quickly spin up new editorial experiences that will meet the standards of the modern Web.** And if you need to implement deeper customizations or complicated workflows, your engineers can still make those adjustments at a reasonable pace.

The main disadvantage with site builders is that, for all their flexibility, **they will still be pretty self-contained, and they’re hard to integrate with other digital properties.** Maintaining brand consistency will also be more challenging since your design system will live both in your site builder and across any other frontends you have. This is fine if you’re building a standalone experience such as a microsite, but can hurt your brand reputation when used for integrated experiences such as a company blog.

### Page builders

After coming full circle with site builders, the content management pendulum is swinging the other way once again with page builders. Like site builders, page builders also offer drag-and-drop editing, built-in headless CMSs, and all the modern developer tooling you might expect. **Unlike page builders, site builders try to be non-obtrusive: rather than taking over your entire website, they allow you to model specific pages or sections of it.** For example, you might let your eCommerce platform power your product catalog and checkout experience while your page builder powers your site navigation and blog.

The most popular page builder is [Builder.io](http://builder.io/), used by several eCommerce brands such as Everlane, J.Crew, and Harry’s. It allows you to use their native visual editor or to import your own components, connects with several third-party data sources, offers built-in A/B testing, and lets you publish your content across the Web, mobile, and wherever else you want. An early-stage contender is [Plasmic](https://plasmic.app/), which offers a very similar feature set, but pairs it with a more modern UX.

![Builder.io homepage](https://cdn.sanity.io/images/kqgmf0g2/production/29e681ed0cb541c8da8d8c65119b10cfe3f08b8d-2560x1528.png?fit=clip)

**Page builders can be an excellent compromise between headless CMSs and site builders**: they allow you to easily integrate your content into your existing digital properties in a non-obtrusive, brand-consistent way, and they offer a visual interface that helps non-technical stakeholders to quickly iterate on both content and presentation.

However, they are not a one-size-fits-all solution. **While an essential page builder integration can be a reasonably low-effort process for your engineering team, getting page builders right can be a complex initiative.** Once you start bringing in your own UI components, performing search engine optimization, running A/B tests, integrating with external data sources, or implementing rich user interactions, the level of complexity goes up dramatically, and keeping everything running smoothly can be a challenge.

## Evaluating the right solution for your brand

As you’ve seen, there’s no easy answer: each eCommerce CMS has its pros and cons, which you should weigh against your company’s stage, requirements, and technical savviness. The three main factors we keep into account when picking a solution for our clients are:

* **Business goals**: what do you want to achieve with your content? This is closely tied to where you’ll want to place your content, which in turn informs your choice of tooling. Are you looking to inform, inspire, or convert? (Often, it will be a mix of these, which is perfectly fine—just make sure you cover all your bases!)

* **Span of control**: site builders give operators maximum flexibility to change whatever they want, whenever they want it. This is both a blessing and a curse: a non-designer making design changes can quickly become a disaster. What’s the sweet spot between not enough and too much control for your team?

* **Implementation effort**: page builders are more complex to integrate than headless CMSs, which in turn are more complex to integrate than a monolithic CMS. Do the benefits outweigh the extra effort of integrating the solution with your tech stack?
Apparel brand and Nebulab client [Huckberry](https://huckberry.com/), for instance, relies heavily on their blog, [The Journal](https://huckberry.com/journal). The Journal is a fully integrated part of Huckberry’s shopping experiences: articles typically feature one or more Huckberry products, which users can add to their cart with a simple click. It’s a very conversion-centric approach.

![Huckberry’s blog, The Journal](https://cdn.sanity.io/images/kqgmf0g2/production/7ce46f90390f88961bbc568a2fafc78deb24b464-2560x2512.png?fit=clip)

Travel brand [Away](https://awaytravel.com/), on the other hand, publishes the travel and lifestyle magazine [Here](https://www.heremagazine.com/). Away’s magazine has a laid-back, inspirational approach with its content, and you can hardly notice that a DTC brand is behind the project.

![Away’s magazine, Here](https://cdn.sanity.io/images/kqgmf0g2/production/85383a0a4b600d7279c82359e0f0da9edf9209b8-2560x1664.png?fit=clip)

### Picking tools vs. building infrastructures

**Rather than only adopting one solution, we recommend creating a content management infrastructure, i.e., a suite of tools that integrate and build on top of each other.** For example, here’s a typical journey a DTC brand might undergo:

1. As a first step, they adopt a headless CMS, which allows them to decouple content and presentation. They use their headless CMS as the source of truth for all their content and integrate it with their existing digital properties (e.g., their product pages).

2. At some point, the marketing team starts complaining that they can’t make visual changes to how the content is presented on their product pages without asking the engineering team. This leads the team to integrate a page builder for specific website sections (e.g., the PDP and the blog). The page builder is connected to their headless CMS, which is still used for managing the actual content.

3. The brand eventually outgrows the page builder as well: the marketing team wants to start experimenting with standalone experiences such as microsites for contests, promotions, and product launches. This is when the team adopts a site builder, giving marketing full power to launch new properties with little to no engineering assistance.

**As marketing teams gain more freedom, brands need to create checks and balances to avoid brand dilution.** This can mean having a content inventory that is continuously monitored for consistency, ensuring the same person is orchestrating all digital experiences, or having a full-fledged design system that can be applied across different platforms. **Ultimately, how much centralization you need depends on your brand’s scale and your reliance on content.**

## Our favorite CMSs for eCommerce brands

At Nebulab, we have helped tens of brands design, launch and optimize their content stack, and we have developed some pretty strong opinions on which CMS platforms to use:

* **Monolithic CMS:** [WordPress](https://wordpress.org/). As mentioned, we rarely pick monolithic CMSs for eCommerce brands—but when we do, we go with WordPress. It has a beautiful, intuitive UX and an incredibly vast ecosystem of plugins and integrations, making it a good fit for many use cases and deployment options.

* **Headless CMS:** [Sanity](https://sanity.io/). A few years ago, we would have recommended Contentful or Prismic ([and we have](https://nebulab.com/blog/five-no-code-ecommerce-management-tools#the-best-headless-cms-prismic)). Ever since we’ve had a chance to try Sanity, we fell in love with its flexibility. While traditional headless CMSs force users to use a standardized UI for managing content, Sanity’s content studio is open-source and can be tailored to your content management needs and editorial workflows.

* **Page builder:** [Plasmic](https://plasmic.app/). While Builder.io has been around for slightly longer, Plasmic offers a more modern UI for their editing backend. With that said, the two tools are incredibly similar, so we encourage you to experiment with both and see which one you prefer.

* **Site builder:** [Webflow](https://webflow.com/). Even though products like Framer offer a more streamlined experience for non-technical users, Webflow remains an incredibly powerful tool if you know how to use it. With support for custom workflows and gated content, your team can quickly spin up rich micro-sites that cover various use cases.

As always, your mileage may vary. Before committing to a solution, you should thoroughly assess your present and anticipated requirements and experiment with different setups to build a stack that can scale with you as your needs evolve. If you need any advice or want to speed up the process, [we’re happy to help](https://nebulab.com/contact-us)!

Building Content Infrastructures for eCommerce Brands

As funding for headless commerce platforms reached a staggering [$1.6 billion](https://www.forbes.com/sites/forbestechcouncil/2021/05/11/why-is-headless-commerce-getting-16-billion-in-funding/?sh=5322b28f513a) in 2021, these systems aren’t to be ignored. But how exactly do they compare to the so-called traditional “monolithic” eCommerce platforms, and when should you pick one over the other?

This guide will explore the headless commerce model, its benefits, how it differs from the all-in-one monolithic commerce system, and when it’s a good option for your brand.

## What is headless commerce and how does it work?

Headless commerce is an eCommerce architecture where the frontend layer, or presentation layer, is decoupled from the backend commerce functionality.

Before we continue, let’s review the key differences between the frontend and backend:

* **Frontend:** This is the user interface. Customers see and interact with the frontend, whether they’re accessing your eCommerce site, shopping app, digital kiosk or other shopping channels.

* **Backend:** The backend is the behind-the-scenes, technical side of an eCommerce store the customer doesn’t see. The backend includes the technologies and tools that run in the background to ensure customers can shop and [have smooth checkouts](/blog/one-page-checkout-with-spree).

In headless commerce, the frontend and backend systems communicate via Application Programming Interfaces (APIs). This approach allows you to update the frontend, the customer-facing part of your site, independently of the backend and even use different development frameworks. This separation of concerns offers several benefits which we’ll explore below.

Examples of headless eCommerce solutions are Commerce Layer, Swell, and Nacelle.


## 4 benefits of headless commerce

![Woman lying on a couch and using a laptop](https://cdn.sanity.io/images/kqgmf0g2/production/96998b94bc1edf8908d27f5af24b1a34e88c56a8-1200x797.jpg?fit=clip)

Platforms that adopt a headless architecture offer several benefits compared to monolithic, or so-called traditional eCommerce platforms. Here are the top four advantages.

### 1. Omnichannel capabilities

In an omnichannel eCommerce experience, customers can start shopping on one channel or device and transition seamlessly to a different channel while the brand retains key information: common examples are a customer completing their purchase online, but selecting in-store pickup, or a customer buying something in-store and having the order show up their online order history.

Headless commerce makes it easy to serve the [74% of shoppers](https://www.salesforce.com/content/dam/web/en_us/www/documents/research/salesforce-state-of-the-connected-customer-4th-ed.pdf) who use multiple channels to shop: because the same backend system can serve multiple storefronts, you can easily adapt customer touchpoints and shopping experiences to serve your eCommerce website, your mobile app, social media pages, and even physical locations. All will be completely integrated and feel seamless for your customers to interact with.

### 2. Technical flexibility

By decoupling backend and frontend, headless platforms allow your development team to pick the frontend stack, including third-party providers, that they’re most productive with. A headless architecture allows you to adopt your favorite content management system (CMS) to create rich editorial experiences, or elevate your storefront through progressive web apps (PWAs). This enables you to create engaging digital experiences that don’t face the limitations of traditional monolithic frontends.

When done right, headless architectures even allow you to refactor or completely replace entire parts of your backend with little to no impact on your frontend experience(s), which allows you to move and experiment much more quickly.

### 3. Superior personalization

Most monolithic eCommerce platforms severely limit your ability to personalize the customer experience by forcing you to work with proprietary templating language and preventing you from accessing customer data. With [80% of customers](https://www.epsilon.com/us/about-us/pressroom/new-epsilon-research-indicates-80-of-consumers-are-more-likely-to-make-a-purchase-when-brands-offer-personalized-experiences) indicating they prefer brands that offer tailored experiences, eCommerce personalization is now table stakes for modern brands.

Headless platforms allow you to not only leverage basic eCommerce data, such as a customer’s profile and order history, but even augment it with brand-specific data points of your own. This allows you to create shopping experiences that feel built for your customer, boosting customer engagement, conversion rates and AOV.

### 4. Blazing fast performance

Storefronts that leverage a headless eCommerce platform can typically be deployed as static sites and put behind a global content delivery network (CDN) such as Cloudflare. In the hands of a capable development team, this can lead to incredible performance that would be hard to achieve with a monolithic platform.

A 2019 study by Portent has found that improving your loading speeds can boost your conversion rates [anywhere from 1.5X to 2.5X](https://www.portent.com/blog/analytics/research-site-speed-hurting-everyones-revenue.htm)! If your eCommerce site loads slowly, you are leaving lots of money on the table—literally.

## 3 drawbacks of going headless

![Four programmers working at same office's table](https://cdn.sanity.io/images/kqgmf0g2/production/0afcfb4759febba635d79b5004c9a4cf4c8c2242-1200x800.jpg?fit=clip)

In some cases, a headless build can lead to an unnecessarily complex architecture that causes more problems than it solves. Evaluating which eCommerce platform to use for your business needs is a complex process that should take into account both short-term and long-term factors as well as your budget and internal capabilities.

Here are three drawbacks of headless eCommerce platforms.

### 1. Technical capabilities

Launching a headless storefront requires you to create an in-house engineering team or hire an eCommerce agency for the long term. Headless sites require more ongoing maintenance to keep the lights on: Dependencies need to be updated, infrastructure needs to be maintained, and the site needs to be continuously monitored for bugs and performance issues.

In our experience, this additional effort has its upsides: It forces brand operators to get into a continuous optimization mindset, where they’re constantly identifying and capitalizing on new technology and other opportunities that can improve the shopping experience. Monolithic platforms, on the other hand, encourage a less intentional set-and-forget approach, which is definitely easier to execute, but also worse positioned for long-term scalability.

### 2. Time-to-market (and cost!)

Headless builds are typically associated with slightly higher timelines than monolithic builds. Adopting a headless architecture requires a significant investment in an agency or an in-house development team that will build your storefront, and this process can take anywhere between 2 and 4 months, depending on the complexity of the build.

Conversely, launching a store on a monolithic platform can be a much faster process with more competitive pricing, if you’re willing to settle for a more standardized look and purchase experience. This can be an acceptable compromise for smaller mom-and-pop businesses, but certainly not for a direct-to-consumer (DTC) brand with large long-term aspirations.

### 3. Integration effort

Headless eCommerce platforms are very flexible because you have full freedom to implement your storefront however you want. Unfortunately, this also means that many of the integrations and plugins that you can use out of the box with a monolithic platform will require a bit more work to be integrated in a headless architecture.

If you want to add reviews to your headless eCommerce website, for instance, you’ll need to work with your designers and engineers to figure out what the experience should look like, where to place the reviews, when to ask for them etc., and then implement and test the new functionality.

Ultimately, this extra effort is a good thing: A headless system asks you to be more disciplined and intentional in how you modify your storefront. This will force you to approach all initiatives with a critical eye rather than jumping from trend to trend, but it can be frustrating if you’re used to installing a plugin and forgetting about it.


## The verdict: headless or monolithic?

![Woman holding a credit card and using a phone](https://cdn.sanity.io/images/kqgmf0g2/production/cb3e8d957a2c46acdf1eda32e9cecd9c5173bf13-1200x800.jpg?fit=clip)

The answer is: It depends on the use case. There’s no right or wrong answer.

While a headless commerce architecture has myriad benefits over monolithic architectures, it’s not ideal in all contexts. In certain scenarios, a headless commerce approach is the best way to build your vision and drive superior brand performance, while in others, you’re better off with a monolithic architecture that saves you time and money.

Headless commerce solutions might be right for:

1. **Brands that want to offer a consistent customer experience across channels:** Any brand that wants to deliver consistent customer experiences regardless of channels or devices should consider adopting this architecture.

2. **Brands that feel their current platform is too rigid and restrictive:** If you’ve ever felt your platform is limiting on the backend or frontend, it’s time to switch to a flexible headless setup.

3. **Brands that put personalization front and center:** If personalizing the shopping experience is critical for your brand’s strategy, then you should explore the capabilities that a headless build will unlock for your development team.

4. **Online stores that have slow-loading pages:** If sluggish pages have been a pain point for your eCommerce store, a headless architecture may be able to help by allowing you to leverage a more robust frontend ecosystem.

On the other hand, monolithic builds are a good solution for:

1. **Brands with limited technical know-how:** Headless commerce requires stronger technical capabilities which might not be everyone’s cup of tea. If you want to launch a commerce website without dealing with the underlying technicalities, headless is not for you.

2. **Brands with time-to-market or financial constraints:** If you’re on a tight timeline or a limited budget, a monolithic build will very often prove cheaper and quicker to launch than a headless counterpart.

3. **Brands that want ready-made functionality:** If you want to leverage ready-made features and integrations without thinking too deeply about how to integrate them in your shopping experience, a monolithic platform will give you more peace of mind.


## Need help picking the right platform?

![Entrepreneur using his phone and laptop](https://cdn.sanity.io/images/kqgmf0g2/production/97e367e0de824649a05070d381052e44e0ca20e4-1200x801.jpg?fit=clip)

Headless architectures allow teams to move faster, address changing consumer needs, improve the user experience, and capitalize on omnichannel opportunities, but they’re not ideal for all brands.

Nebulab can help your new digital brand pick the right eCommerce platform for a greenfield build, or help your established brand design the right tech stack for its next growth spurt. We offer full-service consulting throughout all stages of your eCommerce project.

[Reach out](/contact-us) to see how we can help you create a vision for your eCommerce experience.

The Nebulab

Shopify Just Released Hydrogen v2. What’s In It for You?

Everything You Need to Know About Shopify Hydrogen

Building Content Infrastructures for eCommerce Brands

Headless Commerce: The Good, the Bad and the Ugly