I know I can include an iFrame on the other site containing the URL of the Meteor app page I want to include.
However, I want to know whether or not there is a better way, which would allow adding an HTML snippet.
The applications would be huge. For instance, creating a chat app in Meteor is relatively simple. So, it would be nice to include it on another site.
This is one of the few cases where an iframe is the way to go. It will have its own global scope, which, especially for a client like meteor, makes the best sense.
OK. maybe the example of the chat app was not the best. However, my question is more general; is there a way to create web widgets with Meteor without the need to use iFrames?
I’m interested to hear what you had in mind. I’m having trouble drawing up a picture of something like that myself. I can sort-of see what you’re saying, but I can’t think of anything.
You may be on to something really neat here.
Sounds like we’re talking about a stand alone client side template and code that contains all the ingredients it needs to handle client side events and data binding the meteor way but gets it’s data from the back end of your choosing.
Is that what you mean? A decoupling of the meteor front and back ends?
I can sorta see a lite version using REST or something instead of DDP for the data.
I have different scenarios in mind. For example:
One could be a widget that works just like a Meteor app, based on data from its own back end, but that can get queried based on the context on the host app (where the widget is installed). So depending on the context of the host app it will produce a different response. A simple example could be a weather widget, which shows the weather and other geo related information based on what the user is browsing on the host app (not just the geolocation of the user). This, of course can be done via iFrames exchanging data between the host app and the iFrame (the Meteor widget) using cross-domain messaging with postMessage. However, for more complex scenarios that could be complicated.
Another case could be to use the Meteor app to handle the Single Sign On (SSO) for a couple of applications that already exists. For example, a community site and a learning portal for the same community that were built with other tools. Both are independent sites, but they serve the same user base. In this case it would be nice to have a SSO solution that can handle the users on both sites 9which are the same), without having to create two different accounts and profiles. In this case the Meteor app is a service that handles the SSO and manages all the profile data. This can be extended to track what the users are doing and provide an engine for, say, contextual recommendations, or game mechanics (keeping a leader-board of users based on activities on both sites, etc.). In this case, it could allow developers to create their own services similar to Gigya, or hull.io and others. So it could have a set of (connected) widgets (front-end) that can be included in the host app(s) in different places. The SSO component in the header nav (in both sites) , the leader-board in some pages (in both sites) and some back-end communication (two-way).
you could always get a DDP client implementation from somewhere and write your embeddable in whatever language you like 
There’s a lot of creativity in that. I wonder, guys, if anybody could help out with this question? I’m not of much help. I thought this would be just a simple question about iframes!
In this stackoverflow post, Richard explains the three approaches and their pros and cons briefly. I’m not aware of more integrated and elegant (as in meteor elegant) solution. Would definitely like to. Especially using reactivity features in the rendered widgets.