
Stop Paying Your jQuery Tax - sams99
http://samsaffron.com/archive/2012/02/17/stop-paying-your-jquery-tax
======
alecco
Please go check out StackOverflow's source code before bandwagoning on this
topic.

This is shifting blame to the tools. The problem lies on StackOverflow's
lacking design and not in jQuery.

Pushing jQuery to the bottom of the page is trivial if you do proper HTML
architecture. Pages should have only HTML. JS files only JS. JS files
referenced at the very bottom of the body. Very simple. (if your asp/c#/*
framework doesn't make it easy, blame the framework and not jQuery)

Inlining JS and even having JS code in the title attributes is ridiculous. Fix
your HTML and only then you get the right to say anything. Another telling gem
is StackOverflow page doesn't even have a proper encoding declaration.

You don't need to use jQuery for everything. This is very typical of
developers coming from backend who don't take web development seriously. Use
CSS as much as possible.

Another misplaced attack is refresh, with proper cache headers it should not
take that long. If some browsers are slow and don't keep a pre-parsed cache,
blame the browser vendor and not jQuery.

jQuery taking 80ms on mobiles is quite OK. If you really care about mobile
make a page optimized for mobile and minimize JS rendering and styling.

I absolutely love StackOverflow and it's one of the best things to happen to
programmers in the last few years. But this self-righteousness attack on a
very important tool is very misleading and ungrateful.

Edit: the proposed "solution" of catching $.ready and later calling those is
insane.

~~~
sams99
Let's be clear ... I am not attacking jQuery here, just saying it is misuse to
chuck it in the header and offering a practical mechanism to get out of a mess
you create. I explain the cost of placing it in the header. I am not perfect,
I make mistakes daily, I try to learn.

~~~
alecco
"Stop Paying Your jQuery Tax", that's an attention grabbing title with an
attack on a free open-source project. It took you at least 20m to write that
post, probably over an hour. You can't just say "oops".

~~~
bmelton
1) If it took him a month to write that article, he could still say 'oops'.
He's entitled to err.

2) It seems like you're the only one interpreting his post as an attack on
jQuery. It isn't. You said in another thread that English isn't your first
language. I'd suggest you temper your accusations in light of that knowledge.

3) Even if he were bashing jQuery, and even though it is a good and widely
used framework, that's his right to do. Yes, it is your right to cry foul, as
it is my right to attempt to set you straight.

Simply put, I think you're off the mark here. Your attack on him are more
damning than his supposed attack on jQuery, and strikes me as defensive.

In with the good air, out with the bad.

~~~
sequoia
>You said in another thread that English isn't your first language. I'd
suggest you temper your accusations in light of that knowledge.

As a native English speaker, I would like to point out that alecco is
_correct_ when he interprets the article as slinging mud at jQuery; there is
nothing wrong with his/her English vis-a-vis his interpretation of this
article's title. The fact that you would tell him/her to pipe down because
he's not a native speaker is disgusting and xenophobic. As a side note, your
comment about alecco being "the only one" interpreting the post as attack on
jQuery is completely false. S/he's dead on about it being what I call a DCA,
or "deliberately contentious assertion", designed to win more page views than
an article merits.

Honestly, if alecco were expressing an opinion with which you agreed, would
you _still_ be saying s/he 'just doesn't understand the article due to poor
language skills'? Or do you reserve this treatment for those foreigners who
dare disagree with you? The fact that you dug thru alecco's comments in other
threads to find this ad-hominem rock to sling... the reason you had to mention
his/her non-native speaking comment from another thread is because alecco's
English is good enough that _you wouldn't know s/he's a non-native speaker
from this thread_.

Non-English natives are allowed to have opinions at variance with your own,
sir or madam. Leave

~~~
bmelton
It wasn't meant to be an attack. The point was that I felt Alecco was being
overly harsh, if not in this particular post, in others on that thread.

I didn't dig through their history for a rock to sling, but they mentioned it
elsewhere in the same thread.

I don't have a dog in this fight regarding the article. It isn't an opinion I
particularly agree or disagree with. I have no affiliation to the author, to
the blog, or to any of the individuals I've remarked in this thread. I also
like jQuery, so if anything, I'm arguing from the same bias as Alecco, in that
I think it is a very high quality open source implementation of an amazing JS
framework. I even read through the article multiple times to seek out the
jQuery bashing Alecco alleges. I can't find it.

