DEV Community: Jeff Go

Continuing on my previous thoughts regarding The WordPress Paradox, this article dives now into how to leverage WP native tools just inside functions.php to bypass the traditional monolithic rendering engine entirely, enabling REST API endpoints.

Jeff Go — Mon, 01 Jun 2026 23:42:27 +0000

Jeff Go

Jun 1

Going Headless From the Inside Out: Native WordPress API Customization

#webdev #wordpress #restapi #pwa

2 min read

Going Headless From the Inside Out: Native WordPress API Customization

Jeff Go — Mon, 01 Jun 2026 06:26:39 +0000

In my previous writing on The WordPress Paradox, I explored the deep-seated tension between the platform’s unmatched content editing experience and the performance bottlenecks of its monolithic rendering pipeline. Engineering teams frequently reach a frustrating crossroads: accept sluggish monolithic themes, or adopt bulky, third-party Headless CMS plugins that introduce security risks and configuration bloat.But if we look past the plugin marketplace, WordPress already has the native architecture required to solve its own paradox. By utilizing register_rest_route directly inside your functions.php file, you can bypass the template engine entirely and expose lightweight, type-safe data endpoints tailored for a modern frontend like React.js. Here is how to build a native micro-API endpoint and consume it efficiently.

Step 1: Exposing the Native Endpoint (`functions.php`)

Instead of fetching massive, deeply nested JSON payloads from the default WordPress REST API, we can register a custom route that returns only the specific fieldsets our modern frontend actually requires.

<?php
// Hook into the native WordPress REST API initialization
add_action('rest_api_init', function () {
    register_rest_route('modern-api/v1', '/custom-posts/', array(
        'methods'  => 'GET',
        'callback' => 'get_minimized_custom_posts',
        'permission_callback' => '__return_true', // Adjust for secure infrastructure
    ));
});

// Callback function to fetch and trim the database payload
function get_minimized_custom_posts($data) {
    $args = array(
        'post_type'      => 'post',
        'posts_per_page' => 10,
    );

    $posts = get_posts($args);
    $response = array();

    // Map only critical fieldsets to eliminate database and network bloat
    foreach ($posts as $post) {
        $response[] = array(
            'id'    => $post->ID,
            'title' => get_the_title($post->ID),
            'slug'  => $post->post_name,
            'value' => get_post_meta($post->ID, 'custom_metric_value', true),
        );
    }

    return new WP_REST_Response($response, 200);
}

By filtering the payload down to the bare essentials at the server level, you drastically reduce response times and memory overhead.

Step 2: Consuming the Micro-API on the Frontend

On the frontend, whether you are building a decoupled React layout or fetching data inside a React component, you can consume this native endpoint cleanly without navigating complex, nested plugin data models.

// Fetching the minimized native WP data structure
interface CustomPost {
  id: number;
  title: string;
  slug: string;
  value: string;
}

async function getModernWPData(): Promise<CustomPost[]> {
  const res = await fetch('https://your-wp-site.local/wp-json/modern-api/v1/custom-posts/');

  if (!res.ok) {
    throw new Error('Failed to fetch optimized legacy data');
  }

  return res.json();
}

Shifting Value Upstream

This hybrid approach bridges the gap outlined in the WordPress Paradox. You don't have to rip out the entire backend infrastructure overnight. By turning WordPress into a lightweight data engine from the inside out, you retain a familiar authoring environment for content teams while unlocking the extreme velocity, type safety, and architectural freedom of a decoupled frontend ecosystem

The value in software engineering has officially shifted upstream. Typing code is becoming cheap and instant. The new bottleneck isn't syntax—it's architecture, context, and security.

Jeff Go — Wed, 27 May 2026 05:29:17 +0000

Jeff Go

May 27

AI Agents Aren’t Replacing You, But the Dev Who Steers Them Is

#ai #programming #productivity #automation

3 min read

AI Agents Aren’t Replacing You, But the Dev Who Steers Them Is

Jeff Go — Wed, 27 May 2026 05:28:11 +0000

There is a lot of anxiety in the tech community right now about AI taking software engineering jobs. If your entire identity as a developer is tied to how fast you can type out standard boilerplate or memorize framework syntax, then yes—you should probably be worried.

