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

31–40 of 90 posts

Re: Stop Paying Your jQuery Tax

#31

Post by icebraining »

bruce511 wrote: post #26
bru wrote: post #24

Earlier quoted context omitted.

> 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...

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

All your examples can be accomplished with progressive enhancement, so what's the problem?

Re: Stop Paying Your jQuery Tax

#33

Post by dsingleton »

bruce511 wrote: post #26
bru wrote: post #24

Earlier quoted context omitted.

> 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...

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

> 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-..., 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.

Re: Stop Paying Your jQuery Tax

#34

Post by VMG »

Sodel wrote: post #28
heimidal wrote: post #16

Earlier quoted context omitted.

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.

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.

> 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

Re: Stop Paying Your jQuery Tax

#35

Post by speleding »

heimidal wrote: post #16
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.

After the initial load from the CDN the tax is 10ms (Chrome), 20ms (IE9) or 80ms (Firefox). So for modern browsers it's really a tiny amount you save. For IE7 users the tax is more than 100ms but it seems a waste of time to optimize for them given their market share.

I'd say saving 20ms is premature unless you are already doing everything else you can do.

Re: Stop Paying Your jQuery Tax

#36

Post by riffraff »

sams99 wrote: post #20
joevandyk wrote: post #14

Earlier quoted context omitted.

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

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

Re: Stop Paying Your jQuery Tax

#37

Post by 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.

Re: Stop Paying Your jQuery Tax

#38

Post by alecco »

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.

This is not premature optimization. It's about not making spaghetti code (HTML/CSS/JS in this case). Have clear guidelines from the start, that's it. No optimizations. In fact having clean code makes development easier (this applies to webdev too). If the framework you picked makes it harder, ditch the framework.

Re: Stop Paying Your jQuery Tax

#39

Post by alecco »

fourstar wrote: post #3

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?

Yes, WTF worthy.

Re: Stop Paying Your jQuery Tax

#40

Post by ehynds »

sams99 wrote: post #29
Yahivin wrote: post #21

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

well its more of a legacy problem, we are used to using it everywhere, deferring external scripts is a fairly easy exercise but those tiny snippets everywhere that have $(doStuff) are more annoying to port

If all your scripts are before the closing , the DOM will be ready by the time they execute, and you can safely ditch your legacy ready wrappers.
Post reply on HN