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

51–60 of 95 posts

Re: Broken Links

#51

Post by Isofarro »

aamar wrote: post #40
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…

Very interesting points, but there are couple of errors which undermine part of your point: 1. If the application follows the Google proposed-convention or similar, the crawler doesn't need a full-stack JS implementation; it just needs to do the (trivial) URL remapping. 2. Nothing in this hash-bang approach requires a HTML5-ready browser.

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?

Re: Broken Links

#52

Post by Isofarro »

joelanman wrote: post #25
tlack wrote: post #16

Earlier quoted context omitted.

You can still avoid loading whole new pages. You simply attach Javascript events to your anchor tags and do whatever Ajax content trickery you want that way. The page content itself is maximally flexible and useful to all agents if the URLs inside of it are actual URLs.

The only problem with that is you end up with a mix of both. If a spider collects all the non-ajax links, and shows that to a javascript-enabled browser, the user will end up on eg. /shop/shoes. If the site is ajax enabled for a slicker experience, then as the user browses from here they might get something like this in their address bar: /shop/shoes#!shop/socks or even /shop/shoes#!help/technical which starts to loo…

Can you not use JavaScript to figure out your URL is a mess and redirect accordingly? JavaScript for redirecting people to the homepage of websites have been available on dynamicdrive.com for at least a decade now.

That's one redirect to the homepage (which you're already doing by 301-redirecting the JavaScript-free URLs anyway), so it's hardly going to be difficult.

I'm puzzled, considering the haphazard redirects already going on for incoming links to hash-banged sites, why this isn't a trivial problem.

Incoming link is to /shop/shoes#!shop/socks JavaScript right at the top of /shop/shoes that window.location to /#!shop/shoes

Re: Broken Links

#53

Post by joelanman »

Isofarro wrote: post #52
joelanman wrote: post #25

Earlier quoted context omitted.

The only problem with that is you end up with a mix of both. If a spider collects all the non-ajax links, and shows that to a javascript-enabled browser, the user will end up on eg. /shop/shoes. If the site is ajax enabled for a slicker experience, then as the user browses from here they might get something like this in their address bar: /shop/shoes#!shop/socks or even /shop/shoes#!help/technical which starts to loo…

Can you not use JavaScript to figure out your URL is a mess and redirect accordingly? JavaScript for redirecting people to the homepage of websites have been available on dynamicdrive.com for at least a decade now. That's one redirect to the homepage (which you're already doing by 301-redirecting the JavaScript-free URLs anyway), so it's hardly going to be difficult. I'm puzzled, considering the haphazard redirects a…

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.

Re: Broken Links

#54

Post by joelanman »

robryan wrote: post #46
thomas11 wrote: post #42

Earlier quoted context omitted.

"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.

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.

Re: Broken Links

#55

Post by guelo »

il wrote: post #2

It's interesting how many upvotes this is getting in a very short time. However, I don't think the average Twitter user cares about performance and URL elegance, so I doubt Twitter will change anything.

Considering that twitter is the main reason for the spread of the abomination that is URL shorteners you're probably right. They don't seem to care about the health of the web.

Re: Broken Links

#56

Post by Isofarro »

joelanman wrote: post #53
Isofarro wrote: post #52

Earlier quoted context omitted.

Can you not use JavaScript to figure out your URL is a mess and redirect accordingly? JavaScript for redirecting people to the homepage of websites have been available on dynamicdrive.com for at least a decade now. That's one redirect to the homepage (which you're already doing by 301-redirecting the JavaScript-free URLs anyway), so it's hardly going to be difficult. I'm puzzled, considering the haphazard redirects a…

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 have this problem, so you're only shifting some of the burden through this door instead of the others.

Re: Broken Links

#57

Post by ladon86 »

andolanra wrote: post #37
alexkearns wrote: post #14

Yet another annoying pontificating article about hashbangs. Why can't people accept that there are more than one way of doing things on the web. Just because you don't like using hashbangs does not mean no-one else can. Sure, use of hashbangs might make seo of your site harder. Yes, it might make it harder for hackers who want to do curls of your site's pages. But maybe this is not your aim with your site. Maybe you…

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!

Re: Broken Links

#58

Post by wahnfrieden »

JoachimSchipper wrote: post #19
othermaciej wrote: post #10

HTML5 "AJAX History", also known as History.pushState, can solve this problem. It allows a website to update its contents with AJAX, but change the URL to a real URL that will actually retrieve the proper resource direct from the server, while maintaining proper back-forward navigation. See http://dev.w3.org/html5/spec/Overview.html#dom-history-pushs... ; for spec details. It's in Safari, Chrome and Firefox. While Op…

Well, it "solves" it - you still have to download and parse a ton of Javascript before you even begin downloading the data...

CDNs make the download part much less of a problem.

And your server could easily send a fully rendered page on the first page load when it receives a full URL (one which was made by pushState and linked elsewhere) and still subsequently load pages via XHR. So it wouldn't have to parse any JS on first load -- subsequent loads would, but they'd be saving time from not downloading as much and not refreshing the entire page.

Re: Broken Links

#59

Post by wahnfrieden »

Isofarro wrote: post #51
aamar wrote: post #40

Earlier quoted context omitted.

Very interesting points, but there are couple of errors which undermine part of your point: 1. If the application follows the Google proposed-convention or similar, the crawler doesn't need a full-stack JS implementation; it just needs to do the (trivial) URL remapping. 2. Nothing in this hash-bang approach requires a HTML5-ready browser.

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.

Re: Broken Links

#60

Post by brown9-2 »

nostrademons wrote: post #35

It's not really that bad. The people using hash-bangs are following a spec proposed by Google to make AJAX webpages crawlable: http://code.google.com/web/ajaxcrawling/docs/specification.h... So when you see the lifehacker URL in the article, you know that there's an equivalent non-AJAX URL available with the same content at: http://lifehacker.com/?_escaped_fragment_=5753509/hello-worl... There's no need to execute al…

But as Tim says, the spec proposed by Google is only meant to fix some problems (can't be searched by search engines) caused by using this URL scheme. It isn't meant to be a one-guide-fits-all approach making AJAX content addressable.

In other words the spec treats one of the symptoms, not the original problem.

Post reply on HN