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)

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.

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.

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.

modularization. multiple files allows you to mre cleanly break out different workflow paths and process parts. chances are your Business Rules are something that do not usually directly impact your layout rules and multiple files would better help in editing on what needs to be edited without the risk of breaking something unrelated.

I actually just developed my first application using only one page.

..it got messy

My idea was to create an application that mimicked the desktop environment as much as possible. In particular I wanted a detailed view of some app data to be in a popup window that would maintain it s state regardless of the section of the application they were in.

Thus my frankenstein was born.

What ended up happening due to budget/time constraints was the code got out of hand. The various sections of my JavaScript source got muddled together. Maintaining the proper state of various views I had proved to be... difficult.

With proper planning and technique I think the one-page approach is a very easy way to open up some very interesting possibilities (ex: widgets that maintain state across application sections). But it also opens up many... many potential problem areas. including...

• Flooding the global namespace (if you don t already have your own... make one)
• Code organization can easily get... out of hand
• Context - It s very easy to

I m sure there are more...

In short, I would urge you to stay away from relying on JavaScript dependency for the compatibility issue s alone. What I ve come to realize is there is simply no need rely on JavaScript to everything.

I m actually in the process of removing JavaScript dependencies in loo of Progressive Enhancement. It just makes more sense. You can achieve the same or similar effects with properly coded JavaScript.

The idea is too...

1. Develop out well-formatted, fully functional application w/o any JavaScript
2. Style it
3. Wrap the whole thing with JavaScript

Using Progressive Enhancement one can develop an application that delivers the best possible experience for the user that is possible.

For some additional arguments, check out The Single Page Interface Manifesto and some (mostly) negative reaction to it on Hacker News (link at the bottom of the SPI page):

The Single Page Interface Manifesto: http://itsnat.sourceforge.net/php/spim/spi_manifesto_en.php

stofac, first of all, thanks for the link to the Single Page Interface (SPI) Manifesto (I m the author of this boring text)

Said this, SPI != doing everything through Javascript

Take a look to this example (server-centric): http://www.innowhere.com/insites/

The same in GAE: http://itsnatsites.appspot.com/

More info about the GAE approach: http://www.theserverside.com/news/thread.tss?thread_id=60270

In my opinion coding a complex SPI application/web site fully on JavaScript is very very complex and problematic, the best approach in my opinion is "hybrid programming" for SPI, a mix of server-centric for big state management and client-centric (a.k.a JavaScript by hand) for special effects.

Doing everything on a single page using ajax everywhere would break the browser s history/back button functionality and be annoying to the user.

I utterly despise JS-only sites where it is not needed. That extra condition makes all the difference. By way of example consider the oft quoted Google Docs, in this case it not only helps improve experiences it is essential. But some parts of Google Help have been JS-only and yet it adds nothing to the experience, it is only showing static content.

Here are reasons for my upset:

• Like many, I am a user of NoScript and love it. Pages load faster, I feel safer and the more distracting adverts are avoided. The last point may seem like a bad thing for webmasters but I don t want anyone to get rewarded for pushing annoying flashy things in my face, if tactless advertisers go out of business I consider it natural selection.
  Obviously this means some visitors to your site are either going to be turned away or feel hassled by the need to provide a temporary exclusion. This reduces your audience.
• You are duplicating effort. The browser already has a perfectly good history function and you shouldn t need to reinvent the wheel by redrawing the previous page when a back button is clicked. To make matters worse going back a page shouldn t require re-rendering. I guess I am a student of If-it-ain t-broke-don t-fix-it School (from Don t-Repeat-Yourself U.).
• There are no HTTP headers when traversing "pages" in JS. This means no cache controls, no expiries, content cannot be adjusted for requested language nor location, no meaningful "page not found" nor "unavailable" responses. You could write error handling routines within your uber-page that respond to failed AJAX fetches but that is more complexity and reinvention, it is redundant.
• No caching is a big deal for me, without it proxies cannot work efficiently and caching has the greatest of all load reducing effects. Again, you could mimic some caching in your JS app but that is yet more complexity and redundancy, higher memory usage and poorer user experience overall.
• Initial load times are greater. By loading so much Javascript on the first visit you are causing a longer delay.
• More JavaScript complexity means more debugging in various browsers. Server-side processing means debugging only once.
• Unfuddle (a bug-tracker) left a bad taste. One of my most unpleasant web experiences was being forced to use this service by an employer. On the surface it seems well suited; the JS-heavy section is private so doesn t need to worry about search engines, only repeat visitors will be using it so have time to turn off protections and shouldn t mind the initial JS library load.
  But it s use of JS is pointless, most content is static. "Pages" were still being fetched (via AJAX) so the delay is the same. With the benefit of AJAX it should be polling in the background to check for changes but I wouldn t get notified when the visible page had been modified. Sections had different styles so there was an awkward re-rendering when traversing those, loading external stylesheets by Javascript is Bad Practice™. Ease of use was sacrificed for whizz-bang "look at our Web 2.0" features. Such a business-orientated application should concentrate on speed of retrieval, but it ended up slower.
  Eventually I had to refuse to use it as it was disrupting the team s work flow. This is not good for client-vendor relationships.
• Dynamic pages are harder to save for offline use. Some mobile users like to download in advance and turn off their connection to save power and data usage.
• Dynamic pages are harder for screen readers to parse. While the number of blind users are probably less than those with NoScript or a mobile connection it is inexcusable to ignore accessibility - and in some countries even illegal, see the "Disability Discrimination Act" (1999) and "Equality Act" (2010).

As mentioned in other answers the "Progressive Enhancement", née "Unobtrusive Javascript", is the better approach. When I am required to make a JS-only site (remember, I don t object to it on principle and there are times when it is valid) I look forward to implementing the aforementioned AJAX crawling and hope it becomes more standardised in future.