Monib Asad Masud

Commented on Widget Storm · Jul 21, 2026

You're right about the trade-off. The short answer is I don't isolate at all. No Shadow DOM, no wrapper sandbox. That's on purpose. The widget goes into your page as normal DOM, so your CSS can reach in and restyle it. That recolor in the demo is just the host page styling the widget, not a setting inside it. What keeps it clean is naming. Everything inside a widget uses a prefixed class like wg-countdown-timer or wg-dice-face, and the styles only ever target those classes, never a plain div or button. So nothing leaks back out onto your page. Those wg-* names also don't clash with Tailwind or Bootstrap, so the widget looks the same on both. It brings its own CSS and JS and doesn't rely on anything from the host. The same widget can appear more than once on a page. Each embed gets its own id on the root element, either one you set or an auto-generated one, and the JS only looks inside its own root, never across the whole page. So you can add five of them without them interfering, and if you want to restyle just one, you target its id. User widgets that contain real PHP run server-side in a WASM sandbox, never directly on our server. Their JavaScript does run in your page, like any script you embed, so embed widgets from authors you trust. The one thing I don't block is CSS bleeding in, and that's on purpose. Normal host styles hit their own classes and leave wg-* alone, so in practice it holds up. If your page resets everything globally, like * { all: unset }, then yes, it will bleed. I'd rather keep the restyling, since that's the point, than lock it down for a page that's trying to break it. It's one script tag if you want to try it. I'm curious whether you can find a host-CSS case where it falls apart. There's one more path I didn't mention. The script tag isn't the only way in. If your site runs PHP, you include your wgclient.php and call $wg->get(name, author, params). That renders the widget server-side, right into your own markup. Leave the mode empty and you get the whole widget, CSS and HTML and JS. Ask for just css, js or php and you get only that part, to place wherever you want. No link or script tag needed. Since it renders on the server, the widget is already in your HTML from the first byte. It works with JavaScript off, and search engines see it. You scope it like the rest of your template, so the prefixed class approach only matters for the script tag path.

Commented on Widget Storm · Jul 18, 2026

Maker here — thanks for checking out Widget Storm! The core idea: widgets render natively into your page's DOM instead of being boxed into an iframe. One script tag, and the widget becomes part of your markup — so your site's CSS can restyle it like your own HTML (the demo video above shows a host page recoloring a countdown widget live). Free to use, no per-widget subscription. Under the hood every widget ships self-contained with its own JS and CSS, and user-created dynamic widgets run isolated in a WASM sandbox on the server. I have been building embeddable components since 2008; this launch is the modernized platform. Happy to answer any questions here during launch week — and honest feedback on the embed flow is very welcome.