Everything in the programming world is an abstraction. Concerning programming languages, we can distinguish different designs and approaches to a code that allow us to achieve our goals. Various paradigms and their subparadigms introduce certain advantages and thus may serve as perfect solutions to specific problems.
Web development is no exception; it is the structure of abstractions over abstractions that simplify the creation of web services. Still, to understand the idea, we need to go back to the beginning and look at how different designs influenced today’s front-end environment.
HTML
Our journey begins with the incentive to create a system for sharing documents, and the Internet seems a great place to do this on a broad scale. Those documents have to present not only text but also visual and logical elements that we can distinguish and correctly display alongside the text, like headers, tables, etc.
Let’s consider for a moment what kind of language would suit those requirements. We need a language to easily structure our content, with no other interactions with it besides linking one document to another. It looks like a perfect example for a confined and specific language, because we have a limited number of visual cases, and also a static language, because we have no functional logic. Thus, it is very likely that our potential solution should be a declarative one.
The HyperText Markup Language (HTML) is introduced in 1993 to define the text and document structure using named elements and to visually present it to the audience. This markup language belongs to a declarative paradigm and, to be more specific, it belongs to the family of domain-specific languages. It looks like our premeditated solution was correct.
CSS
The story follows as new needs appear. Properly structured HTML is excellent for creating standalone documents. Still, pretty quickly, engineers realize that we need to separate the presentation layer from the structure layer. That is to reuse specific visual solutions across different documents and to add the possibility to effortlessly present the same content in different flavors.
Again, we may think about the best possible solution. Our domain does not change, because we still have a markup language to work with. However, this time, we need to separate visual definitions from the structure and reference specific elements to connect those two abstractions. A pretty reasonable solution would be to introduce another declarative language, which is also static. It would accurately define how our content should be presented and refer to proper elements via universal selectors.
Cascading Style Sheets (CSS) is introduced in 1996 to describe the presentation layer of HTML and other markup languages. It standardizes the visual aspect of documents and allows moving its definitions away from the content itself. Still, it is interconnected with the HTML declaration, because specific elements may accept only certain attributes that correctly apply to them.
JavaScript
Another essential invention appears due to the increasing demand for making static markup more dynamic. It is not enough to have a well-structured text, and a beautiful one too, hence engineers wanted it to be alive.
The main requirement is to await users’ interactions and perform somehow at that time, for instance, move elements around and display or hide some of them.
How do you approach a task like that? Well, truth be told, we do not have too many options. First of all, it has to be an interpreted language, because we want scripts written in a source code to execute when the browser interprets the document and creates Document Object Model (DOM). Then, we need to have an event-driven code with most of the imperative features, like loops and variables, to move elements around quickly. An obvious addition may include some of the object-oriented ideas, so we match the DOM design. Lastly, we need some clear, well-known syntax, like C and Java, to make everyone fall in love with the new invention.
JavaScript programming language appears in 1995. Initially, it is not designed to produce substantial dynamic websites. It is the tool to handle user interaction and modify DOM elements. Later in development, the language reaches the point where we may fetch additional data asynchronously and introduces run-time compilation to improve speed.
Nevertheless, considering its event-driven design based on DOM elements, it is a predominantly imperative, object-oriented language. Things like first-class functions allow writing a functional code, but the functional paradigm is at best a second-class citizen.
Conclusion
This was a short story of the beginning of web development. It is a perfect example to demonstrate how we can use the advantages of certain paradigms and implement them to create languages precisely fitted to our needs. Learning a little bit of history and understanding its roots may help us to realize not only how did we end up in the place we are now, but most importantly, to recognize why the front-end development is shaped like that.
Of course, this is only the beginning because web development is a vast and quickly evolving field. We will go into further design decisions in the next post. See you!