At first, I thought it was a popular opinion, until I realized that each of
the remarks I believed to be overly negative were from the same person.

There wasn't any malice intended except to say "Hey, lighten up. People are
allowed to make mistakes." One of the tenets I believe is core to Hacker News
working is the assumption of good faith. I don't believe that Alecco was
deliberately trying to malign the author, but the statements certainly come
off as though they did not assume good faith.

I have tried to do so here, as in my original comment, but I do not believe
you have extended me the same courtesy.

In the interest of promoting civility, I'll disregard your final remark,
except to say that English is also not my first language.

~~~
sequoia
I apologize for the last word of my reply. I'm not sure why it was truncated,
it just said "Leave".

------
EGreg
That is a great point!

An interesting question is, why not just put ALL scripts at the end of the
<body> tag, after the HTML of the page has loaded and the CSS probably did as
well?

The only thing I can think of is if you have code ON the page which uses these
scripts. But why not just put that code at the end of the page, too?

~~~
sams99
The main reason this happens is that most MVC platforms generate pages
piecemeal, say for example you are generating a 'product' page:

It has a 'template' that contains your header,footer and scripts that everyone
relies on.

Then the product piece may also need a script or 2 and finally it may need to
add some dynamic love to the page like say: $(myMagicHelper(779,'magic');), in
general people are used to just inlining these kind of mini-scripts close to
the bit that generates the product html. It can be migrated to a system that
defer generates it in the footer, but usually would involve a larger amount of
change (at least on projects I worked on). I guess this trick saves you a bit
of time migrating some inline scripts to the bottom.

~~~
joevandyk
rails has content_for
([http://api.rubyonrails.org/classes/ActionView/Helpers/Captur...](http://api.rubyonrails.org/classes/ActionView/Helpers/CaptureHelper.html#method-
i-content_for)) that helps with this.

~~~
sams99
true, still verbose, but more elegant than the solution in asp.net mvc

~~~
riffraff
out of sheer curiosity, what is the asp.net mvc solution?

~~~
untog
It doesn't really have one. Annoying, because it's 90% of the way there- views
can insert code into specific "sections" of the template, but _sub-views_
can't.

If they just enabled that then you could make a "JS" section just before
</body> and have all your JS inserted there.

------
Yahivin
Why do you still need a document ready function if all your scripts are
loading after the html anyway?

~~~
beaumartinez
The DOM will have been parsed if your scripts are at the end—but external
components (links, imgs) may not have loaded yet.

~~~
ehynds
The same is true whether or not you use a document.ready statement; you're
thinking of window.onready, which fires once all images have been downloaded.

~~~
beaumartinez
You are correct! Thanks. Been spending too long with document.readyState.

------
pragmatic
This linked article is good: the Performance Golden Rule
[http://www.stevesouders.com/blog/2012/02/10/the-
performance-...](http://www.stevesouders.com/blog/2012/02/10/the-performance-
golden-rule/)

(submitted days ago but got no traction)

For years we have been told that we will have to wait on the database so it
doesn't matter how fast your implementation language is...

Well it's half true, depending on what you consider your implementation
language: server side or client side.

Front end performance matters just as much (or by this article) more than
"backend."

~~~
pragmatic
How does this ([http://37signals.com/svn/posts/3112-how-basecamp-next-got-
to...](http://37signals.com/svn/posts/3112-how-basecamp-next-got-to-be-so-
damn-fast-without-using-much-client-side-ui)) get to be number one, while this
[http://www.stevesouders.com/blog/2012/02/10/the-
performance-...](http://www.stevesouders.com/blog/2012/02/10/the-performance-
golden-rule/) goes nowhere?

Are we upvoting simply by name recognition?

<http://stevesouders.com/about.php>

He only wrote the book on high performance web sites...

[http://www.amazon.com/High-Performance-Web-Sites-
Essential/d...](http://www.amazon.com/High-Performance-Web-Sites-
Essential/dp/0596529309)

~~~
joshuacc
It's partly name recognition and partly novelty. The 37signals approach is
unusual, while most competent front-end developers are already aware of the
principles in Souders' post.

------
fourstar
So is the article saying you are basically putting an alias for jQuery's `$`
in the header and so if you _need_ to put `$(function() {});` or
`$(document).ready(function(){})` elsewhere in your page you rely on that
alias and then once jQuery has loaded, map the `$` to it?

