Skip to content

Why the React model is better than Google Apps Script and WPCode

Overview

This document explains why we migrated the Client Portal from a WPCode snippet (with a Google Apps Script backend) to a React application. The migration has dramatically improved development speed, code quality, and maintainability.

The Problem with WPCode

Our original Client Portal was built as a single WPCode snippet containing approximately 2,200 lines of interleaved HTML, CSS, and JavaScript. While functional, this approach created significant development challenges.

Monolithic Structure

Everything lived in one file:

  • HTML templates
  • CSS styles
  • JavaScript logic
  • State management
  • API calls
  • DOM manipulation

Changing one thing risked breaking something else. There was no way to work on the chart logic without also having the reports table, filters, and all styling in view.

String Escaping Nightmare

Building dynamic HTML required embedding HTML inside JavaScript strings:

html += "<div class=\"metric-card\"><span class=\"metric-label\">" + escapeHtml(label) + "</span></div>";

A single misplaced quote, missing escape character, or unclosed tag would break the entire application. These errors were difficult to spot and debug.

No Separation of Concerns

CSS, HTML templates, state management, API calls, and rendering logic were all jumbled together. Making a styling change meant scrolling through hundreds of lines of unrelated JavaScript.

Limited Tooling

WPCode is essentially a textarea. Errors only appeared at runtime in the browser, often with cryptic messages. There was no syntax highlighting for the mixed content, no auto-completion, and no immediate feedback.

The Problem with Google Apps Script Alone

Google Apps Script can be modular - you can split code across multiple .gs and .html files. However, it still has limitations:

Feature GAS React
File separation ✓ ✓
Component encapsulation ✗ ✓
Reusable components with props ✗ ✓
JSX (no string escaping) ✗ ✓
Hot module replacement ✗ ✓
Local development server ✗ ✓
Clear error messages with line numbers Limited ✓

GAS gives you file organization . React gives you a component model .

In GAS, you could split 2,200 lines into 5-6 files, but you'd still have:

  • Manual DOM manipulation ( document.getElementById , innerHTML = ... )
  • String concatenation for dynamic HTML
  • Shared global state
  • Deploy-to-test workflow

Why React is Better

1. True Modularity

React naturally splits code into focused, single-purpose files:

src/
├── pages/
│   ├── Home.jsx        (~150 lines)
│   ├── Quality.jsx     (~670 lines)
│   ├── Services.jsx    (~50 lines)
│   └── Report.jsx      (~200 lines)
├── components/
│   └── Layout.jsx      (~150 lines)
├── api/
│   └── client.js       (~130 lines)
└── styles/
    └── portal.css      (~1,000 lines)

When editing Quality.jsx, you only think about that file. The chart, filters, and reports table could even be extracted into their own components if the file grows too large.

2. JSX Eliminates String Escaping

Instead of error-prone string concatenation:

// WPCode approach - easy to break
html += "<div class=\"metric-card\"><span class=\"metric-label\">" + escapeHtml(label) + "</span></div>";

React uses JSX - HTML-like syntax directly in JavaScript:

// React approach - clean and safe
<div className="metric-card">
  <span className="metric-label">{label}</span>
</div>

No escaping. No string concatenation. The syntax is validated at build time.

3. Component Encapsulation

Each React component manages its own state and lifecycle:

function MetricCard({ label, value, change }) {
  return (
    <div className="metric-card">
      <span className="metric-label">{label}</span>
      <span className="metric-value">{value}</span>
      {change && <span className="metric-badge">{change}%</span>}
    </div>
  );
}

This component can be reused anywhere, tested in isolation, and modified without affecting other parts of the application.

4. Separation of Concerns

React naturally separates:

  • Structure (JSX in component files)
  • Styling (CSS files)
  • Logic (JavaScript/hooks in component files)
  • Data fetching (API service files)

Each type of code lives in its appropriate place.

5. Superior Tooling

Vite development server provides:

  • Instant hot module replacement (changes appear immediately without refresh)
  • Clear error messages with exact line numbers
  • Fast builds
  • Modern JavaScript support

Developer experience:

  • Work in VS Code with full syntax highlighting
  • Git version control
  • npm package ecosystem
  • Proper debugging tools

Benefits for AI-Assisted Development

When using Claude (or other AI assistants) to help write and modify code, React's structure provides significant advantages:

Faster Editing

Claude's str_replace tool needs to find unique strings to replace. In a 2,200-line monolithic file, similar patterns appear multiple times, causing failed matches and retries.

In smaller, focused files (300-700 lines), patterns are more distinct. First attempts usually succeed.

Better Accuracy

  • No string escaping errors to introduce
  • Component boundaries prevent unintended side effects
  • Clear file structure makes it obvious where changes should go

Easier Context

Claude can read a single 670-line Quality.jsx file and understand the full context. Reading a 2,200-line file with mixed concerns is harder to reason about.

Benefits for Human Developers

Faster Development Cycle

Task WPCode React
See a change Save → Deploy → Refresh → Navigate Save (auto-refreshes)
Find a bug Check browser console, guess location Error shows exact file and line
Test one component Load entire app Can isolate component
Revert a mistake Manually undo or restore from memory Git revert

Reduced Cognitive Load

  • Work on one small file at a time
  • Don't need to hold 2,200 lines in your head
  • Clear file names tell you where to look

Maintainability

  • New developers can understand the structure quickly
  • Components can be updated or replaced independently
  • CSS changes don't risk breaking JavaScript

Scalability

If Quality.jsx grows too large, extract components:

src/pages/Quality/
├── index.jsx           (main page)
├── QualityChart.jsx    (chart component)
├── ReportsTable.jsx    (reports list)
├── FilterBar.jsx       (site/period filters)
└── MetricsGrid.jsx     (analytics cards)

The WPCode approach couldn't scale - it would just become a longer, more unwieldy single file.

Summary

Aspect WPCode GAS React
Code organization Single file Multiple files Component-based
Dynamic HTML String concatenation String concatenation JSX
State management Global variables Global variables Component state
Development feedback Runtime only Deploy then test Instant hot reload
Error messages Browser console Browser console Build-time + line numbers
Version control Manual Possible but awkward Native Git workflow
AI editing speed Slow (large file, duplicates) Medium Fast
AI editing accuracy Low (string escaping) Medium High

Bottom line: React provides a proper development environment with modern tooling, while WPCode was essentially a workaround that became unsustainable as the application grew in complexity.