separating separation of concerns


i understand i cover a lot of ground in this talk. i point to a lot of trails we don't go down.

firstly, i don't think that signals or redux are bad libraries/data management methods. i had 7 minutes and i needed a hook. sometimes it's worth it to be funny, even if you're going a little bit further out than you'd otherwise like to. a corollary of my emphasis on the implicit at the end there is that a big part of react is that you don't need to "get it". react works well because of the nature of the tree structure. i profer to get it, but i'm certainly not the best programmer on my dev team. i will say that signals is a firm movement away from what react is. but signals isn't in react! it's in preact! i'm barking up the wrong tree lol!

and yes, saying that "react performs better than vanilla js in general" by treating three.js applications as a representative sample is somewhere between damn lies and statistics. the gripping hand in the question of performance is that Mel isn't a representative sample of programmers, nor a representative sample of the task/concerns of programming.

and yes, this talk was not about philosophy of technology, more like, philosophy and technology. probably not even that. i put the topic in as "philosophy of technology?" thinking they'd put it in a different category lol. that being said, i hear you can pass this off as philosophy of technology in a number of American philosophy departments, so, what do i know.

secondly, the slides are here. the outline of the talk is reprinted below. i may or may not have changed or jammed through some parts of the talk and settled on something slightly different, but this is what i had on my screen while i spoke.

lastly, i'd like to offer some further directions for the interested listener. those are below the outline. quotes are linked to their sources in the outline. i hope to fully expand upon everything i've touched upon here. until then, follow the links below.


  • intro
  • my concern is what i'm attempting to do
  • how i accomplish that mirrors my understanding of my concern
    • let's say i'm trying to make a grand TODO app.
      • i choose to understand the concern as a whole as the management of a list of non-interconnected tasks
      • your understanding is a list so you use a list
    • moving a step up, we can see this functionality is embedded in a page with other functionality
      • if i understand my concern as a number of nested sub-concerns, i'll use some sort of tree structure, such as the DOM
  • nothing is ever only itself
  • but in practice, the job of the programmer isn't just programming. all kinds of other concerns are jostling for attention.
    • how can i ensure the system retains a certain level of performance and functionality?
    • these were the core concerns of Dijkstra when he was writing his seminal paper, on the role of scientific thought
    • a program must be correct and we can study it from that viewpoint only; we also know that it should be efficient and we can study its efficiency on another day ... But nothing is gained ... by tackling these various aspects simultaneously. It is what I sometimes have called "the separation of concerns", which ... is yet the only available technique for effective ordering of one's thoughts ...

  • now, what they're really talking about when it comes to efficiency is how JS is slower than C and react is slower than JS. react is the slowest because it's the most "abstract". and this isn't actually true.
    • Is it slower than plain three.js?

      No ... It outperforms three.js at scale due to React's scheduling abilities.

    • i think the biggest problem here is we conceive of react as a framework, and the way we write code mirrors this conception. we've collectively forgotten what react is, and why we're using it.
    • i think the biggest question is "how can i eliminate unnecessary re-renders? wouldn't it be amazing if someone created a way that only components that depend on a piece of state re-rendered?"
      • they keep taking state further out of react to try to achieve this
      • fortunately, the React Team considered this and came out with this really cool state management library, called React. let's see it in action.
    • what we see are a couple of concerns jumbled together
      • we're concerned with tracking each letter that enters the input
      • and we have the concern of tracking the state of the TODOs
    • these have nothing to do with one another
    • the heuristic i use is "what do i care about[1] right now? what does the component care about?"
      • if there's state in there you don't care about, take it out
    • Remember, the core conceit of react is State -> UI
      • the really, profoundly, gorgeous thing about react is that
      • when we speak components, we're speaking state ui. the component form implicitly binds that together.
      • because react can rely on that, we don't have to communicate these things explicitly. by seprarating our concerns—by separating our state—by relying on the ways in which these things necessarily mirror one another, we're necessarily making our app faster.
      • and there's a profound beauty in that connection.

a note on the atmosphere

i don't spend a lot of time on twitter. i do spend a lot of time reading blog posts from newsletters[2], and i'm getting a feeling. the ideology is shifting. react was getting a lot of hate when i first started drafting my outline. i've experienced a bit less hate recently, just a muted resentment. "was i one of the hosts that helped presence this egregore?" almost definitely.

