Ask HN: How did dark mode win?
If you've ever worked on a mobile app or website before you know that going from one theme (light mode) to two themes (light / dark) is a huge task. You have to make all the colors in your app super generic. And it's even harder than that, because you can't just switch colors one-for-one. In a well-designed dark mode you have to rethink a lot of UI concepts (mostly around light, shadow, and contrast) in order to make things look nice.
I am not opposed to dark mode at all, I think it often looks nice, but as someone who has spent some time in big companies I am really shocked at the level of engineering resources that have been spent on this relatively frivolous feature. Most engineering teams have a huge backlog of features/bugs to fix. Dark mode has somehow made the top of the stack.
So I'm asking HN. Have you worked on a major app that added dark mode? Who within your organization pushed to prioritize it? How much time did it take and was it harder/easier than you expected?
62 comments
[ 3.2 ms ] story [ 108 ms ] threadWhy do developers prefer the dark theme? Because the light attracts bugs.
Rofl.
That's a solution that seems to work for every other app I use, and the phone does it for me. I try to avoid custom modes of anything as much as I can. I prefer the default-case experience, which is usually the best optimized and least likely to get me into a situation I can't get out of.
The impression I get is that developers are noisy about it, and since they're the ones in the room, their voices get heard. Other users who want different forms of accessibility don't attract as much attention and so it's not top of anybody's backlog.
Dark mode makes it possible to see far smaller things than you can see otherwise. This is particularly important on phones with their tiny screens, or when doing things with lots of details, no matter how big the display.
The default used to be light text on a dark window, for decades before the Mac and Windows came along. There were many reasons for it besides avoiding screen burn.
I do use flux [0] though, because the default monitor brightness is too bright for me, even in broad daylight, never mind at night. For my smartphone I use the Twilight app, which isn't as good but better than nothing. Not sure about the whole blue light thing but it's very easy on my eyes, much better than dark mode.
[0] https://justgetflux.com/
grammar edit
"[...]To summarize, a dark-on-light (positive polarity) display like a Mac in Light Mode provides better performance in focusing of the eye, identifying letters, transcribing letters, text comprehension, reading speed, and proofreading performance, and at least some older studies suggest that using a positive polarity display results in less visual fatigue and increased visual comfort. The benefits apply to both the young and the old"
https://tidbits.com/2019/05/31/the-dark-side-of-dark-mode/
Sure, but it doesn't look as cool.
It can be used during day time and it doesn't give you headache at night time.
(added: we’ve got some of those folks popping up in this thread now.)
and then bam one day we’ve got dark backgrounds everywhere.
To save battery and burning issues.
When I started coding in the 90s dark mode was associated with old. "Cobol dinos" used dark modes, we "cool kids" used light modes. Nowadays if you ask most young programmers they will say that light mode is old. They use dark mode.
And I guess this idea of hip, has turned mainstream lately. The latest uses "dark"
Fl-41 glasses work much better, but I often don’t have them handy.
Now that many people moved their CSS into JS and that components are more standalone, you can simply flip a flag and use another color palette.
Take this React pseudocode as an example.
Before, you would have to handle it manually. "html.dark-theme .menu .menu-item .menu-link {color: white; background: black;}" ... for every single style declaration.
Sure, preprocessors made them easier in the way that you could simply do ".dark-theme & {}" which would generate the style declarations for you. But it was still a bit of a pain and required using things like mixins that add an extra layer of complexity and support.
Now, your React component can simply be myAwesomeComponent: { titleColor: theme.text, cardBackground: theme.highlight, cssOverrides: css`border:1px solid ${theme.borderColor};` }
Then you have something somewhere that just flip the theme.
const darkTheme = {text:"#fff", highlight:"#000", borderColor: "#ccc"};
mySuperCoolApp.setCurrentTheme(darkTheme);
This makes adding a bunch of themes an afterthought. On an internal app that I worked on, I made a bunch of themes as easter eggs. All that was needed was to duplicate the theme declarations and change the colors. So some users could decide to use different colors.
Another point is that accessibility is becoming more mandatory than before. If you are required by law to support multiple font-sizes, you might as well make it so that you can support multiple colors. It allows things like high-contrast accessibility themes and you can throw in a few extra fun ones just to make your app stand out.
I can’t think of any app or website where dark mode has been added as a “forced” choice. The addition of a dark mode is almost always implemented as an optional feature and you can generally choose your preference.
So from a user’s point of view, I can only see this as a positive addition. For those of us who prefer dark mode, for a variety of reasons, we enjoy having the choice. For those who prefer lighter themes, nothing really is being taken away.
The more interesting question to me is why this topic evokes such strong emotions with one side stating often in very strong terms how “wrong” the other side is!
Additionally, AFAIK, InfluxDB UI (previously known as Chronograf), only supports dark mode.
My point (perhaps not worded clearly enough) was that there are very few cases where only dark mode is available. I was trying to say that in most cases where a dark mode has been added, a light mode is also available.
I'll give you InfluxDB but, like Grafana, there is a use case of those systems being used on large TV screens so the dark UI has perhaps more of a functional reason behind it than other software.
2016-08-08: Windows 10 Anniversary update includes system-wide dark mode option.
2018-06-04: W3C issue created for light/dark mode via CSS: https://github.com/w3c/csswg-drafts/issues/2735
2018-09-24: MacOS 10.14 (Mojave) includes system-wide dark mode option. Safari tech preview adds the CSS media query `prefers-color-scheme`.
2019: All major browsers implement `prefers-color-scheme`.
Et voilà, dark mode everywhere.
Personally, I'm more interested in high-contrast modes. (Available in CSS via the experimental but widely implemented `prefers-contrast` media query. Web devs, support it today! Make life easier for those of us who struggle when forced to stray from good ol' #FFFFFF and #000000.)
I wish GPUs had programmable scanout "hooks", so that you could run a bit of hard-realtime code to modify colors as they went out. As it stands, you can either twiddle the colorspace knobs (limited control, can't do perceptual color->grayscale), or you can get the system compositor to run a color conversion pixel shader to modify the display buffer. The latter is infinitely customizeable, but eats into frame budget, bandwidth, and runs the risk of not finishing in time for scanout.
(Now I'm wondering if something like this has been added to more recent GPUs, or if it's been there all along and I didn't realize it. Time to do some research.)
But it's also primarily a young person's thing to be able to stay in the cave. Older people are more often put in a position where strong ambient light is assumed, either because of job/household environment or because their eyesight starts to prefer it.