News:

The anti-spam plugins have stopped being effective. Registration is back to requiring approval. After registering, you must ALSO email me with your username, so that I can manually approve your account.

Main Menu

Image Viewing Programs

Started by paper-snow, November 25, 2007, 08:06:25 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Xepher

I don't think that was it... there's a way you can save bandwidth/space with "encoded" javascript files. It basically makes them small, but not really human readable. Complex ones require more CPU juice from the browser too. http://scriptasylum.com/tutorials/encdec/encode-decode.html

Encoding them saves bandwidth, but makes the browser slower.

Miluette

Hmm... in short I am mildly confused, lol. But only mildly.
And wasn't it you who told me,
"The sun would always chase the day"?

Databits

Ok, guess I'll summarize:

Don't use compressed or encoded JS files. :P

Longer clarification:

I'm referring to actual *.js files, not what's directly in a web page. Xepher is right, it conserves bandwidth... but at the cost of performance. At least that's been our recent discovery with jQuery and other larger javascript frameworks or API's. Thanks to the wonderful world of broadband making things dead cheap in the bandwidth category, there's not much need to optimize things as much as there used to be anyhow. What I'm referring to is more along the lines of javascript files that are compressed and need to initialize/decompress/etc... each and every time you load a new page.

The difference we saw was literally noticeable visually. As in we could immediately tell the speed differences.

See, rather than just downloading a slightly larger file, caching it, and then just using it on page loads, it was downloading a smaller, compressed file, caching that, and then each and every page load it'd need to decompress it first, then run it. Though it's more noticeable when you're pulling things via an Ajax API that runs after the page is finished loading.
(\_/)    ~Relakuyae D'Selemae
(o.O)    
(")_(")  [Libre Office] [Chrome]

Miluette

#18


I like code guys who can dumb things down for people like me. :P (I'll never know more than I need to know to integrate Flash and actionscript with aspx files or whatever it was my associate said he'd teach me)

And I fix it by? 5 words or less, please. <3
(Would it be by pasting all that's in the .js file into that "encoded" part of Xepher's link and hitting that <-- button? ...And then copying it into a new .js file?)
Thanks~
And wasn't it you who told me,
"The sun would always chase the day"?

Databits

Hmm, I'm not really sure how to dumb it down much more than I have. Lets see...

Here:
Minified jQuery vs. Normal Uncompressed jQuery

The "minified" version is a lot smaller (54.4 kb), same code and all, but encoded and compressed. It's a smaller download initially, but more work for the browser in the long run because it has to decompress and evaluate it every time it runs.

Then you have the normal version, which is larger (97.7 kb), which is "slightly" larger (though a 40kb difference isn't shit with broadband now days) and less work for the browser since it doesn't have to decompress it and run it through an eval statement each time a page loads with that script.

There's not really a lot more I can simplify it.  ;D
(\_/)    ~Relakuyae D'Selemae
(o.O)    
(")_(")  [Libre Office] [Chrome]

Miluette

#20
But how do I fix my lytebox .js filedsafjkg

("You don't Sen, you go back to using Lightbox")

Hmm... I looked at the lytebox file and it looks nothing like that minisized file there. At all~!

Fun fact: I take solace in how quickly both lightbox and lytebox run on my teacher/freelance employer's superpowerful G5 and macintosh laptop. :D And that my friend, for whom these programs are the slowest, is running a nearly 9-year-old computer.
And wasn't it you who told me,
"The sun would always chase the day"?