Thursday, February 15th, 2007

Saving View Source

Category: Editorial

We look at a lot of Ajax applications, and we have seen a lot of trends over the last couple of years.

In general we are maturing, but as complexity has gone up in Ajax applications we are seeing one scary trend.

The first set of apps simply added some <script> that did some happy XMLHttpRequest dancing. Then we abstracted to libraries such as Dojo and Prototype. Then people tried to do the right thing and use unobtrusive JavaScript where we keep the HTMl structure separate from the code. We would all like to see more of this.

Unfortunately, we are starting to see Ajax applications that look more like Flash web pages:

  1. <html>
  2. <head><title>My Ajax App</title>
  3. </head>
  4. <body onload="startupApp()">
  5. <script type="text/javascript" src="myapp.js"></script>
  6. </body>
  7. </html>

The entire application is in JS that generates HTML to be embedded. If it wasn’t for Firebug and friends we would have no idea what was going on. Debugging this is a nightmare. Doesn’t it look like Flash pages with an embed/object pair of tags only?

I hope that the open web solutions can stick with nice unobtrusive JavaScript, or is View Source dead?

Posted by Dion Almaer at 3:32 pm

3.1 rating from 40 votes


Comments feed TrackBack URI

Any good article to brief on using FireBug?

Comment by — February 15, 2007

I never knew a greater dislike than for single page all flash sites, but you really don’t see too many of them around anymore. Generally flash is used in conjunction with other technologies. I think this is the same thing. Sure, we’ll see people who write their entire site/application with JS and very little markup, but I don’t think it will ever get as bad as flash did. Besides, there are people in this world who follow the mantra of semantic code so close that it borderlines a cult.

Comment by Andrew Herron — February 15, 2007

Yes, view source is dead. Long live right click -> Inspect Element.

Comment by James Prudente — February 15, 2007

How about ‘view generated source’ from the ‘Web developer’ toolbar?

Comment by Marc — February 15, 2007

Damn.. View-source was dead 2 years ago when javascript was invented. Thank GOD for firebug. You can instantly see what’s being generated, being updated, etc.

Then again, most functions don’t HAVE to be generated on the fly and will just eat performance of the clientside browser. I think we’re just in the process of finding the right balance.

The right balance IMO is the ‘unobtrusive’ way…

Comment by SchizoDuckie — February 15, 2007

“2 years ago when javascript was invented”
Ok, I know you were busy then…

Comment by Andrea — February 15, 2007

2 years ago, the web was 2 years old… ;)

Comment by Georges — February 15, 2007

I think that this is a doom (destin) of Web2.0 application! It’s normal that Ajax trend to Flash Application, or not?

Comment by Giovambattista Fazioli — February 15, 2007

I agree, view source is dead. A couple of thoughts on this:
1. If page processing can be delegated to the client, this is a good, because there are vastly more client resources available in the world than server (it is essentially a massive distributed processing system).
2. Using JavaScript to build the page does not equal no accessibility, or non standard. My framework, Authenteo utilizes a server side browser emulator that is capable of simulating the JavaScript rendering process on the server for older browsers (and more importantly, search engines). It still delivers valid accessible XHTML. View source on my page to see it in action. I believe that any serious public facing web app that uses JavaScript to entirely build a page, needs this type of technology.

Comment by Kris Zyp — February 15, 2007

Cannot say that it’s a bad way of developing web app. However if you do web app in that way (like Flash app), the biggest problem, I think, is SEO. There is no way for Search Engines like Google, Yahoo!, MSN to know what’s going on your website and index the keywords. Hence, that will seriously reduce your website traffic, and traffic means $$$.

Comment by NKTPRO — February 15, 2007

The View Source Chart extension for Firefox does a great job with this:

Comment by Michael Geary — February 15, 2007

In my opinion, this is definitely not the way “applications” should work on the web. Without any HTML to parse, the page is about as indexable (and semantically meaningful) as a flash movie. Maybe even less? :)
I don’t think anyone here would disagree that if you’re going to use Javascript to build something, you should keep as much information and content in HTML as possible (separation of concerns, unobtrusive techniques, progressive enhancement and so on) – as for structure and meaning, that’s what HTML is meant for! There are a good number of sites which are doing the correct thing in this regard as well, but it’s unfortunate to see 100% JS-only sites. (Imagine joining one of these projects to do maintenance. Yikes!)

