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

81–90 of 95 posts

Re: Broken Links

#81

Post by prodigal_erik »

bruceboughton wrote: post #48

Isn't the underlying problem that web applications are often displaying combinations of content that doesn't have a natural URL? Take New Twitter, for example. If I click on a tweet in my stream, it shows related tweets. If a drill down a few of those, at some point it becomes impossible to represent the address of the current state in a sane manner. I think URLs are particular to the web (desktop apps don't have the…

In that case "web application" is a misnomer. If the current state has no natural URL, it's not a legitimate part of the World-Wide Web. Instead the authors are tunneling a proprietary protocol over AJAX to carry opaque content to a single-purpose GUI app, just like all the terrible client/server apps from the 90s only slower.

Re: Broken Links

#82

Post by andolanra »

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.

We're talking about different internets, though. You're talking about the hypothetical patched internet that uses Google's #! remapping, whereas I'm talking about the internet as it exists right now. If I go to Gawker with lynx right now, it will not work, period. The fact that there exists the details of implementation somewhere—and the fact that the implementation is trivial—doesn't mean that it should become standard across the board.

I hate to invoke a slippery slope, but it seems a frightening proposition that $entity can start putting out arbitrary standards and suddenly the entire Internet infrastructure has to follow suit in order to be compatible. It's happened before, e.g. favicon.ico. All of them are noble ideas (personalize bookmarks and site feel, allow Ajax content to be accessible) with troublesome implementation (force thousands of redundant GET /favicon.ico requests instead of using something like , force existing infrastructure to make changes if they want to continue operations as usual.)

All of this is moot, of course, if you just write your pages to fall back sensibly instead of doing what Gawker did and allowing no backwards-compatible text-only fallback. Have JS rewrite your links from "foo/bar" to "#!foo/bar" and then non-compliant user agents and compliant browsers are happy.

Re: Broken Links

#83

Post by vanessafox »

I posted more as a comment on the original story, but I have covered this issue in depth (from when Google initially proposed it, to when it was launched) here:

http://searchengineland.com/google-proposes-to-make-ajax-cra...

http://searchengineland.com/googles-proposal-for-crawling-aj...

http://searchengineland.com/its-official-googles-proposal-fo...

Of course, a better solution is some type of progressive enhancement that ensures both that search engines can crawl the URLs and anyone using device without JavaScript support can view all of the content and navigate the site.

Re: Broken Links

#84

Post by jbri »

roc wrote: post #76
mustpax wrote: post #74

Earlier quoted context omitted.

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

Unless you want your URLs to look like twitter.com/someone#!someone_else, you're going to have to take the multi-step page load at some point when you transition from the HTML version to the AJAXy one.

Re: Broken Links

#85

Post by aamar »

andolanra wrote: post #82
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.

We're talking about different internets, though. You're talking about the hypothetical patched internet that uses Google's #! remapping, whereas I'm talking about the internet as it exists right now. If I go to Gawker with lynx right now , it will not work, period. The fact that there exists the details of implementation somewhere—and the fact that the implementation is trivial—doesn't mean that it should become stan…

> If I go to Gawker with lynx right now, it will not work, period.

As a specific issue, that seems like a minus, but an exceedingly minor one, as lynx is probably a negligible proportion of Gawker's audience. In principle, backwards-compatibility is a great thing, until it impedes some kind of desirable change, such as doing something new or doing it more economically.

> it seems a frightening proposition that $entity can start putting out arbitrary standards

I generally do want someone putting out new standards, and sometimes it's worth breaking backwards-compatibility to an extent. So it really depends on $entity: if it's WHATWG, great. If it's Google, then more caution is warranted. But there's been plenty of cases of innovations (e.g. canvas) starting with a specific player and going mainstream from there. I do agree that Google's approach feels like an ugly hack in a way that is reminiscent of favicon.ico.

> All of this is moot, of course...

This is good general advice, but it's not always true. At least one webapp I've worked on has many important ajax-loads triggered by non-anchor elements; it's about as useful in lynx as Google maps would be. The devs could go through and convert as much as possible to gracefully-degrading anchors, that would at least partly help with noscript, but it seems like a really bad use of resources, given the goals of that app.

Re: Broken Links

#86

Post by mbreese »

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…

But Gmail is a webapp, not a website. You don't get a link to an email stored in Gmail. You can only access things once you're already inside.

Twitter is very different. If you're signing in yourself to update your own feed, that's one thing. But when you are trying to view the feed of someone else, that's a horse of a different color.

The question really is: should Twitter be an "app" or a "site"? If you allow links in from the rest of the web, it should be a "site".

Re: Broken Links

#87

Post by Qz »

mbreese wrote: post #86
mustpax wrote: post #74

Earlier quoted context omitted.

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…

But Gmail is a webapp, not a website. You don't get a link to an email stored in Gmail. You can only access things once you're already inside. Twitter is very different. If you're signing in yourself to update your own feed, that's one thing. But when you are trying to view the feed of someone else, that's a horse of a different color. The question really is: should Twitter be an "app" or a "site"? If you allow links…

Regardless of your question, the answer is that it's an appsite.

Re: Broken Links

#88

Post by witten »

jbri wrote: post #84
roc wrote: post #76

Earlier quoted context omitted.

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

Unless you want your URLs to look like twitter.com/someone#!someone_else, you're going to have to take the multi-step page load at some point when you transition from the HTML version to the AJAXy one.

Not if you use the HTML history API: http://html5demos.com/history

Admittedly, you need a modern browser for that. But you can always present full-page-load HTML to users with older browsers and then provide AJAXy history-ified goodness to everyone else.

Re: Broken Links

#89

Post by simonw »

stanleydrew wrote: post #77
simonw wrote: post #75

Earlier quoted context omitted.

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.

Even with the assets cached, there's still an 8-10 second loading time (I just timed it). Compare that to a static HTML page showing the same content which would probably load and render in under a second.

Re: Broken Links

#90

Post by romaniv »

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…

Hashbangs are a workaround. A good _solution_ would be something that doesn't require running JavaScript and doesn't mess with URL/document models most of the Web is based on.

For example, browsers could implement partial caching. Here is how it could work. The first time the browser requests a page, it gets all the content in the response. However, some fragments of the content are identified as cacheable and marked with unique ids. When a browser requests a page for the second time, it sends a list of identifiers for the cached fragments to the server. The server then doesn't render those fragments, but places small placeholders/identifiers where they should be substituted into page content.

---

First Request

GET index.html

---

First Response

[cacheable id="abc"] [h1]This is twitter[/h1] bla bla bla, header content [/cacheable] ... Page content ... [cacheable id="xyz"] footer content [/cacheable]

---

Second Request

GET index.html Cached: abc, xyz

---

Second Response

[fragment id="abc" /] ... Page content ... [fragment id="xyz" /]

Post reply on HN