Теоретично реактивното програмиране се върти около събития. Дадено събитие настъпва и разни неща се променят. Чудесно, нали? А по-конкретно?

Идеята е да не се изпълнява един и същ код хиляди пъти, за да се види промяната. Например, ако имаш код, който изчислява на колко години си спрямо това кога ти е рождения ден и каква е текущата дата.

Пускаш програмата, тя изчислява на колко години си, връща изход и приключва. Изходът може да го видиш на конзолата, на уеб страница, където и да е. Ако приемем, че е на уеб страница - докато страницата е отворена, там ще пише едни и същи години. Ако страницата стои отворена до рождения ти ден, той мине, ти не затвориш страницата - ще виждаш стария резултат. Трябва да рефрешнеш страницата, за да повика на ново този фрагмент код, който изчислява годините.

При реактивното програмиране, всяка промяна в DateTime.Now ще предизвиква преизчисляване и респективно промяна в резултата на колко години си.

За да стигне това обаче до крайния потребител, трябва да бъде пуснато по мрежата, и за да е максимално олекотено, не трябва да караме потребителя да го иска, а ние да му го спуснем по мрежата. Т.е. намесваме и още дена концепция освен събитият (events), а именно - потоците (streams)

Примерът, по-горе не е чак толкова от парадигмата за реактивно програмиране, но го илюстрира доста просто.

В парадигмата за реактивно програмиране, хората са с стиснали ръцете да има Observer-и и Observable-и. Потокът от данни се спуска от една входна точка, регистрират се събития върху него (като евентуално е възможно да изникне грешка, така че се регистрират и събития за грешки) от различните записали се (observer-и). Всъщност това по-скоро се нарича функционално реактивно програмиране с асинхронни потоци и може би е нещото, което се има предвид, когато се каже реактивно програмиране. Тъй като първият пример може да бъде постигнат и без тази архитектура, която споменах.