The importance of View Source

Camino View Source

There’s been a long history of innovation on the web founded in open access to the underlying source code that first websites, then later interactive web applications, were built on. The facility of having ready access to the inner workings of any web page has been tantamount to continued inspiration, imitation, and most importantly, the ongoing education of subsequent generations of designer-developer hybrids.

On my panel today on The Hybrid Designer, I took a moment to call out my concerns that the shininess of Rich Internet Application (RIA) frameworks like and (the framework formerly known as WPF/E) is blocking out critical consideration to the gravity and potential consequences of moving to these platforms. As Marc Orchant put it:

One of the most interesting discussions in the session was precipitated when Messina voiced his concerns that “containers” for web functionality like Adobe Apollo and Microsoft Silver[light] would make it harder to create dynamic applications that leverage these data streams as they will, he predicted, created new “walled gardens” by obscuring what is currently a pretty open playing field of ideas and techniques. [Jeremy] Keith added the observation that by hiding the source for the hybrid applications created using these tool, up and coming designers would lose a valuable learning resource that runs counter to the spirit of a read/write web built using open, standardized tools. Needless to say, the room was pretty sympathetic to the sentiments expressed by the panel.

In particular, I was suggesting that these frameworks effectively remove the View Source command — an utter reversal in the trend towards openness in web technologies leading to, in my view, new silos within a more closed web.

Ryan Stewart, who sadly I didn’t get a chance to catch up with afterwards, took me to task for my oversimplification:

Today at the Web 2.0 Expo, I sat in on a panel with Richard MacManus, Kelly Goto, Chris Messina and . They talked about the “hybrid designer” and touched on some points about the web and the richness that has really created the “hybrid” notion. In one bit, Chris said he was lamenting the fact that a lot of RIA technologies are taking away the “view source” and he got applause from the crowd.

I think this is the perfect example of how misunderstood the RIA world is. Chris used the example of Apollo and Silverlight as two technologies that are killing view source. Apollo is meant for desktop applications. We don’t have “view source” on the desktop, but that doesn’t mean we couldn’t. Apollo uses Flex and Ajax to create the desktop applications, and BOTH of those allow for view source. It’s true that Flex developers can turn off that feature, but really how is that any different than obfuscating your JavaScript in an Ajax application? When people want to share, the RIA tools out there have mechanisms in place to let them do that. Can you ask for more than that?

I was also surprised to hear Chris complain about Silverlight in that group. Of all the technologies, I think Silverlight actually has the best “view source” support. It uses JavaScript as the programming language behind the hood, and the XAML is just text based, so you can view source just like any other web page and see both the XAML and JavaScript libraries. That’s pretty open I think.

I’ll plead ignorance here (especially in terms of Silverlight), but I refuse to back off from my point about the importance of View Source (a point that I don’t think Ryan disagrees with in principle).

Whether you can get at the “goods” in Silverlight or Apollo apps is only part of the problem. I’ve examined the contents of four or five Apollo apps and each one had any number of impenetrable .swf binaries that I couldn’t do anything with, and even with the complete source code of TwitterCamp, a rather simple Apollo app, it wasn’t obvious how a design-leaning hybrid designer like myself would actually modify the app without buying into expensive Adobe tools like ($699) or ($499). And that in sence, is no different than removing the View Source command altogether.

…and even when I finally did figure out that I could right click and choose View Source while running TwitterCamp, I received this error message and no source code:


Now, Ryan also claims that We don’t have “view source” on the desktop, and I would argue that 1) it depends on your platform and 2) I’m not fundamentally prevented from tinkering with my desktop apps. And this is key.

Let’s drill down for a moment.

On the Mac, every application has the equivalent of a View Source command: simply right click and choose “Show Package Contents”. Since every Mac application is essentially a special kind of folder, you can actually browse the contents and resources of an application — and, in certain cases, make changes. Now, this isn’t as good as getting to the raw source, since there are still unusable binaries in those directories, but you can at least get to the nib files and make changes to the look and feel of an application without necessarily touching code or having the full source.

And so just like on the web, especially with free and open source tools like Firebug and Greasemonkey, with a little bit of knowledge or persistence, you can modify, tweak or wholly customize your experience without getting permission from the application creator all by way of “viewing the source”. More importantly, you can learn from, adapt and merge prior art — source code that you’ve found elsewhere — and that, in turn, can be improved upon and release, furthering a virtuous cycle of innovation and education.

Nonetheless, I’m glad that Ryan has corrected me, especially about Silverlight, which indeed is put together with a lot of plain-text technologies. However, I still can’t help but be skeptical when there seems to be so much in it for Adobe and Microsoft to build out their own islands of the web where people buy only their tools and live in prefab Second Life worlds of quasi-standards that have been embraced and extended. It feels like déjà vu all over again; like we’ve been here before and though I’d thought that we’d internalized the reasons for not returning to those dark ages, the shininess of the new impairs our ability to remember the not-so-distant past… While Ryan may be technically correct about the availability of the source, if that top-level menu item vanishes from the first-gen of RIAs, I remain increasingly concerned that the net result will constitute the emergence of an increasingly closed and siloed web.

I do hope that Ryan’s optimism, coupled with activism from other open source and open web advocates, will work with great speed and efficacy to counter my fears and keep that which is now the most open and vital aspect of the web the way it is now and the way it was meant to be.

Author: Chris Messina

