not sure how you solve this, does asm.js also cover the regex engine?

I'm compiling a whole perl binary to WebAssembly, including the regex engine and everything. I haven't gotten very far on porting Perl's test suite yet, because it makes use of some of the stuff that isn't supported (e.g. qx and signals), but the tests I was able to run have looked good so far.

patching B::Deparse to emit native JS should be possible

That's an interesting idea, and perhaps something I could think about is how to optimize code like the example I showed on the website:

js('document')->getElementById('my_button')
    ->addEventListener('click', sub {
        js('window')->alert("You clicked the button!");
    } );
[download]

Running that invokes the JS/Perl glue three times (five if the callback is called), which isn't super efficient at the moment because it does a lot with strings and eval. One possible way to optimize that might be if there was a way to convert at least the first few method calls to

js('document.getElementById("my_button").addEventListener("click",func
+tion(){...})');
[download]

I'm open for discussions, you might also be interested in the work of Flavio Glock and his perlito.

update

A general approach for performance enhancements could be to run Perl your way and to replace time consuming inner functions with direct JS translations.(kind of JIT if you want).

From the Perl perspective these functions would have been monkey patched with XS code.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}

A general approach for performance enhancements could be to run Perl your way and to replace time consuming inner functions with direct JS translations.(kind of JIT if you want).

Yep, although I think it would only speed things up where the Perl<->JavaScript interface is involved, I suspect everything that's pure Perl may even be as fast or even faster than regular JavaScript, since WebAssembly should be faster than JavaScript, and it's a WebAssembly perl binary. OTOH, at the moment I just want to use this for UI's, so as long as button clicks etc. don't cause 100% CPU or noticeable delays, I'm not going to worry too much about performance just yet.

From the Perl perspective these functions would have been monkey patched with XS code.

Yes, the interesting thing there is that "XS" code can include JavaScript code ;-) See WebPerl.xs, a mishmash of C, JS, and XS... (and my first real use of XS too!)

time consuming inner functions

BTW, just another thought: As I said, my original intention with this was to be able to build user interfaces, so there's always the approach of moving the heavy work into a different process, in this case that would be the web server - even if that's running on the same machine, it'd still give a speedup for the heavy lifting.