DEV Community: Juan Martin

I built a paint app where the PNG is the canvas (no

Juan Martin — Wed, 22 Jul 2026 02:28:03 +0000

Paint Canvas — The PNG Is the Canvas — SnapDOM Labs

A paint app with no <canvas> element — a SnapDOM plugin accumulates every stroke onto the last captured clone.

snapdom.dev

[Boost]

Juan Martin — Tue, 14 Jul 2026 02:59:04 +0000

Juan Martin

Jul 14

Why SnapDOM Beats html2canvas for DOM-to-Image Capture

#javascript #webdev #html #opensource

6 min read

Why SnapDOM Beats html2canvas for DOM-to-Image Capture

Juan Martin — Tue, 14 Jul 2026 00:40:20 +0000

Capturing a slice of the DOM as an image is one of those deceptively hard problems in frontend engineering. For years, html2canvas has been the default answer. It works, it's battle-tested, and it's everywhere. But if you've ever pushed it hard — large trees, custom fonts, shadow DOM, or high-DPI exports — you already know where the cracks are. SnapDOM is a newer take on the same problem, and in most of the ways that matter for real applications, it's simply a better tool. Here's a technical breakdown of why.

The core architectural difference

html2canvas works by re-implementing the browser's rendering engine in JavaScript. It walks the DOM, reads computed styles, and then manually paints each element onto a <canvas>. That's an enormous surface area to get right: every CSS property, every layout quirk, every edge case in text rendering has to be reproduced by hand. This is why html2canvas ships with a long list of "known unsupported CSS properties" — it can only render what its authors have explicitly taught it to render.

SnapDOM takes a fundamentally different route. It serializes the target node into an inlined SVG using the <foreignObject> element, then rasterizes that SVG through the browser's native rendering pipeline. In other words, instead of re-implementing the browser, it hands the work back to the browser. The practical consequence is huge: if the browser can display it, SnapDOM can generally capture it — gradients, filters, blend modes, transforms, and modern CSS features included — without anyone having to write bespoke support for each one.

Performance

Because SnapDOM leans on native rasterization rather than a hand-rolled paint loop in JS, it avoids a large class of expensive per-element JavaScript work. For typical UI captures the difference is very noticeable, and it scales better as the node count grows. html2canvas's cost climbs with the complexity of the tree because every node is processed by its interpreter; SnapDOM's serialize-then-rasterize approach keeps more of the heavy lifting inside optimized browser internals.

Caching is another big lever. Resolving fonts, images, backgrounds, and computed styles is some of the most expensive work in any capture, and a lot of it is repeated across captures. SnapDOM leans on caching so those resolved resources don't have to be recomputed every time — the second capture of the same UI, and repeated captures in general (think live previews, thumbnails, or exporting many similar cards), get dramatically faster because the heavy resource resolution is reused instead of redone.

It's also worth noting SnapDOM's output flexibility: you can get an SVG, a raster image, a Blob, a data URL, a <canvas>, or a ready-to-use <img> in a single call. When you don't force a raster round-trip you can keep the result vector-sharp, which matters for retina displays and print.

import { snapdom } from '@zumer/snapdom';

const el = document.querySelector('#card');

// Multiple output formats from one capture
const png  = await snapdom.toPng(el);
const svg  = await snapdom.toSvg(el);
const blob = await snapdom.toBlob(el);

Fidelity and modern CSS

This is where the architectural choice pays off the most. Shadow DOM, web components, pseudo-elements, CSS custom properties, and modern layout all tend to "just work" with SnapDOM because they're rendered by the same engine that renders your page. Fonts are a classic pain point with html2canvas; SnapDOM's approach to inlining resources and honoring the real computed styles produces output that matches what the user actually sees far more often. Fewer surprises, fewer manual workarounds, fewer "why does the export look different from the screen" bug reports.

SnapDOM vs. native capture APIs and other approaches

It's fair to ask: browsers keep gaining native capture-ish capabilities, and there are other libraries in this space — so why SnapDOM? A few reasons it stays genuinely useful:

It already supports the html-to-canvas style output. You don't lose anything by choosing SnapDOM: it can hand you a <canvas> (and PNG/JPEG/WebP from it) just like the canvas-first tools, while also giving you SVG, Blob, data URL, and <img>. It's a superset, not a trade-off.
Native APIs solve a different problem. Things like getDisplayMedia/screen capture or the experimental region-capture APIs grab the rendered viewport through the OS/compositor. They require user permission prompts, capture what's actually on screen (scroll position, overlays, device chrome), and can't cleanly isolate a single off-screen or partially-scrolled node. SnapDOM captures a specific DOM node deterministically, with no permission dialog, regardless of what's currently visible.
<foreignObject> done right. The raw "serialize DOM into an SVG <foreignObject>" trick is well known, but doing it correctly — inlining fonts and images, honoring computed styles, handling shadow DOM and cross-origin resources, and producing consistent raster output — is where most hand-rolled attempts fall apart. SnapDOM packages that hard part into something reliable and extensible.
Consistency across environments. Native and OS-level capture varies by browser, platform, and permissions. A DOM-based approach gives you the same result wherever your page runs, which matters for reproducible thumbnails, share images, and automated pipelines.

In short: native capture is great when you want "whatever is on the user's screen," but for "turn this component into an image, faithfully and programmatically," SnapDOM is the right tool — and it covers the canvas use case on top.

Plugins and extensibility

A big practical advantage of SnapDOM is that it's built to be extended rather than patched. Its capture pipeline exposes hook points, so you can transform nodes before serialization, adjust or inline resources, tweak the output, and plug in custom behavior without forking the library. That plugin-oriented design means teams can adapt capture behavior to their own components and edge cases instead of waiting for upstream to add a special case.

html2canvas, by contrast, is essentially a monolithic renderer. Its extension surface is a set of options and callbacks bolted onto a fixed pipeline. When it doesn't support something, your realistic choices are to work around it, monkey-patch it, or fork it. The extensibility model of SnapDOM turns "the library doesn't do X" from a dead end into a solvable problem.

Flexibility in real projects

Beyond raw capture, SnapDOM is flexible about how you integrate it. Options for background color, scaling/DPI, cropping, resource inlining, and choice of output format let you tune it to the task — thumbnails, social share images, PDF pipelines, or pixel-perfect design exports — without stitching together extra tooling. Because the primitive it produces is an SVG, you also get an escape hatch: you can post-process the vector output before rasterizing, something that's awkward at best with a canvas-only approach.

Scaling to large DOM trees

Big, deeply nested trees are the classic stress test for any DOM-to-image tool, and it's an area where SnapDOM is actively getting better. The stable production releases have already landed impressive speedups for large captures, and the work isn't stopping there: the ongoing effort in the dev branch pushes this even further, with genuinely exciting progress on making large-tree captures faster and more efficient. If you have heavy dashboards or dense component trees, this is a project moving in exactly the right direction — and the gains already shipped in stable are substantial today.

Maintainability

There's a subtler, longer-term argument here too. A library that re-implements the browser is, by definition, chasing a moving target: every new CSS feature is potential new work and a new source of divergence. A library that delegates to the browser inherits new features largely for free. That makes SnapDOM's core smaller and its behavior more predictable to reason about, which is exactly what you want in a dependency you'll be shipping in production for years.

From a project-health standpoint, SnapDOM is actively developed with a clear, modern codebase and a design that invites contribution through its plugin points. A tighter core with well-defined extension seams is generally easier to maintain, test, and trust than a sprawling engine that must account for the entire CSS specification by hand.

The bottom line

If you're starting fresh, capturing modern UI, or you've been fighting html2canvas over fonts, shadow DOM, performance, or CSS support, SnapDOM is the more forward-looking choice. Delegating rendering to the browser instead of reimplementing it gives you better fidelity, better performance, an actual plugin/extensibility story, and a codebase that's easier to maintain over the long haul.

Same problem, smarter architecture.

I got tired of page navigation. So I built a zoom-based alternative

Juan Martin — Mon, 06 Apr 2026 01:10:32 +0000

The idea is simple: instead of navigating between pages, you zoom into content. Mark an element as zoomable, point it to a view, and Zumly handles the transition and inserts the new content. That’s basically it.

I started this in 2020 after stepping back from Zircle UI, a Vue zooming library I built before. I wanted to take the core idea further without being tied to any framework. So Zumly is framework-agnostic and focused purely on the zoom transition. It doesn’t care about your CSS, your design system, or your stack.
Since then I rewrote the engine several times and changed the approach more than once. Only now am I actually happy with how it feels.

The landing page is built with Zumly itself, so you get the interaction before touching any code:
https://zumerlab.github.io/zumly

Still rough edges ahead. Would love to hear what you think about the interaction model and if the API makes sense.

From frustration to open source adoption: my journey building SnapDOM

Juan Martin — Sat, 27 Sep 2025 14:22:02 +0000

I started hacking on what later became SnapDOM in April this year. At first it wasn’t even meant to be a standalone library — it began as an internal tool for a zoomable UI project (Zumly), I was building. To make that project work, I needed a way to capture DOM elements with high speed and fidelity. Existing DOM-to-image libraries like html2canvas often failed in subtle but important ways: missing pseudo-elements, mis-rendering fonts, ignoring Shadow DOM, or breaking on Safari. What started as a quick internal hack slowly grew into its own project.
Open sourcing SnapDOM changed everything. Suddenly the audience wasn’t just me, but anyone with their own browser, CSS, and HTML quirks. That’s when I realized how immense the attack surface really is. Every combination of engines, DOM structures, styles, and external resources can break in unexpected ways. At times it felt overwhelming, but I’ve learned to treat each bug as a reproducible pattern: isolate it, fix it, and carry the lesson forward.

From the beginning, two principles guided the work: fidelity and speed. Capturing “every detail” would not matter if the process was unbearably slow, so I spent a lot of time on caching strategies, incremental updates, and efficient DOM cloning. Benchmarking against existing libraries became part of the routine. Performance was never an afterthought — it was always as important as accuracy.

On the technical side, SnapDOM pushed me into DOM cloning strategies, caching, font embedding heuristics, browser-specific hacks, and the constant tradeoffs between fidelity and performance. On the personal side, it has been just as educational: patience, humility, and learning to really listen to users. Some of the best moments have been receiving thoughtful PRs and clear reproduction cases — collaboration that genuinely made the project better. The respect shown in these contributions has been one of the most motivating parts of the journey.

Another milestone: only a few months in, SnapDOM already has its first two GitHub Sponsors and has passed 6k stars on GitHub. Knowing that people found enough value to sponsor the project, and that thousands more cared enough to star it, has been incredibly rewarding.

I’ve also been designing a plugin system, so the core stays lean while features like cropping, filters, or alternative exporters can live as extensions. It’s not merged into the mainline yet, but it’s a direction I’m excited about — and another layer of complexity to manage as the project evolves.

It’s still early days, but reflecting on the journey from April to now has been meaningful. What started as a small internal helper for a zoomable UI turned into an open source project with real users, contributions, sponsors, and community respect. Balancing the technical struggles with the human side of open source has made this one of the most rewarding experiences I’ve had so far.

Thank you, Martin

Repo: https://github.com/zumerlab/snapdom

🎉 SnapDOM celebrates 3 months! 🎉

Juan Martin — Sun, 27 Jul 2025 10:37:36 +0000

Today, 27 July, we mark the first 90 days since Snapdom was born.
We couldn’t be more grateful to the amazing community that made it possible. 🙌

🚀 In just 3 months, Snapdom has reached:

⭐ 3550+ stars
🍴 107 forks
📦 18 releases published
👥 14 incredible contributors
Snapdom grew fast, but on a solid foundation. During this time, we’ve added advanced support for:

✅ Web Components and slots
✅ Complex pseudo-elements
✅ Remote and local fonts (including icon fonts!)
✅ @import and @font-face styles
✅ mask-image, backgrounds, canvas, SVG, and more
✅ Fixes for Safari, Firefox, Edge, Chromium...
✅ Performance optimizations, compression, and smart caching
✅ New benchmarks, CI compatibility, improved DX and documentation

👩‍🔧 Every release brought significant improvements, with a steady evolution focused on true visual fidelity.

🔥 What truly sets Snapdom apart is its speed — it is hands down the fastest DOM capture tool available.

What truly sets Snapdom apart is its speed — it is hands down the fastest DOM capture tool available.

While other tools like html2canvas, html-to-image, and modern-screenshot may take noticeably longer or face challenges with complex DOMs, Snapdom captures almost instantly, even with deep and dynamic structures. This unmatched speed makes it the go-to solution for real-time apps, visual editors, and any workflow where performance is critical.

Our benchmarks prove it out: Snapdom surpasses these alternatives by a wide margin, delivering high-fidelity results without compromising speed.

The secret behind this performance lies mainly in Snapdom’s advanced caching system combined with its intelligent CSS class assembly. By efficiently reusing cached styles and building compact CSS increments, Snapdom drastically reduces final bundle size and speeds up style processing, resulting in lightning-fast captures even in the most demanding scenarios.

You can check all the progress in the full Changelog, or explore our interactive demos to see what it can do.

💜 Huge thanks to everyone who opened issues, submitted PRs, starred the repo, or helped test.

📊 SnapDOM - Performance Benchmarks For clientside screenshots

Juan Martin — Thu, 10 Jul 2025 16:51:18 +0000

Snapdom has made major performance leaps since v1.8.0.

Simple elements (ms, lower is better)

Scenario	Snapdom (current)	Snapdom v1.8.0	html2canvas	modern-screenshot
Small (200×100)	0.4	1.2	70.3	11.9
Modal (400×300)	0.4	1.1	68.8	14.1
Page View	0.4	1.0	100.5	34.2
Large Scroll	0.4	1.0	153.1	77.8
Very Large	0.4	1.0	278.9	194.7

Complex elements (ms)

Scenario	Snapdom (current)	Snapdom v1.8.0	html2canvas	modern-screenshot
Small (200×100)	1.1	3.2	72.5	16.1
Modal (400×300)	4.5	14.0	90.1	34.6
Page View	32.9	113.6	196.1	181.1
Large Scroll	133.9	387.4	446.6	635.9
Very Large	364.0	1200.4	1275.4	1685.6

⚡ Summary

Snapdom (current) is 2–4× faster than v1.8.0
Up to 500× faster than html2canvas
Much faster than modern-screenshot, especially with large/complex DOMs

🧪 Benchmarks run with Chromium + Vitest on a 2018 MacBook Air

🏎️ Even better performance on modern hardware!

https://github.com/zumerlab/snapdom/discussions/102

Snapdom: a modern and faster alternative to html2canvas

Juan Martin — Tue, 01 Jul 2025 07:36:50 +0000

In less than two months, Snapdom reached 2,120+ stars, with 7 contributors and a growing user base. But the goal has been clear since day one:

Build a modern, accurate and fast replacement for html2canvas.

Why a replacement?

html2canvas was a milestone. I love it. It brought DOM-to-image to mainstream frontend. But time has passed, and the web platform has evolved: higher DPI screens, complex shadows, pseudo-elements with ::before { content: url(...) }, imported icon fonts, variables inside gradients, shadow DOM, web components, and more.

Many of those features don’t render correctly in html2canvas. Snapdom aims to fix that with a new approach.

What Snapdom does differently

Snapdom captures how a DOM looks. While tools like html2canvas attempt to reproduce the layout procedurally using canvas drawing commands, Snapdom takes a different route:

It builds a visual clone of the DOM using a serialized structure and renders it via SVG with <foreignObject>.
Styles are computed via getComputedStyle() and inlined per element, or collapsed into reusable CSS classes when compress mode is enabled.
Snapdom uses caching strategies for computed styles, fonts, and DOM shape to improve render performance.
It supports hi-DPI scaling, fixed size snapshots, and consistent box models across browsers.

This approach makes it fast, modular, and portable — and allows Snapdom to produce SVG output that can be rendered, embedded, or exported in almost any format.

Visual fidelity

Captures ::before / ::after / ::first-letter, including icons, URLs and inline content.
Supports background-image with multiple layers: url(), linear-gradient(...), var(...), mixed.
Handles shadows, filters, transforms, blend modes, scroll, overflow, and z-index correctly.
Captures shadow DOM content and visual order.

Fonts and icon support

Full support for @font-face via stylesheets or FontFace() constructor.
Correct rendering of icon fonts (FontAwesome, Material Icons, etc.) — including inside pseudo-elements.
embedFonts: true will inline all fonts into the SVG.

DOM state

Captures current values of inputs, selects, and textareas.
Preserves scroll position (scrollTop, scrollLeft).
HiDPI / Retina support via devicePixelRatio.
Optional fixed dimensions with width and/or height.

await snapdom(el, {
  width: 1024,
  height: 768,
  embedFonts: true,
  compress: true,
});

Performance-focused

Snapshots in milliseconds, even on complex pages.
One-time capture → multiple exports:

const result = await snapdom(el);
await result.toSvg();
await result.toPng();
await result.toWebp({ backgroundColor: "#fff" });

Coming soon: Plugin system

We're working on a native plugin architecture so anyone can extend Snapdom with custom needs.

Some ideas:

Watermarking
PDF export
WebGL / canvas integration
Post-capture mutation (blurring, tinting, overlays, etc.)
Integration with visual editors

The plugin API will allow users to hook into preprocessing, postprocessing, and export logic.

API at a glance

const result = await snapdom(el, {
  scale: 2,
  compress: true,
  embedFonts: true,
  backgroundColor: "#fff",
  crossOrigin: "anonymous",
});

// Exports
await result.toSvg();
await result.toCanvas();
await result.toPng();
await result.toWebp();
await result.toImg();

data-capture="exclude" skips a node and its children.
data-capture="placeholder" replaces a node with an empty box (useful for ads, iframes, etc).

Try it

📦 GitHub → github.com/zumerlab/snapdom
🧪 Live demo → zumerlab.github.io/snapdom

Snapdom is fully browser-based. No canvas hacks, no server dependency. Just clean JS + SVG + Web APIs.

We're actively looking for feedback and contributors. If you're hitting limits with html2canvas, try Snapdom and help shape its future.

A practical way to test HTML and CSS in real-time using only CSS.

Juan Martin — Wed, 28 Aug 2024 13:16:39 +0000

Recently, I made public a CSS framework I developed for creating radial designs. During development, I faced several challenges, including testing different features. I noticed that CSS linters and other tools didn't allow me to see why something wasn't working, even if there were no basic errors. Another typical CSS problem was seeing how it was shared across different browsers. Fortunately, I discovered that certain new CSS features can be used to create a series of real-time tests. These features are @support, @container, and :has().

By combining these features, I developed a testing system not only to check if the framework works in the browser but also, and most importantly, to see if we are applying HTML correctly according to the browser's requirements and avoiding involuntary errors when developing an application.

Since my CSS framework necessarily uses features that only the newest browsers have, such as trigonometric functions like cos() and sin(), I created a series of rules to test if they are supported by the browser. If they're not, a message appears asking to update the browser. Similarly, if the browser doesn't support :has(), which is used throughout the framework.

There are also typical cases of browser incompatibility, so in some non-critical cases, I use @support or @container to hide certain Orbit features that don't affect its use. For example, Safari doesn't accept SVG context-stroke, so I hide them.

However, beyond those critical checks and compatibility, the most common issue when using a CSS framework is not knowing how to use it properly. That's why I created other CSS rules that allow analyzing if a parent element has the required child elements and not others. Here, visual alerts also appear while developing to give a hint about where the error is in the code.

I don't want to bore you with the details specific to Orbit, but I'll leave you the link to the support source and related documentation.

Repo: https://github.com/zumerlab/orbit
Source file: https://github.com/zumerlab/orbit/blob/main/src/scss/_support.scss
Orbit Support documtation: https://zumerlab.github.io/orbit-docs/tools/support/

Good to go deeper: https://heydonworks.com/article/testing-html-with-modern-css

Orbit a CSS framework for crafting simple or complex radial interfaces.

Juan Martin — Tue, 27 Aug 2024 10:11:02 +0000

Hi Devs!

I've been a long-time fan of DEV, but this is my first post. I'm excited to introduce Orbit, a new CSS framework I've created that allows you to build radial interfaces using only CSS.

Orbit has a flexible API that borrows some spatial design concepts to make it familiar and easy to use. With Orbit, you can create complex radial layouts and designs without writing a single line of JavaScript. Imagine building gauges, charts, watches, Mini Cooper dashboards ;), solar systems, and even esoteric user interfaces seen in sci-fi movies! You can achieve all those and more with CSS.

