The Vue proposal of Shopware

Where Shopware uses Vue

Shopware its Administration is first of all based on Vue. The entire backend panel is headless, served by the Admin API (and its little brother, the Bulk API). This headless approach could theoretically mean that you can create your own React backend, if you don't like Vue. Practically, the Vue application is so rich and full of features that it will be stupid to try to replace it.

The Vue story does not stop there: For the frontend part, we can choose between the traditional Twig frontend (which uses Bootstrap, jQuery but not Vue) and a headless frontend like Shopware PWA. Shopware PWA is based on Vue Storefront 2, which is based on Nuxt, which is based on Vue. So, Vue.

So far for the offerings of Shopware itself. But with the rise of new SaaS services, backed up by apps that one would install in Shopware (public apps or since recent also private apps), you could also base a SaaS on ... whatever. And that includes also using PHP applications like Laravel or Symfony and JS tools like Vue. Or one of the many other frontend / backend solutions out there. The choice is yours.

But if you are a fan, you could offer an entire stack of Vue: Vue in the Shopware Administration, Vue with the Shopware PWA, Vue in your connected SaaS solutions. Kind of my point.

What is the CSS strategy?

While picking a JavaScript framework (like Vue) is quite opinionated, choosing a CSS framework is hugely opinionated - as in, everyone seems to have her/his own opinion and it is tough to make a choice that keeps everyone happy. Shopware has chosen Bootstrap for its Twig-based frontend (not Vue) but also for its Administration (Vue). In the near future, Bootstrap 4 will be upgradeable to 5, but this could be a huge undertaking.

Swapping out Bootstrap with something else (like Björn Meyer did with Tailwind) is an even bigger job. It is not only the CSS that you need to worry about, but the HTML as well. And with either Twig templates or Vue components, that HTML is spread across numerous files. It basically points to the fact that if a certain larger software program (Shopware) is tightly connected to a specific technology (Vue, Bootstrap), it will only be possible to rewrite this to something else if you have (A) plenty of time and (B) a larger group of developers (or a community) that wants this rewrite as well. It simply is a lot of work.

Upgrading to Vue 3

Another limitation of the fixed choice is Vue itself: Currently, Shopware PWA, the Shopware Administration, Vue Storefront 2 - they all rely upon Vue 2. Version 3 has been out some time, with some exciting new features like a faster compiler and the composition API. Funnily enough, the composition API is also available in Vue 2 through a plugin (which is again included in Shopware PWA and VSF2). Still, upgrading to Vue 3 could bring some performance improvements. So what about that upgrade?

It is a bit more cumbersome than just upgrading the Vue core. The bootstrap of the app itself needs changing, third party frameworks & libraries like NuxtJS would need support. And theoretically the benefits only kick in when all components are rewritten to composable components. My point is not that Vue 3 is better than Vue 2, my point is mainly that part of the stack of Shopware currently uses Vue 2 and that might seem like a lock-in.

How weird is the Shopware Administration!

One more part to cover: Shopware its Administration is also based on Vue. But it is not the Vue stack that most Vue developers will be familiar with. There are no Single File Components (by default). There are Twig templates used for the HTML part (by default). Components are registered globally (by default). And logic is mostly offered through dedicated service classes instead of composables. But that's the default, you can add SFC support, replace Twig, use local components and add composables.

It is only that by default the choices of Shopware are made in certain way. It is not bad, it is just opinionated.

Accepting the offer

In short, Shopware offers Vue in a lot of different combinations. And most of these combinations are opinionated. You might like it. You might dislike it and accept it anyway. You might dislike it and drop it. But don't blame Shopware for making changes. And to add an opinion of my own, React is more difficult to learn than Vue, so maybe Shopware has made a wise choice here anyway.

Still, I can understand it if you don't want to accept this offer, for reasons. But is the choice fixed? The Vue app used in the Shopware Administration is driven by an Admin API, which allows you to write your own SPA instead. The Shopware PWA (VSF2) is just an example of a headless frontend based on the Store API. And with the new App system, attaching remote SaaS pages is peanuts - and you base them on whatever.

The choice of Shopware for Vue (and Bootstrap and many other technologies) is opinionated. But thanks to them sticking to that choice, they have been able to build an exciting backend, frontend and remote architecture, where you can easily hook into. And if you embrace Vue, their proposal is awesome.