~~~
sams99
That is one technique you can use to assist you in pushing your jQuery include
to the bottom, the others are having a smart script registration piece that
takes care of it for you or running code that rewrites the html like blaze.io
does

~~~
alecco
Complex solution to simple problems.

------
chokma
The Grails framework has a plugin to organize resources like JavaScript -
<http://grails-plugins.github.com/grails-resources> (scripts will by default
be added to the end of the page and even if your page consists of several
template files which depend on jQuery etc, they will only be included once).

------
sequoia
I'm very confused... why aren't the scripts in the footer? Because of inline
javascript? What problem is this solving? What does this have to do with
jQuery in particular? I'm very confused...

------
jackmoore
This is clever. However, it depends on scripts using the shorthand notation
for jQuery's ready method. Maybe it would be better form to use something
explicit instead rather than doubling up $ operator.

~~~
sams99
true, we are used to using the shorthand notation in fact at SO we use a
special internal variant called StackExchange.ready for a similar purpose, you
could get $(document).ready remapped with a similar trick if you wanted, or
you could simply push the inlines to the bottom as well.

~~~
collypops
Here's my attempt at the similar trick, covering all 4 possible ways to bind
to DOM ready using jQuery: [http://blog.colin-gourlay.com/blog/2012/02/safely-
using-read...](http://blog.colin-gourlay.com/blog/2012/02/safely-using-ready-
before-including-jquery/)

------
VMG
Nah, I'm going to pay the tax rather than optimize prematurely.

But I'll add that to my bag of tricks when I start optimizing.

~~~
heimidal
I'm not sure this qualifies as premature optimization. Allowing jQuery to
block page load incurs a bit of load time where the user has to sit around
waiting. Anything that can be done to minimize user frustration (and maximize
user experience) is probably worth doing when it's so simple.

~~~
Sodel
Agreed. Premature optimization is about "maybe", and feared performance loss.

Responsiveness matters to users; to them, speed is a feature, insofar as they
can perceive it. The "JQuery tax" absolutely is a real, and user-perceptible
issue.

"Avoiding premature optimization" can sometimes make it hard to undo poor
design choices made early on that could have been avoided.

~~~
VMG
> Responsiveness matters to users; to them, speed is a feature, insofar as
> they can perceive it. The "JQuery tax" absolutely is a real, and user-
> perceptible issue.

I think the evil of premature optimization is attacking the wrong target
first. 80ms isn't a small amount, but moving script tags around could have
more potential side effects than say using proper caching, minifying etc

~~~
Sodel
Good point. This hadn't even occurred to me.

------
whichdan
"Chrome seems to be able to do it under 10ms, IE9 and Opera at around 20ms and
Firefox at 80ms (though I probably have a plugin that is causing that pain).
IE7 at over 100ms.

On mobile the pain is extreme, for example: on my iPhone 4S this can take
about 80ms."

I'd be very interested in seeing some more concrete benchmarks for this.

