Trading PHP for TypeScript: what a decade of WordPress taught me about React

After more than a decade shipping WordPress and WooCommerce platforms, I moved into building products on TypeScript, React, Next.js, and Python. The stack looked like a clean break. The thinking turned out to be almost entirely portable, which is the part people underrate when they see “WordPress” on a résumé.

Components were never a React idea

WordPress teaches you to build in reusable pieces early: template parts, and later ACF-driven Gutenberg blocks, a fixed library of components an editor composes freely. A block that takes structured fields and renders a bounded piece of UI is a React component with the serializer swapped out:

// A Gutenberg block: props in, bounded markup out.
function render_stat_block( $attrs ) {
    return sprintf( '<div class="stat"><b>%s</b> %s</div>',
        esc_html( $attrs['value'] ), esc_html( $attrs['label'] ) );
}

// The same shape, typed.
function Stat({ value, label }: { value: string; label: string }) {
  return <div className="stat"><b>{value}</b> {label}</div>;
}

Same instinct: props in, bounded markup out. TypeScript just made the contract explicit instead of a comment I had to hope people read.

The type system replaced a habit I already had

I spent years defensively validating $_POST, coercing meta values, and guarding against a field that might be a string, an array, or nothing at all. TypeScript turns that hard-won paranoia into something the compiler enforces for me. It did not teach me to distrust untyped data; it just moved the check from runtime prayer to compile time.

What actually changed

The genuinely new muscles were the async model, a client rendering against state that arrives later, instead of a page assembled on the server and shipped whole, and owning the build and deploy pipeline directly rather than inheriting WordPress’s. Real learning, but weeks of it, not years.

The part that never changes

Data modeling, drawing sensible boundaries, keeping trade-offs legible to non-engineers, shipping something clickable every week: none of that is stack-specific. A decade of WordPress was a decade of practicing exactly those things under real client pressure.

If you are weighing a candidate whose history is “the wrong framework,” look at what they actually did with it. Frameworks are the easy thing to relearn.