Comment by Scott Schiller — February 15, 2007

Unobtrusive javascript only works if you aren’t doing very much dynamically. When your app starts to get really complex, you don’t WANT your javascript to know very much about the html markup. You want your javascript to be the controller of the view. Like any GUI framework, you don’t want your data objects beholden to the renderers.

At some point, if your app is doing too much you simply have to get rid of all the html and let the javascript handle the UI entirely. Your ajax layer becomes a full-fledged GUI framework, not unlike Swing.

Most apps don’t need this thick layer of complexity but some truly do. However, the Original Post has a point in that I’ve no doubt many apps are going this route even though it’s unnecessary.

Nate Grover

Comment by Nate Grover — February 15, 2007

It is funny how people comment here with debugging tools as a solution for a badly planned application. Generating a whole app in JS is not only an accessibility / SEO problem it also becomes a nightmare to maintain.

You template in server side languages – keeping the HTML separated from the business logic to make it easy to change the frontend. The same should happen for web apps that largely use JavaScript. You can always piggyback on non-JS functionality and override it with event handling. You can use the same backend scripts with normal HTTP calls and Ajax calls. You can even include whole chunks of HTML and replace dummy data with real data. Creating massive chunks of HTML in JS (may it be innerHTML, native DOM methods or helpers like DOMBuilder) is as bad as embedding them in a JSP or PHP page from a maintenance point of view.

Comment by Chris Heilmann — February 15, 2007

In my opinion, this is definitely not the way “applications” should work on the web. Without any HTML to parse, the page is about as indexable

Well, if they are applications, why should they be indexed? They wouln’t contain anything to index anyway. How would you suggest to index something like gmail?

Of course, you should make a page about the application indexable and accessible to search engines, but that is a completely different thing.

Comment by Theo — February 15, 2007

I agree this makes life difficult for developer when it comes to debugging and maintanance. I had this expirience when I was supposed to disable some functionalities in Zimbra Web Client ( built using AjaxTK ). Beside Firebug I also relied greatly on grep to locate the code to work on.

Comment by Samyak — February 15, 2007

There is absolutely no web application that would not allow for a traditional non-JS structured markup such as XHTML. Beyond all SEO issues, it’s a matter of accessibility, and of archivability to provide meaningful logical markup rather than dynamic output which depends solely on the current interpretation of some client which happens to be available at that particular place or point in time.


Comment by Bernd Matzner — February 15, 2007

When you use a java swing or swt app, a visual basic app or a c++ app, do you worry about ‘whats going on’ because you can’t see any source code ? Of course not, and this is no different. Debugging the code behind such an app is no harder than debugging GUI code in any of these languages. You may view source and freak because you can’t actually see any source, but if you know how to use visual studio or firebug, you can debug any js app you can load into your browser, which is more than you do (easily) for desktop apps. We’re talking about applications here, not traditional websites, the considerations are different. As far as indexing goes, the guy above already said it – do you care if your gmail is indexed ?.

Comment by steve heron — February 15, 2007

View source will be dead in the future. But as they say, the future is already here, just unevenly distributed. Bye, Bernd, have fun in the past – while it lasts.

(X)HTML is a container for: a) a manifest of JS, CSS, and other resource files and b) optionally, inline resource strings used for easy DOM instantiation. JS/DOM *is* the application, with the browser providing the system libraries. Search-indexable description is yet another resource which may happen to live in the HTML but has nothing to do with your web app’s execution.

Comment by Steve — February 15, 2007

It IS possible to do SEO/accessibility with JavaScript rendered pages. You can see it at and search in google to verify.
One of the aspects of many websites/web applications, is that the dividing line between website and web application is not so nice and neat. Many public facing web applications do have information that they want indexed, and many web sites need to have the capabilities of a web application. The server side is not the only place to do templating, and client centric programming has some serious advantages in terms of a providing a positive user experience with an MVC framework where the V and C aren’t remotely controlled.

