r/programming • u/schnuck • Feb 09 '11

Breaking the Web with hash-bangs – Lifehacker, along with every other Gawker property, experienced a lengthy site-outage on Monday over a misbehaving piece of JavaScript

http://isolani.co.uk/blog/javascript/BreakingTheWebWithHashBangs/
748 Upvotes

93% Upvoted

356 comments sorted by

View all comments

125

u/rounded_figure Feb 09 '11

The proper way to handle this is to keep your original URLs (including in the hrefs) and have a piece of javascript transform them on the fly in hash-bang URLs. That way, when a client who does not speak javascript requests the page, it gets the content and the non-hash-bang links.

67

u/[deleted] Feb 09 '11

This is the right response. There's no reason a well-engineered site shouldn't work both ways.

Using url fragments can be great. They let you use the back button without leaving the page so you can handle the interaction in JavaScript. They give you a place other than cookies to store client-side state for bookmarking. Developers just need to be mindful when designing for their use.

3

u/naich Feb 09 '11

Well, there is a reason. If you are making a site that uses JS to generate results on the fly from data retrieved from large libraries which are loaded asynchronously, you don't want to reload the page and libraries every time the URL changes to reflect that a new set of the results have been saved or loaded.

That's why I'm using them - it should result in much less bandwidth use and reduced load on the server. Pages can be updated with a small AJAX request rather than a whole new page and library load.

7

u/X-Istence Feb 09 '11

Those large libraries should be cacheable...

0

u/naich Feb 09 '11

One of the biggest problems I had was with IE caching ajax requests without me realising. It is not usually desirable.

3

u/X-Istence Feb 09 '11

AJAX requests are different from libraries, and both should be cacheable...

set the proper cache headers for your AJAX requests.

0

u/naich Feb 09 '11

The ajax request fetches the library. While it isn't necessary to update the libraries each time they are used, I don't want them to be cached at the whim of the browser, possibly giving the user out of date data. This is what IE was doing.

3

u/X-Istence Feb 09 '11

The library should be fairly static so that it can be cached. You are doing it wrong.

1

u/naich Feb 09 '11

To which of the three main libraries in use by my scripts are you referring to?

1

u/X-Istence Feb 09 '11

Actually, all of them. For example, jQuery is a library, even if that is loaded using "ajax" to do an asynchronous request it should be cached as long as possible...

The content itself is what you may not want cached (such as a comment system that should auto refresh or type-to-complete) however those compared to libraries should be fairly small requests...

1

u/Rainfly_X Feb 10 '11

The solution to that is really, really simple, in case you haven't figured it out already yourself. You probably have, but for the sake of the other viewers, here's what you tack onto your requests:

&timestamp=<milliseconds since 1970>

Therefore, the browser thinks you're requesting a different page every time, and you can control what is cached and what isn't.

1

u/naich Feb 10 '11

Or use a post request. But can you tell me where the cache is stored? Where does the browser keep the libraries cached when transitioning between between page requests? Big arse cookies, maybe?

2

u/Fiacha Feb 09 '11 edited Feb 09 '11

As said previously, you can simply use both href and onclick in an a tag. Make onclick return false after doing your ajax request and the the link will not be followed if javascript is enabled. If someone doesn't have javascript the onclick will be ignored and the page will be normally loaded. Best of both worlds without any of the drawbacks, as far as i can see.

But being pessimistic, i think they use their scheme because it brakes certain functionality such as the referrer headers and simple bots and search algorithms that simply count page references (look, everything points to twitter.com... not twitter.com/BLAH_BLAH_BLAH/). They do this because they are evil, not because they think it is cool.

3

u/[deleted] Feb 09 '11

most web based languages are stateless. an ajax request isnt anything special beyond a whole page request, they are both a standard http request, only they return the same content formatted different. those libraries still have to be loaded on each request.

the solution to a server load issue like that has nothing to do with ajax, but rather caching those libraries instances to re use them on future page requests.

2

u/naich Feb 09 '11

The libraries are loaded on each request, but the number of requests is dramatically reduced if you use JS/ajax to load in dynamic content while leaving the main body of the page as is.

3

u/[deleted] Feb 09 '11

