Shopify

Headless is hip - but why deSaaS Shopify? by Linda Bleijenberg

 

This blog was written in 2020, would you like to hear our current view on Headless? Read our latest blog about Headless Commerce on Shopify with HydrogenHeadless: what is it, what does it do, and why don’t we believe the hype at Code? Our CEO Wouter will tell you why in this blog! It’s a lengthy one, but worth the read – so take your time.

Code - Why we don't believe the Headless Hype
Code - Why we don't believe the Headless Hype

You’ve probably heard the term around already, because headless is very hip & happening at the moment. What is it exactly? Briefly summarized, ‘going headless’ means to cut off the storefront bit of your platform – in our case Shopify – and only use its back office. Next, you replace the missing storefront with something you built in-house.

You’re probably thinking: why would you do that? Well, there is something to say for it, because headless sites are superfast. But there are also some heavy downsides, the biggest of them being the enormous investment in cost and effort. You can read more about that in the second half of this article.

Headless = high loading speed

One of the biggest advantages of headless is the speed with which pages load. Headless sites only load what is necessary to show you a new page. Most of the time this is very little and the page loads in a split second. This offers possibilities to make your site heavier and more complex, for instance with animations. Practical sidenote: this sounds attractive, until you realize that returning visitors find these animations annoying

because– the irony – they slow down the user experience. That’s not why you built a superfast, superexpensive headless site, obviously. Besides, we're past the time that headless is the only way to achieve a superfast site. With Shopify's Online Store 2.0, The Site Speed is optimized significantly; 90+ page speed rankings on mobile and desktop are no exception.

Localization with headless: the pros and cons

Headless is also used to solve a known imperfection of the Shopify storefront: the lack of native multi-language support, which of course is a thing for European merchants. These merchants usually resort to a multistore setup, with which they have a separate store for every country they sell to. With headless you dó have the opportunity to provide multiple languages from a single storefront, because you do your content management outside of Shopify – usually in an external CMS and possibly a Product Information Manager (PIM).

At Code we have to add some critical comments to this approach, though. Headless works fine in case of straightforward translation, but in reality you need a bit more than that. Because different countries not only have different languages, but also different customs – ask any Dutch merchant who also sells to Germany, for instance. One-size-fits-all just doesn’t cut it: your site needs to be localized, not simply translated. ‘Localize, don’t internationalize’ is your motto here.

Every region its own store, or all-in-one?

Localizing your store from a single storefront is a pretty complex undertaking. Sure, you can manage all your content from a single dashboard, but there are so many extra customizations per region to add that it will become a supercomplicated whole. In addition to all translations (pages, blogs, menus, labels, tags and microcopy) you will also have to put regional variations in the code somewhere.

And then we didn’t even talk about things like locally targeted marketing campaigns, local payment methods, a regional product range, and local quality certifications yet. These are all much easier to implement in a multistore setup than in a single multiregion shop. Hence, we think it’s smarter to built multiple simple stores that, combined, can do everything, than one very complex store to do it all. That way you can serve each local market from its own environment, without losing overview.

A multistore setup is also what Shopify (and Shopify partner tools such as Klaviyo, Loyalty Lion, PIMs) assumes while further developing their platform. Hence, they invest in features that make it easier to manage a multistore setup, such as multistore analytics dashboards, multistore staff management, multistore flow management and the ability to quickly clone an existing store.

We at Code know from experience that multiple relatively simple stores are easier to manage than one supercomplex store stuffed with expensive ‘business logic’ needed to adapt the site on the fly to the visitor’s location. You don’t need to go headless for that.

The disadvantages of headless: heavy on costs and development

OK, so headless is superfast, and depending on your situation and preferences it could maybe solve your multilanguage issue. What, then, are the disadvantages? By far the most important: the cost of headless architectures.

Wouter explains why headless – the way it is done now – is such a tremendously costly affair. “With headless, what you are actually doing is this: you cut off one half of Shopify, and then remodel this half yourself, with some extra features that Shopify doesn’t have (yet). That immediately presents you with two problems: it costs a ton of money to develop, and you’re forced to maintain it for years to come!” Which again costs a ton of money. Plus: you will always need developers. And that’s where you run a serious risk to find yourself in an old-fashioned vendor lock-in, where you are stuck with your developer agency and have to turn to them for every adjustment. You don’t want that, obviously!

Such a situation is particularly galling when you see other Shopify merchants operate on almost the same (multi-)storefront, without having to pay tons extra, and with the maintenance smoothly taken care of by Shopify. OK, you might not have the extreme performance and flexibility of headless, but these merchants can turn to a whole box of relatively inexpensive solutions to achieve pretty much the same result. As an agency, a vendor lock-in is hard to explain in these cases.

