Live data from Hacker News

Stop Paying Your jQuery Tax

samsaffron.com

21–30 of 90 posts

Re: Stop Paying Your jQuery Tax

#23
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).

Re: Stop Paying Your jQuery Tax

#24

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?

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

Re: Stop Paying Your jQuery Tax

#26
post #24

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?

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

Re: Stop Paying Your jQuery Tax

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

Re: Stop Paying Your jQuery Tax

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

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.

Re: Stop Paying Your jQuery Tax

#29
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

Re: Stop Paying Your jQuery Tax

#30

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.

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.
Post reply on HN