Comment by Kris Zyp — February 15, 2007

Sadly it seems a few people here don’t understand the difference between an “application” and a web page/site. Applications are typically present user specific views of data, and allow people to perform actions on that data. This is exactly the sort of thing that *should not* be indexed by a search engine.

Many web applications are written in server-side languages such as java where the developer does not need to know nor care about the javascript or html which is generated and used at the presentation layer.

So the point is, who cares if you can view source of the application, or even if the manipulated dom structure is semantically pure and correct?

Comment by Silly — February 15, 2007

Hi Dion,

View Source is NOT dead with Flex and Flash. Check out how we implemented it for Flex apps. I think as people build complex apps, not just “pages” it is neccesary to evolve this. In the case of Flex, the choice to turn it on or off is the developers, but it is a simple checkbox in the IDE.

Check out some examples here. Right click on the Flex app (these are just random developers examples I found in a few minutes with google):

Boy, sure would be ironic if Flash was a savior of “view source” -;)

If interested, docs on this here:


Comment by David — February 15, 2007

I wrote an application that started similarly to this, but that was because it was a sandbox application that didn’t know what it was going to do until you told it. I assume sites like the one in the example are similar.

Comment by Andy Kant — February 15, 2007

All of the arguments for pure JavaScript apps are based on one assumption: You know what the environment is the app will be executed in. As you neither know the configuration of the client browser nor the ability of the user it is simply arrogant to assume you can control that.

We put apps on the web to have a wider reach, not to restrict users to what we’d like them to have or be able to.

The other assumption is that JS in a browser using browser controls is as stable and tested as a swing or winforms application. It isn’t. A browser and HTML was never meant as an application platform and HTML has terrible flaws when it comes to keyboard controls. GUI libraries have tested widgets that work with assistive technology and several input devices. They also change with the settings of the OS. In web apps we need to simulate that. ARIA will be a way out, but to date this is not feasible yet. It is very interesting to see that “web application developers” are happy to say that we don’t need any non-JavaScript layer, but hardly ever then REALLY simulate how a real application behaves. Does your grid control allow for keyboard access and navigation with the cursor keys or is tabbing considered good enough?

Comment by Chris Heilmann — February 15, 2007

“Does your grid control allow for keyboard access and navigation with the cursor keys?”

Yes it does.

I agree that html/js is not an ideal gui platform and requires you in many ways to constantly reinvent the wheel. However you make a poor argument – what exactly does html’s lack of keyboard accessibility options have to do with the difference between rendering purely in javascript vs (x)html, and the effect on “view source”? At least with javascript you can implement custom keyboard control handlers within components, whereas using html you can’t.

Comment by Silly — February 15, 2007

This is the opposite of “Step Up” development. I think Matt Sweeney just through up a little in his mouth looking at this site.

Comment by Ben — February 15, 2007

View Source Must Survive! The veins and bones of the web must continue to be readily visible as this is how we got to where we are now! Without view-source, there was no way that years ago I could have used some clunky tools and a very ancient Netscape to make my Geocities website, full of rotating smily faces, “download netscape” icons, and page counters! Nor could the rest of you rapidly learn, evolve and professionalise the quality of websites and the overall industry. Obfuscating the code is a bane to the developer and everyone else. I’m all for javascript and sometimes there is elegance to building HTML via javascript, but lets do everyone a favour and ensure that we can all cross-pollenate ideas and knowledge and keep the internet moving at its astonishing rate!

Comment by Siggy — February 15, 2007

I think it all depends on what you are building. If you are building a website that needs to be indexed by search engines, the accomodate accordingly. Sprinkle your HTML pages with the latest and greatest AJAX libraries, and have fun doing it! But if you are developing a RIA, you are probably not concerned about Google’s spider crawling, and in fact, you may not want it to. If you are developing such an RIA, the user experience is the most important thing. If that can be accomplished, all else is second. Ideally, you want to split out the user elements. There are some great tools for doing such “template” processing in JavaScript. Heck, good o’l XSLT even suffices some times. But again, if a tool you want to use to provide a great user experience for your RIA doesn’t allow “view source” is it really that bad?

