Thread by @swyx

I was asked about why declarative programming is at the heart of "newer" trends in tech all the way up and down the stack, from React to Terraform.

I replied in an email but here it is as a quick thread:

DOM APIs are imperative, which encourages manual setup/teardown of event listeners, and intermingling of business and presentation logic.

At best this is just quite verbose and disorganized, at worst this creates runtime bugs and memory leaks. Lack of structure is painful.

We use React/Vue/Svelte to organize code into declarative components, help us organize the above and automate the boring parts. It also lets us *share code* much easier because the markup, state, and styles are scoped to the component, so they don't leak to the rest of the app.

This then lets us share reusable component libraries, which helps create a more productive ecosystem.

a key schism in approach to declarativeness is the concept of templates - React is against it, Vue and Svelte are for it.

(arguably more templating is more declarative.)

this allows Vue to make optimizations (

https://twitter.com/swyx/status/1199620649527832576?s=20

) for faster rendering, and Svelte to do fast serverside rendering. React understands this, chooses not to be declarative here, because it would involve custom syntax. React prefers to stick to "just Javascript".

another difference is what the reactivity declaration inside components are like. React errs on the side of rerendering all variables by default, prioritizing correctness and early bug discovery over performance. You optimize by declaring idempotence (eg with useMemo/useCallback)

Svelte errs on the side of not recalculating by default, prioritizing simplicity/performance over some intuitiveness (aka theres a learning curve). You selectively make things reactive by using the `$:` label .

projects like Terraform and Pulumi and AWS Cloudformation/CDK are the backend equivalent - "Infrastructure as Code" eliminates error prone manual setup ("clickops").

The "as Code" part is somewhat in flux, as IaC is in the midst of a swing back to imperative.

Anyway, IaC helps you treat your infrastructure like "cattle, not pets", making it easier to reason about because you always start from a clean slate, and its easier to spin up the same resources for testing, or to deploy to another region for scaling needs.

Declarative is NOT automatically "better".

Declarative is higher level (concise, correct, leaky), Imperative is lower level (fast, efficient, powerful).

People always want more power in declarative formats, adding ifs, loops, and vars, ending up with: beza1e1.tuxen.de/articles/accid…

Eventually declarative gets unreadable/slow and we swing back to imperative + General Purpose Languages for more control

Ultimately I think we swing between declarative and imperative every time we go up another layer of the software stack:

https://twitter.com/dan_abramov/status/1016786681880547329?lang=en

🤦‍♂️ In my eagerness to explore details, I forgot to say the thing EVERYONE says:

https://twitter.com/DanShappir/status/1320252614798430208?s=20

You mostly don't care about the HOW, so just specifying the WHAT is better. This lets us do *crazy* optimizations.. if we accept the black box.

This is fine - until it's not.