How on earth would a two-dimensional array be their first approach? And then acting like a tree is a novel concept? I had to double-check that this wasn't a dev.to article.
Why a 2D array makes sense: many people using multiplexers like this seem to use them in a 2x2 or 3x3 grid. You could easily represent panes like that by making an HTML-like grid where each row and column contains a number of which pane it belongs to.
As for why trees seem to be a novel concept: the code is written in Rust, and tree algorithms specifically are hard to do in the traditional way (pointers to pointers being moved around) without unsafe code. While you're at it, you may just as well explain trees I guess.
Of course Rust trees can be done, but the resulting data structure is often unwieldy and ugly. When I'm writing Rust, I tend to avoid writing structures like that because I don't want to deal with Box<Arc<RefCell<X>>> or whatever the correct type is for writing mutable tree structures.
Anecdotally, I've never used or seen anyone use a pure NxN grid. It's always a series of horizontal or vertical splits (a tree).
I'll admit that this being Rust is likely the cause, but this is a simple binary tree. There's no need for backpointers or any troublesome algorithms or anything.
It's just a tad annoying that Rust pushes people towards crappy solutions by making the better solution _spooky and dangerous_ when said solution doesn't even involve the _spooky and dangerous_ `unsafe` keyword.
You're forgetting that the author of the article might not have your level of experience in computer science/engineering. And now you've added a sneering comment to their HN thread. And caused me to make another one that's potentially patronizing. Maybe it would have been better if you had thought a bit more imaginatively / empathetically before your post?
DomTerm (https://domterm.org) uses the Golden Layout library (https://github.com/golden-layout/golden-layout). As far as I can tell, this does everything mentioned in the article. It also supports tabs, and you can also reposition terminal windows by dragging, neither of which I saw mentioned in the article. (I'm currently working on being able to drag between top-level windows. It sort-of-works, but only at the proof-of-concept level.)
A tree makes more sense than a two dimensional array for representing panes, but not for the reasons stated in the article. Sparseness and performance will not be issues with the low number of panes that will ever be used. The main reason to use trees is just that they are a closer representation of the abstraction, and will be easier to reason about and code.
On a side note, I wasn't able to figure out what problem this company is trying to solve. I've been using nvim+tmux+kitty and it does all the things they sell, while being open source.
The blog author thinks copying a smaller than 10x10 array of pointers, less than once per minute, is a memory-intensive, performance-sensitive operation, so it's pretty clear that they don't know what they are doing.
