We recently moved a production B2B app from Elm 18 to 19. What we discovered unfortunately after the fact, was that Browser.application’s behavior & timing of taking over the tag doesn’t play well with popular analytics injection approaches.
Our HTML loads two separate JS bundles. The first is our app code, which in turn triggers a parallelized request to Segment.com for a combined analytics JS bundle. We stall the loading of our Elm app until the Segment bundle has made some progress, so that we can initialize our Elm app with the real-ID or anonymous ID of the current user.
We additionally use Segment to load Intercom (live chat floating widget) and it does so through a few iFrame tricks eventually resulting in a child-of-body div tag representing the floating widget.
The problem is that that either the iFrame or the div for Intercom get blown away once Elm takes over the tag as a result of using Browser.application.
My industry-take is it’s going to be hard (impossible?) to work w/ Elm in full Browser.application mode because so many of these ecosystem analytics/widgets/etc need to store their work in a private child-of-body DOM node.
I think I understand the rationale for Elm so completely taking over, but I’d hope there might be another best-of-all-worlds where Browser.application can leave nodes it didn’t generate alone, and if another “Full browser app framework” modifies URL out of band, perhaps Elm can warn/complain in the manner it does when someone uses the href attribute with JS in it (it triggers an XSS alert)