Live data from Hacker News

Broken Links

tbray.org

31–40 of 95 posts

Re: Broken Links

#31
post #17

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…

True, but the same non-reload could be accomplished with: And wouldn't break spiders.

It also wouldn't change the page URL, making the result of that click non bookmark able or it would mess with the fragment again, sooner or later creating URLs that look like

/help/thing#!/something/otherthing

Which is equally confusing and more error prone for the developers as /help/thing loads code specific to that view and then the /something/otherthing stuff is loaded too. Not insolvable and preventable by proper encapsulation, but stuff leaks, so mistakes will happen.

Re: Broken Links

#32
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…

[deleted]

Re: Broken Links

#33
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…

The main problem with the fragment change solution is that it _doesn't work without JavaScript_. And we're not talking for the one user browsing the site - any links people post (on forums, mailing lists, etc.) that have fragments in them are simply unusable for people without JavaScript, as the server does not get sent the fragment - the best it can do is send a generic "oh, sorry, no JS" page back.

This would be a problem for search engines as well, if it wasn't for the awful translation Google said they'd do. It's just breaking the meaning of fragment identifiers completely, and that really makes me worried.

Re: Broken Links

#34
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…

pushState with non-hash URLs doesn't require you to do server-side HTML generation. You can just send a stub page which looks at the URL and loads the right data, just as with hash URLs. To deploy it incrementally, you only really need one code path with a slight fork depending on whether the current URL contains a #! and whether the current browser supports pushState.

I know, but browsers without JS need the server side generated content for that URL or the original complaints just arise again (empty page, albeit with a different URL now)

Re: Broken Links

#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 all the JavaScript that comes back from the server - if they're following the spec, all you have to do is escape the fragment and toss it over to a CGI arg.

Another option is progressive enhancement, where you make every link point to a valid page and then add onclick event handlers that override the click event to do whatever JavaScript you want it to. I think this is a far superior option in general, but it has various issues in latency and coding complexity, so a good portion of web developers didn't do it anyway.

Re: Broken Links

#36
post #9

I think people are missing a huge benefit of the hashbang syntax: readable and copy/paste-able URLs. Without them, it's impossible to have an ajax application with a decent URL scheme.

I think the real question here is whether the application should be loading the main content via AJAX in the first place. Tim argues here that it should not, for this use case.

Then that's what the article should say, instead of hating on the hashbang syntax, which is currently the best solution to the problem.

I also don't see why these web pages (specifically twitter) shouldn't be an ajax application - I think loading a page statically, and then the data via ajax is a Good Thing™.

Re: Broken Links

#37

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 the idea of microformats. These are just standardized ways of using existing HTML to structure particular kinds of data, so any program (browser plug-in, web crawler, &c) can scrape through my data and parse it as metadata, more precisely and with greater semantic content than raw text search, but without the tedium that comes with ontologies and RDF.

Now, these ideas are about the structured exchange of information between arbitrary nodes on the internet. If every recipe site used the hRecipe microformat, for example, I could write a recipe search engine which automatically parses the given recipes and supply them in various formats (recipe card, full-page instructions, &c) because I have a recipe schema and arbitrary recipes I've never seen before on sites my crawler just found conform to this. I could write a local client that does the same thing, or a web app which consolidates the recipes from other sites into my own personal recipe book. It turns the internet into much more of a net, and makes pulling together this information in new and interesting ways tenable. In its grandest incarnation, using the whole internet would be like using Wolfram Alpha.

The #! has precisely the opposite effect. If you offer #! urls and nothing else, then you are making your site harder to process except by human beings sitting at full-stack, JS-enabled, HTML5-ready web browsers; you are actively hindering any other kind of data exchange. Using #!-only is a valid choice, I'm not saying it's always the wrong one—web apps definitely benefit from #! much more than they do from awkward backwards compatibility. But using #! without graceful degradation of your pages turns the internet from interconnected-realms-of-information to what amounts to a distribution channel for your webapps. It actively hinders communication between anybody but the server and the client, and closes off lots of ideas about what the internet could be, and those ideas are not just "SEO is harder and people can't use curl anymore."

I don't want to condemn experimentation, either, and I'm as excited as anyone to see what JS can do when it's really unleashed. But framing this debate as an argument between crotchety graybeards and The Daring Future Of The Internet misses a lot of the subtleties involved.

Re: Broken Links

#38

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…

totally agree - if using hashbangs provides the best experience for your context, why not use it?

Re: Broken Links

#40

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…

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.
Post reply on HN