At Code we therefore prefer to stay close to our tool. Replacing half of your platform with something that is strikingly similar clearly does not suit that philosophy at all. On the contrary, we always try to build as ‘native’ as possible, stay as close to Shopify as is possible, and solve things in such a way as to make them automatically move along with Shopify. That way you get the maximum out of Shopify, we think, and it is the surest way to stay future-proof.

Why deSaaS Shopify?

It also stays close to the SaaS philosophy: software as a service. Wouter: “With headless you’re sort of deSaaSing Shopify.” You leave aside a big chunk of Shopify, duplicate it, and make the duplicate an in-house system.

This is particularly absurd if you just migrated from an open source platform to Shopify. With headless, you’re again confronted with the issues that you didn’t like about open source platforms such as Magento in the first place: your store is way too complex and therefore fragile; you bear full responsibility when something goes wrong; you depend on developers for everything; and you’re constantly striving to keep up with the high-speed-train that is Shopify – every new feature or improvement from Shopify means you have to catch up to stay close. 

Only they have got a huge army of developers to do this, while you only have a single agency (and probably a much more modest budget). And that's not all: with a headless Shopify setup everything becomes more complex. For instance, most headless setups don’t have a template editor, or only a very limited one, which means you will need developers for even the smallest adjustments. Many of the apps in the Shopify App Store can’t be installed in the usual way anymore: most of these apps weren’t made with headless stores in mind, and you might not even be able to use them at all. What’s more, all apps that are visible in the shop, such as a review app, will have to be integrated by a developer. And if the app-builder changes the app’s integration, that same developer will have to get to work to get the app working again.

Do you really need a Ferrari?

Is all this worth it, for what it brings you? And aren’t there better, cheaper solutions available? Do you really need a Ferrari? Yes, you will get extreme performance, but you will pay a high price for purchase and maintenance, and you really need to know how to drive. If you are ready to invest in a thorough preparation and an extensive development project, this might be the solution for you. But remember the pros need to outweigh the cost, time and effort.

To sum up, for Code the whole headless approach feels like an illogical ruse. You chose Shopify because you wanted ease of use (and maybe also because you have an open-source trauma), and then you throw all that overboard again by going headless? That is a pretty hefty pricetag for fast loading speeds and everything-in-one-place.

Wouter: “People sometimes turn to automation too soon, when you often have more freedom without. What you win in time with automating things frequently gets exaggerated, too: does all this complexity justify the few working hours you save every month? Let me use an example. Do you know these old Russian MiGs? Brilliant military aircrafts. I saw a picture once of a MiG cockpit: the handles all completely worn down by use, but they still worked. That’s what you need: simple, elegant, robust designs. If something takes too much effort to keep it in the air, it’s too fragile. Every system will inevitably gravitate towards the point of least energy, and there it will remain. If you try to force something with all kinds of contrivances, it will for sure start creaking and groaning.”

Developer’s dream

We do realize that this is a perspective on headless you don’t hear too often. That is because there’s a third reason for the headless hype: developers are totally smitten with it and a number of agencies are pushing it as a solution for everything. Headless is the newest gadget, and for developers the technology of headless sites is much more interesting to work with than Shopify’s template engine. Hence, they will be quick to say that headless is better: they’re eager to work with it. And at Code we understand this perfectly! We too are developers after all! But we also have to take into consideration whom we are doing this for, in the end. Does it benefit our clients?

While Headless has some downsides, it also is a superfast and efficient architecture. It is to be expected Headless is very likely to be the future, and that Shopify will follow.

At the time of this interview, Wouter could very well see that happen: “Ideally, Shopify will release its own headless framework with a multistore architecture, to enable easy content localization. That way the disadvantages disappear: Shopify would build and maintain the codebase, which would allow you to keep all the SaaS benefits and avoid vendor lock-in. Shopify would also offer the tools to easily set up and manage these headless stores, the way they do now with their current template editor.”

During Shopify Unite in June 2021, the announcement was finally there: we got a preview of Hydrogen, Shopify's upcoming headless commerce solution. It’s still early days for Hydrogen. Sign up here for updates as they evolve.

 

Our advice

Headless will probably remain the coolest new kid in town for a while. But we at Code believe that anything worth doing, is worth doing right. Our advice, in a nutshell? Stick with the SaaS philosophy and wait until Shopify goes headless.

Linda Bleijenberg
Written by

Linda Bleijenberg

Code easily writes 100 lines of code every day, but a blog is a different story! So we leave that to Linda Bleijenberg, our copywriter. She lives around the corner in Delft and wants to be an IT wizard when she grows up. Until then, she interviews our experts and shares our most interesting insights about Shopify and E-Commerce on our blog.

Back to insights overview