Our time with Preact: Shipping pluggable UX for storefronts
Lessons in building UX that just works on all storefronts
Before writing anything about Preact, I personally wanted to know our history with Preact and found we had our first mention of “preact” in our archives around June 2016 😄, as we were exploring a custom integration into a b2b-ecommerce platform. The real practical usage started around June 2020 as we scaled up. In the early 2010s, I was a huge fan (maybe still looking for that) of knockout.js’s simplicity of declarative bindings aka MVVM type architecture, but missed React’s structure. Preact acted as that balance of utilitarian and familiar as React but without the heavy bulky-feel of React.
When an engineer proposed using preact for the first time, it wasn’t a slam dunk. It had to work with our first principles - We needed to work where our merchants needed us to work, i.e, we needed a UI platform that stayed fast, reusable, and safe to plug into multiple surface areas we do not own and never biased to a UX framework as default. Breaking that into specifics:
plug into storefronts with different frameworks and theme structures,
stay lightweight in embedded runtime contexts,
scale reuse across experiences,
keep regression risk controlled for shared merchant-facing paths.
The goal of this post is not to prescribe an action plan for you, it is to share what we learned from building pluggable storefront UX in real environments, and why those lessons remain highly relevant right now.
Why talk about this now? Shopify extensions is leaning heavily on preact as a welcome change to improve performance on all fronts - size, speed and rendering control. That’s a philosophy we share and it helped us build and scale across thousands of Shopify Plus merchants (including $10M+/yr brands)
“Pre”Preact (pun waiting to happen
From 2016 to 2020, our storefront UI was plain no-dependency JavaScript, low-fi Mustache templating, with custom loaders for css, strings plus other assets and a single deployment model.
What worked
This was lean and generally fast.
Low runtime overhead
Good baseline speed characteristics
Minimal dependency risk
Flexible embedding model
What did not scale cleanly
Testability degraded as interaction depth increased
Reuse was harder than component-first systems
Safe change velocity depended on high expert context
Regression risk stayed high across shared merchant-facing paths
Performance nuance
The old stack was not broadly slow, i.e. Raw script speed was generally not the primary blocker. Constraints were often:
chunk size floors,
older mobile browser compute ceilings pre-2020,
paint and rerender behavior on constrained devices.
So our move wasn’t necessarily “slow to fast.” It was “lean but hard-to-evolve to modular-and-verifiable.”
What we changed from 2020 to ~2022
We moved incrementally to a componentized UI model with a shared base and host adapters.
High-level shape:
Host adapter layer
Shared orchestration and contracts
Shared UI bundle using React-compatible Preact setup
“Chunk”y packaging and deployment artifacts
This gave us a practical component model with low runtime tax in embedded storefront contexts. We evaluated other potential fits like React, ember and other highly versatile frameworks, but each had a bulk that we didn’t want our merchants (and their shoppers) to deal with that additional tax.
What Preact was great at in this model
Reusable UI components with clearer boundaries
Lower runtime overhead in embedded storefront contexts
Better component-level testability
Faster iteration on shared UX behavior across surfaces
Where it was not magic
Host seam bugs still happen
Data/model contract drift still happens
Mixed runtime debugging still requires telemetry
Passing tests still does not prove live-path correctness
What did not change automatically
Seam bugs still occurred at host/runtime boundaries
Mixed script environments still required instrumentation
Poor state placement could still create rerender cascades
Confidence still required live probes, not test-only green status
Architecture for a pluggable storefront model
Here are the visual structure of how our UX component defense is structured, mostly based on internal architecture without all the intricacies
System context: platform vs Swym boundaries
Dependency ownership map
Request path distinction (runtime flow)
Failure isolation diagram (who owns breakage)
Final takeaways
Our long-term value has been predicated by ensuring Preact-compatible shared component base with strict boundary architecture. As confident as we are in our approach and grounding principles, I am not going to claim victory yet, not even close to what we can achieve with this structural unlock.
Here are a few reasons to back that non-claim
When building an SDK that also distributes UX components, the build x deploy challenges are numerous with the first one being nobody wants to have very bulky code. Some bulk is expected for convenience but mostly it is avoidable tax.
Testing pluggable components (that compose entire experiences) without “owning” the storefront is nightmarishly hard and a constantly moving target.
Add to that the fact that true testing is not just that “it works”, it is more that it works fast, looks good, compliant and renders properly across all states of the experience (again, something you don’t own entirely). Even with years of hard grind and doing the “low value” work, the chase for the smooth 100% fit is ongoing.
Non-app-based installations are inconsistent. Through our apps, the hard parts around installation, initialization and loading are pretty well optimized. It also gains directly through improvements made on Shopify’s extensibility. But headless and other non-app/extensions are tricky and varied, be prepared for answers that are inconsistent that nobody likes.
I suppose the most important parts of this post tucked away in this final part 😄 These architectural nuances typically get overlooked in the race to ship. But that’s where the joy (of building) and delightful experiences depend on. Exactly where our team is spending a ton of time and seeing breakthroughs with AI-native solutions.
If you have reached this part and are excited about crafting nuanced solutions for hairy problems, talk to me or any of us at Swym, come build that future with us 🙌
P.S Credit to https://mermaid.live/ for the mermaid chart output