Thanks for the shout-out, @J805! Yeah, @hacker, it’s sort of possible. What my GRUPZ site does is renders vacation rental calendars (or a vacation rental booking widget) that users then embed in their sites via an iframe.
Basically how this works is that “allow iframes” is turned on (this is found in the settings of your app). Unfortunately, this is a server setting and we don’t have access to more granular controls, so this makes every page of your site iframe-able. (This may not be desirable, but there’s nothing you can do about it.)
And then, I’ve designed pages that represent the widgets. These are standard Bubble pages that use the built-in “send data to the page” functionality to display the calendar (or booking widget) for a specific property.
My app then gives users the iframe code to “embed” these pages on their site(s) so they can just copy and paste into whatever tool they use for web site design (these days, typically a hosted service like Squarespace or GoDaddy or whatnot, but some users host themselves).
And, et viola, they have a widget in their site. (I make this sound simple – and it is, conceptually – but there’s a lot more that goes into it. But the basic idea is simple.)
NOW…
It would be cool if, instead of offering users an <iframe>junk</iframe> tag, I had a lil’ javascript file they could add to their site instead, that would (similar to Drift, or Intercom or whatnot), put a little icon in some corner of the page that would (when clicked), pop up the widget instead.
You can’t really build that in Bubble. You would have to craft your own code to do that on the user’s site. While the thing you pop up could in fact embed a Bubble page in itself, at that point you might as well just make an API call to Bubble to fetch whatever data you need from the Bubble database and render it your client-side widget.
Here’s a page with a demo booking widget on it: Booking Widget for BLUE BELL KNOLL TEST 1
NOW, the thing to understand here is that this page is pretty cool (despite the old-skool design of the calendar - more on that later). It loads pretty fast and there’s a lot going on (including the blocked dates are fetched by reading some external calendar – an airbnb calendar in this case, but it can be any ical calendar, and this feeds into the Bubble database, and this relies on an external function running on a FaaS service – I’ll actually be migrating that back to Bubble as an SSA (server-side action) sometime soon, but at the time of launch, I had to do this externally).
In the very first version of GRUPZ, this widget was actually entirely constructed in Bubble (with maybe a line or two of JavaScript, executed by Toolbox / Run JavaScript). So it really was “no code”. And I’m quite sure that this was the most complex client-side thing that had ever been built in Bubble. (It probably still is.)
Also, the technique here of having a range picker that doesn’t require you to “first select start date, now select end date” was entirely novel at the time. (Airbnb had not done it yet.)
But it was dog-ass-slow (as I would say). And this was because Bubble basically locks you out of iteration. The effort it took to make it work was months. (Months that would have been better spent doing almost anything else.)
So I eventually re-wrote the calendar component as a Bubble plugin (now available as Calendar Grid Pro) and it’s literally orders of magnitude faster than the Bubble-built prototype.
Now, before I set out to do that, I did have some JavaScript skills (but they were from way back in the almost-pre-jQuery days – JS itself, and the web in general had progressed wildly since I’d last hacked around in that way) and so there was a lot of learning involved in making the plugin work the way I wanted to. But the total effort was just weeks, not months. (Lesson learned, eh?)
So, long story short, you can do some of this kind of thing in Bubble, but not without also having (or developing) some knowledge of “real” web development.
The main thing about Bubble is that things are super easy, IF (and this is a big if) there’s a plugin for client-side things that you want to render in the page. And, IF you can accomplish other tasks in the platform itself, or understand how to code the extraneous bits yourself.
All of the above is why we today have things like List Shifter and Calendar Grid Pro and my other littler plugins.
Yadda yadda yadda, I could go on, but tl;dr: You can build stuff you can embed via an iframe for your users (and you can make a dollar from that). To build a more modern type of overlay widget entirely in Bubble isn’t possible without going substantially outside of the vanilla Bubble ecosystem, but you could build such a thing that incorporates Bubble on the backend.
(The question however, is whether that is a particularly good idea. It’s probably not in most cases.)
CODA:
Oh, I almost forgot: The GRUPZ booking widget and calendar widget look a little old-skool. But even in the first (entirely Bubble-built prototype), I had paying customers and I didn’t want them to freak out over things wholesale changing. So one of my design criteria for Calendar Grid Pro is that it had to be able to emulate the exact look of my shitty prototype design. Ha! I literally deployed this massive change and just put up a changelog article saying, “Your GRUPZ widgets just got (much) faster.” The replacement pages are like 99.5% pixel exact of the original prototype, even though I think they are kind of donky-looking. Don’t mess with success, ya know?
At some point, I’ll deploy a sexy configurator that allows you to select from way more modern designs, but basically my customers don’t care about that. 
Most people using CG Pro make things that look 100x better. Go figure.