I’ve been working on a bootstrap/loader utility, similar to Dojo’s bootstrap, that allows a developer to define a boot sequence. This ensures all necessary scripts are loaded before application code kicks in, throwing those nasty “object not defined” errors we love. Using this bootstrap, I have one single JavaScript include, so “View Source” would look like the original code example above. :-)

Comment by griffiti — February 15, 2007

Its amazing how much discussion can gather around a big burning straw man… Apart from Dion’s example can someone point me towards a serious, successful site that has been implemented in this way? Does this really seem to be an actual trend or is it just something that would be bad if it were actually true?

Comment by wioota — February 15, 2007

…or is View Source dead?

View source died the day they allowed CSS to load in external files and the day Javascript files became so large that they had to move them into a separate file to encourage them to be cached by browsers. Since then, when you view source a webpage, you never know when CSS really moved the content around or set the wrong width, without also downloading the CSS file.

All of the arguments for pure JavaScript apps are based on one assumption: You know what the environment is the app will be executed in. As you neither know the configuration of the client browser nor the ability of the user it is simply arrogant to assume you can control that.

Maybe the example is for a secondary page that has already passed the initial environment checks and any unsupported environments would have been redirected to a “safe” page? Having them on separate pages is better since unsupported users won’t have to download all the CSS+JS files that they can see anyway.

Comment by Jordan — February 16, 2007

Plain old view source has been dead for years. Hence Jesse Ruderman’s early bookmarklets like “view generated source”, DOM Inspector, and now Firebug.

The arguments for accessibility and SEO as reasons for never dynamically generating JS are incomplete in this case. Accessibility and SEO can be achieved with or without so-called “unobtrusive JavaScript”.

For sites that make extensive use of Comet to return live data (Renkoo, meebo, etc.), given that you only care about the current snapshot of data, there’s a much different use case than other sites that are really just html content with an enhanced or promoted DOM, as well as the argument made above that much of your content is private and would not be indexed in public to begin with. This is why you see easy support for both ends of the spectrum in Dojo, as points all across this continuum are needed for convenience depending on the type of application you are building. Having worked on the full range of such apps, my experience of the maintainability of such apps is not which approach was taken, but that the right approach was taken for the type of app being created.

Comment by Dylan Schiemann — February 16, 2007

I think the “Saving View Source” is not the important issue to discuss here. What needs to be argued is “Is this good to write an application in that way. What are the advantages and disadvantages?”. Any other idea bros? I find this topic interesting.

Comment by NKTPRO — February 18, 2007

Yeah “View Source” is dead. So? Where does the UN Declaration of Human Rights state that you must be able to see a huge load of markup which describes the entire content of your bowser window????

What a strange concept!

Comment by Animal — February 19, 2007

Ok, some important points:

1. View source is gone for dynamically rendered webpages. No problem, Firebug and other tools will show you the CURRENT DOM. Perhaps a future version of Firefox will have an option like: show original source/show current source. Problem solved.
2. Google Web Toolkit (GWT) works this way, no markup, initialize layout with javascript. So at least one of te big three is moving into this direction. They develop it because of theh problems doing it the traditional way.
3. Microsofts view of the future: Applications = Markup + Code. So the 2nd one of the big three is promoting full markup. And that’s cool because they introduced us to code-behind, so we can separate the markup and code.
4. As usual, some Ajaxian readers do not understand the difference between webapps and websites. Many, many, many webapps are developped internally at a company. SEO is NOT AN ISSUE. Developers would rather specify a borderlayout in coce than have to fiddle with CSS.
5. Please stop using every possible argument against any development! It’s always the usability, the download size, SEO, etc. etc. How do you get work done like that? Is it only good if it satisfies each and every requirement that you can come up with?

Comment by Mike — February 21, 2007

All the mistakes of the past seem to live again under the guise of ajax… much better to embrace Hijax/progressive enhancement!

Comment by Ben Buchanan — February 21, 2007

Leave a comment

You must be logged in to post a comment.