I want to be able to simply send bytes into one end and come out the other end, and vice versa. Why doesn't the below work?

I think it's because you simply need to switch the order: start the listener first and then send the data (just like you did in your own pipe example--you started listening first):

# Absolutely first, configure each port using `stty`, as you already
# do:

# set both serial ports to 9600 8n1
# `-parenb` means no parity,
# `-cstopb` means 1 stop bit
# cs8 means 8 bits at a time 
stty -F /dev/ttyUSB0 cs8 -cstopb -parenb 9600
stty -F /dev/ttyS0 cs8 -cstopb -parenb 9600

# THEN, do in this order

# first, in the receiving terminal, start listening
cat < /dev/ttyS0

# then, in a separate terminal for sending, send the data
echo "asdf" > /dev/ttyUSB0

I am pretty confident my answer is procedurally correct, meaning: if you blindly follow it, it will work.

But, the question still remains: why? Why do you have to start listening first? Doesn't the Linux kernel buffer for you? If so, shouldn't the data just be sitting there in the buffer ready to be read? Clearly it isn't, else writing first and reading second would work. But, it doesn't.

I'm guessing here, but I think the answer here is that when the driver receives data, it first checks to see if the receiving pseudo-file at /dev/ttyUSB0 is in an opened state, held open by another process. If not, the driver discards the data, since no one is there to receive it. If the file is open, it allows the process which has the file open to read the buffered data.

Key differences between sending over a serial port and sending over an inter-process-communication (IPC) pipe

This is different from your pipe example where you make a pipe with mkfifo. I just checked, and in the pipe example, you can either start listening in one terminal first or send to the pipe in the other terminal first. It doesn't matter. It works in both cases.

If you write first, the write blocks and waits until a process reads from the pipe. If you read first, the read blocks and waits until a process writes to the pipe. This is confirmed by the Linux documentation for C's mkfifo() function, which the bash mkfifo is almost certainly based on. See man 3 mkfifo (emphasis added):

Once you have created a FIFO special file in this way, any process can open it for reading or writing, in the same way as an ordinary file. However, it has to be open at both ends simultaneously before you can proceed to do any input or output operations on it. Opening a FIFO for reading normally blocks until some other process opens the same FIFO for writing, and vice versa.

This is different from how serial ports behave, however, probably because the serial ports on each end are expected to be controlled from different machines, unlike FIFO pipes, whose read and write ends are expected to be controlled from the same machine. In the latter case, the kernel can easily track when one process tries to read and another tries to write, since it controls both ends of the pipe...hence, it allows either to block.

In the serial port case, however, the kernel has no idea if another device is listening or going to send, so it won't block on sending. To be clear: when writing to a pipe, the write is blocked until a listener is present. But, when writing to a serial port, the computer has no means of checking if a listener is present, so it never blocks! It just sends. Instead of blocking if no listener is present, data sent over serial while no-one is listening is just lost. Again, this is different from pipes, where my experiment and the documentation above both confirm that a process trying to send data over a pipe is blocked until a listener is present to read that data.

References and "see also":

1. I'm actively learning as I write this, documenting various findings in my eRCaGuy_dotfiles repo here, in case you're interested: serial_terminals_README.md.
2. My demo code: eRCaGuy_hello_world/bash/ipc_pipe_fifo.sh
3. man 3 mkfifo: https://man7.org/linux/man-pages/man3/mkfifo.3.html

it is not an existing port, uncheck connect to existing pipe, so it creates a new one.

Thanks

I find more usefull this one:

type com1: >> data.log

The main advantages versus a copy is that you can append data to an existing file and you can open the file with another application (notepad) to see the contents.

I tested this code with the serial port device that uses RS-232 protocol. Its advantage is that you don't need install the third package from npm.

var recVal = '';
mySerial.on('data', function(data) {
  if(data.indexOf('\n') != -1) {
    io.emit('serial:data', {
      value: recVal
    });
    console.log("Data: ", recVal.toString());
    recVal = '';
  } else {
    recVal = recVal.concat(data);
  }
});