Building With Etch

We just relaunched digisavvy.com on Etch. This post is the story of how it got built — the stack, the AI workflow that made it fast, and a couple of lessons that cost us real time.

Why we rebuilt at all

It was time. The old site ran on Kadence for about five years; a genuinely nice product at the time. But I think the verdict on block themes is in, and it isn’t kind: you either suffer with native blocks, or you commit to a builder you actually like. And block themes were always just a band-aid sold as the great compromise. They suck. Over the last couple of years, I’d been building extensively with Bricks, and I couldn’t wait to get my hands on Etch.

Additionally, we’re working on a new site build with a new client using Etch, and that project is coming along nicely. So it was more incentive to get to work. I was able to do this in a few days.

Honestly, learning Etch started as an uphill battle. It cut against habits I’d built over years in other tools. But once it clicked, what I saw was freedom — the markup is mine, the CSS is mine, and nothing is hiding behind a settings panel. I didn’t mind that these panels were gone. I gotta tell ya, thousands and thousands fewer clicks! I got so into it, I spent Christmas break feverishly building a pattern library for Etch — patterns, components, and full templates — purely to teach myself the tool.

The AI workflow (and how it actually evolved)

This is the part people ask about. It went through three distinct phases.

Phase one: an MCP server. Someone in the Etch community posted about building their own MCP server, and that gave me the idea. I built one, pointed Claude at it, and started building with Etch that way. It was pretty good.

Phase two: the accident. Somewhere along the way, I found out — half by accident — that going straight at WP-CLI with Claude Code in the terminal was dramatically faster. No middleware, just the model driving wp commands against the install. Suddenly, I was moving at a pace I’d never hit in any builder. The problem: speed without standards. Claude wasn’t building things the correct way — it wasn’t referencing Automatic CSS, it hardcoded values, and it invented patterns instead of using the ones the framework gives you.

Phase three: write the docs down. The fix was unglamorous. I built out a set of Markdown reference files — how to use ACSS, how Etch structures markup and styles — copied from both products’ documentation and referenced in the project instructions. After that, the output got consistently good. New Etch + ACSS projects still need a little training each time, which is mildly annoying and was true on this build, too. And I’m still doing cleanup passes on hardcoded values that slipped through, but at this point, the site runs almost entirely on ACSS tokens, plus a small set of override tokens I added. I’ll share them at some point… maybe. =)

Once the WP-CLI + Claude Code combination clicked, I got busy growing that pattern library on top of it. I even remarked in the Etch forums: do you all realize this thing is ready for the AI era? What made this possible are that all these endpoints are readily accessible through the REST API and your AI tool can just talk to it!!!

And here’s the part I love — the Etch team didn’t intend to build something that was inherently great with AI. Nobody planned it. It’s just good design out of the box: by exposing everything as clean, scriptable surfaces, they built the most AI-workable builder on the market without trying to. It reminds me of Street Fighter II and combos… The Capcom dev team never thought about ‘combinations’ of moves as a thing; it wasn’t a specifically built-out feature, nor was there any intention behind it; they naturally occurred from well-thought-out patterns.

The stack

• Etch + Automatic CSS for everything visual. Etch owns templates and template parts; ACSS owns the tokens. The child theme is nearly empty — fonts, one override stylesheet, one small JS file.
• GridPane hosting, hybrid-git: wp-content Deploys through the repo, the database is edited live — the natural direction when Etch owns your templates.
• WS Form Pro for forms, FacetWP for the journal filter, wired into an Etch loop riding the main query.
• Small mu-plugins instead of feature plugins — a lead-qualifier widget, journal loop tokens, and a ~130-line performance plugin that replaced our need for Perfmatters.

Animations without a library

Every fade-in on the site is one IntersectionObserver and about sixty lines of vanilla JS. Elements get a reveal class in Etch. The JS adds is-reveal-ready to the HTML element on the live front end, then is-in per element as it enters the viewport. The CSS is the whole trick:

.reveal { transition: opacity .8s var(--ease), transform .8s var(--ease), filter .8s var(--ease); }
.is-reveal-ready .reveal { opacity: 0; transform: translateY(26px); filter: blur(10px); }
.is-reveal-ready .reveal.is-in { opacity: 1; transform: none; filter: none; }

Three lessons baked into that pattern: gate the hide behind a class, only the live front end adds, or the Etch canvas renders blank (your reveal JS never runs in an editor iframe). Exempt above-the-fold elements before arming the hide, or your LCP element fades in and tanks the score. And if FacetWP swaps content in via AJAX, re-mark the new elements, or they sit invisible:

