Different views on view-source

Over on Jonathan Snook’s blog we have a pretty good debate about a controversial tweet by Tom Dale:

Can we agree that, in 2018, human-readable "View Source" is a constraint the web can discard? I benefitted from "View Source" too, but today we have an embarrassment of resources and open source examples I would have killed for as a kid.

— Tom Dale (@tomdale) [February 19, 2018](https://twitter.com/tomdale/status/965681976199077889?ref_src=twsrc%5Etfw) In essence, Jonathan points out that whilst web development has become much more complex, that isn’t a reason to disregard a human readable source: > The increasing complexity of tools doesn’t negate the need for those earlier, simpler tools, though. In other words, horses for courses. A simple web site doesn’t need complex tools and benefits from view-source. Other, more complex web products are not as interesting to look at as a simple HTML display. Tom also points out that he doesn’t mean that you shouldn’t be able to peek under the hood of a site, but that a simple view-source isn’t the correct tool.

Just to clarify: I'm not suggesting removing the ability to inspect what's happening in a web app at runtime. I just mean that it's reasonable to have the assets served to the browser require some sort of post-processing to be understandable.

— Tom Dale (@tomdale) [February 20, 2018](https://twitter.com/tomdale/status/966006492733329408?ref_src=twsrc%5Etfw) And you know what? I tend to agree. There is no doubt that view-source was what made the web great. It drove business owners crazy that all their code was readily visible and copy-able in the browser. For developers it was great, though. Almost all learned by looking at what other people do. And by copying and pasting. And this is where it breaks apart. I want to emphasise this: it used to be great to hit cmd+u and look at a web site in “text mode”. It was even better when the “view-source:” pseudo protocol became a thing. Browsers added colour coding and later on Firefox even highlighted syntax errors in your markup as bold and red. 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. The big proponents of view-source tout its usefulness and simplicity. But we can also start thinking about the problems it has: - Except for a few purist web sites out there, what you see in your current device isn’t the code of the web site. We shouldn’t ship the same code down the wire for a low-end mobile device than for a retina screen, fast connectivity device. View source is thus giving us a false impression. - Code sent to the web is often minimised and bundled. Developer tools give you options to pretty-print those and thus make them much more understandable. - Of course it is great that there is no barrier to entry if you want to know how something works. But the forgiving nature of HTML and CSS can also lead to problems. When we released Edge, we found that thousands of web sites defined a text encoding of utf8 instead of utf-8. We needed to fix this in the browser. Clearly people copied and pasted without thinking or validating. And that’s where unexplained code like in a view-source environment fails. A lot of the fight for view-source stems from a nostalgic view of the internet and how people build for it. Our excitement of learning the web this way is still lingering and we don’t want the next generation to miss out. But maybe it is time to move on and understand that by sticking to old methods we deprive new developers. When we started, view-source was all we had and resources about what these things mean were scarce. Even worse, they were tinted with corporate needs, rather than following a standard. You learned the Microsoft web from Microsoft, the Netscape web from Netscape and standards when you had the time or listened to those Opera freaks. I wrote about this back in 2011 in my [Lynx would not be impressed – on semantics and HTML](/2011/11/16/lynx-would-not-be-impressed-on-semantics-and-html/) post. And now, seven years later, I still think it should be up to the current generation of developers to choose what makes most sense for them. Our nostalgia might actually be hurting the cause. Snook’s right: we have no right to dismiss or actively block view-source as a means to access code and learn from it. But I don’t think that in today’s development world this is enough and it makes so much more sense to delve deeper into the tool stack we have. Just consider the amazing tools we have at our disposal for new developers to learn about web development rather than looking at other people’s code in the browser: - The [MDN Web Docs](https://developer.mozilla.org/en-US/) are an editable resource of everything web, maintained by all the browser makers and with help from many of the large web companies - [Can I Use](https://caniuse.com/) gives you detailed information about what works in what browser, links to the standards and explains implementation quirks - [GitHub](https://github.com/) is the home of the source-code of many web projects with a whole history of commit messages and explanations how the code works and where and why people added hacks you shouldn’t copy - [JSBin](https://jsbin.com/) , [Codepen](https://codepen.io/), [Glitch](https://glitch.com/) and many other interactive development environments help you get started coding things without the pain of setting up all your preprocessors. Something that proponents of a simpler web always bring up as a huge barrier to entry to the web. - Browser developer tools aren’t just “look at code” any more. They are fully fledged development environments that give you amazing insight into what’s going on and how things work. They even audit your code and tell you where things go wrong. All in all I love view source and what it has done to the web. But I also think that in order to build great products these days we should find ways for newcomers to learn about becoming a developer. Not someone who copies and pastes. Learning about code editors, learning about version control, and learning where and how to ask for help are much more important skills. I believe deeply that free, open source tooling and systems like GitHub and the abovementioned editors are a much better way to teach people to get started with the web than view-source is in 2018. We already live in a more complex world, and we have tools to make that easier. This is the main topic of my [Skillshare class](https://skl.sh/christian_javascript) about JavaScript and how to deal with the changes it went through. It is not only about JavaScript, but about the resources I talked about and what tools to use to make your live easier. I wrote this to make myself more content and happy in this demanding world, and I hope it helps you, too. Old-school developers will find things to try out and new developers should get a sensible way to enter the JavaScript world. Beyond View-Source but without having to be a Webpack expert before you write your first line of HTML.