But if you look past the hype, something else is happening. Raw code generation is becoming cheap and instant.

The bottleneck in software engineering is no longer typing code. The bottleneck is architecture, security, and context.

AI agents aren't replacing developers. They are turning senior engineers into one-man engineering squads. The value has completely shifted from writing lines of code to steering the agent.

Shifting from Coder to Conductor

In my daily workflow, I use Cursor as my primary editor. I don’t use it to think for me; I use its AI features—especially Composer—to handle the heavy lifting.

If I need to spin up a new service wrapper, write a comprehensive unit test suite covering twenty edge cases, or refactor an older component to match a new TypeScript interface, I offload it to Cursor. What used to take two hours of mundane typing now takes two minutes.

This doesn't mean my job got easier. It means my job shifted upstream.

Instead of getting bogged down in syntax errors, my brain power is entirely focused on big-picture engineering:

Is this the right data model for our long-term scaling needs?
How will this new module affect our CI/CD deployment pipeline?
Are we introducing hidden security risks or breaking latency budgets?

The "Human-in-the-Loop" Rules of Engagement

If you blindly copy-paste whatever an AI agent outputs, you aren't a senior engineer—you’re a liability. To actually build stable software with AI, you have to maintain absolute authority over the codebase.

Here is how to steer agents safely without introducing massive technical debt:

Be Specific with Context: An agent is only as good as the guardrails you give it. Feed it your strict project typings, your linting rules, and explicit architectural boundaries before you let it touch a file.
Treat AI Code Like an Intern’s PR: Never commit AI code blindly. Treat every block of generated code as if it was written by a junior developer who works fast but doesn't fully understand the business logic. Review every line, check the security implications, and verify the edge cases.
Use AI for Velocity, Not Navigation: You decide where the ship is going; let the AI do the rowing. Use it to eliminate boilerplate, generate scaffolding, and hunt down bugs, but never let it make major architectural bets for your platform.

The New Market Reality

The software market has fundamentally changed. The developers who resist AI out of pride are going to get left behind, not because the AI is smarter, but because they are choosing to build with a shovel while others are using an excavator.

The future belongs to the engineers who can take a complex, ambiguous business problem, break it down into clean architectural requirements, and steer an array of AI agents to build, test, and ship it at breakneck speed.

Stop worrying about whether AI will take your job. Start figuring out how to use it to do the work of a three-person team by yourself.

The Web is just getting better nowadays. Google I/O just announced the HTML-in-Canvas API, and it's going to completely change how we build interactive web apps!

Jeff Go — Mon, 25 May 2026 04:28:09 +0000

Jeff Go

May 25

HTML-in-Canvas: The Wild New API from Google I/O (and How Not to Break the Browser)

#webdev #frontend #html #api

3 min read

Google I/O just announced the HTML-in-Canvas API, and it's going to completely change how we build interactive web apps!

Jeff Go — Mon, 25 May 2026 04:27:28 +0000

Jeff Go

May 25

HTML-in-Canvas: The Wild New API from Google I/O (and How Not to Break the Browser)

#webdev #frontend #html #api

3 min read

HTML-in-Canvas: The Wild New API from Google I/O (and How Not to Break the Browser)

Jeff Go — Mon, 25 May 2026 04:10:10 +0000

Google I/O just dropped an absolute bomb of an API for frontend developers: HTML-in-Canvas.

If you’ve ever built immersive 3D web experiences, map tools, or heavy data dashboards using WebGL or WebGPU, you know the absolute nightmare of rendering UI text or buttons on top of a canvas. You either had to sync floating, absolute-positioned HTML elements on top of the canvas (which lagged during fast scrolls), or draw text manually using WebGL textures (which killed SEO and accessibility).

The new HTML-in-Canvas API fixes this by introducing three new primitives—like the layoutsubtree attribute and textElementImage2D()—allowing you to put real, styleable HTML elements directly inside a canvas. The browser feeds it straight into the GPU as a texture, but keeps it part of the normal DOM layout and accessibility tree.

Because it’s an active origin trial, the wild west rules apply. Here are the practical Do's and Don'ts for this new playground.

