I remember seeing this Tom Dale tweet a while back. It’s literally about the browser’s ability to look at the HTML of the document you’re looking at as it first arrived. Now the tweet is stirring up a new round of conversation.
Jonathan Snook has kind of a baby bear take:
We have the ability to inspect the original HTML source along with its interpreted representation. We have the ability to inspect the source of JavaScript and CSS files mapped from its minified and optimized versions. We have the ability to inspect rendering pipelines. We have the ability to stop and step through JavaScript execution line by line.
The increasing complexity of tools doesn’t negate the need for those earlier, simpler tools, though.
The sites some build may be simple static sites, befitting of a simple View Source. The sites some build may be compiled and bundled and requiring tools that allow us to dig deeper. Just because you don’t need those tools doesn’t mean that somebody doesn’t need those tools.
And Chris Heilmann:
For a simple web site with everything in one document or a few linked scripts and stylesheets, that was enough.
I don’t think it is any longer though. Even navigating simple source code of a web site is much more fun in developer tools rather than a huge text block. We can right-click on an element these days and go directly to it. We see how the cascade works when looking at its CSS and we even can see attached events and hover states.
Sure, developer tools are harder to learn than looking at a document, but you also learn so much more from them. The beauty of view-source was that it came for free with a browser. This made it a tool of choice for anyone becoming a web developer. There was no need to download and learn an IDE – your development environment was the consumption environment.
Well, that’s exactly what developer tools are these days. They are free, they come with the browser, and they are not impossible to understand. If anything, I like the fact that they give you more insights into what the code does rather than what it is.
I’ll take a hard-line stance, just for fun here: I literally don’t care at all about View Source and wouldn’t miss it if it was removed from browsers. I live in DevTools, and I’ll bet you do too. It entirely supersedes View Source, as you can quite literally view source inside it if you’d like. But that’s beside the point.
I don’t want my source to be human-readable, not for protective reasons, but because I care about web performance more. I want my website to arrive at light speed on a tiny spec of magical network packet dust and blossom into a complete website. Or do whatever computer science deems is the absolute fastest way to send website data between computers. I’m much more worried about the state of web performance than I am about web education. But even if I was very worried about web education, I don’t think it’s the network’s job to deliver teachability.
Correct me if I‘m wrong but with dev tools you inspect the dom, not the source. And browsers do funny things to the dom like auto closing tags you missed resulting sometimes in quite strange errors. That‘s when I switch to view source. Counting opening tags & closing tags
You’re not wrong. Typically you’re looking at the DOM because that’s the most useful. But the source is there too.
True, the source can be accessed from dev tools, but it’s more of a pain than a simple
cmd+opt+u
orctrl+u
— or even a right-click > View Source. Sometimes, I just want to a take a quick look at the original HTML without having to search and expand trees in the dev tools.I mostly live in DevTools, but I absolutely use “View Source”. But, I’m a back-end developer primarily. I need to see what my server sent over the wire, before the browser started mucking about with it. “View Source” is extremely important to my work, because when something goes wrong, I need to see if my server is sending something that’s screwing up the rendered site.
Although, as more and more I’m building APIs, I almost as often am using Postman or HTTPie as I am “View Source”
For this, I think, network tab is more useful, as it gives more info about what got sent and how.
it’s critical to know what comes in through the request vs the interpolation of the inspector tool.
View-source offers at-a-glance insight into the methods and attitudes of the site’s developers. Web developers don’t write DOM parts, they write markup. Looking at markup is to looking at dev tools as surveying someone’s living room is to reading a detailed list of its contents.
I find it to still be useful when you want to find a specific bit of code (is it a WordPress? Cmd+Opt+U + Cmd+F wp, done! – also works with the Developer Tools, of course, I just don’t find it as “snappy”), or have a look at some source code on your mobile device. This has happened more than once, e.g. when a friend asks me to look at some website’s source code while I’m on the go, and don’t have any fancy apps/tools for that. It’s a very small usage I make of it, but still, I find it useful and would be a bit sad to see it disappear.
Yup, I use view source when debugging wordpress script and style load ordering. I open two tabs, refresh one after a code change and A-B them to see if a line has changed.
I’m sure I’m missing something here.
What is removing a feature from the browser, that’s helpful to inspect raw HTML source, supposed to achieve for users?
As for readable vs. non-readable code goes – minifying HTML and CSS classnames shave the payload size by a trivial amount. Infact, with GZIP these shouldn’t be an issue at all. One probably has a ton of CSS if minifying classnames saves them a noticeable amount, in which case, the real problem is something else clearly.
Just trying to understand where this is coming from. Making the source un-readable (with the exception of uglifying JS) as a performance tradeoff doesn’t seem very practical.
View Source for life. I can’t believe people would argue for its removal. It’s a simple, yet very insightful, feature that if removed would be of no gain to anyone.
Actually I use both tools. The more Javascript widgets riddle sites I have to take care of, the more I need to know how the page looked like before some remote script took the leisure of inserting new DOM nodes, inserted classes or altered attributes.
It really depends on what I’m trying to do. If I’m looking at what CSS is applied to a particular area of the site then the dev tools are the place to be. If I’m trying to explain how a site was put together then I start with View Source and move to the dev tools as next step.
I like to inspect the raw document that was sent to the browser. As Chris pointed out he wants his source to be fast, not human readable. Allowing folks to see that raw output helps them see how we’ve gone about making things fast before they are updated into the DOM in dev tools.
There’s a big difference between view-source:https://www.nasa.gov/ and the Dev tools version.
I can’t count the number of times I’ve tried to help another developer out and I ask them to view the source… they look at the DOM tree… and I have to tell them to use CTRL+U to get the full raw source in a quick and easy full screen view (dragged to a secondary monitor if available) – OK now we’re cooking! see that badly formed HTML or link/script/base/style tag that got injected before that meta tag… yeah that’s why IE is failing… or that div/span/? before the body tag… yeah that’s why you are having issues. I love the DOM tree but that is the result of parsing the full DOM. Can I see basically the same contents if I dig through the devtools? yeah sort of… but in a smaller window and without a hotkey. In Firefox & Chrome it is also a live window (F5/CTRL+F5) to reload, and all of the links are navigable (e.g. to included scripts, styles, iframes). In Firefox, invalid content is highlighted in red with tooltips indicating why it is an issue. Finally I can actually access the source without needing the dev tools at all by prefixing a URL with “view-source:” e.g. view-source:https://www.google.com/ this comes in super handy when there is some redirection/self-closing or other borked JS on the page that cause the content to change or close before you can get the dev tools open. #LongLiveViewSource!
As Chris pointed out, you can still view the source from the devtools. Why not just open that view when “View page source” is clicked. Best of both worlds.