I did a straight port of Michael Schierl's OberonXref, originally implemented in Java. The resulting out.app.htm has the benefit of being malleable, unlike the JAR, and since it's a triple script, it can be built from source on any machine and run on any machine, even if that machine doesn't already have platform-specific tooling (like the JDK and related tools) or runtimes (like the JRE, etc.). There were some sore spots that were apparent from the porting process, though.
When porting code, even if just a boring "straight" port, static initializers are your biggest enemy.
Lack of typing can be a huge pain, even if you're just doing almost rote copying as I did here. Most of the problems I encountered that didn't have to do with working around the original project's use of static initializers had to do with typos I made. Some of this can be ameliorated by just dumping the bundle into VSCode and fixing some of the errors. (Side note: I had to rename the bundle away from .htm to .js, otherwise VSCode wouldn't handle the t-blocks well; this is a VSCode bug, which should be fixed to match actual browser behavior). Some friction occurred prior to that, during the translation process, especially while I was mentally mapping Java's collections to ECMA-262 data structures, and I didn't know what shape was on the other end of a binding, so I had to traverse up to find the original assignment, and then inevitably flip over to the Java source and look at its type annotations. Losing track of types isn't something that happens much when working on my projects, but I expect it will be a recurring problem especially when porting third-party code while mostly operating in a mindless drone mode.
For highly relevant perspectives on both of these, see Being a polyglot programmer on Project Nayuki. (Project Nayuki in general looks like it will be a great resource for seeding the corpus of triple script modules.)
The typing situation is probably more pressing than I originally thought, but I don't think now is the time to start unveiling even tentative plans for the dialect's "final" typing design. We can punt, I guess, and just advise people to make judicious use of jsdoc-like annotations, which I suppose should serve as "good enough" for our purposes right now, without torpedoing our future work.