Hourglass model and Breadboardfive days beforeArchitecturally, Breadboard aspires to have an hourglass shape to its stack. As…
Declarative vs. imperative
Thinking to write2024I’ve had this realization about myself recently, and it’s been rather useful…
I recently had a really fun conversation with a colleague about “declarative vs. imperative” programming paradigms, and here’s a somewhat rambling riff that I captured here as a result.
Edgewise Thinking2023I stumbled into this framing when talking about product/platform thinking with my…
When we make a distinction between “declarative” and “imperative” programming, we usually want to emphasize a certain kind of separation between the “what” and the “how”. The “what” is typically the intention of the developer, and the “how” is the various means of accomplishing the “what”.
For me, this realization came a while back, from a chat with Sebastian Markbåge in the early days of React, where he stated that React is declarative. I was completely disoriented, since to me, it was HTML and CSS that were declarative, and React was firmly in the imperative land.
Being excited about disagreement2021Chatting with colleagues this week, I am recognizing that it might be…
It took a bit of flustering and a lot of Sebastian’s patience for me to grok that these terms aren’t not fixed. Rather, they are a matter of perspective. What might seem like “you’re in control of all the details” imperative from one vantage point will look completely declarative from another.
Being Strategic2022It all begins with intention. There’s something in our environment – the…
📏 The line between the “what” and the “how”
Build a thing to build the thing2023When building new products, there’s always a weird tension between making something…
Instead of trying to puzzle out whether a given programming language, framework, or paradigm is declarative or imperative, it might be more helpful to identify the line that separates the “what” and the “how”.
The Cruelty of Unattainable Perfection2004First, there was pristine perfection: a vision of a mark up language…
For instance, in CSS, the “what” is the presentation of an HTML document (technically a DOM tree), and the “how” is the method by which this presentation is applied. In CSS, we declare what styling attributes we would like each document element to look like, and leave the job of applying these styles to the document in the capable hands of CSS.
Similarly, in React, we declare the structure of our components and their relationship to the state, while leaving the actual rendering of the application up to the framework.
Asymptotes and Value Niches2023I have been thinking lately about a framing that would help clarify…
Every abstraction layer brings some “declarativeness” with it, shifting the burden of having to think about some the implementation details from the shoulders of the developer into the layer.
AI Baklava2024At its core, the process of layering resolves two counterposed forces. Both…
The Layering Principle2023Preference toward layering is probably one of the more fundamental principles of…
Layer gaps2023I’ve been writing a bit more code lately, and so you’ll notice…
If we look carefully, we should be able to see the line drawn between the “how” and the “what” in every abstraction layer.
Four layers2023Utility might mean different things in different situations: in some, the value…
The cost of opinion2022It appears that I’ve been writing this essay since 2012, never quite…
In drawing this line, the creators of an abstraction layer – whether they are intentional about it or not – make a value judgment. They decide what is important and must remain in developer’s control, and what is not as important and could be abstracted away. I called this value judgment “an opinion” earlier in my writings.
e-LOC2022Another useful property of e-LOC is that it also indicates how much…
One way to view such a value judgment is as a bet: it is difficult to know ahead of time whether or not the new abstraction layer will find success among developers. The degree of opinion underlines the risk that the bet entails. More opinionated abstraction layers make riskier bets than less opinionated ones.
The protocol force2024Here’s a riff on the “hourglass model” conversation I’ve had with Bernhard…
If we measure reward in adoption and long-term usage, then the higher risk bets also promise higher reward: the degree of difference in opinion can serve as a strong differentiator and could prove vital to the popularity of the layer. In other words, if our layer isn’t that different from the layer below, then its perceived value isn’t that great to a developer.
Pace layers of predictability2023One thing that stood out to me was this notion of a…
Cheesecake and Baklava2022I have been reading Alex Komoroske’s Compendium cards on platforms, and there’s…
Therein lies the ancient dynamic that underlies bets (or any value judgments, for that matter): when designing layers of abstraction, we are called to find that balance of being different enough, yet not too different from the layer below.
🪢 The rickety bridge of uncertainty
Development environment for rapid experimentation2023To set things up. I was looking for a way to enable…
While looking for that balance, one of the most significant and crucial exercises that any framework, language, or programming paradigm will undertake is the one of value-trading with their potential developers.
Choosing kale2022Chatting with my friends about choosing developer frameworks, we accidentally arrived at…
Live as our customer2023This tension grows stronger if the difference between the environments is large.…
This exercise can be described by one question: What is it that a developer needs to give up in order to unlock the full value of our framework?
No ship ums2023I’ve been thinking about the path that software dandelions take toward becoming…
Very commonly, it’s the degree of control. We ask our potential developers to relinquish access to some lower-layer capabilities, or perhaps some means to influence control flow.
Porcelains2023However, as a result of creating this layer, I now become responsible…
Sometimes (and usually alongside with lesser control), it’s the initial investment of learning time to fully understand and gain full dexterity of wielding the layer’s opinion.
Whatever the case, there is typically a rickety bridge of uncertainty between the developer first hearing of our framework and their full-hearted adoption.
Retained and immediate mode2021With my apologies to my colleagues — who will undoubtedly make fun…
I once had the opportunity to explain CSS to an engineer who spent most of their career drawing pixels in C++, and they were mesmerized by the amount of machinery that styling the Web entails. If all you want to draw is a green box in the middle of the screen, CSS is a massively over-engineered beast. It is a long walk across unevenly placed planks to the point where the full value of this machinery even starts to make sense, value-wise. Even then, we’re constantly doubting ourselves: is this the right opinion? Could there be better ways to capture the same value?
Moving the ladder2022Riffing on the cost of opinion piece, I realized that there’s a…
This bridge of uncertainty is something that every opinionated layer has to cross. Once the network effects take root, the severity of the challenge diminishes significantly. We are socialized species, and the more people adopt the opinion that the abstraction layer espouses, the more normal it becomes – perhaps even becoming the default, for better or worse.
🧰 Bridging techniques
Deep Stack Engineer2023Riffing on the idea of layer gaps, we can surmise that pretty…
If we are to build abstraction layers, we are better off learning various ways to make the bridge more robust and short.
One technique that my colleague Paul Lewis shared with me is the classic “a-ha moment”: structure our introductions and materials in such a way that the potential value is clearly visible as early as possible. Trading is easier when we know what we’re gaining.
This may look like a killer demo that shows something that nobody else can do (or do easily). It may look like a tutorial that begins with a final product that just begs to be hacked on and looks fun to play with. It could also be a set of samples that elegantly solve problems that developers have.
Placing and wiring nodes in Breadboard2023This one is also a bit on the more technical side. It’s…
Composing graphs with Breadboard2023This post is more technical and more rambling than my usual repertoire.…
Another technique is something that Bernhard Seefeld is actively experimenting with: intentionally designing the layer in such a way that feels familiar at first glance, but allows cranking up to the next level – incrementally. You can see this work (in progress 🚧) in the new syntax for Breadboard: it looks just like a typical JS code at first, rapidly ramping up to graph serialization, composition, and all the goodies that Breadboard has to offer.
The Wallpapering Principle2023This principle builds on the layering principle, and deals with a common…
I am guessing that upon reading these examples, you immediately thought of a few others. Bridging techniques may vary and the technique playbook will keep growing, but one thing that unites them all is that they aim to help developers justify the trade of their usual conveniences for the brave new world of the layer’s opinion.
Polarity-based API layering2021While discussing API design, one pattern that caught my eye was polarity-based…
Developer surface2021I mentioned this concept before, and I feel like it’s worth expanding…
The Breadboard developer cyclethree days afterOver the past couple of months, we’ve been working on a bunch…
Designing new layers is an adventure with the indeterminate outcome. We might be right about our value judgments, or we might be wrong. It could be that no matter how much we believe in our rightness, nobody joins to share our opinion with us. No technique will guarantee the outcome we wish for. And that’s what makes API design and developer experience work in general so fun for me.

Show 2 comments
Dew Drop – January 17, 2024 (#4108) – Morning Dew by Alvin Ashcraft linked here · January 17, 2024
[…] Declarative vs. imperative (Dimitri Glazkov) […]
Peter · January 19, 2024
This post really hits home, thank you for articulating the distinction so clearly. In my work, I am trying to persuade a whole community of standards practitioners and developers that taking the next step, from server APIs to declarative incorporation of maps into HTML (and CSS) is practical and worthwhile. I always thought that the Rule of Least Power was an excellent guideline, but apparently you have to look at the problem from a whole different perspective to see the benefit that it might realize. Anyway, I would have loved to be part of that conversation. Cheers!