does that have anything to do with what industry is doing? the life and death of San Francisco; the retreat of venture capital, the death of crypto, and the slowing of the start-up sphere; the hiring freeze, the apophantical rumblings about soft quitting and soft firing? perhaps. i'm no sociologist.

fresh, remix, perhaps even ultra, all feel to me like a new world struggling to be born. all of them use react. maybe this is a sort of cynicism, a feeling that react will always rule the frontend space. all the big guys are using it, and there are going to be fewer, smaller small guys. or maybe react is just awesome. who knows.

further readings

a note on the implicit

react components don't re-render when their props change.

let's consider what would cause a prop to change. props are necessarily passed in from some parent. there are two cases in which that datum would change:

  • if that datum is calculated during the caller's render phase—ie, in the function that is that component—then that means the parent re-rendered, and the called function will already be queued for re-render.
  • if that datum isn't coming from the function that is the calling component, you're going to need some way to sync up react with that external whatever.

i'd like to draw attention to the words caller and called. i'd like to harken back to programming more generally. consider:

const Caller = ({children}) => <Called>{children}</Called>
const Parent = ({children}) => <Caller><MyEpicChild/></Caller>

the relationship between Caller and Called is very different from the relationship between Caller and MyEpicChild, yet we call both of them a parent-child relationship. the following is left as an excersize to the reader: -d '~/Library/Application Support/Firefox/Profiles/' \
  | jq '.windows[0].tabs | .[] | .entries | .[] | .url' \
  | sort \
  | uniq
const Pipeline = _ => (
  <Extract d path='~/Library/Application Support/Firefox/Profiles/'>
    <Jq q='.windows[0].tabs | .[] | .entries | .[] | .url'>

collective forgetting

there's a tendency in politics[3] to assume that everyone older than boomers had a boomer's politics/politicality. this is understanding is extremely false; nonetheless, the assumption frames all political discourse.

a decision is made and the reasoning behind it is lost to time. eventually, the decision itself is lost. perhaps the team member that made that decision left the team. new team members that never met the decision maker can ask around to try to understand who they were, what they were dealing with, but no amount of asking around will recreate that moment.

on the other hand, why would you want to? the decision was made by somebody the organization trusted, they have more information than you, and they were able to resolve the problem. we collectively forget the question and the problem because we don't really have to think about it.

the culture, so to speak, is said to the haunted by the decision. the closest thing to a formal study of these things is called Hauntology, a term coined by Derrida, highly influenced by Heidegger, Foucault, Nietzsche, &c., and the ship is perhaps most famously commandeered now by Žižek.

i would like to note here the failure of the Nietzschean project, ie, a revolutionary upheaval of modernity's ghosts at a ontogenic level[4]. there is no private language, and understanding progresses Hermeneutically.

on the other side of collective forgetting, we have collective coming into being. react is still a library, but i don't think that's what the debate over whether or not react is a library is actually about. react isn't just react. react—what we're talking about when we talk about react—isn't just code, nor is it just the instructions encoded into that prose poetry, nor is it the code uses that library, nor is it the state of mind that react engenders, nor is it the understanding of react necessary to use it. in the language game of "the discourse", react is the whole lifecycle of using react from the eye of the "business" (from the eye of the programmer) rather than the eye of the act of programming or engineering or architecture. this is why, despite react a library on a technical level, it's nonetheless a framework on a linguistic level. when we say react—most especially because of the tooling needed to make jsx work—we say "a """""""full""""""" react ""app""", the whole react experience.

the question of being


eagle eared listeners may recognize something like Conway's Law in this statement. that's because i'm referring to the good regulator theorem, of which Conway's Law is a corollary.

to get the good regulator theorem, i'd do a bit of mental refactoring. once you understand variety and interface, the good regulator theorem is trivial.

for variety, i cannot undersell the work of Stafford Beer. his Designing Freedom and Falcondale Collection are light and cheery, easy to understand, and deeply, subtly profound. this webinar by Pam Sydelko is one of the most clear and productive applications of the methods.

on the question of interface, i enjoyed Heidegger's The Question Concerning Technology, though i'm sure there are programming books that cover the subject better.

  1. ie, what am i concerned with? ↩︎

  2. mostly this one, es next, and the ones ↩︎

  3. within the opining of anti- and post-political commentators with apophantical politicalities ↩︎

  4. This includes further uncritical developments, of which the worst offender was[4:1] accelerationism. accelerationism isn't relevant anymore. it has completed its metamorphosis into unabashed fascism. ↩︎ ↩︎