Shopware PWA - an honest assessment

Disclaimer: In my position as project lead at Shopware for our Shopware PWA project in cooperation with Vue Storefront I consider myself a huge ambassador of PWA, I’ve been giving multiple talks on that subject and yet we’re just starting to explore the true potential of this technology. This post does put PWA into perspective and can be misunderstood as bashing against it - that is not my intention. Quite the contrary, I wish to educate people and shape the future of PWA and part of that is to state what PWA is NOT (yet). If you are interested in the possibilities of Shopware PWA, feel free to approach me.

At the current stage, I've come across multiple misconceptions about Shopware PWA that may decide upon failure or success for agencies, projects and sometimes entire companies. I've written this article to get to the bottom of these misconceptions and try to resolve them in order to enable a clearer, more informed decision-making.

In the following, I will outline multiple definitions of what PWA means which are all used by different people. These definitions sometimes contradict and lead to a lot of confusion and certainly wrong expectations for projects. Let me start with the text-book definition of PWA:

The Original PWA

Originally, the term PWA was coined by a Google engineer, proposing some changes to traditional web applications using so-called progressive web features. These features were supported by modern browsers which included service workers, local caching, installation support, notifications. These "enhancements" can be added to the application to increase its functionality. However, it's always ensured that the application still works on older browsers - hence progressive. Nothing more and nothing less.

In many respects it remains a classical website. If you supercharge a PHP-based, server-side rendered web app with these progressive features, it technically becomes a PWA.

The Hype PWA

At some point, the idea of PWA enjoyed increasing popularity amongst folks who didn't understand the underlying concepts like service workers or installation support and carried the meaning of the word "PWA" towards the holy grail of web applications. It became equivalent with "mobile optimised", "high performance", "huge SEO improvement" and "headless" (which is an entirely different misunderstanding one could write a blog post on). Unfortunately, and we as developers are also guilty of that - this misunderstanding created so much buzz, that we (tech people) started to adopt the word - to describe something completely different again. And that's where things got messy - because as you will read below - it is not about the tech at all.

The Tech PWA

Describing the "thing" denoted by PWA in a technical sense (and in the sense that we use it in Shopware PWA) is actually way easier when you ask merchants a question:

What are your challenges in engaging with your customers and how do you intend to solve them?

If their answers are

• I feel like my SEO performance is bad
• The mobile experience can be enhanced by providing offline functionality
• I think notifications will allow me to improve customer retention

Shopware PWA is not their solution.

What they need instead are some tweaks and features on top of a normal storefront, but NOT an entirely different software stack. If these are your only challenges, PWA will only increase the complexity of your project.

If, however, their answers are amongst the following (and since most merchants are still coping with the challenges above, it occurs more rarely):

• My brand differentiates through interactive customer experiences
• The current store(front) limits our pace and our scope of customer interaction
• I would like my customer experience to be more dynamic and personalized
• I will potentially integrate multiple services for content, search, personalization and checkout
• I am NOT looking for a shop that looks like any other online shop - PDP, PLP, search, cart, login

Then, Shopware PWA will get you a leap in front of your competition. The technology is not the reason for you to choose PWA, rather it enables you to be better and faster in doing anything of the above.

And it is especially not about your backend. Whenever you ask “does Shopware PWA support feature XY of my backend”, think about why you chose to go with it in the first place. You will find that the reasons to go with such a project become fewer.

However, if you're looking for quick prototyping, innovation or an individual CX (I'm not referring to some parallax banners and a nicely animated product slider), then building upon Shopware PWA will give you the ultimate competitive advantage.

The Real World

In the real world, I see a lot of projects intending to use Shopware PWA out of motivation based on the requirements listed under The Hype PWA. This concerns me a lot because they're being fooled (more often fooling themselves) in a major way. And you cannot even blame them for it because for all the questions listed under The Hype PWA, the answer is "you can also do it with Shopware PWA". But if you ask - "do I have to use Shopware PWA to do it?" - the answer is probably "no". Shopware PWA is becoming the Hype PWA, the great fairytale of solving all merchant problems.

Agencies without major experience in frameworks like Vue.js, NPM, Node.js or Nuxt.js are trying to cross the ocean, expecting everything to work like it did in the good old times of plugins, templates, twig blocks and other benefits of the single-stack age. They have to swim all the way, ignoring the cruise ship nearby taking them almost all the way, apart from a few Jet-Skis they have to buy themselves.

You could continue the metaphor, but it gets a little bit loose. Let's say you wanna cross the pond in style and you have a couple of gifted craftspeople at hand. You'll have to do more work by yourselves, but will be able to build a plane, a hovercraft or a rocket, depending on your needs. Within that picture, Shopware PWA are the craftspeople, the tools and a set of blueprints at your hand that allow you to realize that project.

A couple of positive examples back that. Agencies, especially ones with focus on frontend development are successfully leveraging parts of Shopware PWA to build websites looking totally different from normal online stores. They appreciate the amount of functionalities built into that allow them to interact with the Shopware API, but they tend to override a lot of the UI layer built on top of the application or not bother using it at all.

Conclusion

In my opinion, Shopware PWA is an opener for the API-first age, helping you to fully leverage Shopware's headless capabilities. It requires a different approach. It requires different thinking. And it requires a certain business model. Stop and ponder before you follow the hype.

We are providing Shopware PWA with an interface that allows for a standard eCommerce project. Don't expect it to be the first choice for those. It starts to excel when the standard is not what you want.