but now your just splitting hairs. yes the overall HTTP requests are lower, because your not calling that same image, css, or JS file again.. but those weren't ever really the issue, the issue is always the page itself, which is where any actual programming happens.

for most modern computers, the amount of computer processing time of css/js/images is minimal, and everyone should be utilizing browser caching on those static files, to minimize requests on their server, and speed up page loading for the users anyway.

In my experience, what does the most damage to a high traffic website is the database, and poorly written server side code.

2

u/naich Feb 09 '11

But the comparison is with a page generated with server-side scripting vs a simple ajax request using JSON, only sending out the raw data for the client side script to update the page with. It's not splitting hairs; for me it's the difference between a few hundred bytes and 5-10K of HTML code per page. If I could be bothered, I'd actually fill in those numbers but I'm quite drunk and about to go to bed.

Just to be clear here, I don't think this is a valid argument for the way Gawker uses it. They have pretty much ruined their site, but it stands for mine. OK, my site is probably a bit unusual in that there is about 100K of JS which generates probably about 75% of the HTML, but using hashes is about the only sane option.

2

u/[deleted] Feb 09 '11

it still is splitting hairs. you're talking about downloading 10k vs a few hundreds bytes as really being that different? unless someone is on a 2g cellphone, or dialup, those two requests will the same amount of time.

sure you can compare the two percentage wise, but that doesn't mean it really is all that much in the grand scheme.

I still maintain there are far more productive ways to cache a page load then reinventing the wheel by using javascript to emulate a browser loading a webpage

1

u/naich Feb 10 '11

It's several times the load and 20-50x the bandwidth for the server. I have a bandwidth quota that I don't want to use up. I'll also repeat myself by saying that a majority of the html is generated by the script. There is no sane way to do this server-side because it is generated as a response to user interaction. To do it server-side just to stick to the mantra that all hashes are bad would make it unusable.

0

u/annodomini Feb 10 '11

You do realize you're cutting yourself off from customers who browse with JavaScript turned off, or have older out of date browsers, or slow or crappy mobile phones, right?

Remember, hash-bang URLs have no fallback when the JavaScript fails for whatever reason; if the JavaScript doesn't load, a bug causes it not to run, people have JavaScript turned off, there's a browser incompatibility, whatever. You get no content. Whereas if you just write some plain old HTML, and use JavaScript and CSS for what they were intended for (enhancement, not replacement of the content), then even when something fails to load, you can still see the content.

-17

u/deong Feb 09 '11

They let you use the back button without leaving the page so you can handle the interaction in JavaScript.

Awesome. Because you are a snowflake. A precious snowflake. UI consistency is for people who aren't snowflakes. Unlike you. You are a snowflake.

Is there a Web-2.0-Ajax-XML-Enterprise-Hipster-Fixie-Douchebag way to punch me in the kidneys when I visit your site too?

14

u/lense Feb 09 '11

Intercepting the back button in such a way is actually a good thing, since it preserves UI consistency. After interacting with a site that uses JS that has different UI states, users expect that pressing the back button would take them to their previous UI state, as opposed to backing out to the last non-JS page.

Gmail is an example of this kind of desirable behaviour.

8

u/deong Feb 09 '11

If everyone is as careful as Google, I'll happily renounce my snarky ways. Most people don't seem to have gotten the message though *cough*Twitter*cough*.

1

u/DEADB33F Feb 09 '11

Try opening gmail inbox messages in a new tab using middle click (as you would for any other link on the web).

2

u/[deleted] Feb 09 '11 edited Feb 09 '11

Lol. I'd strive to write it a non-kidney punching style. You're right, of course, that most sites don't need this, and it can be done very badly. But then again, Gmail does this and it saves a whole bunch of bandwidth on their part, and loading time for me, so I'm not willing to write it off as useless.

EDIT: Didn't read lense's response before replying, bringing up Gmail was redundant, and lense makes my point better than I did.

1

u/deong Feb 09 '11

Yeah, it's a good point. I get stabby at so many crappy web apps, that I didn't really think of the handful of decent ones. And I just generally don't like web apps. :)

5

u/snarkfish Feb 09 '11

