JQuery + ProBoards..?

[Malagrond]

Why don't we see any jQuery codes for ProBoards? Is there some unspoken taboo or does it really affect loading times that significantly?

I want to start making codes using jQuery, but I want to make sure it's not against some hidden rule... O.o

[Jordan]

There's no rule, but I highly discourage it unless you are doing a significant amount of coding. The reason is because most Proboard codes are too simple. Including an entire Javascript library just so you can use a JQuery selector rather than having to type a for loop with an if statement is just being lazy. There's also the fact that if people start including JQuery in their codes, it's likely that someone will be loading JQuery multiple times if it's not all from the same domain.

If you are wanting to learn then by all means go ahead, this is just my personal opinion. I'm actually using JQuery on a forum I coded for Sunjo, but it uses JQuery extensively and not just for a few lines of code. There's not really an impact on loading speeds since connections are so fast these days, it's just the inefficiency part of it (loading an entire library to do a small amount of work) that bothers me just like inefficient code bothers me although the end users will never know the difference.

[Malagrond]

I would never load jQuery to do something simple. I'm thinking about massive projects atm, like a drag+drop configurable portal page etc. =p Stuff of dreams, but achievable.

[Jordan]

Then yes, you should definitely use JQuery.

[Virgil Sovereign]

I would never load jQuery to do something simple.

It'll be cached for 99.9% of page loads anyway. Speeds up operation tremendously when you're doing bulk operations.

I usually make the cutoff at about 800 bytes saved using jQuery. 90 page loads per cache wipe and the savings "pays" for itself. Which is worst-case, since the probability of a non-PB site caching jQuery approaches 1 very quickly as one surfs the web.

Note that if you're only using jQuery for the selectors, you can fall back to the document.querySelectorAll() method, which is basically what jQuery sits on top of.

document.querySelectorAll('td[width="20%"] font'), for example, will return an array with the requested elements. You do have to stick the things into a for loop, but it cuts out some of the code bulk and speeds up DOM traversal tremendously in newer browsers.

[Malagrond]

Thanks, Virgil! I actually didn't know about querySelectorAll. That'll come in handy for many things.

[Virgil Sovereign]

Mal, be sure to visit the W3C reference page for which selectors are a part of the standard. jQuery adds some of its own proprietary selectors. Most of the major ones are included in the standard, however.

[Charles Stover]

It'll be cached for 99.9% of page loads anyway.

... Not even 99.9% of browsers have cache enabled, so I don't know where you're pulling this statistic from. IIRC, only something like 60% of browsers will be loading jQuery from cache, and the rest will have to redownload the entire library with each page load.

[Virgil Sovereign]

IIRC, only something like 60% of browsers will be loading jQuery from cache, and the rest will have to redownload the entire library with each page load.

Let's fall back to a simple analysis.

Let x% of viewers have caching disabled. We don't care about this x% because they're pinheads who have explicitly gone into their browser's advanced settings and disabled caching—the only way said disablement can occur—ignoring vocal protests from their browser that taking this action will severely degrade browser performance.

Focusing on the sane 100-x%: suppose the average user has an average of 30 site loads between cache wipes: a highly conservative estimate. Who knows what percentage of sites use jQuery, but it's fairly ubiquitous. Let's lowball it at 10% of websites using it, distribute that evenly over versions 1.4, 1.5 and 1.6,and make it a 3.3% chance a page load off a random website will cache jQuery 1.6. This is a free load as far as we're concerned. If our board happens to be site #10 visited since the last cache wipe, we're looking at a 29% chance of a free load. If our board is site #20, a ~50% chance, etc. Let our site be at index m, 0 <= m < 30 in the queue.

Suppose we don't get a free load. Alas, we hit Google's server for a 72K download. Once. The remaining n page loads to our next cache wipe or forced refresh cost us nothing. What will n reasonably be? IME it would be well into the hundreds. Even assuming a user couldn't figure out how to use private browsing and wiped their cache after every single session, they'd be looking at an n of at least 15-20.

Let's conservatively figure an n between 20 and 70.

Integrate average non-free load per page 1/30·50 (1 - 3%)^m · 1/n over 0 <= m < 30 and 20 <= n < 70 yields a 0.0157 (1.57%) probability of cache miss per page load (98.43% probability of cache hit). Bump n and m up to more reasonable values and this goes up above 99% comfortably.

1.57% cache miss rate by 72KB is 1.13 KB fractional load per page. Half the boards I look at in the support forum have 40-50 times this dumped into their headers, much of it devoted to for loops embedded three deep for DOM traversal.

Q.E.D.

[Charles Stover]

Or instead of making up statistics and pretending like basic yet irrelevant Calculus is meaningful here, let's cite statistics.

yuiblog.com/blog/2007/01/04/performance-research-part-2/

"40-60% of Yahoo!’s users have an empty cache experience and ~20% of all page views are done with an empty cache...even if your assets are optimized for maximum caching, there are a significant number of users that will always have an empty cache. This goes back to the earlier point that reducing the number of HTTP requests has the biggest impact on reducing response time. The percentage of users with an empty cache for different web pages may vary, especially for pages with a high number of active (daily) users. However, we found in our study that regardless of usage patterns, the percentage of page views with an empty cache is always ~20%."

