Status update - November 2021

It’s been a quieter month for projects, with the one holiday done and another coming up.

I spent the last year writing Rust, and now I’m working on a package that’s mostly JS/TS and Go. It’s strange to go from a language where you need to be absolutely explicit about what you’re doing (what’s mutable, what’s a reference, what type you have, how long you have it) to a language that doesn’t care about that at all. I like JS. I like Rust. But it seems like there’s room for something in between. Some language in between that lets you turn on and off constraints based on what you’re doing, or just looks for invariants that look dangerous.

Writing a lot of React lately. The transition from classes to functions is a weird one to get used to. I understand that thinking in terms of functions is useful; the implicit state inside of functions is basically like the fields on a class. But I can’t help but think the required hooks just make the logic too strange. You might get better React code, but you end up with worse javascript. In classes you at least have this, but in functions you have, what, const and let declarations that are opaquely transferred to effect-hooks? Strange. Not at all easy to reason about - but maybe I’ve just not been doing it long enough. Time will tell.

Makefile stuff

In make, .PHONY targets aren’t super great, because they run every time. See https://www.gnu.org/software/make/manual/html_node/Phony-Targets.html for more info. The fix is to create a single, real target, and use that, then use a phony target for the entry point. That’s more or less what I’m doing for every built thing in my monorepo Makefile. There’s a certain amount of work that goes into maintaining a makefile. If it starts to get out of control, then it’s a sign that there are too many people touching it, too many projects, and maybe a refactoring is in order.

Other things

An interesting read about requestAnimationFrame to speed up React rendering; https://github. com/facebook/react/issues/11171. Seems like there are about a half a dozen problems with running React rendering inside an RAF loop, but not many with using it yourself. You either need to sprinkle it in around your event handlers, or actions that are computationally intensive, or use it in a loop. Interesting that this is the sort of thing web developers will have to do for a long time, rather than just getting 60fps with almost any native GUI.

On a similar note, I was reading the Blender source code this week. They’re not using a framework for any of their UI stuff, just raw C++, which is to be expected for an application that is doing raw graphics processing. But it does challenge the assumption that you need Electron or a native GUI or any of that nonsense. There’s a huge, wildly popular open source application built by people that are just doing the hard work. Any startup that is doing Electron because it’s easier isn’t necessarily wrong, but maybe if they were only writing a desktop app it wouldn’t be as tempting to do thin-client shenanigans.