Alberto Vena

A couple of weeks ago, Shopify released the [Summer ’24 Edition](https://www.shopify.com/editions/summer2024). Since its humble beginnings in the [summer of ’22](https://www.shopify.com/editions/summer2022#audiences), Editions has evolved into a major biyearly marketing initiative the Shopify team uses to update their customers and the larger commerce industry about the latest product announcements, upcoming functionality, and the general direction the platform is taking.

The splashy landing pages are then coronated by several official events, earned media (including, yes, the very article you’re reading), and fringe industry gatherings aimed at creating more hype around the platform and, by extension, the hundreds of industry players that live in its shadow and participate in its ecosystem.

And since everyone and their dog has an opinion on Editions, we thought we’d be remiss not to share our take on the most exciting announcements.

In the following paragraphs, you’ll find a recap of our favorite announcements from the Shopify Summer ’24 Edition, along with our opinions on what they mean for the future of the ecosystem.

Let’s get into it!

## You Get a Market, You Get a Market, Everybody Gets a Market

Historically, internationalization on Shopify has been challenging. For a long time, brands that wanted to start selling in other countries were forced to set up expansion stores that were, effectively, completely independent of the main store. This forced brands to sync their product catalog, settings, inventory, apps, etc., across all their stores–a Sisyphean task that often required installing clunky apps.

Then, in late 2021, [Shopify released Shopify Markets](https://www.shopify.com/news/global-by-default-shopify-markets-becomes-new-global-commerce-hub-for-merchants), a game-changing feature for brands looking to sell internationally. Markets allowed brands to sell to multiple countries from a single Shopify store while still controlling product catalogs, pricing, shipping, and other configurations on a per-country basis. Markets simplified international selling on Shopify dramatically and was acclaimed positively by both agencies and brands.

One year later, [Shopify released B2B](https://www.shopify.com/enterprise/blog/b2b-on-shopify), making it easier for brands to sell wholesale. Shopify B2B allowed merchants to manage company profiles, configure B2B-specific payment methods and terms, and set up dedicated price lists. It came at a time when more brands were looking at B2B to drive profitable growth and allowed brands to manage their wholesale operations from the same platform they knew and loved for DTC.

Until now, Markets and B2B have been entirely independent, each functioning according to different rules and concepts and configured in their respective UIs. Add to this Shopify POS, [which was launched in 2013](https://www.shopify.com/news/shopify-launches-revolutionary-point-of-sale-system) and also operated as a completely separate sales channel. Understandably, this created friction for merchants, who needed to navigate a complex maze of settings and rules to determine how their brand shows up in different channels.

![](https://cdn.sanity.io/images/kqgmf0g2/production/d624cc7cae90e895dd78cf1ee360266218b672ea-1280x720.jpg?fit=clip)

In the Summer ’24 Edition, Shopify announced that [Markets will become a unified home](https://www.shopify.com/editions/summer2024#markets) to manage all of your brand’s expansion efforts, whether you’re talking about new countries, B2B, or POS. For each channel, you can now configure the product catalog, availability, pricing, and much more from a single UI, and you can even combine different types of markets (e.g., all retail stores in the UK).

This not only gives brands an unprecedented amount of flexibility, but it also dramatically reduces the operational effort of maintaining multiple sales channels.

Finally, Shopify also announced that [each market will be able to use a separate business entity](https://www.shopify.com/editions/summer2024#multiple-business-entities) for payments. This long overdue change often prevented international brands from adopting Markets, forcing them to use expansion stores with all their quirks and limitations.

Our team was pretty excited about this change: It brings much-needed consistency to several areas of the platform and unlocks a range of use cases that were not possible before, such as having completely different themes for different markets or having complete control over the product catalog available to retail stores. It all _feels_ right, as evidenced by the ecosystem’s overwhelmingly positive response.

The new Markets experience is not available to the public yet, but you can [sign up](https://www.shopify.com/editions/summer2024#markets-top-10) to get notified when it will be released.


## New Shopify POS Functionality Gives Your Retail Stores Superpowers

Besides Markets, Shopify has put a lot of effort into making sure that all the different sales channels they offer to merchants are fully integrated. In the process, they’ve resolved some annoying gotchas and inconsistencies that had bothered merchants for years and unlocked new, exciting use cases.

POS got a lot of love in this regard. First of all, the POS hardware is now available in nine new countries–Belgium, Denmark, Germany, Ireland, Italy (yay!), the Netherlands, New Zealand, Spain, and the UK. In the last few years, we’ve seen pretty strong demand for Shopify’s POS devices in Europe, so it’s great to finally be able to offer them to merchants–Shopify’s hardware is excellent, and we can’t wait to experiment with it a bit more.

Secondly, Shopify is also enabling truly unified shopping experiences with two new features that bridge the gap between online and offline:

* [Ship to store](https://www.shopify.com/editions/summer2024#ship-to-store), which boosts Shopify’s existing BOPIS (Buy Online, Pickup In Store) functionality by allowing customers to choose their favorite pickup location regardless of inventory availability. When the product is unavailable, Shopify will seamlessly orchestrate delivery to the customer’s chosen pickup point.
* [Ship from store](https://www.shopify.com/editions/summer2024#ship-from-store), which allows merchants to use their stores as last-mile fulfillment networks. Online orders will appear on the retail store’s POS interface, from which store operators can fulfill the orders or, if unable, delegate fulfillment to another location or back to a standard fulfillment center.

![](https://cdn.sanity.io/images/kqgmf0g2/production/4b3bebec01781cec89054946a6bb6a758e528894-1280x720.jpg?fit=clip)

Finally, POS became more intelligent and more integrated with the rest of the Shopify ecosystem. This includes functionality such as:

* [One-tap digital receipts](https://www.shopify.com/editions/summer2024#digital-receipts-with-opt-ins), which can be delivered by email, text, or, if the customer has a Shop Pay account, to the Shop app.
* The ability to [collect personal information](https://www.shopify.com/editions/summer2024#require-info-at-checkout) such as name and email, marketing opt-ins, and sales staff attribution at checkout.
* Automatic integration with your store’s [return rules](https://www.shopify.com/editions/summer2024#return-rules), which reduces the likelihood of out-of-policy returns.

Combined, these features allow brands to make the most of their physical stores, reducing fulfillment costs, improving the customer experience, and helping brands collect more zero-party data. In an era when all merchants are trying to do more with less, this is the sort of innovation that we like to see from Shopify.

## Checkout Is Getting a Flexibility Boost 

Shopify’s checkout has long been a significant component of the platform’s value proposition and, at the same time, one of its biggest weaknesses. While it’s great for merchants to be able to delegate compliance concerns or checkout CRO to Shopify, the lack of customizability in the checkout flow has prevented specific categories of brands from implementing their ideal customer experience or, in some instances, from adopting Shopify altogether.

Some of this rigidity is by design: Shopify doesn’t want brands to shoot themselves in their metaphorical foot by making changes that could negatively impact their conversion rates. Finding the right balance between flexibility and compliance with industry regulations is also challenging, especially with the new limitations imposed by [PCI DSS v4](https://www.shopify.com/partners/blog/checkout-compliance).

That said, Shopify has been doing some great work on this front over the last few years by adopting a two-pronged approach: They’ve been opening up the checkout to more types of customizations and more elaborate use cases, but they’ve also been forcing merchants to use a set of standardized APIs (dubbed [Checkout Extensibility](https://www.shopify.com/enterprise/blog/checkout-extensibility-winter-editions)) to alter their checkout flow.

![](https://cdn.sanity.io/images/kqgmf0g2/production/bf8f13000bd1a4fc566adcfea2f55adb32bde12a-1280x720.jpg?fit=clip)

In the latest Edition, Shopify has continued on this path by releasing a slew of new features and customization APIs for their checkout:

* [Checkout Blocks](https://www.checkoutblocks.com/), a third-party app that allowed merchants to apply complex customizations to their checkout in a no-code UI, has been acquired by Shopify and is now free for all Shopify Plus merchants. It’s a fantastic product, and we couldn’t be happier for [Gil](https://www.linkedin.com/in/gilgreenberg/) and his team!
* Checkout will soon support [split shipping](https://www.shopify.com/editions/summer2024#split-shipping), allowing customers to see when an order will be split into multiple shipments and pick a different shipping method for each shipment. On a similar note, it’s now possible to [capture partial payments](https://www.shopify.com/editions/summer2024#payment-per-fulfillment) when part of an order is fulfilled.
* In a move that will undoubtedly be appreciated by brands outside the US, Shopify is now offering the ability to implement third-party integrations for [pickup points](https://www.shopify.com/editions/summer2024#3p-pickup-points-api) (not available yet) and [address autocompletion](https://shopify.dev/docs/api/checkout-ui-extensions/unstable/targets/utility/purchase-address-autocomplete-suggest), as well as to collect region-specific [address fields](https://www.shopify.com/editions/summer2024#region-specific-addresses) and different forms of [tax ID](https://www.shopify.com/editions/summer2024#tax-id-fields) for individual and business customers.
* Developers can now use the [Checkout Branding API](https://shopify.dev/docs/apps/build/checkout/styling) (available to Shopify Plus merchants only) to configure the checkout flow’s overall styling and UI elements. Additionally, they can [pre-fill the address at checkout](https://www.shopify.com/editions/summer2024#prefilled-addresses), which is handy for gift and wedding registries and other non-traditional shopping experiences.

These changes, most of which are targeted at international brands or brands with complex use cases such as marketplaces, give merchants some much-needed flexibility while still allowing Shopify to guarantee compliance and retain control over the end-user experience. 

In fact, we were working with a couple of brands waiting for some of this functionality to switch to Shopify, and we can’t wait to try it in the wild.

## Analytics, Controls, and Automation for Operators That Mean Business

Last but not least, Shopify announced a range of new features aimed at larger, more sophisticated brands that need greater visibility into and control over their businesses.

The spotlight goes to the [new Shopify Analytics](https://www.shopify.com/editions/summer2024#rebuilt-analytics), which allows merchants to build advanced custom reports and dashboards and, soon, query their data directly using ShopifyQL. Combined, these two features unlock much greater flexibility when it comes to business analytics, reducing the need for merchants to roll out and maintain dedicated business intelligence infrastructure.

![](https://cdn.sanity.io/images/kqgmf0g2/production/b489a739028c98fd8168cafd505dd0874b2b0c52-1280x720.jpg?fit=clip)

Organization settings and staff access also received some love. While the details are not completely fleshed out yet, it looks like companies will soon be able to [manage multiple stores from a unified interface and](https://www.shopify.com/editions/summer2024#organization-settings) assign staff access through a [Role-Based Access Control (RBAC) system.](https://www.shopify.com/editions/summer2024#role-based-access-control)

Finally, Shopify is releasing several improvements for Shopify Flow, their built-in task automation platform. Flow is becoming more powerful (thanks to features such as the ability to [send direct requests to the Admin API](https://www.shopify.com/editions/summer2024#send-admin-api-in-flow)), easier to use (see the [improved UX for working with metafields](https://www.shopify.com/editions/summer2024#custom-data-for-flow)), and more convenient to debug when something goes wrong (with a [better search experience](https://www.shopify.com/editions/summer2024#search-runs-for-flow) and [manual reruns](https://www.shopify.com/editions/summer2024#manual-reruns-in-flow)).

While Flow still leaves a lot to be desired (how much longer until we can use the result of an API call inside Flow?!), it’s a robust product for automatic basic tasks in a low-code environment. In fact, we’ve been able to use it in several instances where we would have previously reached for a custom app or an external automation platform, such as Zapier.

## Hydrogen Gets The First-Class Treatment: Visual Editor and B2B Storefronts

On the headless front, much work went into creating consistency between Hydrogen’s off-the-shelf capabilities and what brands can do with Online Store.

The most prominent announcement here was the new [Hydrogen Visual Editor](https://www.shopify.com/editions/summer2024#hydrogen-visual-editor), based on an open-source solution called Utopia. The editor, which is yet to be released, will allow marketers to manage the content of their storefronts through a visual page builder.

Furthermore, the new visual editor _actually updates the underlying code_ of your storefront rather than loading content through a client-side network call. This comes with several benefits, including much faster page load times and all the goodies of Git-based version control.

In the past, we’ve had to roll out similar features manually through solutions such as Sanity and Builder.io, so it’s great to have this out of the box and officially supported by Shopify. That said, we were surprised that Shopify didn’t just acquire an established player in the space, such as [Pack](https://packdigital.com/) or [Instant](https://instant.so/), and integrated their solution natively.

We’re also still waiting for the day when Shopify will decide to unify its content management solutions, using the same technology across Online Store and Hydrogen. Perhaps this is a small step in that direction.

![](https://cdn.sanity.io/images/kqgmf0g2/production/257a779594efae973c9a1d3fe3c5d84b98eb04e0-1280x720.jpg?fit=clip)

In addition to the Visual Editor, it is now possible to launch [headless B2B storefronts](https://shopify.dev/docs/storefronts/headless/bring-your-own-stack/b2b)–a feature that was previously only available for Online Store. There’s even a [Hydrogen B2B template](https://github.com/Shopify/hydrogen/tree/main/examples/b2b) that you can leverage to speed up time-to-market if you wish.

These are the major announcements, but Shopify also announced [many additional improvements to Hydrogen](https://hydrogen.shopify.dev/update/summer-editions-24-announcing-the-hydrogen-visual-editor-and-a-ton-of-dx-improvements), such as an optimistic cart API for instantaneous cart updates, official support for Vite, native integration with Shopify Analytics and the Customer Privacy API, better environment variable management, and improved SEO tooling.

One of the main problems with headless Shopify architectures has been the feature and capability gap between Hydrogen and Online Store. There are still inconsistencies to figure out, especially when it comes to the app ecosystem. Still, with some of these announcements, it feels like we’re getting closer, which is excellent news for all merchants that need a more sophisticated storefront than what Liquid themes allow.

## There’s Much More…

In this article, we have deliberately omitted a lot of stuff, cherry-picking the announcements and capabilities that were most relevant to the work we typically do with our clients. We didn’t talk about the [improvements to Shopify Magic](https://www.shopify.com/editions/summer2024#ai-for-commerce) or all the work Shopify is doing around [third-party sales channels and Shop](https://www.shopify.com/editions/summer2024#connect-with-customers), their own marketplace. If you run a Shopify brand, we encourage you to check out [the official Editions site](https://www.shopify.com/editions/summer2024#connect-with-customers) to ensure you’re not missing anything!

That said, it’s clear that Shopify plans to continue pushing in all directions. For smaller brands, they are rolling out features that allow them to do more with less, leveraging the strength of Shopify’s ecosystem and economies of scale.

For larger brands, they’re making the platform more flexible to support more complex use cases. At the same time, though, they’re also creating consistency and feature parity across different flavors and sales channels to minimize the amount of gotchas and “insider knowledge” required to navigate the Shopify universe.

Given the size of that ecosystem, it’s an uphill battle, but if anyone has the market traction and R&D budget to pull this off, it’s Shopify–and we’re excited to be part of the ride.

Shopify Summer ’24 Edition: Are Things Getting Serious?

Daniel Bergholz

If you have been working with Shopify’s Hydrogen framework for some time, you might still have some scars after the
[migration from Hydrogen v1 to Hydrogen v2](https://nebulab.com/blog/shopify-hydrogen-v2-updates).

One of the major changes in Hydrogen v2 was the transition from a custom-built React framework to
[Remix](https://remix.run/), a relatively new framework that is seeing a lot of traction thanks to its streamlined
developer experience, its reliance on Server-Side Rendering and its deep focus on web standards.

Remix was a significant improvement over Shopify’s in-house React framework, and allowed Hydrogen stores to benefit
from a much larger ecosystem of Remix docs, plugins and system integrators. We’ve discussed the benefits at length in
[our blog post covering the migration](https://nebulab.com/blog/shopify-hydrogen-v2-updates).

Unfortunately, the migration process from Hydrogen v1 to Hydrogen v2 was also incredibly complex. So much so, that many
large brands were better off re-building their storefront from scratch with Hydrogen v2 rather than attempting to port
their existing codebase. This caused a lot of discontent and frustration with Shopify’s decision, which didn’t seem to
fully appreciate the complexity of maintaining a complex headless architecture.

Now, it _feels_ like history might be repeating itself: Remix just announced a new major release. Remix v2 comes with
several new features and improvements to the developer experience that Hydrogen developers will also benefit from.
However, Hydrogen teams are also worried that the transition to Remix v2 might be their latest time-suck and source of
frustration.

But is that really the case, or are things better this time around?

In the past few weeks, we’ve been following the Remix community and trying to unpack the implications of this release
for Hydrogen. Let’s see what this release actually means for you, and how you can make the best of it!

## What’s New in Remix v2 for Hydrogen Devs?

Let’s start by taking a look at the changes and new features in Remix v2 that are most relevant for Hydrogen developers.

Keep in mind that you can always read the [release announcement](https://github.com/remix-run/remix/releases/tag/remix%402.0.0)
if you want to see the complete list of changes!

### New Dev Server with HMR and HDR

If you’ve used a more established React framework such as Next.js, you’re probably familiar with HMR even though you
might not know the acronym. HMR, which stands for Hot Module Replacement, is the feature that allows the page to update
instantaneously and reflect any changes you make to your code. It’s a handy functionality when you’re actively
developing a new page, or making small visual tweaks that you want to preview in real time.

Historically, Remix did not offer support for HMR: that meant you had to manually refresh the page whenever you made
a change to your client-side or server-side code, which was old-school and time-consuming.

Luckily, that’s not the case anymore! Remix v2 ships with a new dev server that supports HMR and Hot Data Reloading
(HDR), the equivalent of HMR for server-side code. Whenever you make a change to your Hydrogen app, it will be
propagated immediately to your browser. Client-side state is also maintained, so that you can continue interacting with
the app without restarting any user flows from scratch (e.g., if you’re in the middle of checkout).

It has support for hot module replacement (HMR) and hot data reloading (HDR). The announcement is available
[on YouTube](https://www.youtube.com/watch?v=79M4vYZi-po).

On earlier versions of Remix, whenever there was a code change, you would have to manually refresh the page to see the
new changes (pretty old-school tech). Now, that is unnecessary and HMR will not reset client-side state between updates.
And HDR can be described as HMR for data loaders. With HDR you can make changes to your server code and see those
updates reflected in your UI immediately without resetting client-side state, just like HMR.

### Native Support for PostCSS and Tailwind and PostCSS

As you probably know, Hydrogen uses [Tailwind](https://tailwindcss.com/) as the default CSS framework.

Unlike more traditional CSS frameworks (such as Bootstrap), Tailwind relies heavily on CSS post-processing to generate
your final CSS build: it scans all your files, understands which Tailwind classes need to be generated, and then
generates just the classes you need. This allows you to minimize the amount of CSS you’re shipping to the client while
also allowing you to do incredible things, like attaching [arbitrary CSS properties](https://tailwindcss.com/docs/adding-custom-styles#arbitrary-properties).

Before Remix v2, you would have to run any CSS transformations in a separate process, e.g. with
[Tailwind’s CLI interface](https://tailwindcss.com/blog/standalone-cli), then import the final CSS file into your Remix
app. This worked, but wasn’t really a smooth development experience.

Remix v2 adds out-of-the-box support for [Tailwind directives and PostCSS](https://remix.run/docs/en/main/start/v2#built-in-postcsstailwind-support),
a popular CSS processor that Tailwind integrates natively with. If you’re using Hydrogen, all the relevant configuration
is generated for you: simply bootstrap your app, and your Tailwind styles will just start compiling automagically!

Check out Remix’s documentation about [PostCSS](https://remix.run/docs/en/main/styling/postcss) and
[Tailwind](https://remix.run/docs/en/main/styling/tailwind) for more details.

### Server-Side Streaming with `defer`

This one is a game-changer. Remix v2 aims to provide first-class support for React 18's SSR streaming capabilities
through the `defer` helper.

When you return a `defer` function call in a route loader, you are initiating a streamed response. This is very
useful when serving lower-priority data that may take longer to load. After all, you don’t want your users to wait on
slow data if more important content is ready to display on the page!

Here’s an example of what streaming looks like on the server:

```javascript
import { defer } from "@remix-run/node";

export async function loader ({ request }) {
  // Product info query is small, cached aggressively, ad
  // high priority for the user. Let’s go ahead and let it
  // resolve since it’s fast!
  let productInfo = await getProductInfo (rewquest);

  // Product reviews query is large and cache is more lax.
  // Let’s initiate the query but not wait for it to resolve.
  let productReviewsPromise = getProductReviews (request);

  // With defer, we initiate a streaming response. This allows
  // the user to access the resolved data (`productInfo`) as
  // soon as it’s available, while the unresolved product
  // reviews are loaded in the background.
  return defer ({
    productInfo,
    productReviewsPromise,
  });
}
```

The corresponding client-side code would then leverage the `Await` component, which is built on top of
[React’s `<Suspense />` API](https://react.dev/reference/react/Suspense):

```javascript
import { Await } from "@remix-run/react";

function ProductRoute () {
  let {
    // Product info has already resolved. Render immediately!
    productInfo,
    // Product reviews might not be ready yet 🤔
    productReviewsPromise,
  } = useLoaderData ();

  return (
    <div>
      <h1>{productInfo.name}</h1>
      <p>{productInfo.description}</p>
      <BuyNowButton productId={productInfo.id} />
      <hr />
      <h2>Reviews</h2>
      <React.Suspense fallback={<p>Loading reviews…</p>}>
        <Await resolve={productReviewsPromise} errorElement={<ReviewsError />}>
          {(productReviews) =>
            productReviews.map ((review) => (
              <div key={review.id}>
                <h3>{review.title}</h3>
                <p>{review.body}</p>
              </div>
            ))
          }
        </Await>
      </React.Suspense>
    </div>
  )
}

// Error fetching the data? Slow connection and timed out?
// Show an error message *only* for reviews. The rest
// of your product UI is still usable!
function ReviewsError () {
  let error = useAsyncError (); // Get the rejected value
  return <p>There was an error loading reviews: {error.message}</p>;
}
```

This was a framework-agnostic example, but Hydrogen is already leveraging `defer`. On the home page, for instance,
recommended products are streamed rather than being loaded immediately:

```typescript
export async function loader ({context}: LoaderArgs) {
  const {storefront} = context;
  const {collections} = await storefront.query (FEATURED_COLLECTION_QUERY);
  const featuredCollection = collection.nodes[0];
  const recommendedProducts = storefront.query (RECOMMENDED_PRODUCTS_QUERY);

  return defer ({featuredCollection, recommendedProducts});
}
```

For more examples of how Hydrogen leverages Remix features to optimize data handling, you can take a look at
[this article](https://hydrogen.shopify.dev/update/improving-data-handling-in-hydrogen-and-remix).

### Flat Routing by Default

Older versions of Remix use subfolders to nest route segments. This leads to a lot of directory nesting, and also makes
it harder to navigate the directory tree.

Remix v2 embraces [flat routing](https://remix.run/docs/en/main/start/v2#file-system-route-convention) instead. With
flat routing, all your routes are in the same directory, which makes it easy to find them at a glance. For example,
here’s the new folder structure in a Hydrogen application based on Remix v2:

![](https://cdn.sanity.io/images/kqgmf0g2/production/59ae846180e55976494ef64fb35b7ee854107044-698x1370.png?fit=clip)

There’s a bit more to it, so we encourage you to check out [Remix’s documentation](https://remix.run/docs/en/main/start/v2#file-system-route-convention)
about the change to fully understand the new folder structure.

Since not everyone will love this change, you can also maintain the current approach by installing the
`@remix-run/v1-route-convention` package and adding the following to your `remix.config.js`:

```javascript
const {
  createRoutesFromFolders,
} = require ("@remix-run/v1-route-convention");

/** @type {import ('@remix-run/dev').AppConfig} */
module.exports = {
  future: {
    // makes the warning go away in v1.15+
    v2_routeConvention: true,
  },

  routes (defineRoutes) {
    // uses the v1 convention, works in v1.15+ and v2
    return createRoutesFromFolders (defineRoutes);
  },
};
```

## How to Upgrade Your Hydrogen Application to Remix v2

Now, this is the part you were all waiting for! How difficult is it to upgrade an existing Hydrogen application to Remix
v2? Luckily for you, not very difficult.

The typical approach for performing major upgrades to your application’s dependencies typically involves creating a
separate, long-lived feature branch, working on the upgrade in isolation, and then releasing it all in one go.

![](https://cdn.sanity.io/images/kqgmf0g2/production/a7da987d49c9126fa8f5bc3dd60f94bbf867eea6-1516x634.png?fit=clip)

This approach, which is still very widespread, has several drawbacks:

- It is time-consuming, because it requires a lot of work and frequent rebases.
- It is prone to error, because you’re releasing a lot of changes in one deployment.
- It is all-or-nothing, because it prevents you from adopting new features before the upgrade.

Remix aims to fix this problem through [Future Flags](https://remix.run/docs/en/main/start/future-flags). Future flags
allow developers to incrementally adopt new features and then seamlessly upgrade their application, eliminating the need
for long feature branches and scary deployments.

Conceptually, the way they work is very simple: the Remix team releases Remix v2 features in Remix v1, but puts them
behind a feature flag that you need to manually enable in your Remix configuration. Then, when Remix v2 is released, the
Remix team simply removes all future flags and turns them into default behavior. This allows you to integrate one
feature at a time as it’s released by Remix, rather than doing it all in one pass.

![](https://cdn.sanity.io/images/kqgmf0g2/production/79ff3d1e16ca4fb2421871fa9cce3b5ba6a56599-1999x441.png?fit=clip)

For instance, here are the future flags for Remix v2:

```javascript
/** @type {import ('@remix-run/dev').AppConfig} */
module.exports = {
  //…
  future: {
    v2_dev: true,
    v2_meta: true,
    v2_headers: true,
    v2_errorBoundary: true,
    v2_routeConvention: true,
    v2_normalizeFormMethod: true,
  },
};
```

If you are on the latest version of Remix v1, your `remix.config.js` looks like the one above, and you’re not getting
any errors, you should be able to safely upgrade to Remix v2 by following the [official upgrade guide](https://remix.run/docs/en/main/start/v2).

If you haven’t enabled those future flags yet, then we strongly recommend doing so in the next few weeks so that you
can have a smooth upgrade path in front of you.

Note that the Hydrogen team still needs to officially release support for Remix v2, but thanks to future flags,
most of Hydrogen’s code is already compatible. All you need to do is upgrade the dependency in `package.json`, remove
the future flags in `remix.config.js`, and you should be good to go!

## What’s Next for Remix and Hydrogen?

In our work so far, we found the developer experience offered by Hydrogen through Remix is miles ahead of what we had in
Hydrogen v1. With a few lines of code, it’s possible to develop rich e-commerce experience while also abiding by web
standards and following modern UX practices. Because of that improvement, we’re very excited for the future of this
synergy!

The Remix team recently [announced](https://remix.run/blog/open-development) that they want to be more transparent about
their plans for the framework, but the [public roadmap](https://github.com/orgs/remix-run/projects/5) doesn’t offer a
lot of information yet. That means it’s still early to tell what other features might be coming up that Hydrogen
developers can benefit from.

One initiative on our radar is the [work](https://remix.run/blog/remix-v2#what-about-rsc) done by the Remix team to
integrate React Server Components (RSC). Unfortunately, this will take some more time, as RSC are still unstable and
won’t be included in Remix just yet as a result.

If you were waiting for more features or stability in order to start using Hydrogen, today is the best time to give it a
try! We’re sure you will be pleasantly surprised.

What Does Remix v2 Mean for Shopify Hydrogen Developers?

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.

The Nebulab

Shopify Summer ’24 Edition: Are Things Getting Serious?

What Does Remix v2 Mean for Shopify Hydrogen Developers?

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

Everything You Need to Know About Shopify Hydrogen