It's been over a decade that I really worked with Tk, but here some meditation on the subject.

I'll address it to you since I know that you are quite an expert on this subject.

so IMHO

1. Tk heavily relies on callbacks.

2. The aim of those callbacks is located somewhere between 2 extremes^₄
   • a) manipulating the GUI (e.g reordering elements)
   • b) interacting with the application. (e.g. access DB)

3. Since Perl doesn't run within browsers, there are 2 options for those callbacks
   • A) porting to JS
   • B) tunneling callbacks via http to the server¹

4. For different reasons one would mainly like to go
   • a -> A # performance
   • b -> B # complexity, server bound

5. While it certainly is possible to mimic most (or all) Tk-widgets in HTML&JS, it's pretty unlikely to have an AI which analyzes the code to split it into a) and b) parts.

6. The most likely solution is to design a meta-language (maybe even a DSL) which is already addressing these needs.

7. This meta approach would create the necessary output in either Perl/Tk or Perl+JS/HTML²

8. having a restricted sub-dialect (intersection) which reliably translates Perl <-> JS shouldn't be impossible.³

What ya think, did I miss something?

footnotes

¹) with different possible approaches for client-server communication:

• classic http
• AJAX
• Web-Sockets (bidirectional)

²) or even other targets like Perl/Tkx or Perl/Wx or even Lisp/Emacs or whatever

³) But this restricted "Perl" could look very strange, e.g. only allowing scalars and hence only array-refs and hash-refs like

$array->push($a,$b)   <->   array.push(a,b)

... or only allowing function scopes and no block scopes (JS does hoisting of lexicals)

updates

moved side-notes to footnotes.

more footnotes

^₄) somehow analogous to the MVC paradigm, making a distinction between template code (View) and pure Perl code (Controller).