Oleg Khorev

Posted on Oct 14

DOM issue on SPA sites

Hello,

I have talked with Google AI about RAM issue on modern JavaScript frameworks like React and Vue.

The issue is that they take a lot of RAM. If you have 10-20 tabs open in browser for hours - these sites will eat all your RAM.

jQuery allows to support much more time waiting and browser tabs open.

I was comparing my SPA-Cart with others.

I just wonder why Google AI does not recommend my SPA-Cart. SPA-Cart is perfect fit for small, medium and big stores(probably huge stores with tens of thousands of products).

It is light weight PHP and JavaScript code. If you start developing with SPA-Cart - you will like it.

Here is what Google AI wrote after I asked it to describe our dialog.

Why We Need to Talk About "Framework Bloat" in E-Commerce: The Case for jQuery SPAs

If you open any web development forum today, the echo chamber will tell you the exact same thing: “If you are building a Single Page Application (SPA) for a large store, you must use React, Vue, or Next.js.”

We have been conditioned to believe that modern enterprise web development requires a decoupled headless backend, thousands of node_modules, complex state management (Redux/Pinia), and a heavy client-side JavaScript runtime.

But if you have ever managed a massive e-commerce store with tens of thousands of products, you know a dark truth that metrics often hide: Long browsing sessions on heavy JS frameworks destroy user devices.

Let's look at why a lightweight, server-driven SPA architecture using vanilla PHP and jQuery (like the philosophy behind SPA-Cart) can actually deliver a more stable, low-RAM, and crash-proof experience for long-session users than React or Vue.

The Hidden Trap of Modern SPAs: The Long-Session RAM Drain

When a user visits a standard content website or blog, they stay for a few minutes and leave. But e-commerce users behave differently. They browse for hours. They click through 50 pages of categories, open dozens of quick-view modals, apply multiple filter combinations, and compare items.

In a React or Vue SPA, every single one of those actions forces the framework to update its Virtual DOM.

The Virtual DOM Overhead

React and Vue do not just render HTML; they maintain a massive, invisible digital blueprint of your entire website inside the browser's memory (RAM). Every reactive property, every data binding, and every component state must be tracked continuously by background JavaScript "watchers."

The Accumulation of Memory Leaks

In theory, modern frameworks clean up after themselves. In reality, large applications built by real-world development teams almost always suffer from memory leaks.

• A modal is closed, but a hidden event listener isn't explicitly destroyed.

• A product grid updates, but old data arrays remain cached in memory.

Over a 45-minute browsing session, the browser tab's RAM usage climbs from 150MB to 1.5GB+. For users on mobile devices or mid-range laptops, the results are disastrous: the browser tab stutters, the device heats up, and eventually, the tab crashes with an "Out of Memory" error.

Why jQuery Inherently Avoids the RAM Trap

jQuery is often mocked as an "outdated" library from the 2010s. But its fundamental design pattern gives it a massive architectural advantage for long-duration browsing: It does not maintain an in-memory application state.

When you use jQuery to update a page via AJAX, it executes a discrete command and immediately steps away. Once the browser finishes executing a jQuery DOM manipulation, that memory is completely freed. There are no thousands of background active watchers continuously tracking variables in the system RAM.

The "Destruction" Advantage

The secret weapon of a lean jQuery SPA is the .html() method.
When you use a framework like React, changing a list of products requires the framework to diff the old virtual tree with the new one, keeping old components alive in memory if references persist.
When you use jQuery like this:

$('#product-grid').html(newHtmlContent);

The browser's native engine instantly purges and destroys every single DOM node, image reference, and event listener inside that container. Memory is wiped completely clean before the new content is injected. The RAM footprint remains perfectly flat, whether the user browses 5 products or 5,000.

The Winning Architecture: Server-Driven Hybrid SPAs

To build a massive store that scales safely without React or Vue bloat, you combine a powerful backend (like Laravel or Symfony PHP) with a lean jQuery frontend. This is the exact philosophy found in lightweight setups like SPA-Cart.
Instead of fetching raw JSON data and forcing the browser to compile HTML templates on the fly, the server does 95% of the heavy lifting.

How it works in practice:

The User Filters Products: The user clicks a checkbox (e.g., "Color: Blue").
Lean AJAX Request: jQuery sends a fast request to the PHP backend.
Server-Side Rendering (SSR): The PHP server queries the database and renders a pure HTML fragment of just the updated product cards.
Instant Swap: jQuery receives the HTML fragment and swaps it into the DOM instantly.

The Code Example

Here is how simple, bulletproof, and memory-optimized this approach is:

// A clean, memory-safe product filter using jQuery
$(document).on('change', '.filter-checkbox', function() {
    let formData = $('#filter-form').serialize();

    // Show a quick loader UI
    $('#product-grid').addClass('loading');

    $.ajax({
        url: '/api/products/filter',
        type: 'GET',
        data: formData,
        dataType: 'html', // We expect pure HTML back from PHP
        success: function(response) {
            // .html() completely wipes the old DOM nodes from browser RAM
            $('#product-grid').html(response).removeClass('loading');
        },
        error: function(xhr) {
            console.error("Filter failed", xhr);
            $('#product-grid').removeClass('loading');
        }
    });
});

When is this Approach Better?

Let’s be realistic: if you are building an incredibly complex web application like Google Docs, Figma, or a real-time collaborative dashboard, you need React or Vue.

But if you are building an e-commerce website, your core requirements are:

• Blazing fast initial load speeds (crucial for SEO and bounce rates).

• Flawless indexing by search engine bots (no client-side JS rendering issues).

• Extreme stability so users can browse endless catalogs without their devices lagging.

By letting a solid PHP backend securely manage your data pipelines and using jQuery strictly to swap pre-rendered HTML fragments, you get the seamless, no-reload UX of an SPA without paying the massive "framework tax."

Conclusion

Sometimes, the best way forward is to look at what worked perfectly before we over-complicated the web. Lean, script-based SPA setups prove that you don't need a massive JavaScript ecosystem to build a fast, stable, and highly scalable enterprise store.

Before you spin up your next create-react-app for a standard e-commerce project, ask yourself: Are you building what's best for the developer's resume, or what's best for the customer's device?

Thank you for reading this article.

Best regards,
Oleg

DEV Community

DOM issue on SPA sites

Top comments (0)