As a tip, you don't have to forcefully alter your browser to not accept cache. Many computers, and especially third-party/non-browser programs, will do this by default. It's not even about disabling cache entirely, but limiting it in such a way that something such as the jQuery framework won't be prioritized - such as not caching just JavaScript files, having a restricted write-access, or being low on disk space for examples.

But, I mean, you can keep pulling statistics out of your, uhh, bottom, if you want. I'll stick with the scientific method. One of the four main categorizations that separate "belief" from science is personal logic. It is the reason people used to think mice came from bread (true story). But we can prove now that that is not the case. Actual studies disagree with you.

Q.E.D., I suppose.

[Virgil Sovereign]

Many computers, and especially third-party/non-browser programs, will do this by default. It's not even about disabling cache entirely, but limiting it in such a way that something such as the jQuery framework won't be prioritized - such as not caching just JavaScript files, having a restricted write-access, or being low on disk space for examples.

We don't care about third-party or non-browser programs. I don't care about people who have script caching disabled or are running on some dead-end library machine with writes disabled, or who don't have a hard drive with a few hundred megs of slack space. Maybe I didn't make this clear enough in Reply #8.

Your stats are at least five years old, possibly a lot older, from the era of daily cache wipes before private browsing, before surfing the Internet on tablets and mobile phones went from caches of a few megabytes to a few hundred. It's also looking at a site with a huge number of bots crawling over it minute by minute.

Give me statistics for even halfway modern browsers, with no-write, low-hard-disk-space, whatever... substandard configurations filtered out, with stats corrected for bots/scrapers, if you want to convince me—or anyone—that your "actual studies" have any more scientific relevance today than a straightforward numerical analysis.

I've hit maybe 80 pages on my board today alone. Zero overhead for jQuery.

Tomorrow. Another 80 pages. Zero overhead for jQuery. But maybe I'm just that one-in-a-million guy who doesn't have to recache my entire site every five page views.

Q.E.D., kind of, again

[Charles Stover]

We don't care about third-party or non-browser programs.

Umm, firstly, yes you should, and secondly, I was not talking about the kinds of programs you think I was. I was discussing such programs that alter the browser settings without direct user interaction, such as "optimizers" and disk cleaners.

Feel free to make your own statistics on the matter. I have never seen a statistic contrary based on an actual study versus speculation and personal logic. Right now, one study in my favor, personal logic/logical fallacies in your favor.

I love how the burden of proof is on me though.

Give me statistics for even halfway modern browsers, with no-write, low-hard-disk-space, whatever...

Oh, only the modern browsers that support your argument? Yeah. Forget about the modern browsers that don't, even though they make up - what was it? - 20% of every page view your website receives. They don't count in a statistic about what percent of page views have cache disabled. I believe they call that a spurious correlation with a restricted range, since you seem to love statistics.

[Virgil Sovereign]

I have never seen a statistic contrary based on an actual ancient study on a bot-ridden site versus speculation and personal logic.

Fixed.

I love how the burden of proof is on me though.

The numbers I put out are reasonable. Plug them into a simple formula, given clearly stated assumptions, they produce a defensible statistic. Your apples-and-oranges study and quips about personal logic, mice, and breadcrumbs do not an invalidation make.

Oh, only the modern browsers that support your argument? Yeah. Forget about the modern browsers that don't, even though they make up - what was it? - 20% of every page view your website receives.

Let me put it this way: with a 75 KB masthead image, 120 KB background image, 100 K worth of scripts, 60 K of bulky Proboards-esque HTML, 10 KB of CSS, 60 K for the graphic bells and whistles, 80 K for the extended smileys, and xyz KB for avatars, sig blocks, and posts in images, a viewer whose machine has third-party software running rampant liquidating their browser cache has bigger problems to worry about than recaching jQuery.

Do I advocate using jQuery for little three-line scripts? No.

Is the average viewer going to have to recache jQuery once every five page loads? No. And for viewers where it does, somehow I imagine they're very, very used to long waits by now.

Thanks for the debate, sir.

[Charles Stover]

Oct 13, 2011 16:47:06 GMT -8 Virgil Sovereign said:

Plug them into a simple formula, given clearly stated assumptions, they produce a defensible statistic.

Case in point.

Your apples-and-oranges study and quips about personal logic, mice, and breadcrumbs do not an invalidation make.

Appes-and-oranges? You mean my statistics about how many users have cache enabled has nothing to do with how many users have cache enabled? My mistake! I could have sworn it had something to do with how many users have cache enabled.

Thanks for the debate, sir.

It isn't a debate when you are making things up, and I am citing research. I mean, you can call it that, but that doesn't make it so.

[Virgil Sovereign]

Your statistics are badly outdated and were collected on a site with a heavily biased source of traffic. Both of these deficiencies are duly criticized in the comments section of your vaunted report.

Since you're unwilling to acknowledge this fact, and since you seem incapable of recognizing the difference between a mathematical model with conservative, challengeable assumptions and "making things up", I bid thee adieu and happy programming your jQuery-free pages.

As a parting gift, might I point out that your avatar is 594 KB in size: more than eightfold as burdensome to the poor cacheless masses than the 72 KB library you're decrying.