👑 The DO's

DO use it for complex data visualizations and 3D UI: This is the ultimate sweet spot. If you are building high-frequency data dashboards or immersive spatial sites, you can now build your menus, form controls, and text overlays in standard HTML/CSS and let the GPU layer them directly over your canvas without a hint of frame lag.
DO keep accessibility in mind: Because the elements inside the canvas are real DOM nodes, screen readers can finally read your canvas text, and browser translate features actually work on it natively. Make sure you use semantic HTML (<button>, <input>, etc.) inside your canvas subtree so the accessibility tree populates correctly.
DO use CSS for layout: You don't have to write custom JavaScript positioning math anymore. You can apply standard CSS styling to children within the layoutsubtree. Let the browser engine calculate the bounds, then use the onpaint hook to upload the fresh layout changes to your WebGL/WebGPU shaders.

🚫 The DON'Ts

DON'T dump your whole app into a canvas: Just because you can render HTML in a canvas doesn’t mean your entire landing page belongs in one. Canvas-heavy rendering consumes significantly more battery and GPU resources. Use it strictly for high-fidelity interactive sections, not standard text articles.
DON'T update the inner HTML 60 times a second: The API relies on a .onpaint event to upload changes as a GPU texture. If you are blasting text modifications or CSS transitions inside the canvas subtree on every single frame, you will bottleneck the main thread with heavy texture re-uploads. Keep the static UI inside the canvas, and use WebGL shaders for the crazy animations.
DON'T ship this to production blindly yet: It’s an origin trial. It currently requires a flag in Chrome Canary and isn't a baseline standard across Safari or Firefox yet. Use this phase to build prototypes, learn the architecture, and write feedback for the WICG proposal while the API matures.

The Verdict

The web is getting fun again. HTML-in-Canvas breaks down the wall between traditional document layouts and hardware-accelerated creative engineering. It’s going to completely change how we build tools, dashboards, and spatial interfaces over the next few years.

Are you planning to test out the origin trial? What wild UI ideas are you thinking of throwing into a shader? Let’s chat shop in the comments.

sometimes Wordpress frustrates me, but hey, it is here to stay. here's what we as devs can do about it

Jeff Go — Sat, 23 May 2026 12:06:15 +0000

Jeff Go

May 23

The WordPress Paradox: Why It’s Here to Stay (and How to Stop Ruining It)

#webdev #wordpress

3 min read

The WordPress Paradox: Why It’s Here to Stay (and How to Stop Ruining It)

Jeff Go — Sat, 23 May 2026 11:21:47 +0000

Let’s be honest. If you are fluent in React, TypeScript, and modern backend architectures, working on WordPress feels like taking a massive step backward. For years, developers have been predicting its death, claiming modern stacks would completely wipe it out.

But it’s 2026, and WordPress still powers over 40% of the internet. It isn't going anywhere.

As developers, we have two choices: we can keep complaining about it, or we can understand why businesses love it and learn how to engineer it properly.

The Real Problem: Plugin Abuse

WordPress gets a bad reputation, but the fault usually lies with the people building it. Too many developers (and clients) treat the plugin directory like a candy store.

Need a Google Analytics tag? Install a plugin. Need a basic contact form? Install a plugin. Need to compress an image? Install another one.

Before you know it, the site is running 40+ heavy plugins. They constantly fight for database resources, conflict with each other during updates, create massive security vulnerabilities, and turn the user experience into a slow, bloated mess.

Why Clients Won't Move On

We love our frameworks, but clients care about business outcomes, not our tech stacks. WordPress wins because of two things:

The Non-Technical Content Editor: Marketing teams know how to use the dashboard. They want to fix a typo or publish a landing page instantly without opening a GitHub ticket or waiting for a developer to deploy code.

The Mature Ecosystem: Spinning up standard features like WooCommerce or Advanced Custom Fields (ACF) takes days, whereas building those from scratch in a custom stack takes weeks of expensive engineering time.

The Modern Compromise: Headless WordPress

You don’t have to build monolithic, slow PHP sites to give clients what they want. The modern way to handle this is Headless WordPress.