document.addEventListener('facetwp-loaded', function () {
  document.querySelectorAll('.facetwp-template .reveal')
    .forEach(function (el) { el.classList.add('is-in'); });
});

The dot backgrounds

The animated dot fields are a small custom canvas engine built as Etch components — a wp_block using the element script attribute, so the code loads only where the component is used. Perf rules we landed on, in order of impact: actually stop requestAnimationFrame for offscreen canvases (don’t just freeze the clock), cap at 30 fps, cap devicePixelRatio, render one static frame on phones, and respect prefers-reduced-motion.

The biggest lesson: Safari will not paint a tall image

Random edge case storytime. For a while, the homepage ran at 4 fps in Safari and Firefox, while Chrome cruised at 120 fps, and every Lighthouse run looked fine because Lighthouse is Chromium. The culprit: a faint decorative SVG stretched behind the entire page, about 9,900px tall. Chrome’s compositor shrugged; WebKit repainted it constantly. If you want a behind-everything watermark, position: fixed at viewport height reads almost identically and paints a twelfth of the area. And test in the real engines — Playwright ships WebKit and Firefox builds, and a ten-line hide-elements-and-measure script found in minutes what dashboards never would.

Where it landed

Mobile PageSpeed sits at 90–98 with the animations, the canvas backgrounds, and a multi-step lead form all still in place. Not because of a performance plugin — because the stack stays out of its own way.

If you’re weighing a rebuild on Etch, our work shows what this approach produces, and the approach page covers how we run projects. Questions about any of it just ask. I like talking about this stuff.

Things I could have done better…

I could have made better use of components. I know it’s an odd way to think, but sometimes I just want to build, build, build, and getting stuck in the details isn’t an option. I get too impatient! So I definitely could have made better, more effective use of components and slots. I’ll be going back through to get things up to speed.

There are still a lot of custom tokens that got created. I wasn’t as vigilant as I could have been in ensuring that ACSS tokens were used. I’ll be spending tie in the coming weeks tidying that up. But taking the time up front will save more time in the future (as I’m about to find out).

I wanted it built, and I wanted it NOW, lol.

The difference between working with etch and bricks

It’s night and day, clearly. I can do so much more quickly in Etch than with Bricks. And I’ve been building with Bricks the last two, maybe three years, and I love Bricks. I don’t have a bad thing to say about it. And I’ve got to tell you, it’s a phenomenal tool, and I think the bricks team is awesome. And I like how thoughtful Thomas creates things and gets them out there. It’s really cool to see.

I think the dev process, building a site with Bricks versus building a site with Etch, is just completely different, very different approaches. Etch is not a page builder. It’s an IDE of sorts, but I think the way in which you can choose to build with it within its own little unified development interface, whatever you want to call it. And that works. It’s great. It’s fast and snappy, and it’s awesome. But you can also take AI to it, and you don’t have to finagle with it.

Once you have your AI tool tuned and trained on using etch, the rest is blazing fast. And with Bricks, you can do it, and you’ve got Novamira now, too, so you can build a little more easily with AI and Bricks, but man, it’s rough. I haven’t used Novamira, and I don’t intend to. I just don’t see the value in it, but trying to build from the command line with Bricks, even after training it up, isn’t fun anymore… Maybe that’s my shiny object syndrome going off, but I gotta tell you… Getting down with Etch has been AWESOME. Hard to go back.

That said, it’s an exciting time, this space, but yeah. My beloved Bricks, I’m definitely looking at different directions these days.

Final thoughts

How quickly I was able to pull this together was shocking. Claude’s Fable model did serious heavy lifting. My mind is blown. The speed is real. The value that I can build is real for my clients.

Etch really is an incredibly well-thought-out tool. It’s not just another builder; it dumps that whole way of doing things on its head. Yes, Etch is a kind of abstraction layer, but I think it’s one that really leans into using the block editor as a content-editing tool (rather than a layout-building tool). What you build in Etch shows up as editable blocks in the block editor. This feature probably should be listed in the first sentence; it’s that cool.

This tool should be more popular than it is.

The progress on this tool has been wild to see. I bought in when it was little more than vaporware, and I’m so glad I did. Something that deserves its own post is the study of how Etch was built. It was built in public (if you paid for it); they gathered user feedback and demoed early and often. Like… it was the perfect execution from concept to usable product. Truly impressed. Hopefully the Etch team thinks what I built is cool. =)