DEV Community

Discussion on: Detecting dark mode on every request 🌓

 
bryce profile image
Bryce Dorn

Yes, that contrived example will load quickly enough to not have a noticeable flicker. But inlining logic directly inside a script tag isn't a good practice, nor is it always possible. If you pull that out into a file and load it via src you will notice a flicker, which is what the codesandbox example I shared demonstrates.

Thread Thread
 
darkwiiplayer profile image
𒎏Wii 🏳️‍⚧️

So your point is that an inline script won't work because it won't work anymore if you don't inline it? Do I need to explain how that doesn't make any sense?

As for inlining a script being "bad practice", I couldn't care less. People have been using tools to inline critical CSS for ages (or even doing it manually) so the same could be done for JS. Inline critical JS snippets that need to be there instantly, then put everything less important in its own file.

And again, I don't know how exactly codesandbox loads its content, so I can't really comment on any results you're getting with it. But if the results don't align with using a small localhost HTTP server, I'll trust the actual server setup before the sandbox.

Thread Thread
 
mangor1no profile image
Mangor1no

Developers nowadays are running wild while talking about "best pratice" and "anti-pattern" makes me reconsider my basic HTML skill everyday. To summarize, there is no such thing that exists. Everything comes with their own advantages/disadvantages, why do we bother to make things become more complicated, just add a simple tag at the begin of the body and it will be loaded before the whole thing. How slow it could be to load this tiny script? Maybe 0.0001 second or even less?

document.documentElement.classList.add('dark');

Thread Thread
 
darkwiiplayer profile image
𒎏Wii 🏳️‍⚧️

Yep. If you want to be really fancy, you can even use that script to set up some simple loading spinner so the page loads more nicely. All in all you'd end up with maybe 10 lines or so.

Thread Thread
 
jon_dewitt_ts profile image
Code_E_Pendant • Edited

@darkwiiplayer This tone of bullying and gatekeeping is neither helpful to the author nor those reading this conversation. I know this is like a year later, but I'd really encourage some self reflection about how inappropriate and unprofessional this was. We should strive to be a welcoming and helpful community. If we have knowledge someone else lacks, we should present it tactfully so it's apparent our goal is to teach. If your approach involves mocking your students for being stupid, then you quite frankly should not participate.

Coming back to the conversation at hand, I'd like to teach the next folks who landed here about what I learned (or relearned, really, I've been away from traditional JS for too long.)

The spec tells us that inline <script> elements are render blocking, and are executed to completion before resuming the HTML parser.

If you're like me, you may have forgotten this after becoming accustomed to modules and modern frameworks. My mental model shifted to assuming all client-side scripts were executed after rendering, which is the typical case nowadays. But this rings a bell when I recall the old days of listening for the DOMContentLoaded event or jQuery's $.ready()

Script tag comparison diagram

So if you ended up here from Google, here's the takeaway - the request headers are still exciting, but they may not be necessary to avoid that flicker or FOUC. Remember, render-blocking is not evil, it's just a performance factor to be aware of.

But, to @bryce's point, it may not be possible if you're bound by your framework. For example, I'm using Next.js and the earliest their <Script> component allows the execution is their strategy="beforeInteractive" attribute, but even though it executes before Next scripts and hydration, it's still deferred until after the first paint. I'm still working on a workaround, but I'm considering ye olde open-source contribution to request a "beforeParser" strategy.

In my case, I want to load the proper favicon based on the user's dark mode preference, but it's worth noting that if you're just trying to apply the proper styles, you can use some variation of the following CSS:

:root {
  --color-primary: #fff;
  --color-primary-contrast: #000;
}
@media (prefers-color-scheme: dark) {
  :root {
    --color-primary: #000;
    --color-primary-contrast: #fff;
  }
}
Enter fullscreen mode Exit fullscreen mode
Thread Thread
 
darkwiiplayer profile image
𒎏Wii 🏳️‍⚧️ • Edited

If you think calling someone a gatekeeping bully for getting a bit too snarky several months ago is gonna make them more receptive to your criticism or do anything to improve the climate of a platform, then maybe you have just as much reason to reflect.


Regarding the actual topic of the discussion,

The spec tells us that inline <script> elements are render blocking, and are executed to completion before resuming the HTML parser.

This part here is really important. It may not be as relevant in a world of frameworks, but inlining JavaScript into the HTML makes it execute as the document is parsed, blocking this process. This is generally not what developers want, but for small snippets of "critical" logic, this property of inline JS can be very useful, as in the example of changing a theme before the whole page has loaded. With some luck, the script might even apply the necessary changes before the actual stylesheet is even loaded (unless that is also inlined)

What's important to note here is that an inlined script cannot access DOM nodes that haven't been reached yet:

<body>
   <p>Before JS</p>
   <script>
      console.log(document.body.querySelectorAll("p").length)
   </script>
   <!-- prints 1 -->
   <p>After JS</p>
</body>
Enter fullscreen mode Exit fullscreen mode
Thread Thread
 
jon_dewitt_ts profile image
Code_E_Pendant

maybe you have just as much reason to reflect.

Perhaps, hard to say, but I felt compelled to reassure future readers that they don't have to feel stupid for missing this. I'm not calling you names, I'm calling you out. I've been called out before too. We're both better than that.

Credit where credit is due, you reminded me of this behavior I had long since forgotten about after more than 6 years without using DOMContentLoaded.

Some comments have been hidden by the post's author - find out more