Reactive programming

In computing, reactive programming is a declarative programming paradigm concerned with data streams and the propagation of change. With this paradigm, it is possible to express static (e.g., arrays) or dynamic (e.g., event emitters) data streams with ease, and also communicate that an inferred dependency within the associated execution model exists, which facilitates the automatic propagation of the changed data flow.

For example, in imperative programming, a := b + c would mean that a is being assigned the result of b + c at the time the expression is evaluated, and later, the values of b and c can be changed with no effect on the value of a. In contrast, in reactive programming, the value of a is automatically updated whenever the values of b or c change, without the program having to explicitly re-state the statement a := b + c to re-assign the value of a.

Reactive programming has been proposed as a way to simplify creating interactive user interfaces and near-real-time computing animation.t = seconds + 1 g = (t > seconds)

Because t should always be greater than seconds, this expression should always evaluate to a true value. Unfortunately, this can depend on the order of evaluation. When seconds changes, two expressions have to update: seconds + 1 and the conditional. If the first evaluates before the second, then this invariant will hold. If, however, the conditional updates first, using the old value of t and the new value of seconds, then the expression will evaluate to a false value. This is called a glitch.

Some reactive languages are glitch-free and prove this property.

For example, in a word processor, marking spelling errors need not be synchronized fully with adding or inserting characters. Here, differentiated reactive programming can be used to give a spell checker lower priority, allowing it to be delayed while keeping other data flows more immediate.

However, such differentiation introduces added design complexity. For example, deciding how to define the different data flow areas, and how to handle event passing between different data flow areas.

Evaluation of reactive programs is not necessarily based on how stack-based programming languages are evaluated. Instead, when some data is changed, the change is propagated to all data that is derived partially or completely from the data that was changed. This change propagation could be achieved in a number of ways, where perhaps the most natural way is an invalidate/lazy-revalidate scheme.

It could be problematic simply to naively propagate a change using a stack, because of potential exponential update complexity if the data structure has a certain shape. One such shape can be described as "repeated diamonds shape", and has the following structure: An→Bn→An+1, An→Cn→An+1, where n=1,2... This problem could be overcome by propagating invalidation only when some data is not already invalidated, and later re-validate the data when needed using lazy evaluation.

One inherent problem for reactive programming is that most computations that would be evaluated and forgotten in a normal programming language, needs to be represented in the memory as data-structures.

If an OORP language maintains its imperative methods, it would also fall under the category of imperative reactive programming.

Functional reactive programming (FRP) is a programming paradigm for reactive programming on functional programming.

The actor model (actors) is proposed to design reactive systems, often combined with functional reactive programming (FRP) and Reactive Streams to develop distributed reactive systems.

A newer category of programming languages uses constraints (rules) as main programming concept. It consists of reactions to events, which keep all constraints satisfied. Not only does this facilitate event-based reactions, but it makes reactive programs instrumental to the correctness of software. An example of a rule based reactive programming language is Ampersand, which is founded in relation algebra.

• Elm, a reactive composition of web user interfaces.
• ObservableComputations, a cross-platform .NET implementation.
• Quantum JS, a runtime extension to JavaScript that brings imperative reactive programming to the language, creating a whole new category in the reactivity spectrum.
• Reactive Streams, a JVM standard for asynchronous stream processing with non-blocking backpressure
• ReactiveX, an API for implementing reactive programming with streams, observables and operators with multiple language implementations including RxJs, RxJava, Rx.NET, RxPy and RxSwift.
• Rimmel.js, a stream-oriented JavaScript UI library designed to use with RxJS and Observables.
• Shiny is an open-source web framework by Posit PBC that enables the development of reactive, interactive web applications using R or Python, with various deployment options ranging from cloud-hosted services to on-premises containerization.
• Solid.js brings reactivity to JavaScript without changing JavaScript syntax semantics, along with reactive JSX templating.
• Svelte, brings reactivity in the form of a variant JavaScript syntax that looks like JavaScript but is naturally reactive where JavaScript normally isn't.

• Observable (computing), used in reactive programming

• Machine
• Assembly
• Compiled
• Interpreted

• Low-level
• High-level
• Very high-level
• Esoteric

• First
• Second
• Third
• Fourth
• Fifth