Sono due API diverse che consentono di accedere allo stesso flusso di blocchi di dati. L'API 'readable' è stata introdotta nel nodo 0.10.0 come parte di "Streams 2", quindi se la cerchi, dovrebbe essere d'aiuto. Il nocciolo della questione è che l'interfaccia 'readable' consente una gestione e buffering dei dati molto più semplice.
L'esempio 'data' chiama la tua funzione con un blocco e non hai altra scelta che gestirlo, altrimenti sarà perso per sempre. Nell'esempio 'readable', la funzione ti dice che i dati sono disponibili, ma puoi leggerli in qualsiasi momento. Ciò consente al sistema sottostante di sapere se i dati sono stati gestiti o meno, quindi è molto semplice supportare un concetto chiamato backpressure.
Ad esempio, in un flusso di rete, se un client invia dati tramite una connessione TCP a un server e il server è molto occupato, riceverà gli eventi readable, ma potrebbe scegliere di attendere i dati fino a quando non lo leggerà ha effettivamente le risorse per gestire i dati. Non leggendo i dati, il flusso lo bufferizzerà e man mano che quel buffer si avvicina a una dimensione massima, il flusso smetterà di leggere i pacchetti dal sistema operativo per evitare di occupare troppa RAM. Quindi il sistema operativo inizierà a rilasciare pacchetti e, poiché i pacchetti sono stati rilasciati, il client che sta inviando i dati ridurrà la velocità con cui invia i dati per cercare di ridurre la quantità di pacchetti.
Questo è tutto tecnicamente supportato con l'implementazione "V1" del flusso precedente, ma era molto più difficile da fare.
Quindi, in sostanza, se ci si aspetta un sacco di dati, l'utilizzo di 'leggibili' o la progettazione dei flussi da collegare è una buona idea, ma se si stanno solo leggendo bit di dati da un terminale, è probabile che si vedrà differenza zero.