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

71–80 of 95 posts

Re: Broken Links

#71

Post by wmf »

zemaj wrote: post #49

Despite all the FUD around hashbangs, the genuine problem I see with them is that they optimise for internal page loads, not the entry into a website. For example with hashbangs, requests to twitter when logged in go like; 1) HTTP GET http://twitter.com/some_account [~500ms for me] 2) 302 redirect -> HTTP GET http://twitter.com/ [~600ms for me] 3) HTML tells browser to download some JS -> HTTP GET bundle.js [~500ms f…

Basically, NewTwitter isn't a Web site, it's an app and you have to "launch" it before you can do anything.

Re: Broken Links

#72

Post by rahoulb »

_delirium wrote: post #62
othermaciej wrote: post #26

Earlier quoted context omitted.

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,…

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

Re: Broken Links

#73

Post by dtby »

Hi, HTML/HTTP are the second worse application delivery platform available. Try not to be shocked.

Sorry, your other choice was #1.

Re: Broken Links

#74

Post by mustpax »

wmf wrote: post #71
zemaj wrote: post #49

Despite all the FUD around hashbangs, the genuine problem I see with them is that they optimise for internal page loads, not the entry into a website. For example with hashbangs, requests to twitter when logged in go like; 1) HTTP GET http://twitter.com/some_account [~500ms for me] 2) 302 redirect -> HTTP GET http://twitter.com/ [~600ms for me] 3) HTML tells browser to download some JS -> HTTP GET bundle.js [~500ms f…

Basically, NewTwitter isn't a Web site, it's an app and you have to "launch" it before you can do anything.

But once you do launch it, everything is faster than it would have been if you were performing full page loads at each step. For sites you "live" in, the application route makes a lot of sense. This is the way GMail works and people seem to like it a lot.

Unfortunately, web applications and web pages are growing increasingly divergent. It is simply not feasible to take the performance of web apps to the next level without doing away with full page loads. This is why Facebeook, Twitter et al are going the #! route. That's the cold hard truth.

Re: Broken Links

#75

Post by simonw »

wmf wrote: post #71
zemaj wrote: post #49

Despite all the FUD around hashbangs, the genuine problem I see with them is that they optimise for internal page loads, not the entry into a website. For example with hashbangs, requests to twitter when logged in go like; 1) HTTP GET http://twitter.com/some_account [~500ms for me] 2) 302 redirect -> HTTP GET http://twitter.com/ [~600ms for me] 3) HTML tells browser to download some JS -> HTTP GET bundle.js [~500ms f…

Basically, NewTwitter isn't a Web site, it's an app and you have to "launch" it before you can do anything.

Which sucks, because I frequently end up "launching" it by clicking a link to a Twitter profile or tweet on another site, so every few minutes I have to wait for the entire thing to load - and I often end up with a dozen tabs containing the Twitter app when all I really wanted was a few hundred bytes of HTML containing a single tweet!

Re: Broken Links

#76

Post by roc »

mustpax wrote: post #74
wmf wrote: post #71

Earlier quoted context omitted.

Basically, NewTwitter isn't a Web site, it's an app and you have to "launch" it before you can do anything.

But once you do launch it, everything is faster than it would have been if you were performing full page loads at each step. For sites you "live" in, the application route makes a lot of sense. This is the way GMail works and people seem to like it a lot. Unfortunately, web applications and web pages are growing increasingly divergent. It is simply not feasible to take the performance of web apps to the next level wi…

Wouldn't js click handlers work just as well?

You follow a canonical link to the resource, get a real page back, with real links, but js click handlers to enable AJAX-goosed speed for those with javascript enabled? And given that they imply a fallback for those times when javascript fails, aren't they actually better?

And GMail is a bit different than Twitter. It handles inward-facing data; content that no-one particularly wants crawled and wouldn't benefit much from caching.

Re: Broken Links

#77

Post by stanleydrew »

simonw wrote: post #75
wmf wrote: post #71

Earlier quoted context omitted.

Basically, NewTwitter isn't a Web site, it's an app and you have to "launch" it before you can do anything.

Which sucks, because I frequently end up "launching" it by clicking a link to a Twitter profile or tweet on another site, so every few minutes I have to wait for the entire thing to load - and I often end up with a dozen tabs containing the Twitter app when all I really wanted was a few hundred bytes of HTML containing a single tweet!

Presumably your browser caches the app so that you don't have to re-download it on subsequent visits.

Re: Broken Links

#78

Post by wahnfrieden »

Isofarro wrote: post #68
wahnfrieden wrote: post #59

Earlier quoted context omitted.

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.

They aren't? You're only supposed to use them if you follow Google's convention, in which case they should be reliably replaced with a normal URL sans the hash. Of courses your scraper must be aware of this, but it should be a somewhat reliable pseudo-standard (and it is just a stopgap after all).

Re: Broken Links

#79

Post by [deleted] »

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…

[deleted]

Re: Broken Links

#80

Post by aamar »

Isofarro wrote: post #68
wahnfrieden wrote: post #59

Earlier quoted context omitted.

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.

I'm sorry if I implied that curl/wget handle this already. However, they could handle this with a very small wrapper script, maybe 3 lines of code, or a very short patch if the convention becomes a standard. That's not nothing, but it's maybe 7 orders of magnitude lighter than a full JS engine, and it's small anyway compared to the number of cases that a reasonable crawler needs to handle.

Also, with that wrapper or patch, curl & wget will still not be remotely HTML5 ready, which I hope demonstrates that HTML5 is not a requirement in any way. A single HTML5-non-ready browser that can't handle this doesn't mean therefore that HTML5 is a requirement.

Post reply on HN