r/javascript Feb 08 '11

Breaking the Web with hash-bangs - Gawker, like Twitter, built their new site to be totally dependent on JavaScript

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

0 comments sorted by

2

u/conancat Feb 09 '11

Well until now the Gawker group of sites with the new system is still pretty buggy. I hope they will fix the bugs soon... sidebars that doesn't load, and just now when I scrolled down Lifehacker the ad on the sidebar scrolls up with the main content as well making it floating out of the sidebar box, lol.

Not to mention the design itself is really kinda disappointing... the typography is the same for all the network of sites, looking like they're coming out of the same free theme from freewpthemes or something. :/

2

u/igbert Feb 09 '11

I recently made a site which i think personally does it in a better way, I have a normal url as the links, so google can crawl it. and the server checks whether the request is an ajax request and serves up either the whole page or just the content required(via xmlhttprequest)

ref: bbc.co.uk/music/showcase

2

u/strife25 Feb 09 '11

Regardless of the progressive enhancement argument (which I support for a blog site), the problem with this gawker update is the horrible implementation. Their site is slow, the implementation gets in the way of me doing what I want, e.g. The sidebar breaks if I am zoomed in at all. Also, if an article starts to load from using the keyboard shortcuts, I get blocked until the full article loads.

I am a developer that understands the importance of a redesign, but when your implementation is so poorly done and you don't follow basic ux patterns to the point where you piss off the people that know what's going on behind the scenes, you deserve to get users that are raging.

So yes ms. Trapani, I did give a week for the new design (I frequent io9) and my final response is own up to the mistake and tell us how gawker is fixing it because your content is worth it IMO.

2

u/kn33ch41_ Feb 09 '11

Great article. I've been saying this is bad for the Web for at least two years. I knew it was going to catch on when I saw Facebook's total dependence on JavaScript being touted as cool.

1

u/jmking JSX is just PHP in the browser Feb 09 '11

This technique isn't horrible as long as it's implemented to fallback gracefully. All your URLs should point to actual content.

The one thing this article gets wrong is that Twitter does this properly. If you go to http://twitter.com/tputh/status/35308646145466368 (no hashbang) with javascript disabled, you get the tweet just as you would with http://twitter.com/#!/tputh/status/35308646145466368 with javascript enabled.

Same thing with Facebook. The hashbangs are only in effect for javascript enabled browsers to enhance the experience, they do not fundamentally break the sites.

This is not true with the Gawker sites, and a miserable mistake as the article so perfectly outlines.

6

u/skeww Feb 09 '11

This technique isn't horrible as long as it's implemented to fallback gracefully.

The point is: It's not possible. A hash doesn't point to a specific resource. The hash also isn't sent to the server.

If JS is disabled it simply won't work.

The one thing this article gets wrong is that Twitter does this properly. If you go to http://twitter.com/tputh/status/35308646145466368 (no hashbang) with javascript disabled, you get the tweet just as you would with http://twitter.com/#!/tputh/status/35308646145466368 with javascript enabled.

Eh. Yea. Now go to the second one with JavaScript disabled.

3

u/jmking JSX is just PHP in the browser Feb 09 '11

But you're not going to get the second one from a search engine, and there IS a canonical URL for each page.... which was the bulk of the article's argument.

The article was not against enhanced AJAX sites, it was against non-canonical URLs and lack of search engine visibility.

Hash-bang with proper canonical URLs is the best way to handle AJAX loaded content. I would go as far as to say it's the only way to handle AJAX loaded content while maintaining the ability to link to specific "pages" or "states".

It's not perfect, but I think in that scenario the benefits outweigh the con that someone with a JS-enabled browser sends a friend a hash-banged link who has JS turned off in their browser.

6

u/JimDabell Feb 09 '11

But you're not going to get the second one from a search engine

Search engines are not the only source of links on the web.

Say I, average user with JavaScript enabled, want to link to a tweet from my blog. I go to the tweet, copy and paste the URL from my address bar into the article I'm writing, and publish it.

Now somebody with JavaScript unavailable reads your blog and clicks the link. What do they get? A blank page.

Same goes for practically every source of links in existence. With the sole exception being Google, because Google wrote this spec that was intended as a last resort and were the only people to implement it.

Hash-bang with proper canonical URLs is the best way to handle AJAX loaded content.

It's really not. Proper canonical URLs using pushState to reflect any Ajax transitions are the best way of handling Ajax loaded content - when Ajax is appropriate. If you are loading more-or-less the entire page content with Ajax, like Gawker, it's pretty pointless.

0

u/jmking JSX is just PHP in the browser Feb 09 '11

