Hacker News new | past | comments | ask | show | jobs | submit login

It's really great that in a few years, browsers will support a new AJAX technology that solves this problem that we wouldn't even have with sane, traditional URL schemes.



Maybe you're trying to be snarky, but I'll choose to take your comment seriously.

The AJAX approach to Web apps does provide a genuine user interface benefit. A full page load is very disruptive to application flow, and being able to have new data appear without incurring that penalty is great. Most of the time you only need to load a little bit of data anyway, and it's wasteful to reload all the markup that wraps it.

AJAX solves that problem, but it creates the new problem that your address field no longer properly reflects the navigation you do inside a web app. #! URLs are one approach to fixing it, and pushState will do even better. At that point, the user won't even have to notice that the Web app they use is built in an AJAXy style, other than the navigation being smoother and faster.


A full page load is very disruptive to application flow, and being able to have new data appear without incurring that penalty is great

On many examples I don't see any real disruption to application flow with just using normal links, though there are more full-fledged webapps (like gmail) where I would agree. Playing around with old v. new Twitter, the old one actually has considerably faster navigation performance, at least on my setup (and I'm using a recent Chrome on a recent Macbook Pro). Sure, some HTML header/footer stuff is being retransmitted, but it's not very big.


I would put it down to there finally being a distinction between web-sites and web-apps.

Within an app, my current context (which control has the focus etc) is important and a full page reload loses all of that.

Within a web site, as it is less interactive, this stuff doesn't matter so much.

As to whether New Twitter is a site or an app is debatable (I say site and therefore shouldn't be using #!). And as for Gawker...


"Most of the time you only need to load a little bit of data anyway" - that's highly questionable as a general statement. In a rich UI like GMail, yes. But in examples like the new Lifehacker, you load a whole story, yet its locator is behind the hashbang.

Not every website is a web app. Just show one article or item or whatever the site is about under one URI.


That might be the case for LifeHacker (don't know; don't use it). But the example in Tim Bray's post is Twitter, which definitely needs to load a lot less data than it's full interface markup on most navigations.


Lifehacker kind of looks nicer only loading reloading the story and not the whole page. I gives things an application feel rather than a collection of pages and saves a heap of extra processing, why run the code again to generate a header and footer and side bars constantly when the version the user is seeing is perfectly up to date.


The experience is slicker - if you run a search on lifeHacker, you can click through and browse the results without affecting the rest of the page (including the list of results). With traditional page refreshes this would not be possible.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: