Declarative vs Imperative - a Thoughtful Comparison
Published: 2019-06-26 14:14:55

You might see a lot of people talking that declarative is better because it is simpler and give an example like this:

declarative code (what would you like):
```
a tea
```

vs imperative code (what would you like me to do):
```
- boil water
- pour water into a cup
- add a tea bag to the water
```

One short line of declarative code vs three long lines of imperative code. Evidently declarative must be better. But is this a fair example? What if we modify it a bit:

declarative code:
```
a tea

```
vs imperative code:
```
make a tea
```

Not much a difference, is it?
So, is declarative superiority just a hoax?
Spoiler alert: no, but if you want to know the real reasons, read on.


The basics

With declarative code, we specify what we'd like - the end result or state.
With imperative code, we specify a set of steps - an instruction that we'd like to be performed.

What are pros and cons of both? From a developer perspective, when looking at the code we are mostly concerned about what the code does (the end result), not so much how the code makes it happen (the steps). That's why we tend to put imperative code like this:
```
- boil water
- pour water into a cup
- add a tea bag to the water
```
into a module with a meaningful name like `makeTea`. This saves a bit of time and effort needed to figure out what that three lines are all about. With declarative code we declare the final goal so we have this feature inherently. That's a slight advantage of declarative code - we immediately know the end goal, with imperative code the end goal is implicit (it is there but we need to analyze the lines to get it or otherwise comment the code, or put it into a function or a module with a meaningful name). 

The real advantage of declarative code is that it doesn't specify the starting point. With imperative code an initial state is implicit and mostly we start from scratch (which is the easiest way) like here:
```
- boil water
- pour water into a cup
- add a tea bag to the water
```
It implies that we are starting with cold water. What if we already had a hot water? It would get thrown away or would be boiled twice. A wasted effort.
With declarative code the system can be smart and reuse the resources it already has. The way of figuring out how to go from current state to the desired state is not our business anymore because we can't really specify the initial state in a declarative language - the state change is managed internally by the engine.

That's the real deal here:
- With declarative, you specify the end goal and let the system work it out by itself.
- With imperative you implicitly specify the starting state (or states if you want to be more resource efficient) by explicitly specifying a set of steps that lead to some final state.

What are some real-world implications of this?

Let's say we want some function that takes a string of HTML and renders it.
The easiest implementation would be:
```
const render = (html) => document.body.innerHTML = html;
```
The problem with this is that DOM is stateful, for example, the user might type something to an `<insert>` element and we want to preserve that. The above code doesn't care about what is currently in the `<body>`, it throws away everything and puts new content there.

You might've heard that React is declarative. In fact React `render()` function is declarative. It takes a description of how view should look like and figures out a way to make it happen. It is declarative because it takes a description as an input. It might work similarly to the code above - discard current content and replace it with the new one - but is much more intelligent and reuses the elements when it can.

That's the power of declarative. You only need to specify the desired state and let the system figure out how to get there. This is really important in places where resource reuse is important, where you can't just throw away everything and start from scratch like in DOM and network clusters because it takes this really hard problem of figuring out how to go from any state of the system to the desired state off your back.