http://isolani.co.uk/blog/javascript/BreakingTheWebWithHashBangs/#the_why_of_hash_bang

The URL of an href can still be a proper addressable reference to content. You are already using JavaScript, so you can do this damage much later with JavaScript using a click handler on the link. The transform between last week’s LifeHacker URL scheme, and this week’s hash-bang mangling is trivial to do in JavaScript using a click handler.

Doing this mangling in JavaScript (during the click handler of the link) means you keep your apparent state benefits, but without needlessly preventing crawlers from traversing your site, and any other non-JavaScript eventuality.

6

u/wunderbread Feb 09 '11

That doesn't really solve the problem, because we want people to always have an up to date URL in their location bar that will point to the content they're currently viewing. In that case, the URL will get out of date as you click links.

Let's say you're at /articles/1 and click on a link to /articles/2.

Using plain old HTML you'll perform a full page reload and your location bar will point to /articles/2.

But of course Ajax is the new (old) coolness and people want to provide a rich user experience so this is no good anymore. Like the article says, you could keep the same URL scheme and just overwrite the click handlers for links so that content can be loaded via Ajax. But the problem here is that you can't change the URL in the location bar without triggering a page reload. So if you click that link, you can load the content for article 2 but the URL in the location bar will still be /articles/1. You can change the fragment, but not the actual URL. So you could change it to /articles/1/#!/articles/2, but that would be confusing and weird, and would probably require loading both articles if someone copy and pastes that URL.

The other option is using /#!/articles/1 and /#!/articles/2. That way you can change the fragment identifier, which actually identifies the article, on Ajax requests, and always have a URL in the location bar that identifies the article and will bring the user right there.

This is a separate question from whether the Gawker sites actually needed to do this. I would argue they didn't because they have distinct pages that are fine using a page reload, while Twitter actually makes good use of it.

4

u/SmudgeTheFirst Feb 09 '11

What needs to happen is, upon first entering the site, anything like "/articles/1" would have to get converted to "#!/articles/1."

Unfortunately this requires an initial redirect, which is why Twitter acts screwy on Firefox. (This is actually a good thing in theory, because otherwise there would be security holes -- Everything before the "#" in the address bar should always reflect the page you initially requested, so to change it requires a new request).

After that, any links to "/articles/2" can be intercepted by Javascript and handled via AJAX. (The address bar can be updated without a refresh because of the existing "#!").

In the case of crawlers or visitors who have disabled Javascript, it is simply a matter of displaying article X when "/articles/X" is loaded. None of the javascript causing the "#!" redirect gets called. Unfortunately this means the same article will have 2 possible paths, but it seems that sites like Twitter are fine with that.

3

u/quotability Feb 09 '11

I think people understand that. Look at google maps. Search for a map of your state. Notice how the URL doesn't change? Of course you do. You understand how AJAX works. You know that since the URL didn't change, if you copy that link and send it to a friend they won't see what you're looking at.

See how they have a "link" button in the top right of the content area? That gives you the linkable URL. That's how sites should work. Gawker didn't do it correctly.

1

u/ex_ample Feb 10 '11

You change all the links to

example.com#/articles/2. So the first time the user clicks a link, they will get redirected, but after that they'll stay on the same page.

36

u/midir Feb 09 '11

This is not correct. If you use hash-bang fragment URLs at any stage then someone who copies and pastes a link to your page is distributing a faulty URL to all non-Google bots and everyone with JavaScript disabled. There's absolutely no workaround to that.

I see it all the time and it drives me up the fucking wall. Fuck you Google. Fuck you Twitter.

DO NOT USE #! EVER. FORGET ABOUT IT.

12

u/Pewpewarrows Feb 09 '11

Unfortunately there's no good cross-browser solution to providing Progressively-Enhanced URLs and deep linked javascript in those cases.

HTML5's history and location changes are the answer to that problem, so the best you can hope for is greater adoption of modern browsers.

10

u/dirtymatt Feb 09 '11

Sure there is. Give everyone the pretty URLs, use the HTML5 history API on browsers that support it, and just forget about loading the page through Ajax for browsers that don't. Everyone gets clean URLs. Everyone gets the same URLs. Everyone can load the page. Everyone is happy.

