Stop Building SPAs for E-Commerce. Try This Instead.

You’ve probably noticed something strange happening in the Shopify ecosystem lately. Developers are reaching for .liquid templates — the same server-rendered, logic-less templating language that powered e-commerce stores a decade ago. And they’re not doing it out of nostalgia. They’re doing it because modern JavaScript frameworks have been quietly strangling their projects.

Every over-engineered frontend is a tax on the end user, and the bill always comes due.

Here’s the uncomfortable truth nobody in the frontend community wants to admit: Single Page Applications were never designed for e-commerce. They were designed for app-like experiences — dashboards, editors, real-time collaboration tools. But somewhere along the way, the industry convinced itself that every product page, every cart, every checkout flow needed a reactive client-side framework with 400KB of JavaScript shipped to the browser just to render a button.

The results were predictable. Bloated bundle sizes tanked performance scores. SEO suffered because crawlers couldn’t parse client-rendered content properly. Maintenance costs exploded as teams wrestled with state management libraries, build pipelines, hydration mismatches, and the endless churn of framework updates. Developers spent more time fighting their tooling than building features.

And then someone looked at a Liquid template and realized: this just… works.

The server renders the HTML. The browser receives it. The page loads fast. SEO works. The code is simple enough that a new developer can understand it in an afternoon. There’s no virtual DOM, no dependency tree from hell, no build step that takes four minutes. There’s just a template that outputs HTML.

We didn’t need a revolution in frontend complexity. We needed to remember that most pages are just pages.

This isn’t anti-progress. Reactive frameworks have their place — and it’s a specific place. If you’re building Figma, build a SPA. If you’re building Google Sheets, build a SPA. If you’re rendering a product listing page with a title, an image, a price, and an add-to-cart button, you don’t need React. You don’t need Vue. You don’t need hydration or server-side rendering that tries to pretend it’s a SPA while also pretending it’s not.

You need a template. A server. And HTML.

The return of Liquid on Shopify signals something bigger than one platform’s technology choice. It’s a pragmatic rebellion against the assumption that newer always means better. Developers are waking up to the real-world costs of complexity — the SEO penalties, the performance regressions, the bundle bloat, the onboarding friction. They’re rediscovering that logic-less, server-rendered templates solve 80% of e-commerce use cases with 10% of the overhead.

The most dangerous phrase in software engineering is ‘we might need this later.’ Most of the time, you won’t — and you’ll pay for it every single day until you do.

For Shopify merchants, this matters directly. Faster pages mean better conversion rates. Cleaner code means cheaper maintenance. Simpler architecture means your next developer doesn’t need three weeks to understand your build system before they can change a button color. The technology choices that seem invisible to the business side are the ones that quietly determine whether your project survives its second year.

So the next time someone suggests rebuilding your storefront in the hottest new framework, ask one question: what problem does this actually solve? If the answer is ‘developer experience’ and the cost is ‘user experience,’ you already know what to do.

Go back to the future. Your customers — and your future self — will thank you.