You keep WordPress strictly as a backend Content Management System (CMS). The marketing team gets their familiar login dashboard to manage posts. But instead of letting PHP render the front-end, you pull that content via the WordPress REST API or WPGraphQL.

Then, you build the actual website using Astro, Next.js, or Remix. The end-user gets a blazing-fast, secure, compile-on-demand static or React site, and the client still gets their favorite editor. It’s a win-win.

How to Keep Monolithic WordPress Lean (Without 50 Plugins)

If you do have to build a traditional monolithic WordPress site, you can easily keep it from choking if you stick to a few senior development rules:

Stop using plugins for embed codes: If a client needs a Google Analytics tag, a Facebook Pixel, or a custom script, do not look for a plugin to inject it. WordPress gives you native hooks like wp_enqueue_script or wp_head and wp_footer. You can open your functions.php file, write a quick action hook, and drop the code directly into the header or footer yourself. It takes five minutes, requires zero overhead, and eliminates an entire third-party plugin attack vector.

// Drop this in functions.php instead of installing a Google Analytics plugin

add_action('wp_head', 'add_google_analytics');

function add_google_analytics() {
    ?>
<!-- embed code here -->
    <?php
}

Use native core features: If you need to register a custom post type, change a minor layout behavior, or adjust image thumbnail crop sizes, write a few clean lines of native PHP in functions.php. It keeps your logic version-controlled and tightly integrated with your theme.
Ditch heavy page builders: Avoid tools like Elementor or Divi that inject endless nested tables, bloated CSS, and unnecessary DOM elements. Use native Gutenberg blocks paired with Advanced Custom Fields (ACF) to give clients flexible layouts that remain incredibly lightweight.
Offload to the Edge: Stop using heavy security and optimization plugins that run massive, unoptimized cron jobs on your origin server. Put the site behind Cloudflare and let the network edge handle caching, web application firewalls (WAF), and image optimization.

The Takeaway

WordPress isn't a tech stack problem; it's an engineering discipline problem. Once we stop fighting the fact that it's here to stay, we can start using modern architecture to make it fast, secure, and actually pleasant to work with.

DEV Community: Jeff Go

Continuing on my previous thoughts regarding The WordPress Paradox, this article dives now into how to leverage WP native tools just inside functions.php to bypass the traditional monolithic rendering engine entirely, enabling REST API endpoints.

Going Headless From the Inside Out: Native WordPress API Customization

Going Headless From the Inside Out: Native WordPress API Customization

Step 1: Exposing the Native Endpoint (functions.php)

Step 2: Consuming the Micro-API on the Frontend

Shifting Value Upstream

The value in software engineering has officially shifted upstream. Typing code is becoming cheap and instant. The new bottleneck isn't syntax—it's architecture, context, and security.

AI Agents Aren’t Replacing You, But the Dev Who Steers Them Is

AI Agents Aren’t Replacing You, But the Dev Who Steers Them Is

Shifting from Coder to Conductor

The "Human-in-the-Loop" Rules of Engagement

The New Market Reality

The Web is just getting better nowadays. Google I/O just announced the HTML-in-Canvas API, and it's going to completely change how we build interactive web apps!

HTML-in-Canvas: The Wild New API from Google I/O (and How Not to Break the Browser)

Google I/O just announced the HTML-in-Canvas API, and it's going to completely change how we build interactive web apps!

HTML-in-Canvas: The Wild New API from Google I/O (and How Not to Break the Browser)

HTML-in-Canvas: The Wild New API from Google I/O (and How Not to Break the Browser)

👑 The DO's

🚫 The DON'Ts

The Verdict

sometimes Wordpress frustrates me, but hey, it is here to stay. here's what we as devs can do about it

The WordPress Paradox: Why It’s Here to Stay (and How to Stop Ruining It)

The WordPress Paradox: Why It’s Here to Stay (and How to Stop Ruining It)

The Real Problem: Plugin Abuse

Why Clients Won't Move On

The Modern Compromise: Headless WordPress

How to Keep Monolithic WordPress Lean (Without 50 Plugins)

The Takeaway

Step 1: Exposing the Native Endpoint (`functions.php`)