Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stop Paying Your jQuery Tax

samsaffron.com

Post reply on HN
Print view View original

11–20 of 90 posts

Re: Stop Paying Your jQuery Tax

#11

Post by [deleted] »

sams99 wrote: post #4
EGreg wrote: post #2

That is a great point! An interesting question is, why not just put ALL scripts at the end of the 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?

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 inlini…

[deleted]

Re: Stop Paying Your jQuery Tax

#14

Post by joevandyk »

sams99 wrote: post #4
EGreg wrote: post #2

That is a great point! An interesting question is, why not just put ALL scripts at the end of the 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?

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 inlini…

rails has content_for (http://api.rubyonrails.org/classes/ActionView/Helpers/Captur...) that helps with this.

Re: Stop Paying Your jQuery Tax

#15

Post by [deleted] »

pacomerh wrote: post #10
sams99 wrote: post #8

Earlier quoted context omitted.

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

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.

[deleted]

Re: Stop Paying Your jQuery Tax

#16

Post by heimidal »

VMG wrote: post #13

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.

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.

Re: Stop Paying Your jQuery Tax

#17

Post by roel_v »

VMG wrote: post #13

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.

One of the points the post makes is that by that time, making changes is a lot harder than it would have been if one had just started out with the proposed setup.

Re: Stop Paying Your jQuery Tax

#18

Post by alexchamberlain »

VMG wrote: post #13

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.

I would tend to agree with the other commenters and say, why not just put it at the bottom in the first place? That way, you design the whole site with jQuery loading last and, hence, you never have a massive headache trying to change it!

Re: Stop Paying Your jQuery Tax

#19

Post by alexchamberlain »

pacomerh wrote: post #10
sams99 wrote: post #8

Earlier quoted context omitted.

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

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.

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.

Re: Stop Paying Your jQuery Tax

#20

Post by sams99 »

joevandyk wrote: post #14
sams99 wrote: post #4

Earlier quoted context omitted.

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 inlini…

rails has content_for ( http://api.rubyonrails.org/classes/ActionView/Helpers/Captur... ) that helps with this.

true, still verbose, but more elegant than the solution in asp.net mvc
Post reply on HN