Just In General: JS Only Vs Page-Based Web Apps

Question

When a developing a web app, versus a web site, what reasons are there to use multiple HTML pages, rather than using one html page and doing everything through Javascript?

I would expect that it depends on the application -- maybe -- but would appreciate any thoughts on the subject.

Thanks in advance.

EDIT:

Based on the responses here, and some of my own research, if you wanted to do a single-page, fully JS-Powered site, some useful tools would seem to include:

JQuery Plug Ins:

JQuery History: http://balupton.com/projects/jquery-history

JQuery Address: http://plugins.jquery.com/project/jquery-address

JQuery Pagination: http://plugins.jquery.com/project/pagination

Frameworks:

Sproutcore http://www.sproutcore.com/

Cappucino http://cappuccino.org/

Possibly, JMVC: http://www.javascriptmvc.com/

Answer 1

page based applications provide:

• ability to work on any browser or device
• simpler programming model

they also provide the following (although these are solvable by many js frameworks):

• bookmarkability
• browser history
• refresh or F5 to repeat action
• indexability (in case the application is public and open)

Answer 2

One of the bigger reasons is going to be how searchable your website is.

Doing everything in javascript is going to make it complicated for search engines to crawl all content of your website, and thus not fully indexing it. There are ways around this (with Google's recent AJAX SEO guidelines) but I'm not sure if all search engines support this yet. On top of that, it's a little bit more complex then just making separate pages.

The bigger issue, whether you decide to build multiple HTML pages, or you decide to use some sort of framework or CMS to generate them for you, is that the different sections of your website have URL's that are unique to them. E.g., an about section would have a URL like mywebsite.com/about, and that URL is used on the actual "about" link within the website.

Answer 3

One of the biggest downfalls of single-page, Ajax-ified websites is complexity. What might otherwise be spread across several pages suddenly finds its way into one huge, master page. Also, it can be difficult to coordinate the state of the page (for example, tracking if you are in Edit mode, or Preview mode, etc.) and adjusting the interface to match.

Also, one master page that is heavy on JS can be a performance drag if it has to load multiple, big JS files.

Answer 4

At the OP's request, I'm going to discuss my experience with JS-only sites. I've written four relevant sites: two JS-heavy (Slide and SpeedDate) and two JS-only (Yazooli and GameCrush). Keep in mind that I'm a JS-only-site bigot, so you're basically reading John Hinkley on the subject of Jody Foster.

1. The idea really works. It produces gracefully, responsive sites at very low operational costs. My estimate is that the cost for bandwidth, CPU, and such goes to 10% of the cost of running a similar page-based site.
2. You need fewer but better (or at least, better-trained) programmers. JavaScript is an powerful and elegant language, but it has huge problems that a more rigid and unimaginative language like Java doesn't have. If you have a whole bunch of basically mediocre guys working for you, consider JSP or Ruby instead of JS-only. If you are required to use PHP, just shoot yourself.
3. You have to keep basic session state in the anchor tag. Users simply expect that the URL represents the state of the site: reload, bookmark, back, forward. jQuery's Address plug-in will do a lot of the work for you.
4. If SEO is an issue for you, investigate Google Ajax Crawling. Basically, you make a very simple parallel site, just for search engines.

When would I not use JS-only? If I were producing a site that was almost entirely content, where the user did nothing but navigate from one place to another, never interacting with the site in a complicated manner. So, Wikipedia and ... well, that's about it. A big reference site, with a lot of data for the user to read.