~robcee/ more than just sandwiches

Posted
8 January 2010 @ 10am

Tagged
Mozilla, Programming

View-Source IS Good. Full-stop.

I saw a tweet this morning from Joe Walker linking to this article asking Is View-Source Good? from Alex Russell of Dojo fame and I had to write about it. It’s something I’ve been thinking about a fair bit lately, so his timing was excellent.

Open systems are better and lead to more productive coders. This is a wild assertion I’ll make with some cheek, mostly because I don’t think any exemplars from closed-system programming can really refute it, or will. Programmers who get into pure languages like Lisp and Smalltalk ramp up quickly and become more productive because they have full view of the system’s source code.

So too, the web.

Web-programming is often a cut and paste experience. I hear the term “cut-and-paste inheritance” used derogatorily too-often. While it’s true that in some cases, from a code-design perspective, just pasting blocks of code from one document to another can lead to a poorly-designed system, it is great for getting little pieces of code to work. It is the scientific method applied to programming. You see something that works in one place, you try copying it over and see what fails on your page. Continue.

One area where view-source breaks down is in the analysis of “what happens” with that source code. The Error Console in Firefox is a poor-excuse for a debugging mechanism and linked to the view-source window only by a hopefully connected error and a line number you can click on. Errors can come from any tab and are not necessarily associated with your code. There is no sense of iterative feedback. You have to hunt for it and usually fall into a pattern of clearing your console and reloading the page to see when the errors occur. This leads many developers to write their own logging function. Or when they’ve graduated to more advanced development, install Firebug which presents dynamic views of your source code in exciting (and sometimes surprising) ways.

Another mysterious failing of view-source is in a dynamically generated page. Something that uses document.write() or a bunch of appendChild() calls often doesn’t show correctly in view-source. A trick I learned recently to see these types of changes is to select some text and right click on it and “view-selection source”. Not exactly intuitive, but this will show you what your code generated.

I don’t think anyone can claim that view-source is a bad thing, though I have seen people try to get around it. Usually under the guise of “I have some important information or data that I need to protect”. I have seen people file bugs to add a mechanism to Firebug to prevent inspection of the underlying HTML on certain pages. I find these types of requests pretty funny, generally, and a little sad because people who think this way fundamentally don’t understand what the web is about and how it works and why it got to be the wonderful thing it is today.

It’s a fairly common practice to hide content behind a flash barrier to prevent people from getting their grubby paws on it. This creates a large swath of the web that you really have no ability to play with or learn from. Also, I think it’s fairly safe to say that learning to program in Flash is a more expensive proposition than learning to program for the web. You have to pay for tools, books and example code. If you want to make something that looks like this widget over here that has some wandering penguins on it, you have to figure it all out for yourself.

Alex mentions generative tools and libraries like GWT that create HTML and CSS styling as by-products of their execution and that these create a not-very useful rendition for view-source. This is true. Even PHP-generated HTML can be pretty disheartening to look at if you’re trying to figure out what’s going on in a web-page — its poor formatting and machine-generated constructs are not pretty to look at, but you can still sometimes glean some of the workings behind them. Having hacked around in WordPress for a few years, understanding the way the PHP code generates a blog’s output is an interesting experiment to puzzle through. I wouldn’t have been able to do that without view-source.

Anyway, I think I’ve burbled about this enough. I love view-source. There, I’ve said it. It is one of the most valuable tools we have for understanding and learning about the web.


11 Comments

Posted by
Topher
8 January 2010 @ 11am

The web developer toolbar has a function called “View Generated Source” which I’ve found to be REALLY handy when dealing with html generated by JS.


[...] Russell poses the question that few probably ever think to ask: Is View Source good? Rob Campbell replies "of [...]


Posted by
Sumana Harihareswara
8 January 2010 @ 2pm

I nearly can’t believe people ask Firebug to block some inspection! Wow.


Posted by
Aaron
8 January 2010 @ 4pm

More the reason to improve Firefox’s View Source, i.e., See my blog post

http://aaronmt.com/?p=601


Posted by
Ozten
8 January 2010 @ 6pm

I think the current challenge to view source is performance. Getting better yslow scores means concatenating separate scripts, minifying, etc or with “Closure” recompiling easy to read JavaScript into high performance JavaScript.

I think View Source should trump performance concerns, but for high volume websites it’s a hard sell. The more the platform makes these optimizations unnecessary, the better for View Source.


Posted by
robcee
8 January 2010 @ 7pm

@ozten: that’s a good point and one of the big problems with JS debugging in Firebug too. It’s hard to come up with a decent all-around solution. JSBeautifiers only give you a reformatted view of a minified source file, but the variables and function names are still cryptic. Maybe some cleverness would work: Detection of a popular JS library would offer a link to the non-minified source for browser? I dunno, but good food for thought!


Posted by
Atul
10 January 2010 @ 3pm

Is there any kind of ad-hoc standard we could create that might allow a minified file to be able to “point” to its full-source representation? e.g. a comment at the beginning of the minified source of the form “//@non-minified: http://foo.com/blah.js“? I suspect if some standard were set up, a lot of library and “minifier” tool creators, as well as web devs, would be happy to put metadata in to make it easier for folks to understand their code. I could be wrong, though.

Another thing I frequently try is that, if a file is called foo.min.js, I try just removing the “min” and seeing if that works. Often it does, so perhaps the view-source tool could just do that automatically. Ideally we should be able to access the JS parse tree of the code and make sure the un-minified source matches the minified source.


Posted by
robcee
10 January 2010 @ 4pm

@atul I like the idea of prepending some kind of link to a non-minified version of the file. It doesn’t add a lot of weight to the file and provides an easy way to see what you’re really looking at. I’d certainly use that feature if it were available and I bet others would too.


Posted by
Alex
11 January 2010 @ 4pm

Firefox’ “View Source” functionality has always been quite useless for me until I found this plugin: http://users.skynet.be/mgueury/mozilla/

That’s probably the most comfortable way to validate you markup in Firefox (not more than one click) and view the pages source at the same time.


Posted by
Lukas
23 March 2010 @ 3pm

Excellent points. I wouldn’t be here today, or even be that interested in the web if it wasn’t for stuff like view source that helps you learn how to customize the web. From early attempts to learn html, to my current side project of wordpress theming – it’s all much better when you can see the code behind the pretty pictures laid out on the page.


Posted by
~robcee/ – Inspector Impetus
21 May 2010 @ 11am

[...] we include View Source in Firefox 3.6. I’ve blogged about how important view source is and how awesome it is that we have it, but inspection is a [...]