Xray – An experimental next-generation Electron-based text editor

I want to build a text editor where git history is displayed as first class files directly in the file tree. Like a page named landing.html would have landing.html.v0, landing.html.v1, landing.html.v2, etc. directly as regular files. With maybe the git commit message also in the file name for more context.

What would be the best way to make this happen? Build an app from scratch with something like Electron? Build an extension for an existing text editor like Sublime, VSCode, or Atom?

I take the opposite approach: I really enjoy using hardware which is exactly adequate to what I need it to do.

My entire senior year (2016-2017) of college, I ran Arch linux on an IBM Thinkpad X40 that I bought on eBay for 30 USD. It had a 1.1 GHz 32-bit Pentium 4, 1 GB of memory, a 32 GB CompactFlash card as a hard drive, a 1024x768 12" display, two hours of battery life, and a glorious keyboard (with an amber light above the screen!). I did everything on that computer: writing papers (vim and LibreOffice), writing assignments in C, Python, and Scheme (Chez and Racket), web browsing (Seamonkey), light image editing (Gimp and Inkscape), interactive 3D biochemistry simulation (Compucell), 3D modelling (Blender and Solvespace), and retrogaming (DosBox and Zandronum (Doom)).

I owned much newer, much more powerful computers, but I didn't use them at all that year because I really enjoyed using a computer that was exactly large enough in every dimension (spatial and otherwise) to do all the things I wanted to do without making me wait.

During that time, I learned a lot about the resource usage of various applications:

* Seamonkey used way less memory than Firefox. (Seamonkey has since switched to using the same rendering engine as Firefox ESR, so I don't think this is the case any longer.)

* UBlock Origin really is faster than Adblock Plus.

* Using ad blocker makes a HUGE improvement in browser CPU usage.

* I couldn't install Chrome/Chromium at all because they require a 64-bit processor.

* Dillo is really fast and uses very little memory, but isn't very standards-compliant.

* Netsurf is pretty fast and pretty low-memory, but it still isn't quite standards compliant. (For example, monospace text on Github always rendered as black text on black background.) It also doesn't ship with javascript support.

* No matter the browser, javascript animations in webpages always ran slowly and pegged the CPU at 100%. [0]

* Playing videos in VLC or mpv uses way less CPU than playing the same files in a browser.

* A lot of websites, including the HTML version of gmail, actually look pretty good in xlinks2.

* Suckless's `st` terminal has a very small memory footprint but takes an amazing amount of CPU time to redraw itself when scrolling.

* Blender and Solvespace are both very conservative with memory, and also are remarkably usable on a single-core machine with software OpenGL.

* Inkscape has a nifty tile-based rendering engine -- with a sufficiently complex file, I could watch it refresh the screen over the course of 0.2 to 0.4 seconds.

* Older versions of Inkscape (back when it was written in C) render way faster than newer versions (even the new 0.91 release, which substantially improved over the previous (still written in C++) 0.48).

* DrRacket allocates more memory every time you run your code. After a half-hour or so of write-test-write-test, I would have to restart DrRacket to avoid running into swap.

* CompuCell is actually very usable, even in a Windows XP virtual machine with 640 MB of memory running on the above laptop. [1]

* AbiWord is faster to launch but otherwise not much faster or lower-memory than LibreOffice Writer.

* When playing a video which the computer can't quite keep up with, VLC has a bad problem of ruining the picture and not fixing it for several seconds (until it gets to and successfully decodes a keyframe). mpv is much smarter about throwing away or skipping work, and is much less likely to propagate rendering errors over time.

* Brutal Doom's built-in low-performance setting doesn't clean up gibs over time, it just reduces the rate at which they are produced. A separate mod is needed to keep 1000's of gibs from accumulating.

* Quake 3 does not work well on a single-core 1.1GHz Pentium 4. (It runs, but the even with all of the settings turned down the frame rate is so low it's like having about a 250-500 ms ping.)

* muPDF is by far the fastest PDF rendering engine on linux.

* Vanilla Emacs is actually really fast.

* Spacemacs is remarkably more CPU-intensive than vanilla Emacs.

As a result of all of this knowledge, I was able to set the laptop up so that it was able -- barely -- to do literally everything I wanted to do on a computer on it, in a way that was comfortable for me. The machine and I were very in-sync, and I was working just as hard on my assignments as my computer was. I was very happy with the X40 and the way I had it set up, and very unhappy when it died the common X40 death (bad solder on the motherboard). I was very sad to get rid of that laptop; I had a much closer connection to it than my 2.4 GHz quad-core i5 with 6 GB of RAM. The more powerful machine is more distant. I never have to try to cooperate with it, and I never feel that it's really working with me in the same way that I felt about the X40.

I've been tinkering with a pair of OLPC XO-1 laptops. It would be awesome if I could comfortably use them for everything. I think that they're beautiful examples of industrial design, they are very open-source, and their screens have a really cool grayscale triple-resolution sunlight-readable mode. Unfortunately, I don't think I could live with 256 MB of RAM. There are just too many webpages that can only be rendered properly by engines that will need more memory than that. (Not to mention that the official operating system can't install more than 1 package at a time without running out of memory, and it has a memory leak that will fill the RAM up in less than a day.) Also, some projects I'm working on in Java would probably take a very long time to render on the 433 MHz AMD Geode. (Maven seems very bad at doing the minimum necessary amount of work.) I have been able to do some real work on them - I edited an existing SVG and animated it using Inkscape, a text editor, and epiphany. (http://bloominglabs.org/index.php/Logo#Animated_Logo)

I've turned this into a big, boring story about my own experience and preferences. I just wanted to say that, aesthetically, I really don't like software that clearly uses much more space, time, or energy than necessary to do what it does, and that I really do appreciate software that makes good use of space, time, and energy. After all, time, space, and energy are all finite. This occasionally has practical implications, but personally this is largely ideological. Obviously don't waste time (I only have but so much of it!), but as long as the software can keep up with me, conserving energy and space is admirable and desirable.

I should probably just write a blog post about this.

[0] This is, of course, only the case for browsers that support javascript (Seamonkey, Firefox, all the webkit-based stuff). The performance of Dillo, Netsurf, xlinks2, and all of the terminal browsers are unaffected by javascript.

[1] CompuCell's linux installer was completely broken at the time, and the build instructions didn't work. I did a semester's worth of CompuCell homework assignments and in-class interactive modeling in a 640 MB Windows XP virtual machine. It really was okay. In class, when we were all trying to tweak a simulation to get it to act a certain way, I was first to find working parameters a fair percentage of the time.