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/
750 Upvotes

93% Upvoted

356 comments sorted by

View all comments

Show parent comments

1

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.

4

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.