Forem: Jeff Go

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

Comments

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

Comments

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

Comments

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.