~~~
ericflo
Here's an interesting chart I came across recently:
[https://docs.google.com/spreadsheet/ccc?key=0Aq_a4WNAMuCEdDd...](https://docs.google.com/spreadsheet/ccc?key=0Aq_a4WNAMuCEdDdjSlhyWXJaTkQ0TVJFc1k1RzlTTlE#gid=0)
(via [http://blog.pamelafox.org/2011/11/porting-from-jquery-to-
zep...](http://blog.pamelafox.org/2011/11/porting-from-jquery-to-zepto.html))

------
Roboprog
While I personally would prefer to put most JavaScript in an separate file,
rather than sprinkled inline, it happens. So, why doesn't the browser handle
this problem for us???

Why not have the browser drop all of the js script fragments and references
into a queue, then run them later? Why make people reshuffle the stuff that
they have working?

Hell, for that matter, I'm a bit puzzled why js even runs before the document
is ready anyway. Is there some user in a hurry to get his alerts and popup
windows?

------
firefoxman1
How does Pushing jQuery to the footer solve the "constant tax"?

~~~
sams99
you get to see your content on the page rendered before jQuery is parsed and
compiled. There are other approaches like asyc or defer that are preferred but
harder to implement and you could go for a leaner jQuery like say jQuip

~~~
pacomerh
What you just said is this article summed up I think. Getting to read the
content before the jQuery is parsed is the key and solves the cache issues.
The other part where you collect all the jQuery functionality and you push it
to the array/.ready loader at once, forces you to be organized.

~~~
alexchamberlain
I hope it also forces people to use CSS where possible (which is more
efficient for certain animations etc), and only use jQuery where necessary.

------
tghw
When we were working on WebPutty.net, we found headjs (<http://headjs.com/>)
to be very useful for ensuring all other script calls are run outside of the
<head> tag. The full library runs 2.7k gzipped, while just the loader is 1.3k
and is the only javascript file you need to block on. (The full script
includes a modernizer library in addition to the script loading
functionality.)

------
bmuon
I think they're still missing the point. The idea is to stop using jQuery like
that. Think of it as another required module of your application and move
everything to requireJS. You'll gain speed and peace of mind once you learn to
modularize all your JavaScript code.

~~~
alecco
That's yet another dependency. Not my cup of tea. I'd rather wait for the
upcoming light/modularized jQuery rewrite.

------
jebblue
I think the world should just go back to rich client apps and forego the web
browser development tax in general. At least consider something like GWT which
let's developer code the server and client in Java and Google worries about
how to optimize JavaScript.

------
radicalbyte
If you're looking into these kinds of optimilisations then why not sidestep
the problem by moving to a single page application model?

Or is it still acceptable to support clients who do not enable javascript?

~~~
bru
> Or is it still acceptable to support clients who do not enable javascript?

I deeply believe that yes, it is. Making Javascript mandatory on websites
where it should only enhance the user experience still seems to me like a very
bad practice, and I hope it will stay so.

I even want to say that, if your website if correctly designed, offering its
content in a Javascript-less way should not be that hard...

~~~
bruce511
I think it's less an absolute, and a lot more "it depends".

If you're building a 3 page website for a mom and pop operation, then ok, have
a JavaScript free site. If you're happy with the sites from the 1990's, then
no JavaScript is just fine.

It's possible in some cases to use progressive enhancement, so that those
without JavaScript get a working, albeit really poor, experience. How much
effort you put into creating that option, and maintaining it, depends on your
cost-benefit analysis.

If however you want to build a site that the user interacts with, then
JavaScript makes such an important difference that not to use JavaScript
results in a crappy user experience.

I want every bit of data entry to be validated when it's entered, either on
the client or the server, not wait for the user to click "submit".

I want forms to morph as the user enters data. Shipping address same as
Billing address? Great, user clicks "Same As Billing" and all the Shipping
Address fields vanish.

Shipping out-of-country? Ok, shippers that service the US only are removed
from the Shipping options drop-down.

Don't get me started on a zillion user-interface improvements, like data-
lookups, sliders, menus, autocomplete etc which enhance the user experience
and make people want to use my app, and come back to it.

There are only 2 groups who don't have JavaScript support. Those using truly
ancient browsers, and those who've actively turned it off. I honestly don't
see the point of degrading the experience for everyone based one these two
demographics. It's unlikely that either group will contribute significantly to
my income, certainly not in proportion to what it costs to support them.

We make this trade-off all the time. If I write a desktop Windows program, I'm
ignoring the 10-15% of folk not on Windows. If I write an iOS app I'm ignoring
the folks with Android et al.

So - it depends.

~~~
dsingleton
> There are only 2 groups who don't have JavaScript support

That's not entirely accurate. While those are two of the most common cases
there are plenty of other contributing factors
([http://developer.yahoo.com/blogs/ydn/posts/2010/10/how-
many-...](http://developer.yahoo.com/blogs/ydn/posts/2010/10/how-many-users-
have-javascript-disabled/#comment-17071), this comment makes a good case).
Errors stemming from network congestion, developer error and even CDNs failing
- only a few weeks ago the google hosted version of jquery (iirc) failed
leaving lots of sites with broken JS and an effective no-JS experience.

Personally I think building a site that works well without JS and then
progressively enhancing it is the Right Thing to do. It means you're building
a robust site for the real web and the multitude of clients and conditions
that comes with. In your example I wouldn't want JS failing to prevent a
checkout process, it should be robust and continue working, albeit less
smoothly.

> honestly don't see the point of degrading the experience for everyone based
> one these two demographics

IMO If you're doing progressive enhancement well then this is not the case. I
don't think the iOS/Android comparison is accurate either. The web is much
more varied, the differences less well defined.

You're right, it does depend on what you're building and for who. But I don't
think the general case is as binary as you've make out.

------
ricardobeat
Stop paying your .NET tax and start using proper javascript.

