OWID's JS code does not run when captured in the Internet Archive

[marcelgerber]

Description

The way we load our JS using ES modules containing import statements is not currently compatible with the way the Wayback Machine is injecting custom JS snippets.

Expected behaviour

https://web.archive.org/web/20231104154417/https://ourworldindata.org/grapher/life-expectancy should load fine and be interactive, but it isn't and instead the grapher chart itself is blank.

Additional context

There's a thread on StackOverflow where someone ran into the same problem.

[marcelgerber]

I just sent an email to the Internet Archive (info@archive.org) outlining this problem, and will also put it here because it contains more context:

Hello, and thank you for the amazing work you're all doing at archive.org.

We ran into an issue where in the archived version of our site, our JavaScript code is not running properly, whereas it is running just fine on our end. This affects Our World in Data, our web publication, and the problem can be found at this link for example: Original version, Archived version

To get to the bottom, I have recreated the problem using a minimal demo website. You can find the code used in this CodeSandbox, and there's a deployed version of the same code here, and an archived version here. Notice that the live version is saying "JS is working just fine", whereas the archived one is saying "JS is not working".

Also, you will notice that on the archived version, the DevTools console will say "Uncaught SyntaxError: Unexpected token '{'".

That's because archive.org wraps the JS code in file index.mjs up as such:

if (!self.__WB_pmw) { self.__WB_pmw = function(obj) { this.__WB_source = obj; return this; } }
{
  let window = _____WB$wombat$assign$function_____("window");
  let self = _____WB$wombat$assign$function_____("self");
  let document = _____WB$wombat$assign$function_____("document");
  let location = _____WB$wombat$assign$function_____("location");
  let top = _____WB$wombat$assign$function_____("top");
  let parent = _____WB$wombat$assign$function_____("parent");
  let frames = _____WB$wombat$assign$function_____("frames");
  let opener = _____WB$wombat$assign$function_____("opener");

/// BEGINNING OF ORIGINAL CODE
import { wording } from "./util.mjs"

document.getElementById("app").innerHTML = wording;
/// END OF ORIGINAL CODE
}

While that's valid for CommonJS code, it isn't for ES modules code as we're using here, since the "import" statement can only ever appear in the global scope (and not wrapped inside any braces) in ES modules.

I saw another user run into the same problem and posting on StackOverflow about this.

Since ES modules are the "future" of JavaScript on the web and are only gonna go up in usage, it seems reasonable that this problem should be fixed.

I'm a web developer myself and am happy to help out in any way if I can help in investigating this issue - feel free to reach out.

All the best, Marcel

[danyx23]

Hey Marcel, we just talked about this in site issue triage. This seems like something we should tackle but also a bit of a hard problem. I'm assigning this to you as the person to carry it forward but you don't have to act on it at this point of course - just try to keep the conversation going on potential options in the next cooldown or similar. Thanks!

[ikesau]

Latest update for archive.org is that datapages kind of work (static embed works, FAQ is broken), but grapher pages don't.

Datapage:

Grapher page