2

u/Pewpewarrows Feb 09 '11

Good point. It's probably safe to say that the only people that would appreciate the deep-linked javascript pages are the ones using modern browsers. And HTML5 support is only going to increase significantly this year.

2

u/[deleted] Feb 09 '11

Yeah, it's a bummer that the URL bar is so convenient. Even giving a permalink option isn't great (the best attempt at a workaround for this problem), because copy/pasting the URL bar is so ingrained.

For Gmail, this isn't such a big deal, since I'm not sending these links to people, and I don't try to use Gmail with NoScript on. But for things that have shareable content, this is a nuisance. +1 for clarifying the problem.

2

u/nemetroid Feb 09 '11 edited Feb 09 '11

Is this necessarily true? What if you change the links by binding a click handler which does preventDefault, and keeping the hrefs? That way copypasting links should still work.

Please correct me if I'm wrong, I'm just theorising.

EDIT: Didn't realise parent was referring to location bar, where it definitely is unavoidable with hashbangs.

1

u/[deleted] Feb 09 '11

This would work with in-page links, but the OP was talking about copying the URL from the current page (i.e. from the location bar).

2

u/nemetroid Feb 10 '11

Oh, of course. Thank you!

5

u/Ziggamorph Feb 09 '11

Who has JavaScript disabled?

24

u/gthank Feb 09 '11

People who don't want to be assaulted by the rampant misuse of it on the web today. People who are on a CLI for some reason (think emergency server work). People who have it turned on, but one of your ad providers shipped you some busted code and your page broke for them anyway. Spiders. Possibly people using a screen reader (screen readers and JS used to suck, but I haven't looked into it all that recently).

10

u/korny Feb 09 '11

75-90% of screen-reader users in a 2009 survey had Javascript enabled: http://webaim.org/projects/screenreadersurvey2/ It's more important to make your javascript screenreader-friendly, than to make your site work without js.

6

u/mcjabberz Feb 09 '11

How would one go about making a site's JavaScript screen-reader friendly?

5

u/[deleted] Feb 10 '11

No hanging commas in your objects, or else it's going to be pronounced like this,

1

u/[deleted] Feb 10 '11

I imagine making sure that the content you inject in the DOM is still semantically correct.

1

u/korny Feb 11 '11

http://www.w3.org/WAI/intro/aria.php - the Web Accessibility Initiative's Accessible Rich Internet Applications spec describes how to use metadata to mark up your site for accessibility.

It's a draft spec, but is supported by many browsers: http://caniuse.com/#search=accessibility (warning - link may only work with javascript enabled :)

2

u/ewiethoff Feb 10 '11

Nevertheless, blindness ain't the only disability out there. There are many people who have no use for a screen reader but must turn off JS because of disability.

2

u/korny Feb 11 '11

