When building a web page composed of different parts, the different parts can be combined at different stages of page rendering. Everything can either be loaded on the server before being returned to the client, or the client might receive the minimum amount of data immediately before loading individual components using JavaScript. The first way might be more straight-forward, but the latter both allows for looser coupling between services as well as allowing better user interation with the various page components. There are many scenarios where third-party JavaScript provides a good separation of concerns. You might be building a site with several secondary features like comment fields, feedback dialogs or shared toolbars, or you might be providing widgets or an API for other websites to consume. All of these cases are good candidates for writing so-called third-party JavaScript applications. When writing JavaScript that should run on known or unknown sites there are a lot of considerations to take into account. Should the application provide a near-seamless experience, giving the impression that the components are a native part of the parent page - like for instance a login widget, or should the widget give a branded and more isolated impression like the Facebook widget? Can the site be trusted? Should the web site or the users be allowed to interact with the application? Depending on the answers there are a number of different approaches, ranging from tight integration to sandboxed iframes. In this talk I will go into detail on the following subjects: - Loading and initializing the JavaScript application, - Running JavaScript and rendering HTML in unknown environments, - The balance between integration and sandboxing, - Communicating with other sites and components, - Security, and how to work around browser constraints