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?

What a strange concept!

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.

…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.

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. :-)

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.

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?

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): http://www.darronschall.com/downloads/AnimateColorDemo/AnimateColorDemo.html
http://www.arpitonline.com/blog/downloads/closeableTabNav/TabManager.html
http://www.arpitonline.com/blog/downloads/numberedList/
http://www.brucephillips.name/flex/moduleexample/moduleexample.html
http://weblogs.macromedia.com/sho/archives/Example_5_3_05.swf

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

If interested, docs on this here:
http://livedocs.macromedia.com/flex/201/html/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Book_Parts&file=build_044_13.html

Regards,
David
Adobe

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?

(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.

Bernd