I'm a bit leery of this, as I'd prefer separate accessible URLs for these things. (Though to some extent one could stick things on hashes.... eh.)

Some 'quick' items loading inline might be nice, though. We can reconsider some options later once we've moved on more of the basic things and have beefed up the infrastructure more.

(Reopening from RESOLVED LATER.)

There is now a way to do this with accessible URLs: the HTML5 History API, supported in all major browsers (other than IE < 10) [http://caniuse.com/#feat=history]. In old IEs, we could resort to using hashes (as Brion suggested) or just not enable this feature.

However, to implement this, we would need a way to apply things like sortable tables or collapsible navboxes after the page load. Bug 30713 tracks this.

The history API would allow this feature to be more transparent, but doesn't help in the implementation of it.

This bug is way too generic and not solvable in and of itself, unless it is repurposed for something like "Implement client-side html template mash-ups and convert all special pages and actions to expose their data through the API to make everything AJAX".

A "just" make tabs AJAX is not useful, nor very desirable as stuff would break all over since extensions can manipulate the page in many ways (not just the main content area, things like tabs, toolboxes, user portlet, redlink status, set cookies etc.) all kinds of things have state in the interface. For example extensions can set session, and cookies. Those can't be converted to be loaded through the API without being completely refactored or rewritten (it may be done in an automated way, but such implementation would not be acceptable or scalable by our standards).

For example, VisualEditor has an "Edit" tab that generates the surface dynamically (no reload), however this is a specific implementation for one feature in one extension.

Marking this as INVALID because it is not an implementable or thought through development issue.