Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Broken Links

tbray.org

Post reply on HN
Print view View original

61–70 of 95 posts

Re: Broken Links

#61

Post by jules »

drdaeman wrote: post #43
pilif wrote: post #24

With pushState not widely implemented, you have three choices: 1) don't use AJAX in response to actions that alter the page content in a significant way. This of course forces page reloads and prevents the cool emerging pattern that is to not serve dynamic HTML but just have a REST API and do the rendering client side. 2) you do the ajaxy stuff but you don't touch the URL. This leads to a nonworking back button and p…

I've proposed sort of possible solution here, in a related discussion: http://news.ycombinator.com/item?id=2197064

Might this confuse search engines? For example bing seems to use click data from IE users clicking links in their ranking, so perhaps the whole site being one URL would confuse it. More alarmingly, when people link to your site they will link to site.com/#xyz by copying from the address bar. So search engines will think all links to your site are to the homepage.

Re: Broken Links

#62

Post by _delirium »

othermaciej wrote: post #26
thomas11 wrote: post #21

Earlier quoted context omitted.

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…

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.

Re: Broken Links

#63

Post by joelanman »

Isofarro wrote: post #56
joelanman wrote: post #53

Earlier quoted context omitted.

two problems 1) The link is weird and confusing in the first place, /shop/shoes#!shop/socks refers to two different resources 2) The server will already have done work to find the shoes, when the javascript redirects to the socks page.

1.) Is a limitation of Google's crawlable Ajax proposal. That would probably not have occurred with a proper standards body. What sequence of events would have to happen to have that as an inbound URL? I sense some previous JavaScript would have to have failed to allow that scenario. 2.) The site is already paying this price by redirecting _escaped_fragment_ URLs, and the old clean style urls. All inbound links will…

no, with google's proposal, the #! links are all from the site root, see Lifehacker and Twitter's implementation. So these ugly half and half URLs never exist, and you're not paying a double request price

Re: Broken Links

#64

Post by jvdongen »

[EDIT: never mind, missed this response, similar in style but 2h earlier ... http://news.ycombinator.com/item?id=2197064]

May be I'm missing something, but it seems to me that there is a way to have your cake and eat it too in this case.

Say we have a site with a page /contacts/ which lists various contacts.

On this page there are completely normal links like '/contacts/john/', each link preceded by/wrapped by an anchor tag - in this case.

If you visit this site without javascript enabled (e.g. you happen to be a web crawler), you just follow the links and you get just regular pages as always.

If however you've javascript enabled, onclick events on each url intercept a click on a link and fetch just the information about the contact you clicked on (using an alternate url, for example /contacts/john.json), cancels the default action and (re)renders the page.

Then it does one of two things: - if pushState is supported it just updates the url - if pushState is not supported it adds '#john' to the url

If someone visits '/contacts/#john' with javascript enabled, /contacts/ is retrieved and then john's data is loaded and displayed.

If someone visits '/contacts/#john' without javascript enabled, he gets the full contact list, with the focus on the link to john's page, which he can then click.

By using this scheme: - search engine and other non-javascript users can fully use the site and see completely normal urls - XHR page loads are supported - XHR loaded pages don't break the backbutton - XHR loaded pages are bookmarkable - Bookmarks to XHR loaded pages are fully shareable if the recipient has javascript enabled or pushState is supported, and at least not totally broken if not.

The only drawback I can see is the 'sharing bookmarks with someone who has no javascript support' issue - is that a real biggie? In addition of course to the 'made error in javascript, now all stops working' issue - but that is something that has not so much do with the #! debate as well as with the 'is loading primary content via XHR a good idea' debate.

To me it seems that current users of the #! technique have just gone overboard a bit by relying only on the #! technique instead of combining it in a progressively enhancing way with regular HTTP requests.

Re: Broken Links

#65

Post by jarek »

ladon86 wrote: post #57
andolanra wrote: post #37

Earlier quoted context omitted.

A while back, there was this pie-in-the-sky idea which was really interesting but not too practical, called Semantic Web. It didn't really pan out because it turns out that annotating your sites with metadata is boring and tedious and nobody really liked to do it, and anyway, search and Bayesian statistics simulated the big ideas of Semantic Web well enough for most people. The ideas behind it still stand, though, in…

Ah, but the #! is probably just using JS to access a well-defined API - the same API which anyone else can access in completely uncluttered, machine-readable form. So perhaps the solution is for every #! page to have a meta tag pointing to the canonical API resource which it is drawing data from. Bingo, semantic web!

You also have to ensure every relevant site (in this example, every site that would have used hRecipe) uses the same API scheme.

Re: Broken Links

#67

Post by zachbeane »

This rant would be more effective and persuasive if also directed at the Google engineers who made this hashbang style pervasive in Google Groups. I didn't think it would be possible to get deep links to old articles even worse than before, but they managed it.

Re: Broken Links

#68

Post by Isofarro »

wahnfrieden wrote: post #59
Isofarro wrote: post #51

Earlier quoted context omitted.

I tried both curl and wget last night (neither of these are HTML5-ready browsers), and neither of them could get content using the hash-bang URL. They both came back with an empty page skeleton. Also, how do you reassemble the hash-bang URL from HTTP Referrer header?

Neither curl nor wget follow the Google convention for handling hashbangs as suggested by the parent, so I'm not sure what you're getting at with this reply.

Hash-bang URLs are not reliable references to content - that's what I am getting at. Curl and WGet are perhaps the most used non-browser user-agents on the web. And both of them are unable to retrieve content at a URL specified by a hash-bang URL.

In this context hash-bang urls are broken.

Re: Broken Links

#69

Post by Isofarro »

joelanman wrote: post #63
Isofarro wrote: post #56

Earlier quoted context omitted.

1.) Is a limitation of Google's crawlable Ajax proposal. That would probably not have occurred with a proper standards body. What sequence of events would have to happen to have that as an inbound URL? I sense some previous JavaScript would have to have failed to allow that scenario. 2.) The site is already paying this price by redirecting _escaped_fragment_ URLs, and the old clean style urls. All inbound links will…

no, with google's proposal, the #! links are all from the site root, see Lifehacker and Twitter's implementation. So these ugly half and half URLs never exist, and you're not paying a double request price

Google's proposed kludge doesn't limit URLs to the site root - a path segment is documented. Have a read of it: http://code.google.com/web/ajaxcrawling/docs/specification.h...

Re: Broken Links

#70

Post by joelanman »

Isofarro wrote: post #69
joelanman wrote: post #63

Earlier quoted context omitted.

no, with google's proposal, the #! links are all from the site root, see Lifehacker and Twitter's implementation. So these ugly half and half URLs never exist, and you're not paying a double request price

Google's proposed kludge doesn't limit URLs to the site root - a path segment is documented. Have a read of it: http://code.google.com/web/ajaxcrawling/docs/specification.h...

ah you're right, and yes that could possibly introduce the issue of redundant work done on the server depending on the implementation. However the two major implementations I've seen (Twitter and Lifehacker) use it from the root and so dont have that problem.
Post reply on HN