Head of West Coast Business Development at Republic. Ever-curious product designer and technologist. Hashtag inventor. Previously: (YC W18), Uber, Google.

15 thoughts on “The importance of View Source”

  1. Opening a .app package is a far cry from View Source. It isn’t really any different from resource hacking with ResEdit. The bundle contents can be as opaque or transperent as the developer desires. The same goes for Apollo or Flex applications.

    Also the Flex and Apollo SDKs are free as in beer. You only need to pay if you want the shiny buttons the IDE provides. TextMate + SDK work fine.

  2. I think the freedom to tinker is a key, fundamental freedom whose importance is growing as we depend more and more on software and computer hardware.

    The lack of access to the source code of web services is just as scary to me as the incomprehensibility of .swf files.

    I expect that Silverlight will be fairly transparent. I think Microsoft have learned the value of View Source more than Adobe have. Adobe has built it’s empire on write-only formats.

    The tool that I think is perhaps more important than View Source is DOM Inspector (and probably Firebug). To be able to look at the running state of the application and tinker with it is more valuable in many ways than just being able to read the source.

  3. I don’t think the lack of a “view source” is a fatal flaw (i.e. flash became the favorite toy for young web designers for a while without having a view source).

    However, I completely agree that having a view source does level the playing field quite a bit on the web. I also learned web programming through the magic of view source!

  4. well stated. View-Source is a feature, not a bug, and one that has taught countless people how to code, including me. i’ve always had uneasy feelings about opaque file formats. from search transparency to mobile compatibility, attempts to “rebuild” the web using new formats with little (R)’s or (TM)’s attached usually ends in tears.

  5. fyi

    View source is possible within Apollo, both within Flash based, and HTML based applications. The difference though, is that it is up to the developer on whether they want to allow it.

    You can see an example of view source in a Flash based Apollo application in the eBay application. Video here:

    (toward the end of the video).

    As far as the error with the TwitterCamp app, that is simply a bug in Apollo (which is an alpha). The issue is that the wrong URL is generated and passed to the browser. This will be fixed.

    Finally, you can compile TwitterCamp with the free Flex SDK, which among other things, includes a compiler. More info at:

    mike chambers

  6. Mike: Can you share any URLs of Apollo apps with view source enabled? I’m a Flash developer since the FutureSplash days and I’ve never seen a Flash asset that was view-sourceable without a decompiler. I’m anxious to see this new capability!

  7. If you rename a .xap to .zip you’ll have your source code? much like if i view source now on this blog, all i’d get is the rendered result not so much the actual source. Instead i have to ask you for a copy of it and then would you be willing to provide it as-is.

    That being said, if the end user whom creates and produces Silverlight solutions CHOOSES to withhold the actual source than it’s their right to do so and one that we should all openly respect.

    Just like on the footer of your blog, whereby you’ve opted to protect the content under the Creative Non-Commmerical share license – where it specifies certain restrictions like Commercial usage forbidden – as you’ve just outlined a restraint in the openness of which you’ve just stated should occur.

    I’ve also noted that whilst View Source is freely available in JavaScript/HTML it’s not always helpful or useful. A lot of the times i’ve seen folks obsfucate their JavaScript to ensure it adds extra layers of complexity to those whom wish to reverse engineer it.

    Scott Barnes
    Rich Platforms Product Manager

  8. Thanks Scott.

    I appreciate your point — it’s a valid one. My premise is that content published on the web should be as open and inspectable as possible. In fact, you more or less can get the source of my blog if you download WordPress and the Sandbox theme. Your browser will also give you access to my CSS file and you can readily download all the plugins that I use to power this blog. But that’s not really what I’m talking about.

    The problem that I have with platforms like Silverlight and Air is that, by default, it seems *easier* to choose to make the code harder to get at — or to require expensive tools to tinker around with an app — or to have some strange build process that doesn’t work cross-platform — where I have the biggest problem.

    If you guys put all the effort that you put into Silverlight into open, freely implementable standards that ended up in web browsers that worked cross-platform, I’d have very little grounds to give you shit since the browser, by default, exposes the inner working a webpage with View Source (even if it’s obfuscated). Instead, the Silverlight approach to the web leads to more fragmentation and the need to download yet another plugin, which I refuse to do.

    There is so much promise with HTML5 and CSS3 that I can’t conceive of why you’re continuing to go down the path of inventing your own proprietary stack for building on the web that I must presume that you continue to wish to compete with it, rather than improve upon and unify it.

  9. We’re inventing our own approach to the plugin because it’s what our customers have requested. There’s no hidden meaning, it’s simply free trade working in full view. Whilst I take your point that having view source can help those come to terms with how HTML/JS/CSS works in general, it doesn’t always work that way in reality.

    Out of the % of developers around the world, most would yield their answers to the “how” things work via blogs, tutorials or simply conversations. If a developer or designer wants access to someone elses work, simply ask? the worst they can say is no or don’t answer.

    I disagree that you feel it’s your right to view otjher peoples work and there’s a lot of flaws in your arguement, point and case – how do i get access to the source code in this blog via “View Source”. At what point do you define the safe open source boundaries?

    Scott Barnes
    Rich Platforms Product Manager

  10. This is actually one of the places where I see that Apple is truly innovating by pushing on the CSS standard to do things that I think people never really invisioned. Their implementation of animations and 3D transforms using plain text CSS is really compelling, especially if you can easily fallback to more traditional markup when the feature isn’t present. Degraded experience is another problem with the plugin model.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: