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
this, but in functions you have, what,
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.
.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.
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.