Let's take a look at the alternatives to breaking the back button, then:
- The web application could serve static pages and then update them with AJAX
What if the user clicks back /then/? All the AJAX updates would be lost, and they'd go back to an older version of the page - they'd then see the data on the page "jump" to the updated version.
- The web application could not use AJAX at all, and serve everything as static pages, without automatic updating
Some web-applications can't work like that. Mine has instant messaging, and I want the IM windows to be there when it loads. Besides, most users /like/ AJAX. They're not thinking "oh no, this application ruined the web", they're thinking "nice, the page updated itself".
- The web application could use Flash or some other plugin, instead of the native HTML/Javascript
Which of these are you suggesting developers do instead? Why is the HTML5 history/hashbang URL model not better than all of these?
"Some web-applications can't work like that. Mine has instant messaging, and I want the IM windows to be there when it loads."
There are already internet protocols for real-time notifications, like XMPP and a whole host of non-open protocols. Re-implementing messaging on a platform that isn't by it's nature a push platform will always be inferior to the real thing.
Wouldn't it make more sense to implement a web-like application on-top of a real-time messaging platform instead of the other way around?
(Though, it's not clear what a back button should be doing in an "instant messaging" interface - will it undo the a conversation? Does a user bookmark a message or a conversation so they can edit/refine individual messages later?)
"Which of these are you suggesting developers do instead?"
I'm suggesting developers use the right tools and platforms for the job.
So you're suggesting there shouldn't be any (for example) instant messaging in the web browser, it should be in a separate application.
Well, it's pretty clear what you mean now, and I guess we'll just have to agree to differ. Real-time AJAX applications in the web browser are the future, and I know I'm not the only one who thinks so.
Also, if you think I'm trying to say the back button should do anything to an IM conversation, you're misunderstanding the whole issue.
- The web application could serve static pages and then update them with AJAX
What if the user clicks back /then/? All the AJAX updates would be lost, and they'd go back to an older version of the page - they'd then see the data on the page "jump" to the updated version.
- The web application could not use AJAX at all, and serve everything as static pages, without automatic updating
Some web-applications can't work like that. Mine has instant messaging, and I want the IM windows to be there when it loads. Besides, most users /like/ AJAX. They're not thinking "oh no, this application ruined the web", they're thinking "nice, the page updated itself".
- The web application could use Flash or some other plugin, instead of the native HTML/Javascript
Which of these are you suggesting developers do instead? Why is the HTML5 history/hashbang URL model not better than all of these?