Hashbang URIs Aren't as Bad as You Think
mtrpcic.net
Hashbang URIs Aren't as Bad as You Think
1–10 of 46 posts
Re: Hashbang URIs Aren't as Bad as You Think
#2> Now, take away the constant loading of the JavaScript and CSS, and you've significantly decreased bandwidth and server load
On a related note, if this is a problem for you, now might be a good time to check your Expires headers. The 'some clients turn off caching' seems like a bit of a non sequitur too- some clients also have javascript disabled. Some clients are IE6. How many clients are like that in the wild? How many of /your/ users?
Re: Hashbang URIs Aren't as Bad as You Think
#3> Now, take away the constant loading of the JavaScript and CSS, and you've significantly decreased bandwidth and server load On a related note, if this is a problem for you, now might be a good time to check your Expires headers. The 'some clients turn off caching' seems like a bit of a non sequitur too- some clients also have javascript disabled. Some clients are IE6. How many clients are like that in the wild? How…
I agree, and that's kind of the point I was making towards the end. You need to know what your target audience is, and whether or not those are issues you might face. In either case, if you have a "DOM Heavy" application, you can still save bandwidth by not needing to send anything except the data across.
Re: Hashbang URIs Aren't as Bad as You Think
#4> Now, take away the constant loading of the JavaScript and CSS, and you've significantly decreased bandwidth and server load On a related note, if this is a problem for you, now might be a good time to check your Expires headers. The 'some clients turn off caching' seems like a bit of a non sequitur too- some clients also have javascript disabled. Some clients are IE6. How many clients are like that in the wild? How…
The caching justification felt very contrived to me. I'd guess that the percentage of users with broken cache handling is lower than the percentage of users with javascript disabled. I'd rather not guess, but the author didn't provide any actual evidence that this is a problem.
If your cache headers are set incorrectly, you should probably fix that instead of reworking your entire site.
Re: Hashbang URIs Aren't as Bad as You Think
#5> Now, take away the constant loading of the JavaScript and CSS, and you've significantly decreased bandwidth and server load On a related note, if this is a problem for you, now might be a good time to check your Expires headers. The 'some clients turn off caching' seems like a bit of a non sequitur too- some clients also have javascript disabled. Some clients are IE6. How many clients are like that in the wild? How…
I agree, and that's kind of the point I was making towards the end. You need to know what your target audience is, and whether or not those are issues you might face. In either case, if you have a "DOM Heavy" application, you can still save bandwidth by not needing to send anything except the data across.
Yes, but if you want to be honest about numbers, you should say something like
Reddit.com HTML.: 37.6 KB Text in that HTML: 5.9 KB
(That's just what I got from copy+pasting.) The difference at issue is loading another 37.6 KB page versus loading whatever part of that 5.9 KB is the "interesting" text (i.e. probably not the header or footer) plus its links and styles and the overhead of whatever you want to stick it in (JSON, an HTML fragment, etc). The huge CSS and JS files are not reloaded every time you go to a new page.
Re: Hashbang URIs Aren't as Bad as You Think
#6> Now, take away the constant loading of the JavaScript and CSS, and you've significantly decreased bandwidth and server load On a related note, if this is a problem for you, now might be a good time to check your Expires headers. The 'some clients turn off caching' seems like a bit of a non sequitur too- some clients also have javascript disabled. Some clients are IE6. How many clients are like that in the wild? How…
The caching justification felt very contrived to me. I'd guess that the percentage of users with broken cache handling is lower than the percentage of users with javascript disabled. I'd rather not guess, but the author didn't provide any actual evidence that this is a problem. If your cache headers are set incorrectly, you should probably fix that instead of reworking your entire site.
It's true that the caching argument seemed contrived (and was, in a sense), so I've added an edit to it to take your comments, as well as others, into consideration, and to make them known to other readers. Thanks for the feedback.
Re: Hashbang URIs Aren't as Bad as You Think
#7Earlier quoted context omitted.
I agree, and that's kind of the point I was making towards the end. You need to know what your target audience is, and whether or not those are issues you might face. In either case, if you have a "DOM Heavy" application, you can still save bandwidth by not needing to send anything except the data across.
Yes, but if you want to be honest about numbers, you should say something like Reddit.com HTML.: 37.6 KB Text in that HTML: 5.9 KB (That's just what I got from copy+pasting.) The difference at issue is loading another 37.6 KB page versus loading whatever part of that 5.9 KB is the "interesting" text (i.e. probably not the header or footer) plus its links and styles and the overhead of whatever you want to stick it in…
That's a good point. The big issue is loading the "Heavy" part of the DOM every time (navigation links, header/footer, user panel, etc), rather than the real "content". I'll make an edit and make that a more prominent point. Thanks for the feedback. If you don't mind my asking, how did you pull the 5.9KB number out of the 37.6 one? Just checked the size of the interesting part of the page once saved into a new file?
Re: Hashbang URIs Aren't as Bad as You Think
#8Hear hear.
I can think of many cases where ajax loaded content and the attendant hashbang URLs are far preferable, like with twitter's web interface or with gmail. It just makes sense for web applications to work differently than static content, and persistent display of information often beats out clean looking URIs.
Plus the whole anti-hashbang thing has a reactionary air to it.
Re: Hashbang URIs Aren't as Bad as You Think
#9Large/lots of javascript files can slow down the loading of the page, but that wasn't the real issue people were taking with JS-controlled sites (as I interpreted things).
The real delay cost was from the inevitable redirect to the root of the website. When you visit domain.com/user-name, a JS-controlled site will usually redirect you to domain.com#!/user-name, and then loading up the page. There is no avoiding this unless you want really ugly urls: domain.com/user-name#!/user-name...
So large JS files might increase the load speed slightly, but adding an entire redirect is the kicker.
Like most things, there's a time and a place. Using hashbang urls can increase response-time when navigating through a site and provide a really cool experience. On the other hand, it definitely doesn't work for all browsers and users.
Re: Hashbang URIs Aren't as Bad as You Think
#10Hear hear. I can think of many cases where ajax loaded content and the attendant hashbang URLs are far preferable, like with twitter's web interface or with gmail. It just makes sense for web applications to work differently than static content, and persistent display of information often beats out clean looking URIs. Plus the whole anti-hashbang thing has a reactionary air to it.
That's the thing. When you're making something on the web, you need to define to yourself whether it's a Web Application or a Web Site. The hashbang approach lends itself very well to the Application side of the browser.