Status update - November 2021
An update for the month of November
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.