Granted, this case is a bit different, because, looking at the source code, the script itself loads really quickly, you've just also got an onload event listener in there that does some really hefty logic. I would call this current design buggy, because it prevents the end-user from interacting with anything, and causes those browser prompts asking the end-user to kill it.
A better design would be to:
do an occasional pause during this long-running task, to give the browser a chance to let other things execute for a bit. This will keep the page responsive, and make it so the browser isn't constantly asking the user to kill the page. I noticed in the code that you already figured this out and had such a solution coded up, you just currently have it disabled.
If we assume a later-run script needs access to functions exported from this one, we ought to design this API to facilitate this. There's multiple ways to do this, but @mhofman's solution works fine here, of just having some sort of event exported, that future-running code can listen to know when you're done building the thesaurus, and when other functions you export can be used.
So, yes, it's certainly possible to make long-running stuff happens when a script loads, or during an on-load event, but I wouldn't call this a "use-case" since it makes for an extremely poor user-experience, and can be circumvented by breaking up the long-running task.
I think you misunderstood. This is a case of code continuing to execute on a page after a script has been preempted (a non-catchable error). Execution resumes after preemption at least: when the dev console triggers code, when an animation frame / interval / timeout lands, when the user interacts with an element that triggers code, when a script that began downloading prior to preemption finishes post-preemption, and maybe under other circumstances. Non-spec behaviors are hard to experiment with.
Also, it's not "buggy", from the readme:
modified as a browser load-test ... to render the page unresponsive during initialization. User agents will react differently, including potentially: Asking the user to stop the script or triggering an out-of-memory error.
(To get the "normal" behavior, with a load bar, you would set USE_LOOP = true in the source; I disabled it specifically to create this preemption example.)
No host would then be allowed to perform any further execution inside the agent that failed this way.
I would say that unfortunately what to do in these cases has been left unspecified, which leads to these problematic cases. Thankfully all these example are web host integration caused. I wouldn't be surprised however if a simple host callback from the 262 spec may not also be allowed to continue execution, for example a finalization registry callback.
Anyway, thanks for the report, we knew the current state was bad, but I didn't realize even "uncatchable preemptions" are also botched.
When you say "this is a case", do you mean "use-case", as in, "this is useful behavior that someone may want to do with public-facing software", in which case, I would lean on my arguments above, stating that, no, this behavior makes for an extremely bad experience for the end-user, and it can be circumvented by inserting pauses into the execution of the long-running task, and I would call this behavior "buggy" the same way I would call a program buggy if one of its many processes would sometimes crash with a null-pointer exception - even if that crash was documented in the README I would still consider it to be buggy.
Or, does "this is a case" mean "it's possible to make this happen", in which case, yes, absolutely, this webpage definitely proves that bad scripts can be killed part-way through and yet the page can still be interacted with afterward. And, your README does state it's a "browser load-test", i.e. you're purposely trying to make a bad user experience just to see how the platform behaves, in which case, no, it's not buggy, because it's a special program that's doing its job of showcasing how browsers behave when given a long-running task that doesn't pause.
Just realizing that @mhofman was saying earlier that they would be interested in knowing more about the behavior of pre-emption mechanism, and then you replied with this example.
So, "this is a case" probably meant "here's an example for you @mhofman".
By the way, animation frames also survive page kills / reloads (and continue logging to the console). They interact with an outdated global context so they wont affect the context of a reloaded page and they can't keep re-scheduling themselves for long, but they can continue posting messages to workers and servers.