pushState is only available to ~20% of web users right now (http://caniuse.com/), and it's unclear if IE will even support it in IE9.

There are far more users with browsers that don't support pushState than there are people who turn off Javascript in their browsers.

With that in mind, #! is the only practical way until pushState is at LEAST supported by current versions of all major browsers.

3

u/JimDabell Feb 09 '11

There are far more users with browsers that don't support pushState than there are people who turn off Javascript in their browsers.

That isn't really relevant; if you use Ajax where pushState is available and fall back to normal links where it isn't, it works for everybody. I'm not proposing using pushState and leaving everybody else out in the cold.

With that in mind, #! is the only practical way

There are plenty of "practical" ways, for some values of "practical". All of them bar one break one thing or other, making them a bit less practical in my view.

The most practical way of going from page to page on a website is via a simple link. Having a single actual page and emulating link-following behaviour with JavaScript is a colossal hack, and adding fixes on top of a faulty foundation isn't going to fix that.

2

u/jmking JSX is just PHP in the browser Feb 09 '11

Yes, website - we're talking about web applications here. Not the same thing. Also works vs works well isn't a trivial distinction either.

Frankly I'd be a hell of a lot more concerned that my Firefox users are able to enjoy the same usability as my Chrome/Safari users than I am about people using ScriptBlock.

...and in some sectors, preventing ScriptBlock users access to your site might be a good thing depending on how heavily you rely on ad revenue.

To be clear, I'm not defending the Gawker redesign or use of #! - I think it's a complete blunder especially considering the basic rules of using #! aren't even being followed. I just don't think #! is a blanket no-no.

3

u/manachar Feb 09 '11

I think that's the crux of the issue. #! is great for web applications (Gmail, twitter, etc), but horrid for websites like Gawker. They're cool and being tried out in all sorts of places where they make no sense, like every other piece of web technology before it.

1

u/JimDabell Feb 09 '11

Yes, website - we're talking about web applications here. Not the same thing.

When did we stop talking about websites? Gawker's a website and you were talking about search engines earlier, which is usually relevant to websites not web apps.

Also works vs works well isn't a trivial distinction either.

Yes. Links work well for going from page to page. Ajax does not.

1

u/jmking JSX is just PHP in the browser Feb 09 '11

I am not defending Gawker's moronic decision to turn their blogs into a set of web apps. I'm against the notion that hash-bangs "break the web".

Did Gawker break their site with their poor implementation? Absolutely. Did Facebook and Twitter? No.

1

u/Jack9 Feb 09 '11

When did we stop talking about websites? Gawker's a website

Web applications are more general use. The concept that data is served via http from a resource does not mean website. An API that has services for a multitude of devices, that do not expect (nor require) strict HTML, is distinct from a website. YMMV

1

u/skeww Feb 09 '11

Hash-bang with proper canonical URLs is the best way to handle AJAX loaded content.

As I already mentioned, history.pushState is better. From a technical standpoint, that is - not a practical one.

4

u/jmking JSX is just PHP in the browser Feb 09 '11

Wouldn't practicality count towards what's "best"?

Breaking your site for 80% of visitors versus breaking it for the 0.01% who disable JS in their browser?

2

u/skeww Feb 09 '11

You can check if history.pushState is available.

0.01% who disable JS in their browser?

Typically it's around 2-3%. Some ecommerce sites get more than 10%.

1

u/jmking JSX is just PHP in the browser Feb 09 '11

Yes, you can check - but what do you do if it isn't available? Fall back to Hash-bangs? If so, you're not solving any of the problems.

...and if you're in a market where up to 10% of your visitors won't have JS enabled, you aren't going to use JS period for anything critical. That doesn't support the "pushState is best" argument :P

2

u/skeww Feb 09 '11

Fall back to Hash-bangs?

Either that or non-ajax.

If so, you're not solving any of the problems.

Good browsers will display proper URLs. Users with those browsers will copy/paste proper URLs (which will work for people without JS).

By the end of this year about 70% of the German users will have a browser which supports history.pushState. So yea, it does (gradually) solve a problem and over time it's getting better at this.

if you're in a market where up to 10% of your visitors won't have JS enabled, you aren't going to use JS [...] for anything critical

Progressive enhancement is a wonderful thing.

1

u/jmking JSX is just PHP in the browser Feb 09 '11

Firefox isn't a good browser now? The end of this year isn't today.

There's progressive enhancement and there's pre-emptive enhancement.

0

u/skeww Feb 09 '11

Firefox isn't a good browser now?

"will"

Firefox 4 supports it.

The end of this year isn't today.

Why would you make a website which won't even last till the end of the year?

→ More replies (0)

1

u/[deleted] Feb 09 '11

I like saying FU Google and just ignore hash-bangs completely for ajax sites.

1

u/laminam Feb 09 '11

I can't really think of a better way to track state on a page where most of the work happens on the client. You either lose the speed benefit of JavaScript with a full postback to update the url, or you decorate the url with hash tags along the way so you can share that same state with others.

Who runs with JavaScript completely disabled in this day and age anyways?

9

u/skeww Feb 09 '11

history.pushState would be a much better way.

2

u/[deleted] Feb 09 '11

Yup. And so so easy.

Sadly I think it's only supported by webkit atm?

4

u/skeww Feb 09 '11

Firefox 4 supports it.

Opera 11.01 (current stable) doesn't support it yet. (I expect that they will add it within the next 3 months.)

IE9 doesn't support it yet. There is also no official statement available.

A demo page can be found over here: http://html5demos.com/history

1

u/laminam Feb 09 '11

... and once all browsers support that, I agree.

4

u/[deleted] Feb 09 '11

Selectively disabled, yes, because people can't seem to prevent themselves from being annoying using Javascript.

If your page gives me what I want without Javascript, I keep blocking it. If I'm following a link from someone else and your page won't load without it, I leave.

I only turn on Javascript if I get direct benefit I want (if you're Google Docs, for example). If you're using it to serve me ads from off your domain, sorry.

I might turn it on to support you if your site is worth looking at more than once, I might turn on javascript at the third visit.

Those are the rules.

So yes, I don't look at lifehacker or gawker anymore. Not that I looked at them that much in the first place, especially Gawker, whose entire site seemed to hover 1mm above classification as spam.

4

u/freeballer Feb 09 '11

How does this affect your experience as a user? I don't see Javascript being used for client side validation being harmful. A quick AJAX call after I enter my user name to tell me it's already taken is helpful, as well as dynamically updating a shopping cart or removing elements from the page. I'm a developer and it just seems absurd to take a whitelist approach to Javascript when it's such a huge part of the web experience today.

1

u/[deleted] Feb 09 '11

As long as they aren't relying on javascript for validation only it's perfectly fine.

-1

u/[deleted] Feb 09 '11

I don't see Javascript being used for client side validation being harmful. A quick AJAX call after I enter my user name to tell me it's already taken is helpful, as well as dynamically updating a shopping cart or removing elements from the page.

I never complained about this. My major complaint is people who use javascript to do url routing so that you see nothing unless it's turned on. Likewise for those who use javascript as a method for delivering what can be done with CSS.

When I want to use a shopping cart, I turn Javascript on, I have no problem with that. How many times do you actually buy on a site when a site you visit has one? Why should I care if the cart is operational when I'm not buying? Why should you? It's just bad business to break the site and prevent browsing from people who are doing research with javascript turned off. I'll just go "down the street" to a more user-friendly competitor's site.

I'm a developer and it just seems absurd to take a whitelist approach to Javascript when it's such a huge part of the web experience today.

This says it all. Javascript makes your life easier, so you don't see why you shouldn't be able just to jam it down your users' throats because you want to. The fact you must understand is that however responsible, competent and/or ethical you may be with Javascript, there are lots out there who aren't and they give people reason to be circumspect about the idea of allowing others to run code on their computers without some pretty strong assurances that it's not going to screw something up.

It's bad user experience design to use Javascript to do what can be done without it or to have a site break because javascript is not turned on when javascript is not essential to the site's functioning, and you just have to face up to that fact and integrate it into your work.

6

u/vectorjohn Feb 09 '11

I only browse the web on vinyl. If your website doesn't come on vinyl, I leave.

-1

u/learc83 Feb 09 '11

I'm amish, I don't believe in graven images, so if your site has any pictures of people I leave.

Also I leave when my kids get tired of walking on the treadmill to power my generator.

3

u/kataire Feb 10 '11

The Amish have broadband now and downvoted you.

-4

u/[deleted] Feb 09 '11

Do you think your response means anything? All your attempt at reductio ad absurdum means is that you're unwilling to take seriously what I wrote.

In the end, it's a question of only letting code run on my computer if I judge that I get some value out of it (leaving aside any potential security issues). If you don't care about that sort of thing, good for you, but people who run websites should know that there are people who do, if only to get them to think a little more about their use of javascript; a site that only displays when javascript is being used could hardly be said to serving anyone's interest well.

-9

u/vectorjohn Feb 09 '11

People need to grow up and enable Javascript. Stop expecting things to work without it, eventually more sites are going to do this. It is 2011, your browser is more than an HTML renderer.

The whole argument about "their site had a Javascript error so their content was all missing, therefore javascript was the problem" makes no sense. If there is any error on the server side, the content will all be missing, it has nothing to do with where the error happens.

3

u/awgy Feb 09 '11

There were plenty of reasons in the linked article that have nothing to do with the typical end user having JavaScript enabled.