My Communities

Since 2017 I have been Biodiversity Informatics lead for IMERSS, the Institute for Multidisciplinary Ecological Research in the Salish Sea. I have been working to help communities with different models for knowledge — expert naturalists, citizen scientists, and Indigenous individuals and others — respectfully cooperate to share their knowledge of the natural world and be empowered as stewards of their natural environment. Some visualisations I've produced can be seen on the IMERSS portal.
The Malleable Systems Collective believes, as I do, that it should be as easy to change software as it is to use it. We believe in widening the circle of those empowered to make decisions about their own technology, through making it as easy as possible to understand and change it. [More Communities]

My Projects

Since 2022 I have worked for the Oregon Bee Atlas to help landowners understand plant-pollinator interactions and guide their land use decisions including evaluation of seed mixes, as well as supporting their volunteers' observation work. I have implemented the Melittoflora tool using a provisional version of the Infusion framework which filters the project's data on wild bees by geographical, temporal and taxonomic filters and visualises the resulting interactions as a live, attractive bipartite ribbon graph.

Since 2008 I have been the lead developer of the Infusion framework, a JavaScript framework supporting the development of flexible software. Versions 1 through 4 of Infusion were relatively conventionally structured libraries supporting the development of various UI widgets. Since 2024 a comprehensive rewrite of Infusion has been underway for version 6 based on reactive primitives throughout, structuring it as a software substrate constituting an integration domain. [More Projects]

An era for new notations

I argue that there has never been a more promising time for developing fruitful new notations. Some, considering the enormous success of modern LLMs in solving increasingly complex “problems” – in terms of translating a verbal or pictorial design specification into code – means programming is now a “solved” problem. They imagine a future where humans no longer need to understand or write code. I believe this is wrong on several accounts. [Read More]

Coming Out of the Shadows

Or – “Evading Gilad’s Comparison”. A 2014 posting of Gilad Bracha’s, A DOMain of shadows, has prompted a lot of thought over the years. I refer to it in passing in last month’s On UI as Code but this week a line of argument became a bit clearer on how the comparison in the posting might be dodged. Gilad’s note is about the design tension constantly pushing complexity into any purportedly “simple” user-facing language, that we might call a DSL. [Read More]

On UI as code

UI as Code as a named slogan originated in the context of Dart’s Flutter UI toolkit created by Google. It is centrally described by Bob Nystrom in this thoughtful posting Marking Dart a Better Language for UI. I see it as part of a wider trend in many environments to express designs in general-purpose programming language code rather than configuration languages with less expressive power. For example, ESLint’s flat config system introduced in 2022 moves its previous JSON-based linting configuration into JavaScript code. [Read More]

On Development Speed

A recent posting Why the Latest JavaScript Frameworks Are a Waste of Time sparks a short train of thought. As well as the characteristically disrespectful tone of discussion that technical people often adopt, and the suggestion, contrary to my speculations looking at DOM reconciliation, that people really do use low-level benchmarks when choosing frameworks, is the notion of frameworks contributing to development speed. One commentor invites us to watch him against the clock to implement a front end in Svelte rather than React. [Read More]

Benchmarking DOM reconciliation algorithms

Since the Infusion 6 renderer is close to being a reality, it is time to understand the characteristics of some of the various DOM reconciliation algorithms out there. Could we do without a virtual DOM entirely? To start with is the question of whether we even really want one at all — the classic Svelte Virtual DOM is pure overhead post has been though its various hype cycles but 7 years later the majority of frameworks out there still have one so the consequences are clearly not as clear-cut as the argument would have it. [Read More]