Or just have the user load a rom locally, like I do with my little NES ROM painter[0]. Nintendo strikes down hard on emulation like this. Although I see why he chose DKC, that is one beautiful GBC game.
What would be even more interesting is a JIT-based emulator that worked by compiling bytecode into Javascript, then relying on the browser to compile it back into machine code.
A machine-independent, JIT-compiled JS emulator might actually end up being faster than some purely-interpreted native-code emulators. And unlike a purely native JIT emulator, it wouldn't need a compilation component (the browser would do that itself).
Obviously such a thing would be dramatically slower than a native JIT emulator -- but surprisingly few emulators are JIT-based.
(Possible catch: I know for a fact that some Nintendo DS games use small amounts of self-modifying code. This probably is true of previous generations, too.)
Not a good idea with hand-coded ROMs for CPUs that are in single-digit MHz that use interrupts liberally, it would cause code cache invalidation a lot.
Some stats for SML2 running (Audio ON (web audio for mac in about:flags for chrome, mozAudio for Firefox 4), scaling OFF):
Ported is different from emulated though. Ported involves altering the game itself to run on a different platform. Emulation is building a virtual version of the original platform that does "translation" of sorts between the original platform's methods/attributes/etc and the new platform, leaving the game itself unaltered.
http://www.zophar.net/pdroms/gameboy.html