I couldn’t find any references to the term in the first article and the first instance I found in the second sounds much more like the typical definition and upshot is simply that it is an additional layer of abstraction on top of classic FE code which historically has not been complex over the last few decades has become to complex to handle “imperatively,” i.e. without the benefits of specially tailored abstractions. I didn’t see anything that sounded like your definition, but I only skimmed.
tfwright
JKWA
Author of Advanced Functional Programming with Elixir
For me, DRY matters most when we’re codifying domain rules. Domain logic can drift when a rule is expressed in multiple places. In library code, it’s less about being DRY for its own sake and more about keeping the surface area as small as possible.
0
garrison
I guess that first article happened not to use the word “declarative” but it does describe the concept. You can find the term all over the place with React. The second provides a simple definition at the top but the rest of the article is about implementation details for React-likes so it’s not going to be as helpful.
The Wittens article has by far the most thorough explanation. Read the first two sections of that and see if it starts to make more sense. He uses a video game analogy in the first section and then provides a more detailed webapp example in the second.
0
JKWA
Author of Advanced Functional Programming with Elixir
There might be another way to look at this.
SQL has a limited set of well-defined operations. This makes it a good syntax for new database implementations, where they can start with a subset like select and filtering, then later add joins and window functions.
Ash and Ecto also compile their query DSL down to SQL, using it as an adapter across different database implementations.
0
tfwright
I’ve read that before start to finish, I think maybe you linked it last time we tried to tackle this 
. I like his explanation the best but am still unconvinced about the usefulness of the category. To me, the main example from the beginning involving tabs mainly shows the limitations of trying to maintain complex set of logic paths without relying on any abstractions to help. It’s not as if the example shows one abstraction that is somehow not “declarative” and then shows how a properly “declarative” abstraction would do better. It is simply an example of a suitable abstraction for the case.
It does seem like the peculiarity of the term “declarative” makes the most sense in contexts like the FE, where the complexity involved is often managing sets of interdependent “nodes,” each as you point out with their own state, so that the type of abstractions that prove to be useful are usually ways to concisely express a desired snapshot of related data, vs something like my router DSL example or your validation example. So maybe I can convince myself that this is a certain “style” of abstraction but isn’t that what we usually call a pattern?
1
garrison
It’s not necessarily about abstraction; or, rather, everything is an abstraction so this is vacuous.
The technique, very simply, is that when you have state changes you want to avoid mutating derived state manually. Instead, you want to shove everything down one codepath that recomputes the derived state from scratch. All of it, in one pass.
The first example he gives is the video autoplaying on a particular tab. What you do not want to do is have some tab click event handler that mutates the “video is playing” state. That’s imperative. Instead, you want the decision about whether a video should be playing to be downstream of the selected tab, e.g. by “re-rendering” the entire component from scratch. That’s declarative.
You do not need a framework to do this. You just need to structure your code the right way.
The reason most of the literature on this topic is from the frontend side is that frontend is harder than backend. How we ended up drawing this arbitrary line between FE and BE is beyond me, but for some reason all of the hard stuff ended up in FE. Because it’s the part the users actually have to use, I guess.
If you try to work on the more difficult stuff in backend (e.g. distributed reconfiguration databases) then I can confirm that the same technique applies and is useful. As I said, FoundationDB uses the same principle to avoid branching codepaths in its recovery logic. But their docs are terrible so I can’t link you a good source other than “trust me I know exactly how it works because I reimplemented the entire thing from scratch”.
What’s funny about “traditional” HTML apps is that they are rendered entirely declaratively. They take URL state and output an entire page. It was only once people started manipulating stuff with XHR and JS that things went off the rails and they had to invent React to restore the declarative nature they had lost.
The difference between React and a standard HTML server render is that React is incremental, but that’s actually a performance trick. It is, in reality, too slow to re-render an entire HTML page for every little interaction.
0
derek-zhou
tfwright
Well, that’s my point exactly. If declarative in essence is just about abstraction then it’s vacuous. What continues to be difficult for me to see is what defines a declarative abstraction precisely. In my judgment most existing definitions are not cogent, and the examples too non-specific.
The definition you’re getting out is more promising, and maybe I need to read through some of this material more closely, but this still sounds a bit too general and too specific at the same time. It clearly is something different than what most people seem to mean by it, which is frankly the use I have the most problems with. It might be there is a proper use of this term that has been diluted more and more as its use has spread, especially into the BE.
I mean, it doesn’t have to be 
but yes in the last decade or two the pursuit of more UI features has made the web a lot more complex on the FE (personally not thrilled tbh). One way to rephrase my question might be, what is it about this new FE complexity has given so much force to the concept of “declarative” programming? How does the term itself help steer us in the right directions when making architectural decisions on the FE? Even between frameworks?
I have been locked into React for years, but I’ve really like the spirit of what I’ve seen of htmx (not in small part due to my affection for the grug brained manifesto from the author–definitely my favorite software engineering manifesto). I suppose a lot of people would say it’s not declarative, but I’m not sure if I should care or not lol
1
Asd
I’ve read the blog post and it is very funny.
Quote
So our minimum requirements for interesting program transformations include:
- Static typing (so that we know what values look like).
- Static dispatch (so that we know which functions will be called).
- Some way to reason about the properties of functions (eg that a == b implies hash(a) == hash(b) or that addition is commutative).
- Some way to reason about which values are finite and which functions terminate.
- Some way to reason about the time and space cost of functions (so that we can predict if a given transformation is worthwhile).
- Some way to reason about the effects caused by calling functions (eg by only allowing pure functions, or by tracking effects and aliasing in the type system).
While I can say that most of these points are not true (for example functions can sometimes be speculated and made pure by postponing effects, etc.), but it generally describes a qualities of declarative programming language, not the imperative one.
To put my 2 cents into the overall discussion, I think that declarativeness and imperativeness are not two separate opposites and not even a spectrum, but are just qualities of information description or code.
Here’s a table to demonstrate the idea, where languages in boxes are the most extreme examples I can think of.
| Not declarative | Declarative | |
|---|---|---|
| Not imperative | Prolog | Markdown |
| Imperative | Assemble | SVG |
For example, Prolog is neither declarative, nor imperative, because it is logical. You dont state the instructions and you dont explain the expected result, you just define rules and then ask questions.
Markdown is declarative, because it describes the end result: a text document. Different editors and viewers decide how to render it.
Assembly is imperative, because all you have is a set of instructions. You don’t describe the end result in any way, you just write down a bunch of instructions which bring to the end result.
And SVG is both declarative and imperative, because it defines an image as a set of curves and shapes and then it lets user apply some changes and actions (some transforms) to these curves, in any order. So it contains both a description of an image and some very detailed instruction on how to change the image. I think CSS also belongs to the same category.
Most general purpose Turing-complete programming languages (like C, Haskell, Elixir or Python) are somewhere in-between, some are leaning more to one thing or another, or some leaning more towards both (like Scala or C++, for example).
This information is fun to know, but for me personally, it is completely useless 
2
garrison
It is actually much more complicated than that, but I didn’t want to get into it.
Actually if you think about it the page is rendered at 60hz no matter what you do. And this gets into “immediate mode GUI” and so on.
What happened with React is a funny coincidence, where it was created to incrementalize DOM updates (because the DOM is slow, and still is today to be clear). But in the process they somewhat accidentally created a tool which is useful for incrementalizing application code. So even if you get rid of the (useless) DOM, something like React is still meaningful.
Wittens (the third article) work in the area is on use.gpu, a framework that provides an incremental, declarative GPU API. And Levien’s work (the second article) was in the context of a UI library for Rust, where they have no DOM, and he goes into that. Both of these individuals, by the way, are very experienced graphics programmers, not a couple of webdev rookies
0