ICYMI: Three ways of handling user input
I realized that my previous email subscription / newsletter setup wasn't working anymore, which is why you didn't see any email when my last blog post came out. Sorry about that! I've migrated to a new setup on Buttondown, so things should go smoothly from here on out.
Like before, I'll mostly use this list to let you know about new articles on my blog. I'm also going to experiment with some newsletter-only content β longer-form stuff than what I post on Twitter, but a bit less polished than my blog posts (and hopefully more frequent).
A new-ish blog post
So, maybe some of you have seen this already π¬ but I recently published a new blog post β Three ways of handling user input:
Itβs 2022 and things are pretty much the same: the dominant way of handling user input is still based on events and β in some form or another β callbacks. They come in slightly different forms (addEventListener, responder objects, etc.) but the core idea is the same.
Itβs still going strong more than 40 years later, so the event-and-callback-based approach clearly has something going for it. But in nearly every code base Iβve worked in, the hairiest, most difficult-to-modify logic is in the event handling code. Handling user input is β to borrow a phrase from Laurence Tratt β a solved problem that isnβt.
To help me understand the pros and cons of the events-and-callbacks model and to experiment with some other approaches, I decided to write up a simple example in a three different styles.
After publishing the post, I actually discovered an article by Ingo Maier Martin Odersky called Deprecating the Observer Pattern which covers similar ground. If you enjoyed the blog post, their paper is worth reading as well.
Several people got in touch to tell me about bugs that they'd found, which wasn't totally shocking. One of the points I wanted to make was that even simple drag-and-drop behaviour is surprisingly hard to get right! Here's a bug with Figma's implementation that took me about two minutes to find:
(The bug: I hit "Esc" to cancel the drag while the alignment guides were visible, then the guides don't disappear on mouseup like they should.)
In the last few weeks, I've been exploring the process-oriented model a bit more. I got turned on to Concurrent ML (CML) a few years back through a couple articles by Andy Wingo: Lightweight Concurrency in Lua and A New Concurrent ML. I spent a good chunk of this weekend writing a JavaScript implementation of the CML primitives. Which led to this tweet:
There's such a huge difference between reading a paper about an algorithm/system/etc., and trying to implement it yourself.
β Patrick Dubroy (@dubroy) January 23, 2022
I read the paper and think "I get it".
I try to implement it and realize I didn't get it at all.
Anyways, I'm planning a follow-up post where I'll dive a bit deeper into the process-oriented model, and probably cover CML a bit. I hope to have that out in the next few weeks. π€
Reading and listening
- π A Biography of the Pixel - a history of computer graphics, by one of the founders of Pixar. I'm really enjoying this so far (though I skipped over some the very early history in the first half).
- π» Designing multiplayer apps with patterns from architecture - Can ideas from Christopher Alexander's A Pattern Language be applied to digital spaces?
- π§ Metamuse #48: Rich text with Slim Lim - a great episode of my favourite podcast.
- π Papers on Concurrent ML, if you want to go down the rabbit hole:
- CML: A Higher-order Concurrent Programming Language - the canonical paper from '91.
- Parallel Concurrent ML
Until next time,
Pat