React and a short history of programming paradigms and languages

React is one of the most popular JavaScript frameworks in 2020. It is used by thousands of developers around the world. React is a library based on the idea of reactive programming. It uses a declarative paradigm and automatic propagation of changes.

In this article, I want to go through the history of programming languages and concepts to show how old ideas from the past century evolved to current programming tools.

First of all, we have to start from Alonzo Church’s mathematics. He was an outstanding mathematician who invented “Lambda calculus” in mathematical logic. The main concepts of lambda calculus were rules of “Variable”, “Abstraction” and “Application”. What is important here is that with lambda calculus, he invented Turing complete. And lambda-expressions that were used to represent this calculus.

Lisp became a huge milestone in the programming language evolution, and it was originally created by John McCarthy in 1958 while he was at MIT, and influenced by the lambda calculus notation of Alonzo Church. Separately, it is worth noting a known feature of the language - “s-expressions” and parenthesised prefix notations. Lisp has plenty of dialects that are being used these days.

Haskell programming language was another big step in functional programming. Defined in 1990, Haskell is good for parallelism, concurrency, stability and performance. It had type classes as a way to add overloading. It also had a monad concept to handle side effects.

The rise of Object Oriented Methodology (OOM) began in the 80s. Together with the appearance of C++ language, this symbiosis became attractive for business. The subsequent development of languages such as Objective-C and then FoxPro shows that the paradigm has become popular. OOM methodology became widely available and popular in the 90s. Delphi, Java and other tools and technologies were heavily influenced by this methodology.

An FP renaissance in popular mainstream languages arose in the middle of the 00s. Complex architectures, problems with managing state, mutable data structures and multi-core systems evolution brought a functional paradigm shift in the languages used for business logic and for system programming. Real-world applications languages should be flexible, not only biased to one coding paradigm. My personal observation is that teaching programming in schools and universities pays attention to imperative programming. That’s why Basic, SQL, Java, Python and C/C++ are so popular. OOM methodology plus imperative mindset - this combination was successful on software development market.

But changes came. There were ideas for metaprogramming, writing DSL languages, rise of scripting languages like Lua, Python. And what developers wanted - flexibility. Languages required more than 1-2 paradigms. Thus, popular mainstream languages started to incorporate elements of flexibility.

Microsoft released LINQ as a part of .Net Framework in 2007. LINQ and C # was successful combination for data structures transformation.

Another project of Microsoft was F#, a language that was an attempt to reinvent functional programming.

Not only was Microsoft interested in functional paradigm, but Oracle introduced lambda expressions in Java language in the Java 8 release in 2014.

Even more traditional C++ language got lambda expressions support in C++ 11 standard.

Another paradigm of programming became RX and Reactive Programming, which is based on a declarative programming paradigm and the main concerns of it were data streams and propagation of change.

And finally, it’s worth it to talk about JavaScript, a multi-paradigm language by nature. Its syntax has been created to be like Java language, but not other scripting languages at this time or functional language like a scheme. But JavaScript is not so simple as it looks.

Many developers became frustrated when transitioning from OOP languages to JS. Their experience with more "classic" languages, like C++/C#/Java couldn't help them to be quickly productive in the new language.

Maybe that's why, maybe not, but Microsoft was trying to invent a new language to help these developers be in their usual context. Thus, with the emergence of the TypeScript language in 2012, the most common feature was types, interfaces and classes. The developers saw the designs they were used to, which they had used for years and began to use TypeScript instead of JavaScript. The popularity of the language has become a matter of time. It’s hard to find front-end job without knowledge of TypeScript. If you try, you can find them, of course. But TypeScript has become an industry standard in 2020.

This whole story ultimately leads to what we have on the JS market today; Reactive paradigm, types and type checking and functional paradigm.

The main concepts of the functional paradigm were such concepts as immutability, state, “side effects” and lambda calculus.

The idea began to spread in the community that mutation is not good in JS land. And we finally have immutability in JS. All new tools in ES5 (map, reduce, filter, some, any) and later in ES6 (const, let) made language more solid.

We also have plenty of immutable libraries in JS. The most known is Immutable.js, for persistent immutable data structures.

And finally, we should overview the current landscape of JS world. The most usual requirement for a front-end developer is knowledge of JavaScript / TypeScript, immutable data structures, principles of functional paradigm and at least one of most popular frameworks - React, Angular and Vue.

Now, after a short reading of the history of languages and their development, you can understand why the JavaScript language is what it is.

We also have WebAssembly. This technology is also noteworthy. It may well be that, with the development of development tools, we will abandon the TypeScript language and will use C#/C++ and Java or Kotlin to write front-end. Such technologies as QT for WebAssembly, Blazor (Microsoft) and Kotlin with WebAssembly as a target (JetBrains) are still in development, but they look promising.

I have more experience in React. Therefore, I would like to write some observations related to it. React became a synthesis of all these ideas. It has TypeScript support, it encourages functional programming, it also has propagation of prop changes and it’s declarative (JSX). So, there we have reactive principles. It all works quite well.

Over the past couple of years, we've seen React lean more towards the functional paradigm. React “hooks” and functional components instead of writing classes are most common practices of creating components in React these days. But when we use “hooks” there are not clearly “pure” functions. We also have “state” but in different syntax.

In my opinion, state mutability is not necessarily a bad thing. There are situations when we still need to have mutable data structures. It is also important to understand that the functional paradigm is just a tool and we shouldn't use it where we don't need it. That is, you do not need to rewrite all classes to functional components in your React application right now.

At the end of the article, I would like to add that all new ideas are associated with their development in the past. And what we call the new trend in functional development on the front-end was already 60 years ago.