/ INTRODUCTION
Over the past four years, we’ve been working on a WordPress project that doesn’t fit the classic headless vs. monolithic dichotomy. We’re talking about a very large e-commerce project. It consists of two online stores that manage three main functions:
- Cart-less sales funnel: products sold come from third-party APIs;
- Targeted landing pages: approximately 30 “Scarcity & Urgency” landing page templates;
- User profile area for managing payment methods and active subscriptions.
Our initial setup consisted of a well-established WordPress theme, an endpoint routing plugin, and about 30 static .php templates for landing pages.
In short: lots of PHP, jQuery, and little flexibility.
/ OUR GOAL
Modernize and ensure continuous delivery, maintaining updates and backward compatibility.
/ METHODOLOGY
We started evaluating React. However, since we didn’t have a solid background with React and knew Vue was growing, we decided to test it with Vue.js. We immediately realized that Vue was faster and more versatile, so we decided to adopt it as the primary tool for all our future work for the client.
/ WHAT WE UNDERSTOOD
Automatic Reactivity and Performance
In Vue.js, reactivity is based on dependency tracking.
When you use ref or reactive, Vue:
- intercepts variable reads;
- records which components use them;
- updates only what depends on that variable.
In React, the philosophy is different.
When a state changes:
- the entire component is reexecuted;
- React diffs the virtual DOM;
- it updates the real DOM.
Less boilerplate: We didn’t worry about manually optimizing performance as much as you would with React; Vue does it for you “under the hood”. We also quickly realized that since we were building small apps, we wouldn’t need a framework capable of handling large enterprise projects.
Documentation and dependencies
One of the historical advantages of Vue is the quality of its official documentation.
Official ecosystem
Vue provides official and integrated solutions for common problems:
- Router: Vue Router;
- State Management: Pinia or Vuex (we used Pinia, and it’s very convenient);
- Tooling: Vite, which is much faster than Webpack (we initially used Webpack, but it was too slow to compile).
In React, we felt like we had to choose between dozens of third-party libraries and hope to find a suitable setup that would be maintainable over time.
Vue Flexibility: Options API vs Composition API
While it may seem more rigid than React, Vue doesn’t impose a single way of writing code.
- Options API: Perfect for beginners or small projects, it organizes the code by “type” (data, methods, computed). The first part of the project related to the Funnel was built with the Options API.
- Composition API: Introduced with Vue 3, it offers the same power and reusability as React Hooks, but without the mental pitfalls of the hook lifecycle. We’re transitioning the entire project to Composition APIs to gain greater control over the codebase.
/ THE CREATION
First of all we decided to leave some parts in the traditional PHP templating flow, while others were pushed towards a headless approach with Vue.
Specifically, we created 3 Vue single page applications (SPAs) mounted inside dedicated .php templates:
- SPA for dynamically managing landing pages. A single .php file manages all necessary landing page types.
- SPA for managing the sales funnel: speed of purchase, tracking, and thank-you pages.
- SPA for the profile area: card management, PayPal, and privacy preferences all in one.
An additional strength is that the three SPAs do not penalize the SEO of the rest of the legacy site in any way. Indeed, we’re talking about an intervention carried out on platforms that have been around for over a decade, and which rank well in the SERPs.
/ BUT THE QUESTION THAT ARISES THEN IS: WHY NOT A COMPLETE REWRITE?
When it comes to headless WordPress, the temptation is always the same: “let’s just redo the whole thing”.
In practice, however, we found ourselves faced with constraints too significant to be ignored.
- the site already had legacy pages and logic that worked;
- the team was well versed in the classic WordPress cycle (template, hook, plugin);
- time and budget did not allow for a complete radical transition.
The philosophy was to gradually introduce Vue where needed. Vue’s introduction didn’t stem from an ideological goal (“we need to be headless”), but from specific needs:
- interactive components that are difficult to manage in pure PHP/jQuery;
- more dynamic UX in high-interaction sections;
- need to better separate presentation and client-side logic.
In practice, Vue entered as an “island” in targeted areas, leaving the rest in the classic WordPress model.
WordPress remains the center for:
- editorial content management and landing page enrichment (daily use of ACF);
- third-party plugin integration (see Yoast for example);
- endpoints and server logic where needed.
VUE takes charge of:
- smoother UX where the traditional theme was rigid to modify;
- dynamic rendering of specific sections;
- richer client-side state.
/ WHAT HAVE WE GAINED?
Progressive migration without architectural downtime: we were able to prioritize the migration, avoiding long blocks and massive rewrites.
Reduced operational risk: leaving stable WordPress flows intact allowed us to reduce regressions in business-critical areas.
Improved user experience in the right places: the areas enhanced with Vue improved reactivity and perceived quality.
/ THE REAL DIFFICULTIES AND WEAK POINTS OF OUR CHOICE.
Double complexity
With two paradigms combined, the focus increases: frontend build, deployment, dependencies, and cross-layer debugging. Furthermore, WordPress was built with React under the hood (see Gutenberg). Vue, on the other hand, works well, but isn’t part of the WordPress ecosystem.
Cognitive cost
New team members need to understand both sides of the project, not just one. Since Vue is less widely used, dedicated KTs are needed for new developers just starting out with Vue.
/ WHEN WE RECOMMEND A HYBRID APPROACH
- it makes sense if you have a WordPress project already in production with real value (the same applies to other CMSs);
- you want to modernize without disrupting your business;
- you need advanced components only in specific areas.
It makes less sense if:
- you want complete layer separation right from the start;
- you can afford a complete rewrite;
- you already have a very mature frontend/headless pipeline.
/ CONCLUSION
This experience has taught us that the most robust solution is often the third way: a hybrid, context-driven architecture. The best migration is not the most radical, but the one the team can sustain over time.
Web Developer, Piksel