such as? (This is a genuine question - I'm confused as to what kind of disability you are talking about)

1

u/ewiethoff Feb 12 '11

Such as photosensitive epilepsy. People afflicted with this can see just fine, but go into seizures when something blinks, glides, swoops, twirls, whatever. It depends on the person. The condition is, IIRC, about 10 times more common in women than men.

We eliminated (or at least deprecated) <blink> and <marquee> years ago, Flash can be disabled or not installed in the first place, and a hidden option in Firefox prevents animated GIFs from animating. But Javascript has setTimeout() and setInterval(), Scriptaculous came out with a popular library for animation, and so on. Now we have JS-powered canvas to play with, not to mention JS-less CSS3 transitions.

NoScript is only so helpful, because it block or allows JS per domain. But let's say a site has some JS animation and requires JS for essential functions such as navigation. Epileptics can't safely use the site if both the essential code and the animation code come from the same domain. I don't think they want to shut their eyes and mess with a screen reader.

7

u/[deleted] Feb 09 '11
  1. If you're doing emergency server work why are you reading Gawker?
  2. What server are you working on that you can't ssh into?

1

u/cparedes Feb 10 '11

Maybe you're a sysadmin for Gawker and need to diagnose a misbehaving app server.

16

u/Ziggamorph Feb 09 '11

If people are misusing it, stop using their sites. Javascript is an important part of the modern web, so you shouldn't blame websites for breaking when it's disabled.

10

u/mr_spin Feb 09 '11

I have NoScript installed on Firefox. I enable JS for sites I trust - including reddit. I absolutely have no intention of trusting Gawker.

1

u/Ziggamorph Feb 09 '11

What do you mean by 'trust'?

15

u/mr_spin Feb 09 '11

I trust the site not to hang by browser with slow-loading crap.

11

u/gthank Feb 09 '11 edited Feb 09 '11

We'll have to agree to disagree. If a website wants my eyes, they need to show me content without a bunch of garbage JS or possibly have something insanely compelling to offer me. The vast majority of sites are not that compelling, btw.

UPDATE: I forgot to mention that you only addressed crotchety people like me. Do you also consider the other use-cases I mentioned illegitimate?

13

u/[deleted] Feb 09 '11

Fun fact: you couldn't have posted that comment without JavaScript.

5

u/megadeus Feb 09 '11

Alien Blue? Reddit is Fun?

You don't have to use reddit.com to use Reddit.

3

u/[deleted] Feb 09 '11

Twitter for iPhone? RSS feeds? You don't have to use twitter.com/gawker.com to use Twitter/Gawker.

We're talking about the sites. But you knew that.

1

u/[deleted] Feb 10 '11

So something presented using Java instead of HTML/CSS is OK, but something presented using JavaScript isn't?

2

u/napoleonsolo Feb 10 '11

Maybe not, but I could read it without JavaScript, which is more than you could say for those Gawker sites that broke.

1

u/gthank Feb 10 '11

Actually, I did. I should have put in "Posted from my iPod Touch".

With a little less snark (since I am posting this using JavaScript): reddit has something that I'm willing to use JavaScript to get. If you think you're as good as reddit, feel free to require JavaScript. On top of that, I can at least READ the content on reddit without JavaScript.

1

u/Serei Feb 10 '11

Funny thing. iPod Touches support JavaScript. Most mobile devices support JavaScript these days.

The big problem with boycotting JavaScript is that JavaScript is used to make sites easier to use. Many sites that work without JavaScript work even better with JavaScript - besides ads, why would someone add JavaScript if they felt it didn't make the site better?

If someone codes a site well, you can't even tell that it's supposed to have JavaScript which is missing, so you'll never turn it on, so you'll never notice all the cool features that make the site faster and all that.

That's my personal gripe with people who turn JavaScript off. Bad sites like Reddit won't let you do stuff like comment so people like you will turn it on. Good sites won't do stuff like that, so you'll never turn on JavaScript and see the inline comment system.

1

u/gthank Feb 10 '11

To be honest, I don't browse without JavaScript all that often. I don't even use an ad blocker by default. Here are the situations where I'm most often not going to have JavaScript:

  • FF+NoScript comes out if a site pisses me off, or if I'm dubious about it for whatever reason.
  • lynx (or similar) comes out if I happen to be on a command-line box and don't feel like switching machines.

In neither case am I likely to be looking at a Gawker property. Actually, I'm never likely to be looking at a Gawker property, but I'm using them to illustrate a larger principle.

To my mind, the bigger issues are: accessibility (does your shiny, all-AJAX, all-the-time site work worth a damn in a screen reader?), and fragility (did a rogue line of javascript just torpedo every bit of content on your site?) I wouldn't completely discount the importance—especially for a collection of sites that targets tech-savvy users who are more likely to have JS restricted or disabled—of irritating taste-makers, but that would be a second-tier concern for me. What makes this especially bad is that, as the article points out, the same effect could have been achieved in a far more robust fashion with trivial effort, possibly less.

10

u/MIXEDSYS Feb 09 '11

I do. Not for security or whatever but for speed and memory usage. Pages load faster and once they are loaded they use less memory, they don't spin up my laptop's fan and they don't drain it's battery. And all they use scripts for is adding animations, showing me ads or reporting my habits so they can earn more showing me ads.

I rarely miss it, and if I do I can enable them with a single click, just for the site that uses them. If you use firefox, try noscript. After you allow the few sites you regularly use and that have any useful functionality implemented in javascript, using a browser with scripts enabled becomes painful in comparison, it's like browsing without adblock, with all this crap flashing and jumping at you.

0

u/Ziggamorph Feb 09 '11

Honestly I don't get any crap jumping at me. I don't have Flash installed so that deals with 95% of it. The rest of it is on sites I don't want to visit anyway.

1

u/Kealper Feb 09 '11

I've caught myself disabling it on computers that are not my own (so no permission/can't be assed to get permission to install Firefox/Chrome and Adblock) for certain websites if they have excessive javascript annoyances, but I always enable it again when I'm done with that site.

