Thanks to you and floitsch for answering. My concerns have been allayed about the DOM, and cutting up a program into components. I don't want to focus overmuch

Thanks to you and floitsch for answering. My concerns have been allayed about the DOM, and cutting up a program into components. I don't want to focus overmuch on the specifics of the Google Analytics example, but it's illustrative so I'll continue. While GA can be isolated, if you want it to track any events that involve your script code, they need to call out to the API that GA loads onto the page. Its their intention that they can push code updates to my page (which may change how it communicates to GA servers), without me needing to redeploy my own code. The analytics world is now proliferating with a number of script-loader services that serve the same purpose: update tracking (including interacting with other parts of the page), without integrating into the deploy process. There are plenty of arguments that this is a Bad Thing, but nonetheless enough people are willing to pay for this service to keep afloat multiple companies where that is their only product. It's totally possible to load scripts like that in via the JS FFI, especially ones with a well-defined API. But, if both parts are separately Dart, it would be nice if they could integrate more easily than round-tripping through JS. Among other things, it would be nice to have the type information carry through. So that's where I'm coming from, and the use cases I'm interested in. And if you say that those development practices are something you don't want to encourage I wouldn't entirely disagree. It does seem like something rather different than the approach your taking, and the best way to reconcile it would be for library authors to publish a header file for functions/types that Dart2JS could assume to exist. Dunno if that's a route you would want to go.