This project is certainly mind-blowing when you first encounter it, but there's nothing magic going on. I'll start with a simple explanation, then try to explain as detailed as I can. There will be gaps and inaccuracies since I'm working off the minified source code, I'm not a Linux kernel hacker, and it's been a few years since my last computer engineering course.
My Attempt at a Simplified Explanation
jslinux is essentially a complete computer implemented in software, specifically JavaScript. This is of course known as an emulator. This particular version is setup to run Linux, but in theory it could run other operating systems instead.
The emulator (JavaScript, ~90KB minified, ~7000 lines formatted) is loaded into the browser. A version of Linux was previously compiled into machine code for an x86 processor is loaded and copied into a big array of integers that acts as the emulated computer's RAM. The emulator CPU is then pointed to the first instruction of the machine code and told to start interpreting the instructions (such as reading/writing RAM, doing arithmetic and logic operations, jumping around to different instructions, etc). Sometimes it will write data (like the system log, or a shell command prompt) to the "terminal" via another piece of JavaScript code that simulates a serial port and a terminal using the browser DOM. Your key presses are also sent back to Linux via this simulated serial port.
More Technical Explanation
At a high level, jslinux implements hardware emulators in JavaScript for the minimum hardware necessary for booting an x86 Linux kernel. This includes the CPU, MMU, RAM, interrupt controller, interrupt timer, serial port interface, terminal emulator, and a few other little pieces.
CPU
The "32 bit x86 compatible CPU" emulator implements all of the common x86 instructions necessary to boot Linux, but lacks certain features like a FPU (which Linux can emulate) and is much simpler than a modern physical CPU (which has all sorts of crazy optimizations that wouldn't make sense in an emulator, as well as multiple cores, etc).
There's a JavaScript object that holds all of processor state you'd expect like the registers (EIP, EAX, etc; look at the "dump" method) as well as references to the memory arrays (see "RAM" section) and IO controller.
This object has a method called "exec" that accounts for the vast majority of the project's code (~6000 LOC). This method implements most of the logic for the CPU: things like instruction decoding (look for the massive "switch" statements), the ALU, reading/writing to memory, etc.
"exec" takes an integer argument specifying the maximum number of instructions to execute, and returns an integer status code telling the caller why the processor stopped executing. JavaScript execution can't be interrupted, so we occasionally need to stop to check for interrupts (additionally modern browsers will also complain if your JavaScript executes continuously for too long).
The CPU object also has a method called "load_binary" which loads a file over HTTP using a synchronous XMLHttpRequest and copies it to RAM at the specified address.
RAM
The "physical" RAM in the emulator is 32MB and is implemented as an ArrayBuffer Typed Array (http://www.khronos.org/registry/typedarray/specs/latest/), along with Uint8Array, Uint16Array, and Int32Array "views" (backed by the same ArrayBuffer) for efficiently accessing different size (1, 2, or 4 byte) chunks of memory.
In theory jslinux could have been implemented using regular JavaScript arrays, but Typed Arrays are far more efficient for dealing with binary data.
The processor object also implements the MMU (memory management unit) for translating virtual memory addresses to physical addresses, including a TLB (translation lookaside buffer).
IO
[I'm a little unclear on how the IO system works]
Emulated IO devices have several common methods including "ioport_write", "ioport_read", "update_irq".
Devices include the programmable interrupt controllers ("pic"), programmable interrupt timers ("pit"), real time clock ("cmos"), serial port ("serial"), keyboard ("kbd").
An instance of the terminal emulator (which displays the console in the browser and captures key presses) is connected to the serial port to provide the terminal you see when you run jslinux.
Terminal Emulator
The terminal emulator, term.js, translates the stream of data from the serial port into what you see on the display. A basic stream of normal ASCII characters simply gets scrolled across the virtual terminal display, but more complicated control code sequences get translated into cursor movements, colored text, etc.
The terminal emulator is also responsible for capturing keypresses and sending the appropriate sequence of bytes to the serial port.
In the browser the terminal display is shown using DOM elements, and keypresses are captured using DOM events.
Booting
Upon calling the "start()" function a new CPU object is instantiated, a 32MB buffer for RAM is created using the "phys_mem_resize" method, and all of the IO devices and are initialized.
Three binary images, "vmlinux26.bin" (an uncompressed Linux kernel), "root.bin" (the filesystem?), and "linuxstart.bin", are loaded into that RAM using the "load_binary" method. The EIP register is set to the beginning address of where "linuxstart.bin" was loaded, EAX is set to the size of RAM (32*1024*1024), and EBX is set to the size of "root.bin".
[I'm not sure what goes on in "start_linux.bin"]
A JavaScript timeout is scheduled which will begin execution of 100,000 cycles. "update_irq" on the interrupt timer is called, then "exec" with the number of remaining cycles in this set of 100,000. This is repeated until the 100,000 cycles have passed, at which point another timeout is scheduled to begin another 100,000. This gives the browser a chance to update the UI, and prevents "long running script" warnings from being displayed.
Linux
And this is where the jslinux story comes to a close. There's plenty of information on the Linux boot process elsewhere and I believe it should mostly apply to jslinux as well.