I'll stop here, as I just want to introduce Orbit to the community. In future posts, I plan to write some tutorials and examples to help you get started with Orbit. If you have any suggestions for examples or projects you'd like to see, please let me know!

I left here a Codepen example

I'd love to hear your feedback.

Thank you,
Martin

DEV Community: Juan Martin

I built a paint app where the PNG is the canvas (no element) snapDOM is normally stateless — every capture re-clones the live element. https://snapdom.dev/labs/paint-canvas/

Paint Canvas — The PNG Is the Canvas — SnapDOM Labs

[Boost]

Why SnapDOM Beats html2canvas for DOM-to-Image Capture

Why SnapDOM Beats html2canvas for DOM-to-Image Capture

The core architectural difference

Performance

Fidelity and modern CSS

SnapDOM vs. native capture APIs and other approaches

Plugins and extensibility

Flexibility in real projects

Scaling to large DOM trees

Maintainability

The bottom line

I got tired of page navigation. So I built a zoom-based alternative

From frustration to open source adoption: my journey building SnapDOM

🎉 SnapDOM celebrates 3 months! 🎉

📊 SnapDOM - Performance Benchmarks For clientside screenshots

Simple elements (ms, lower is better)

Complex elements (ms)

⚡ Summary

Snapdom: a modern and faster alternative to html2canvas

Why a replacement?

What Snapdom does differently

Visual fidelity

Fonts and icon support

DOM state

Performance-focused

Coming soon: Plugin system

API at a glance

Try it

A practical way to test HTML and CSS in real-time using only CSS.

Orbit a CSS framework for crafting simple or complex radial interfaces.

I built a paint app where the PNG is the canvas (no