We just went live on DevHunt — launch week runs through Monday: https://devhunt.org/tool/widget-storm
TL;DR: Widget Storm is a library of embeddable web widgets (countdowns, dice, flip cards, guestbooks, todo lists and more) that render natively into your page's DOM — one script tag, no iframe, free to use.
Why "no iframe" is the whole point
Most embeddable widgets arrive in an iframe: a sealed box with its own document, its own styles, and a fixed frame you end up fighting with.
Widget Storm renders the widget directly into your DOM instead:
<script src="https://widget-storm.de/wgembed.php?w=wg_countdown&a=WidgetStormSystem&lang=en"></script>
That single tag injects real markup into your page. Which means:
- Your CSS reaches the widget. Restyle it like your own HTML — colors, fonts, spacing. Our demo video shows a host page recoloring a countdown widget live, purely with host CSS. An iframe structurally cannot do that.
- It inherits your layout. No fixed-size box, no surprise scrollbars, no postMessage resize dance.
- Self-contained delivery. Each widget ships with its own JS and CSS, scoped under its own class names.
What about safety?
Rendering user-authored widgets without an iframe raises an obvious question. Two answers:
- Open widgets are only rendered at origin if their stored code is provably inert — no active server code — verified before embedding.
- User-created dynamic widgets execute in a WASM sandbox on the server (wasmtime + PHP compiled to wasm32-wasi, deny-by-default: no filesystem, no network, no exec — pure compute over widget parameters).
Background
Widget Storm has been quietly building embeddable components since 2008; this launch is the modernized platform — bilingual (DE/EN), Composer distribution for PHP integrators, and a browser-based widget editor ("Station").
If that sounds useful, an upvote or honest feedback on the DevHunt listing during launch week helps a lot: https://devhunt.org/tool/widget-storm
Questions welcome in the comments — the maker is answering on DevHunt all week.
Prefer server-side rendering
If your site runs PHP there's a deeper path than the script tag. You download your wgclient.php, then call $wg->get('name','author',$params). That renders the widget into your server HTML, so it lands in the initial markup. Search engines see it and it works with JavaScript off. Leave the mode empty for the whole widget, or ask for just css, js or php and place each part yourself. The full breakdown is in Three Ways to Put a Widget Storm Widget on Your Page.
Top comments (2)
Super interesting that these are native widgets without an iframe! Are you leveraging Shadow DOM or custom elements for isolation
Neither, actually. There is no shadow root and no custom element anywhere in it.
Two separate things do the work. Everything inside a widget uses prefixed classes and the styles only ever target those, so nothing leaks out onto your page. For the other direction there is a placeholder in the widget source that gets replaced at render time with the widget name plus a hash of that instance. You put it in your CSS and JS selectors and every copy is scoped to itself, which is what lets you drop ten of the same widget on one page without them fighting over styles or scripts.
The honest trade-off is that host CSS can still reach in. That one is on purpose. The whole point is that your stylesheet restyles the widget like your own markup. Shadow DOM would hand me isolation for free and take exactly that away, so I went the other way and did the scoping by hand. Good question, that trade-off is really the centre of the thing.