I've been building an embeddable-widget platform since 2008. I just modernized it and put it out there.
I've built embeddable web components since 2008, mostly quietly. A few weeks ago I finally rebuilt the whole thing as a modern platform and launched it.
The idea is simple. Most widget tools drop your content into an iframe. That keeps it isolated, but the widget never really fits your site, and you usually pay a monthly fee per widget. Mine does the opposite. A widget loads with one script tag and renders as normal DOM in your page. Your own CSS styles it like your own HTML. No iframe, no per-widget subscription.
Your page and the widget share one document, and that cuts both ways. Everything inside a widget uses its own prefixed class names, so its styles never leak out onto your page. Your CSS can reach in, and that is the point. It is how you restyle a widget like your own markup instead of fighting a frame. Each instance takes an id you pass in from your page, so you can drop the same widget more than once without the copies fighting, whether you embed it with a script tag or a PHP call.
If you run PHP there's an even cleaner path. You download your wgclient.php, include it, and call $wg->get(). One call and you get the whole widget rendered on your server, right in your HTML. Leave the mode empty for everything, or ask for just css, js or php and place each part yourself. It works with JavaScript off and search engines see it.
I'm still figuring out what actually matters to people who'd use this, so I'd rather hear real opinions than pitch. If you've ever embedded a third-party widget and hated how it looked or behaved, tell me what annoyed you.
Here's the link if you want to poke at it. https://widget-storm.de/en?utm_source=indiehackers
What I found interesting is that you're optimizing for a widget to stop feeling like a separate product.
The closer an embedded tool feels like it belongs to the host site instead of coexisting beside it, the more invisible the integration becomes—and that's often where the experience feels strongest.
That is the trade off I keep running into. The moment a widget renders into the host document instead of a frame it stops being a guest and becomes part of the page, and that cuts both ways. The host CSS can reach in, which is the whole point. The widget's own styles can just as easily leak out if you are careless about it. Prefixed class names per widget is what keeps that honest for me. When a widget needs to address a single instance it takes an id passed in from the host page.
The part people underestimate is libraries. A widget that quietly pulls a framework into someone else's page has already broken the illusion, however well it matches the design.
Where do you draw the line on how much the host should be allowed to restyle? I keep going back and forth on whether shipping any default styling at all is helping or getting in the way.
That’s an interesting tradeoff. I’d be curious what you’re seeing from users around that balance — what’s the best email to reach you on?
Easiest is the Contact Widget-Storm link in the footer of widget-storm.de, that comes to us.
Happy to keep this going here as well if you would rather.
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.