The Three Meanings of "View Source"
When developers talk about "View Source," they aren't always referring to the same thing. Jim Nielsen recently highlighted this ambiguity, and it's worth unpacking because the assumptions we bring to the conversation often cloud what we're actually discussing.
There are three distinct interpretations, each with a very different purpose:
- View source code: The original code that generates the HTML sent over the network.
- View page source: The raw HTML as delivered by the server.
- View runtime source: The live, mutable DOM as rendered in the browser.
These three are nowhere near equal in practical value. If you were to slice the pie by what developers actually use, the distribution looks something like:
- 10%
- 5%
- 85%
The runtime source is where the overwhelming majority of value lives. Every major browser ships with DevTools that expose this living DOM, and it's hard to imagine the ecosystem without it. For non-developers, that tool alone can be the gateway into web development.
Why Runtime Source Wins
DevTools also offers a way to inspect the exact HTML that arrived over the network. This capability is part of why the traditional "View Source" command feels so obsolete. As I've said before, I wouldn't notice if it disappeared entirely. DevTools fully supersedes it — you can quite literally view the page source from inside the developer tools when you need it.
The Client-Side Caveat
For sites built entirely with client-side JavaScript, viewing the HTML over the wire is nearly meaningless — it's just a shell waiting to be populated. The real logic lives in the codebase. If that codebase is open, of course, there's real value in examining the full source. But for the vast majority of debugging and learning, the runtime DOM is what matters.
Nielsen's post covers the distinctions between all three kinds of "viewing source" thoroughly, and it's worth a read if you've ever found yourself in a conversation where everyone assumes they're talking about the same feature.
