🚀 SnapDOM v2: Moving Toward a Fully Modular, Tree-Shakeable Release #312
Replies: 2 comments
-
|
I ran some tests to make the exporters (toPng, toWebp, etc.) fully tree-shakeable. The issue is that the final bundle size only drops by about 15%. Not a huge gain. I could go deeper and split out additional modules, like the plugin system, but even then the total reduction would probably stay around 20%. Another option would be to make the font module optional and tree-shakeable, which would reduce the size more significantly — but it would also introduce complexity for developers, who would need to understand exactly what must be imported for a proper capture. What do you think about offering that level of granularity? |
Beta Was this translation helpful? Give feedback.
-
|
I think the best strategy for now is to make |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi everyone,
A quick update on the roadmap. I’m shifting focus to one of the most important architectural improvements for SnapDOM: true modularity.
The goal is simple: let developers import only what they need.
This means the core will remain lightweight, and each export format will live in its own module. The existing convenience API (snapdom.toPng(), etc.) will stay exactly as it is, but implemented through small lazy wrappers so it no longer forces every exporter into the main bundle.
Why this matters:
• Smaller bundles and real tree-shaking
• A cleaner architecture for plugins and custom exporters
• A clearer path for new output formats (PDF, MP4, ASCII, WebGL, etc.)
• A more maintainable and predictable codebase moving forward
This modularization is the last major step before I publish the stable SnapDOM v2 release. Once the exporters are fully separated and the build refined, we’ll lock the API and ship.
Thanks to everyone providing feedback and testing. We’re close to reaching a solid, future-proof v2.
—Martin
Beta Was this translation helpful? Give feedback.
All reactions