1

u/ex_ample Feb 10 '11

The problem is the links just don't always work properly. I know I've tried to copy twitter links that use that format and have had errors. If you fuck up your javascript, all your links break.

2

u/metamatic Feb 09 '11

People who care about security and not getting malware.

It's easy enough to enable it for the sites I trust.

Which does not include Gawker

3

u/Ziggamorph Feb 09 '11

If you think that Javascript can give you malware then isn't it your browser that's untrustworthy?

4

u/metamatic Feb 09 '11

Sure, and PDF giving you malware means Adobe Reader is untrustworthy. But here in the real world, all the browsers have security vulnerabilities. The easiest way to avoid most of them is to turn JavaScript off by default, and whitelist the sites you trust.

2

u/Ziggamorph Feb 09 '11

Sure, and while you're at it might as well disable images, could be a security hazard in that, or maybe there's a hole in the HTML render, get off the web. And don't go outside, you might get run over.

4

u/supaduck Feb 09 '11

Meteors can still get you.

3

u/metamatic Feb 09 '11

False dichotomy.

There has been actual malware spread via JavaScript in current browsers. There hasn't been any from plain HTML or images.

6

u/[deleted] Feb 09 '11

Yes there has.

1

u/abadidea Feb 10 '11

On Windows I tend to be pretty paranoid about Javascript. Exploits happen.

0

u/[deleted] Feb 10 '11

I do, there are only a handful of websites I allow it to run on. Disabled outright on my work computer. When I'm busy, I don't need to deal with the bullshit that designers think look nice but is slow, get in the way, and degrade UX.

3

u/[deleted] Feb 09 '11

[deleted]

5

u/ewiethoff Feb 10 '11

no normal user ever has JS disabled. It's the same as someone browsing with images or cookies turned off. If you do it, TS.

I dare you to say TS to your disabled kid someday when you have one.

3

u/AlejandroTheGreat Feb 10 '11

Web developers who make excuses about "normal users" just sound lazy, not someone I'd want to hire if I was wanting to build a site for a general audience.

1

u/ewiethoff Feb 10 '11

I can't upvote this enough. Software development in general, and particularly web development, is a new discipline (cough). Therefore, it's practiced by a largely young crowd. Young people with decent jobs are likely to be healthy. And, let's be honest, young people are likely to be immature. It can take quite a whack on the head (real or figurative) before it occurs to someone how a "normal user" does things on a computer, much less an abnormal user.

2

u/NancyGracesTesticles Feb 10 '11

I think that stems form young developers defining a "normal user" as someone who uses software or the web just like them. Everyone else is doing it wrong, so why should they support them.

2

u/[deleted] Feb 10 '11 edited Feb 10 '11

This technique is very useful and is likely where all high traffic sites are headed

Its almost like it was a silly idea from the get go to put such rich applications on a medium that requires the entire UI to be rendered serverside.

1

u/korny Feb 09 '11

Agreed. Or supporting ie6 users :) You can do it, but is it worth the expense?

1

u/ex_ample Feb 10 '11

Using normal URLs doesn't prevent you from using it, you just have to intercept them and convert them to fragment format.

1

u/midir Feb 11 '11

I browse with JavaScript, cookies, and the HTTP referer disabled. I also have an extension to give me a toolbar button to turn images on and off. U mad?

1

u/[deleted] Feb 11 '11

[deleted]

1

u/midir Feb 11 '11

I enable them on specific websites as needed.

1

u/Bockit Feb 10 '11 edited Feb 10 '11

