What is Digg?Sponsored by Best Buy
Best Buy casts another employee in holiday campaign. view!
youtube.com/bestbuy0 - Jarice Brodie has done some cool things in his life. Next: Best Buy’s holiday campaign.
41 Comments
- snide, on 10/12/2007, -2/+9"though I never completed it..."
All you need to know. - apotropaic, on 10/12/2007, -1/+7not all websites have to have massive amounts of javascript. But if you are a web DEVELOPER.. you should know this. If you've made a web page... that doesn't make you a web developer.
Also... sometimes... JS files shoudln't be cached. - Scriby, on 10/12/2007, -2/+8I'm pretty confused by this whole article. Every major browser already caches javascript and does a date check before re-fetching the file. What additionally is the author trying to accomplish?
- armbar, on 10/12/2007, -4/+9I got to "irregardless" and stopped reading.
- Otto, on 10/12/2007, -0/+5Why would the browser download the file multiple times anyway? It's only going to do that if you improperly configured your web server. Methinks somebody needs to learn about the Cache-Control header.
People who don't understand how the basic technology works are doomed to reimplement it in the worst possible way. - elroy, on 10/12/2007, -0/+4h2d2: write a remote XUL application and you'll see why you need to change JS files often.
- captaindan, on 10/12/2007, -0/+3Or the Oxford English Dictionary.
I'm serious. It's in there, although it has the following in its usage notes: "Irregardless is avoided by careful users of English." - konkushn, on 10/12/2007, -2/+5Reading these comments is like listening to the Comic Book Guy berate some poor nerd on the Simpsons. Condescending and arrogant.
- traherom, on 10/12/2007, -1/+4Well... that's not as exciting as I had hoped. It's pretty much just chaching the JS files...
- ScnnrDrkly, on 10/12/2007, -1/+4This is ***** lame. Setting up a proper caching scheme on your server is the correct way to do this. To add insult to injury, in the provided code there's a nice, fat XSS exploit staring you right in the face. Oops...
- ldhertert, on 10/12/2007, -6/+9yes because every single website uses massive javascript files. oh yeah, and all web developers have expertise in the use of php to cache files.
- Poco, on 10/12/2007, -1/+3What's worse is the Digg spell checker doesn't have a problem with irregardless.
- h2d2, on 10/12/2007, -2/+4JS should be cached, everyone knows that. And they are cached, by the browsers. That's simple.
But why do you need to _change_ JS files so very often, so often that a they should be created from server-side scripting on every load to prevent browser caching. That's insane. If you need to change client-scripting so very often, why not just use server-side scripting?
The author just wrote a PHP script because he needed to update his client-side scripts often (it was a failed cause, as you see). This has nothing to do with AJAX, much less than speeding them up. - dogas, on 10/12/2007, -1/+3This script does absolutely nothing. Your browser will cache the javascript files automatically, and even then, it will still load them occasionally, and will load them every time when you explicitly hit the refresh button.
That dude's blog is filled to the brim with so much ***** I don't even know where to begin. First off, dotbeta.net doesn't even work. 2nd, and probably most importantly, he didn't even invent anything. Javascript files are not dynamic! They will be cached anyway. All this guy DID invent is a way to ensure your javascript files will NOT be cached just in case you actually change your javascript files. 3rd, look at his "php" code, which is so obviously VB!!
Jesus.. this makes no sense. No digg. HOW did this make the front page?! - sfacets, on 10/12/2007, -0/+2This is like the third (serious) suggestion for Digg to streamline it's code, which is bloated, bulky, and buggy. Hello? Anyone there?
- Bogtha, on 10/12/2007, -1/+3> Unless you're maintaining multiple versions of an app there is no reason to present the versioned js to the user.
No, there's a very good reason for versioning in this manner, in the very common case of dynamically generated pages and static external resources. 99% of the time you want clients to use the copy of the static external resources without bothering to redownload or validate their cached copy. But if you set your headers up to allow this, when you make a change, you can't notify them of it. But because you are using dynamic pages, you can merely point to a different URI where the new version is found. All the clients with an outdated copy automatically download the new one when they next request a page.
The long expiry time+versioned URI technique is pretty much the only efficient solution to this problem. Everything else involves either letting things go out of date or forcing clients to keep validating their cached copies, causing needless roundtrips to the server in almost all cases.
Of course, that doesn't mean the code the article uses is in any way sensible. Why would you willingly pipe your JavaScript files through the (relatively) slow PHP interpreter when you can just set up a decent caching policy with your server config? Why is the code completely oblivious to ETags? What's with Cache-Control: cache? That's completely non-standard - it should be Cache-Control: public or similar. It seems to me the author hasn't even bothered reading the HTTP spec. - vh1`, on 10/12/2007, -1/+3neither does google
- Durrok, on 10/12/2007, -1/+2Digg is downright slow on my work PC. 1.5ghz with 1 gig of ram and onboard video. However my home PC 2.8ghz with 2 gigs of ram and a pci-x ati x800 flies through digg. Not sure what is causing the major slow down, but I shouldn't have to have a top of the line PC to see a speedy response when I digg a story or comment.
- posure, on 10/12/2007, -1/+2As was mentioned, timestamps on the JavaScript works better and doesn't take any processing. Contrary to the title of this article, this actually decreases your performance. This article is for ASP.NET/PHP, but for anyone who doesn't know, Ruby on Rails does this for you automatically.
- xile, on 10/12/2007, -1/+2Someone please send this to the Yahoo Mail Beta developers.
- vh1`, on 10/12/2007, -1/+2I especially like how there's no checking of whether or not the file to be included is actually a javascript file, or in a certain directory
- s_mk, on 10/12/2007, -0/+1heres a post I posted about this a while ago........
no additional software installs needed
http://digg.com/programming/Dynamically_include_Javascript_libraries_at_runtime - MatttK, on 10/12/2007, -4/+5Worst. Digg Article. Ever. ;)
- DaWolfman, on 10/12/2007, -2/+3or Word.
- Staryx, on 10/12/2007, -2/+2Oh yeah! Well, my Dad can beat up your Dad!
Oh, sorry, we're poking fun at elitists, not immaturity. - Rice, on 10/12/2007, -2/+2I'm pretty sure the digg staff would disagree.
- armbar, on 10/12/2007, -0/+0Irregardless is one of the words that's been added to dictionaries because of repetitive (and incorrect) use. Podcast is also now in the dictionary, although it's arguably more valid than irregardless.
The correct, traditional usage is regardless. Or to stay away from the issue entirely, try nonetheless, anyway, or although on for size. - agarc, on 10/12/2007, -1/+1Even if this did something useful, one has to question the worthiness of a solution that requires lots of code. Lame.
- nferrier, on 10/12/2007, -2/+2oh dear this is lame.
And I wouldn't recommend this technique anyway; you should use cool-uris-that-don't-change. In other words make a symlink for your javascript file and then put each version underneath it.
Unless you're maintaining multiple versions of an app there is no reason to present the versioned js to the user. - l3e3e7, on 10/12/2007, -1/+1regardless and irregardless have the same meaning and are both valid, however irregardless has become less regard-ed.
- elroy, on 10/12/2007, -1/+1i'm still waiting for them to actually use my default threshold setting in my profile. it's always -4 no matter what i specify...
- KentiVarna, on 06/15/2009, -1/+1Caching is not the major problem(your browser will already do this). Just need to compress and combine all those pages so the size of them is smaller.
http://digg.com/technology/digg:_JavaScript_and_CSS_reloaded - surfichris, on 10/12/2007, -1/+0So in summary, this idea provides the following:
- Higher load on the server as it is now parsing dynamic content for the files, all of which now needs to be fed through a scripting interpreter.
- Duplicates browser caching.
- A solution which wouldn't actually work for some browsers which incorrectly handle the 304 header and still expect content.
Cool - trajano, on 10/12/2007, -1/+0I think the slowest part of the system would be the multiple network connections. I tried to fix that with the AjaxQueue pattern [ http://www.trajano.net/2006/04/ajax-queue.html ] although it just all theory at the moment.
The main idea is to cluster together multiple Ajax responses into one request rather than several blocking ones.
Actually if Digg implemented this, they can add new comments as they come in to the servers. They just push the new comment into the queue which gets picked up by the browser side javascript. Since there is no requirement that every response from the server has to be triggered by a request. It is cluster-safe too. - inactive, on 10/12/2007, -3/+2Misread the rss headline first as "Speed up your AJAX based weapons"
Was thinking cool, AJAX really does make _everything_ better! - mfearby, on 10/12/2007, -2/+1I find that PHP developers typically resort to the spaghetti approach for "fixing" things. I'm no genius programmer myself, but I'm good enough to know that PHP is an old-patchwork-rug-the-dog-sleeps-on which brings shame to programmers everywhere!
I'm with you: HOW did this make the front page?!?!?!?! - tracker1, on 10/12/2007, -2/+1no digg for me... this can simply be done with src="somefile.js?ver=x.x" instead of creating the aspx/php file, most browsers will cache irregardless, and the ver change in the main html (more likely aspx/php etc file) will trigger the browser to download the new version, as it is still a "different" link to the browser.. :p
- uptown, on 10/12/2007, -2/+1"even digg"
"regular visitors"
There's all sorts of extra words thrown into that description.... - fforw, on 10/12/2007, -3/+0Hello??? Forcing javascripts to be cached until 2011?? And what happens if you have to make a change? Many of your visitors don't have any clue what a cache is or how to flush it. So are you going to put up notices on the front page of your website explaining how to flush the cache every time you make a minor javascript change??
Sounds really strange to me.. Better just keep your javascript thin, put the javascript you need into one big file, compress it ( http://dojotoolkit.org/docs/compressor_system.html ) and maybe set up gzip/deflate compression for your web server. - tracker1, on 10/12/2007, -5/+1armbar, sorry to offend your sense of the english language... I've never been very good with writing/speaking... I'm very good however with many other things... Einstein had trouble matching his socks, and tying his shoes.
- zirtbow, on 10/12/2007, -16/+7If you write webpages and didn't know 90% of whats in this article already then you should probably give up now. (I'm sorry that sounds bad but really... reading down this is almost like someone saying "Water is wet.")
© Digg Inc. 2009
— Content created and posted by Digg users is