Young developers nowadays seem to mostly use dark backgrounds, which to me feels like a weird '70s throwback. I suspect it's primarily an identity signal: it's harder to feel like you're hacking The Matrix if your IDE looks like Word from a distance.
As someone who used dark themes with CRTs whenever possible in the ‘90s, my theory is simply that those studies you mention were academic horseshit - CRTs with bright backgrounds were eye-killers. Well, they were eye-killers in general, but more when set with bright backgrounds.
Unfortunately, colorbleed in small-size text made it a bit more difficult to read text on dark backgrounds, but that could be somewhat compensated with larger fonts if you had a big enough display. So basically you could choose two different ways to kill yourself, but one of them gave you a chance if you were rich enough (and lucky enough - most programs on Windows never allowed you to change their white background). Man, CRT was so shit.
LCDs are much better in general, and occasionally worse (a lot of games make my eyes cry, with their aggressively shiny palettes). I still prefer dark out of habit in most cases, but it really depends on the monitor (and its calibration) and the surroundings. Saying one mode or the other is superior in all circumstances is silly, imho. And certainly wouldn’t bash millennials, or question their geek-manliness, for choosing this or that mode.
The bashing is mostly the other way around though. I regularly get shit from people because I prefer white backgrounds. It's also some kind of meme — just the other day I saw a popular tweet that read "People who use light background IDEs are serial killers." As an edge case GenX-millennial who buys expensive avocados and lets them rot, it's pretty much my glass house for rock-throwing practice anyway...
Everything "young developers" nowadays do seem to me a weird '70s throwback - from the proliferation of the command line (as opposed to actually trying to create advanced GUI tools for people who know what they are doing, like a lot of developers did in the late 90s/early 2000s whereas today you mainly have dumbed down GNOME 3 lookalikes), to using tiling and lightweight window managers "for performance" on "low end computers" when those low end computers have massive supercomputer abilities compared to the computers that people used -again- in the 90s with UIs that did WAY more stuff despite their limited performance, to having crude dumb TUIs that look and behave worse than what you'd get in DOS in the 80s, etc.
Plus, in this environmentally conscious time, isn't it nice that people want to do more with less? Why waste GPU cycles adding shadows and lens flares to text? I don't get it.
I like using tiling WM's (dwm and Awesome) because they organize windows for me and nothing is hidden in a bar. The concept of workspaces is much nicer than shuffling windows around a screen. I can quickly jump between workspaces and immediatly see my windows and contents. What more do I need? GPU rendering of windows? Why?
I along with many others enjoy doing more with less. My old i3 Thinkpad runs just fine. Plays youtube videos, streams music and edits text using OpenBSD. What more do I need? Why pointlessly throw more at a problem that doesn't need it?
If only I could find a car that adheres to the same principles!
No i am not confused, i'm perfectly aware of what i am seeing and writing, thank you.
> developers work with text. What more can computing power bring to text?
This is highly myopic, there is more to development tools that just source code and even visualization of source code and programs do benefit from being able to work with graphics. There is more to computing and programming than a 70s terminal.
And people use computers for more than programming.
> I like using tiling WM's (dwm and Awesome) because they organize windows for me and nothing is hidden in a bar. The concept of workspaces is much nicer than shuffling windows around a screen. I can quickly jump between workspaces and immediatly see my windows and contents.
Sure, although workspaces are available in overlapping window setups too. The rest you mention are just personal preferences, my comment weren't about liking tiling window managers over overlapping windows, it was about using those (and lightweight window managers - i included overlapping window managers too there) using them due to their resource use.
> What more do I need? GPU rendering of windows? Why?
I don't know but i have a feeling you'll just call irrelevant whatever i suggest.
But honestly...
> I along with many others enjoy doing more with less. My old i3 Thinkpad runs just fine. Plays youtube videos, streams music and edits text using OpenBSD. What more do I need? Why pointlessly throw more at a problem that doesn't need it?
...i think you totally missed the point of what i wrote. My point wasn't to throw more at a problem and especially not be wasteful about resources. Using and -especially- writing efficient software doesn't imply 70s terminal UIs.
A Pentium at 133MHz with 32MB of RAM, a machine that is a fraction of power of even the first Raspberry Pi, can run at comfortable performance an interface as rich as Windows 98. Even the lowest of the low performance laptops you can get your hands on today will have a ton more power, yet people treat it like it isn't anything more than a dumb terminal.
> GPU rendering of windows? Why?
GPU rendering of windows is likely more power-efficient than doing the same rendering work on the CPU.
Of course, once GPU rendering is possible, developers tend to fool themselves into thinking lots of animations and effects are a good idea, which then sucks up the efficiency gains again...
Yes, we work in text. Yes, text is quick easy and powerful. That does mean it is the right tool for every job.
Not everyone works somewhere taking down all your machines in some region for 30min because you typo'd -a when you meant -s when invoking some automation script is no big deal. Some of us work places where having normal operations carry the risk of that kind of thing isn't ok. GUIs when designed at least half-assedly make it significantly harder for people to enter dumb, dangerous or erroneous inputs while working at the same speed.
There's nothing preventing you from using a GUI to generate commands that will be passed as command line args and showing that to the user. In the few cases where you need to do something unsupported just invoke the command from the CLI.
Tossing up a quick web UI to streamline routine tasks while making users go out of their way to do non-routine or dangerous tasks is worthwhile at all but the smallest scale. Yes, it's quicker and easier to write a CLI tool but restricting the amount of rope just laying around to hang yourself with is part of operational maturity. With a GUI people at least have to go out of their way to find the rope.
Edit: Am I being down-voted because my opinion is unreasonable or just because it makes some people uncomfortable? At least tell me why I'm so wrong.
You're conflating two entirely separate issues: Making it harder to trigger dangerous functionality vs. how the functionality is presented to a user. Nothing prevents hiding dangerous options behind extra steps in a CLI either.
I work mostly in text mode, but I also do use various simple GUI tools, and I half-way sympathise with what you want, though. What I've found is that in fact there are lots of nice little tools written to support minimal WMs or systems without desktop environments that are very useful in that respect. E.g. tools like rofi, dmenu and the like are great to wrap tiny GUIs around functionality that is hard to remember how to use correctly.
I work mostly in my own text-editor, and instead of writing a UI from scratch for it, I depend on the IPC support for the bspwm window manager to implement multiple windows/panes (the editor buffers are maintained in a server process, so I can have multiple views to the same buffer), and use rofi to bring up UI's. E.g. I have little scripts that bring up rofi with suitable input to select a server to ssh to, open a file in my editor, run a yarn/npm/make target, select a theme for my editor, switch buffers in my editors etc. Most of them are a handful of lines at most.
I'd love to see more tools like that, which makes building simple tool-specific GUIs for scripts easy.
Modern PCs being insanely fast doesn't mean we have to use software that requires insanely fast computers.
Never claimed that, but efficient software doesn't imply 70s terminal UIs.
They are modern terminal UIs. We pick terminal UIs because the terminal tends to expose a lot more features than a gui. This tendency is probably because it is easier to add features to a tui than to a gui.
Then there is a kind of self reinforcing effect where people like working within similar paradigms, and people get used to TUIs in general. This makes those people prefer making TUIs over GUIs even more. Incidentally, it is mostly developers who tend to need the more powerful features currently only offered in a TUI.
> Then there is a kind of self reinforcing effect where people like working within similar paradigms, and people get used to TUIs in general.
Yes, it is basically a matter of fashion and what baffles me is that fashion.
I mean, even if you consider that terminal-based applications are great, why limit yourself to what a beefed up VT100 could do? Why when typing "ls" not also have a tiny folder icon near the directories (you are already going into the hassle of adding colors anyway, a little icon would make it more obvious which are folders and which are files when you are looking at a huge list), why not having a command akin to "cat" that can decode and display image files right in the terminal, why not have an over-time graph in "perf"'s realtime TUI mode, Emacs already supports different font sizes when running as a GUI program, why not have this in terminal mode too, Clang's static analyzer can show you data flow-based errors, why not have graphical arrows superimposed over your syntax highlighted code when you run it from the terminal (Xcode already does that but it is a GUI), etc.
These are just some examples from the top of my head, i'm sure i can come up with even more.
I think by using only text-based UIs people get used to text-based UIs and all they can imagine is within the limitations of text-based UIs.
My setup does use a Sixel enabled (and ReGIS but the ReGIS support is poor) Xterm.
Here's the thing:
Years of experience is that the gain is very much marginal. I really want to do more related to this, and it can sometimes be useful. But unless you're sending images over an ssh connection, Sixel output to xterm is no easier than opening another window most of the time. My ls replacement locally already shows symbols and uses colours; the benefit of going to images instead of unicode characters is minimal. Drawing lines instead of using Unicode box drawing is similarly such a marginal improvement that for most things it doesn't offer much.
There are things where it can be nice, such as e.g. being able to plot a histogram from output from shell tools without opening a separate window (and making it work over an ssh connection), but even then you can mostly get there with unicode characters too, and then you don't have to worry about whether or not you'll need to use those tools from somewhere without a Sixel or ReGIS enabled terminal.
And there's the rub: these gains in functionality are so marginal that the benefit is very easily lost when you often work on multiple machines, because suddenly you have to distribute them to all the machines you work on, or juggle between multiple sets of tools.
I still want to do more with it. I grew up with an Amiga where the terminal was a system service that could be trivially embedded in a window and co-mingled with gui elements. I still think parts of that design are ahead of modern gui's. But it's also an ecosystem thing. It's more important to have software that works together than to get those gains that individually are quite minor. You first get the full benefits when things start coalescing into a greater whole.
This is already reality. Tools like lsd do that by default.
> I think by using only text-based UIs people get used to text-based UIs and all they can imagine is within the limitations of text-based UIs.
No. One of the main reasons I like this "limited" UI is because it also means less clutter. No popups, no stupid notifications or animations, no useless and seemingly infinite menus. Just relevant information and nothing else. I can imagine a UI without these limits, I've used it for decades, and now I'm glad I can often stay away from it. If there wasn't a huge problem with horrible overloaded UIs we wouldn't have plugins for blocking ads and scripts on websites or distraction-free modes in text editors.
I'm not against displaying simple graphics in the terminal(e.g. like ranger does), but there's a point where a decrease in limitations only means an increase in eye candy.
I'm not sure how you could have a TUI that didn't look old. For serious applications, you have to build TUIs assuming the worst - that the user has no colors or special keys. Sure, some terminals can display bitmapped images with 24-bit color, but you can't depend on that, especially for anything running over SSH or within Tmux, screen, emacs, (neo)vim, or some combination of these. These can create some very obscure bugs related to colors and keybindings, so you can't assume every key will work as expected or that your users will have color at all (I disable Vim syntax highlighting over SSH because it tends to demolish its performance, for example). This is why many TUIs are 16-color and use just ASCII characters - you don't know if the user can display emojis or if it'll show up as a garbled mess.
GUI applications (including text-based ones like gVim and emacs) have a lot more flexibility because they can control more than they can in a terminal and can guarantee 8- or 24-bit color instead of having to hope for 16-color support.
> Why when typing "ls" not also have a tiny folder icon near the directories (you are already going into the hassle of adding colors anyway, a little icon would make it more obvious which are folders and which are files when you are looking at a huge list)
That would probably break a lot of scripts. I just alias "l" to "ls -l" so I can see the permissions (which has a "d" to indicate directories).
Realistically, what are the chances of this happening nowadays and how worth is it supporting such users?
> That would probably break a lot of scripts.
If an icon would break scripts, so would having colors, but it doesn't since ls knows when it outputs to a terminal or to a pipe and adjusts the output accordingly. But this misses the point, it could be another commands like vls (visual ls) or whatever, the point is the ability to use more than ASCII text.
> I just alias "l" to "ls -l" so I can see the permissions (which has a "d" to indicate directories).
An icon is more distinguishable from a single letter and using the -l view would not take advantage of any horizontal space you have.
I've ~yelled at~ talked to a bunch of gnome developers trying to figure out exactly what's going on. I think that they're making the weird UI decisions in the name of "inclusiveness". They believe that simpler apps, and a standard unified ecosystem, makes things easier for marginalized groups to adopt free-software. All their weird technical decisions ultimately seem to be justified by making things easier for marginalized groups.
This is more of an accident of history, there's no reason you can't have pipe friendly collection of graphical tools, dmenu is one simple example: https://wiki.archlinux.org/index.php/Dmenu
Then try to come up with better tools!
Who are you addressing this to, end-users or UI designers? The debate seemed to start off asking "why do people prefer text UIs" and now seems to have morphed into "why don't OS vendors innovate in text UIs more".
I don't know the answer to that, but it's not really relevant to the initial debate; text UIs, for all their lack of innovation, are still dramatically better than GUIs for many use cases, which is why I use them.
I do not want to go off and spend years designing and implementing the theoretically perfect OS and toolchain before I can do other work, I just want to use the best of what exists today.
I've tried to use the existing "containers" systems on regular desktops and they simply sucked. Not even close to what I get on i3.
This idea of using the mouse to click on everything you need to do is something I cannot get around. Creating advanced GUI tools for "people who know what they are doing" sounds counter-intuitive to me. If you know what you are doing, you can use the damn command line.
GUIs are normally built with less features and/or dumbed down versions for the average user, not the other way around. I suppose if we forced ourselves to build better GUIs that were super flexible, this wouldn't be true. But the reality of today (or ever?) is that normally if you know what you're doing, you're using a CLI and not a GUI.
I was thrilled when I finally had the opportunity to use graphical workstations.
You could expand your software in seconds.
My first startup was an heavy Tcl shop, thanks to it I learned never again to depend on languages without support for JIT/AOT on their canonical implementations.
My team was responsible for writing FFI wrappers.
Because text is a lot more portable across platforms.
Because interacting with text is a lot easier to automate. And extracting information from text automatically is easy whilst extracting it automatically from a picture is very difficult.
GUIs are great for discoverability, and complex long ineractive sessions. But they also have downsides.
I have to use HeidiSQL in Linux via Wine because IMO all GUI MySQL clients written for Gnome are either not powerful enough or are just memory hogs.
But you will have to kill me before I use something that's not a dark theme in my code editor.
Text is the most expressive GUI ever invented, but only for literate people.
I am also an order of magnitude faster at my job than my colleagues stuck in gui land,pecking away at their IDEs. Not to mention I have a greater command of the languages we use because I am not relying on an AI to guess syntax for me.
And it has an inline window-search menu which is really convenient, it can autocomplete window names too :D "xterm -T yourtitle -e nvi", then in my case I press super+a, I type "you<tab>", I press "intro", and my xterm raises up.
No stupid tiling, no window resizing, no borked aspect ratio. To unclutter my screen, that's what are tags (almost like virtual desktops) for.
I was like you, until I began to use a max 2-3 open per tag/workspace. The clutter ended.
Tiling is useless under Unix environments where virtual desktops are a norm since ~1989. They may worked great under DOS and pre Windows 3.1 where few things are open, not under a powerful multi virtual-display based environment with several terminals running at once.
I've used virtual desktops since my Amiga days in the mid 80's - they are not a replacement for wasting as little of what space is actually visible at any given time.
As an aside point taken. I feel the same way, about using VIM+Terminal for coding.
I lost hours discovering what an icon/menu did or what a function actually meant in an IDE/advanced suite.
The Windows API was utterly nonsense.
When I discovered Unix, Ksh, AWK, and TCL/TK, I was in heaven. Easy, straightforward, composable, and you could AUTOMATE stuff.
Oh, about tiling/Gnome 3, I don't care. I have a FLOATING WM with virtual desktops (tags), and crontab handles everything else.
With a few scripts, I get the work done.
Try that with Windows.
The two main issues with the above was that because it was made to be interoperable with any native language that had support for functions and structs, it was complex to do it right and only expensive (meaning, difficult to acquire for many developers) tools could help you with that. And, really, another issue was that most developers simply didn't appreciate the flexibility and composability it offered (they still don't, see how no Linux environment provides even something like Windows 3.1's OLE, let alone something like COM).
Poweful, but as it was too obscure for the end user/programmer compared to the in-place source of Nixen+man pages, guess which platform was both free and easy to code. VC++ was expensive too, BTW.
On COM/OLE, on UNIX no one cared because by design you could embed whatever shit you wanted, from video players to window manager modules. And TCL was amazing.
I have to wonder whether that research took into consideration how large and bright modern displays are, and for the duration that modern IT professionals are using them for.
I would guess that the majority of these people would have been using 15-19" CRT monitors, and mostly single displays.
In pretty much every office that I've seen, most people have two or three 23-27" displays. Modern LCD panels are also extremely bright.
Staring at that much screen realestate with primarily light/white colours can be painful for long periods of time. It certainly feels less uncomfortable to use a darker theme.
I doubt that this is the reason. On a CRT I prefer bright text on dark backgrounds because it minimizes visible flicker. Where the screen is dark on a CRT, the beam is simply off. This becomes especially important if the monitor has low refresh rate and/or fast phosphor. I think that it's for this reason that a lot of (actual) terminals have really long afterglow phosphor and use bright text on dark backgrounds. It's basically a prerequisite to use them regularly for any extended amount of time. Newer CRTs improve the situation considerably, though, with much faster refresh rates to compensate for the short afterglow necessary for media like games and video.
Overall I think that using CRTs is more exhausting than LCDs, even taking into consideration the typical size of a computer CRT display compared to a modern office dual LCD setup. After a couple of hours of use of a 15" 2002 CRT my eyes feel dry and sandy, and the problem is exacerbated by bright screen content. Also, my LCDs (at home and at work) are not nearly as bright as my CRTs.
On LCDs I tend to use bright backgrounds in daylight because it seems much easier to read, and the screen doesn't need to be so bright. In the dark, I use dark backgrounds because bright screens easily become the brightest thing in the room with little natural lighting. In practice this means a bright theme at work and a dark theme at home.
I can't wait for paper-like unlit desktop displays with fast refresh rates. IMO it's the most important step for improved computer ergonomics. Then we can fully embrace natural lighting e.g. during summer time office hours, which is healthy for soul and body and easier on the eyes than basically staring into a lamp. Also potentially a lot more energy efficient.
I find this much easier on my eyes than light theme. Especially when I read some pdf's just before bed and all lights are off where my screen is the only source of brightness. Granted I also reduce my laptop screen brightness and pdf viewer (Zathura or Mupdf) supports custom colors (solarized dark). My eyes never get too tired.
I've also used redshift for some time but I don't need the gamma reduction actually with the above approach. At night my laptop looks very similar to "e-paper" or a Kindle. And my gf who has to get up a couple of hours earlier doesn't even notice my late night reading next to her.
I suspect the real answer is a big, fat, "it depends."
The brightness setting is like the adjustments on a car driver seat: the point is not to always use an extreme of the range. You probably wouldn’t move the seat all the way back just because the setting exists.
With the computer screens I've seen, it's only possible to approach paper in a brightly lit environment. I'm normally setting brightness to minimum and contrast to maximum, and still using light-on-dark themes with good (though not extreme) contrast.
For dim environments, some mobile phone screens (and I've heard computer screens as well) attempt such adjustment automatically, and can go dimmer than common computer screens, but it usually leads to a very low contrast and illegible texts.
The answer is no.
Do you know research validating or contracting these claims:
- light text on dark background in dark room better
- dark text in light background in bright room is better
- light text on dark background is better when refresh rate is low
- the font size changes the situation.
My personal experience after some testing is that light on dark with slightly larger monospace font that 'feels right' [1] leads to fastest long term reading and comfort. Also light on dark background is always better in dark room. Otherwise dark on light is better. Back in a day when we all had low resolution CRT monitors font size was large for everyone and light on dark was common.
[1] If I just sit in a monitor and set up my programming environment I settle to text size that I can read well but is still relatively small. It seems reasonable that you want to see more text. But if I choose little bigger font than what 'feels' right I can read faster. Large font, light on dark background seems optimal.
Using vi for 5y here (switched to neovim) in dark mode, with nofrils-dark[1] theme now, I don’t feel any less productive, on the contrary I can focus for way longer than before.
[1] https://github.com/robertmeta/nofrils/blob/master/README.md
[citation needed]
I have no strong opinion on this subject, but I'd be interested in more data.
Wouldn't the change in display technology from CRT to LCD make a huge difference? I'm not suggesting the ergonomics research from the era was wrong, but a new study could come up with very different recommendations today.
(n.b. I'm not weighing in on whether one white-on-black or black-on-white is more ergonomic, I'm just saying that it's rare that someone preference is actually grounded in ergonomics)
There's no shame in having an aesthetic preference, nor in sacrificing some ergonomics to realize it. If people always preferred ergonomics to aesthetics, everyone would be wearing New Balance shoes (I'm a happy owner of a pair). Your system UI and your code editor is something you stare at a lot, and it's reasonable to want it to look good.
This is also my theory. My theory is that "hacker signals" like dark backgrounds, tricked-out shell config, and using vim are more common in language communities where people feel insecure about their claim to technical status - or rather, about the acceptance by others of their entirely legitimate claim - such as those of Ruby and JavaScript.
What about us greybeards who just feel naked without vi/vim? I've ended up (due to market demand) in the frontend world, but I still use vim because I feel horribly unproductive plodding around with a mouse and arrow keys in Visual Studio or what have you. Yes, given a few weeks I could learn the shortcuts and be more productive, but I can't imagine I'd ever reach my vim level of productivity (same applies to emacs users as to vim users, I'm sure). So why put myself through that?
Just something to keep in mind. Many of us use vim because that's what we're used to. And to be fair to the younger developers, some of them see how productive vim users are in navigating a document and make the switch. Nothing to do with "signaling".
The best thing about modern GUIs is they let me have a zillion command lines open at the same time.
it may just be my own circle, but comparing the Ruby folks I know from 10 years ago to the Ruby folks I know now... there's fewer of them, and those that remain using Ruby day to day never went in for those 'hacker signals'. But the Ruby folks I know from 10 years ago who've left and moved in to other arenas (like JavaScript) did throw use some of that sort of signaling.
When you're reading a block of text, you interact much less with the background than when you're searching and jumping between lines.
Dark themes are much better for my eyes.
Having a hard time believing any research suggesting otherwise. Would surprise me, to say the least.
Also, this is anecdotal - I have 240Hz monitor, and since I started using it (couple of years), I have less eye strain. It could be the refresh rate, or it could be this particular monitor somehow (the quality or whatever). I am not sure.
Basically, 240Hz + dark background + light text + low brightness is ideal for my eyes, based on my experience.
On my phone with an OLED screen I still prefer white-on-black, but that's mainly because even at the lowest brightness it is still far too bright at night.
I don't think one is necessarily better than the other "in general" but there are a couple of things to keep in mind:
- White background might be better on more illuminated environments. Too much contrast is bad
- Syntax highlighting is easier to resolve on a dark background
Definitely an unsubstantiated claim.
There are studies that have shown that in the lab. Meaning that it's worked out that way under whatever conditions were present in the lab, which aren't necessarily the same as the conditions in one's workplace. Real life is probably messier.
For example: https://www.maketecheasier.com/are-dark-themes-better-for-ey...
Blooming, for kids these days, is when the HV supply of a CRT is poorly regulated in a constant-power sense and changes in display brightness cause changes in electron beam current cause fluctuation in acceleration voltage literally make the screen zoom in and out a couple percent while under high load. The poor regulation was usually worse under high current demand, so you could "clear ; top" a black background and there would be no weird zoom effects but a white background might zoom flutter in and out as the content of the screen varied. Very annoying to have one window flutter a little because another had its content change.
Interference and weird aliasing problems showed up in vast fields of illuminated white background more than unlit black background. Retrace lines looked particularly awful on large fields of white. Yes there's a clamping circuit that SHOULD totally shut off the beam on vert-retrace but as you'd expect it looked awful on a $200 CRT monitor and beautiful on a $1000+ monitor. Its just not noticeable on a black background.
There was also a filtering effect, light backgrounds having terrible image quality, a tech giant of 2002 spent decades staring into mostly black background terminals so anyone who in 2019 would not be able to stand black backgrounds was simply filtered out of the pool of possible tech giants back in that era. If you couldn't stare into the abyss of a TRS-80 model III black background sorta low res CRT display for 40+ hours per week, you simply had to leave the computing field in 1981, for example.
The only times we used light backgrounds on CRTs was for non-text purposes (games) and very strange lighting problems (the hated glossy screen with a light source reflected into your eyes, perhaps a very bright CRT background would reduce the massive glare distraction)
To some extent USABLE white background on a CRT was conspicuous consumption in that it was unusable on a $250 monitor or a TV connected to a 1980s home computer but usable white background CRT meant someone bought a $1000+ fancy name brand monitor. Anyone could have a decent black background display regardless of personal wealth but a white background meant you wanted everyone to know you had money, or at least you had money before you spent it, LOL.
WRT conspicuous consumption I was multi-monitor back to the 80s (aka multiple machine on desk) and CRTs were an absolute nightmare where a 70 hz monitor next to a 60 hz monitor made both unreadable or in some ways it was even worse to have a 60.01 hz VGA card next to a 59.99 hz card because then you'd get a magnetic interference crawlie that crept up the screen slowly like a visual hallucination. The tech giants in the linked article were not doing tech work (generally) as most listed people most were (generally) managers and as such having one monitor on a desk for gnatt chart manipulation and email and such was typical for managers of that era, even if the techie front line personnel had three (or more) monitors on their desk.
One of the most interesting interior design aspects of the CRT to LCD transition about two decades ago is my multiple monitors on my desk at home went from as far separated as possible to as close as possible due to no more interference. Roughly as interesting was the transition from 4:3 monitors to wide TV aspect ratios.
I think dark text on a light background looks better in my Kobo. It is a device that looks great on a sunny day.
But I prefer light text on a dark background in Sublime Text when reading on the laptop screen. Different technologies, different light profiles.
Maybe what you want and need is an e-ink laptop screen.