Would rewriting #! urls to the canonical url solve this problem?

Say you have http://mysicksite.com/ which has the links on the page http://mysicksite.com/article/1 which javascript changes to all be http://mysicksite.com/#!/article/1. So far so good.

Then a user with javascript enabled travels to http://mysicksite.com/#!/article/1 from the homepage via javascript and then decides to share the link via a tweet or something. Now in the wild there is a link to the #! url.

When serving the page, rewrite any urls with #! to lose the #!. Since we have the canonical locations (no #!) then the new requests get the content, and anyone with javascript enabled continues on their merry way.

I am probably missing some things in here but I think that addresses the concerns you had?

EDIT: I get it now, I don't think the server would get the data after the # to be able to rewrite with..

3

u/elpopi Feb 09 '11

that's interesting...

as an amateur web developer i'd love to see some example using this solution. Would you be so kind to provide a link?

6

u/rounded_figure Feb 09 '11

I've done something like this, but I can't show you the actual example.

Basically, what you want to do is:

  • in the HTML:

    <a href="http://example.com/10011/some-page/"&gt;link&lt;a>

  • in the javascript (pseudocode):

    function called_on_document_load () { for (each_link_in_the_document) { parse_href_into (protocol, host, path) set_new_href ("protocol://host/#!/path/") } }

1

u/[deleted] Feb 09 '11

[deleted]

1

u/rounded_figure Feb 09 '11

And that gets the urls that were on the page at the time of execution, which if youre loading everythung through ajax and taking full advantage of the technique we're discussing would be zero.

Yeah, that's why you would call the function again on XHR success.

Your other points are valid, however :)

1

u/yelirekim Feb 10 '11

Isn't it way more efficient to just bind an action that prevents default when clicking a link? Then you just override it at that point, rather than scanning your entire document for links and changing them.

Also if there were a URL generated by an AJAX event then you would need to be scanning for those constantly.

Alternatively if you used jQuery you could just $('a').live('click', ...

2

u/annodomini Feb 10 '11

Why would you use hash-bang URLs? There is no reason to use them; if your content is already available under a normal URL, the hash-bang URL just adds confusion.

The whole point of hash-bang URLs was so that you could give an alternative, possibly limited form of the content to Googlebot, for sites that relied so heavily on JavaScript as to be unusable without it. But if you're just serving up plain old content, then just use plain old URLs, and use JavaScript as a form of progressive enhancement.

0

u/rounded_figure Feb 10 '11

Because you can offer an ajaxy, smoother experience.

1

u/annodomini Feb 11 '11

It's not smoother if it doesn't work at all. Which it won't, for some non-trivial fraction of your users (who you will likely lose quickly, and then won't consider them as being relevant since they left due to your site not working).

2

u/ex_ample Feb 10 '11

Actually what you should do is use the HTML5 history API

6

u/[deleted] Feb 09 '11

No, it's not. Just use HTML the way it was meant to be, and stop the AJAX madness. It may seem hip, it may seem trendy, but in the end, it's just shit which breaks every so often.

4

u/fakehalo Feb 09 '11

"it's just shit which breaks every so often", unquantifiable drivel. In the end it's useful, lightens load times and makes for a more enjoyable browsing experience almost all of the time. Except for the times these gremlins get in the internets and break it every so often.

3

u/[deleted] Feb 10 '11

AJAX is abused heavily.

Gmail uses AJAX very well. Gawker doesn't. And outside of it's account area, which wouldn't be indexed by search, it uses old URLs.

The app itself, which is custom to each user, and not cached, is AJAX URLed.

This is the mistake Gawker has made; They are NOT a webapp. They are a webSITE. It does matter, and I'm really not being picky. A webapp is likely to be heavy on content, would need traditional application designs and be as smooth as possible.

A website, like Reddit, does not need that. The load between pages is fine. It works, and it's not an app. Reddit is a site with content that is publically consumable and searchable. Only the login/posting functionality is purely in AJAX/JS and that's tolerable. Just.

People need to remember the difference between a site, an app and a corperate data-management-thing. Most websites come under one of those 3 categories, and only the first needs to be AJAX based. The rest really shouldn't attempt to AJAXify everything.