Live data from Hacker News

You might not need jQuery

youmightnotneedjquery.com

281–290 of 360 posts

Re: You might not need jQuery

#282
post #57

No, please no. If size is an issue for some reason or you want to have no dependencies you can use something like http://zeptojs.com/ and just embed everything in one minified file. If you do things right only the functions you are actually using will get placed in there as well. Do not reinvent the wheel to solve problems that can't be solved in much cleaner and nicer ways. Managing dependencies can be annoying, but…

I believe the point is that many libraries use about 1% of jQuery. That hardly justifies pulling in the entire thing. A personal anecdote: I recently un-jQueried a little piece of code and ended up with only a couple lines of extra code. Certain parts of jQuery are heavenly and well worth it, but really basic usage doesn't actually save that much. $("#something") instead of document.getElementById("something") is not…

Two things:

1) The minified jquery script is ~100kb, for a script that is loaded once per website that's pretty tiny. Especially when you consider the fact that the latency involved with opening the network connection to fetch the file will likely exceed the time required to pull the file down. Once you've initiated the download the difference between pulling down 20kb and 100kb isn't all that much.

2) You can use the google jquery file reference. That means a big % of your site visitors will already have the cached script in memory, and for those that don't the download will be pretty speedy given that it can be fetched from the google domain in the background (while the rest of your site assets are being fetched by the browser).

Re: You might not need jQuery

#283

Earlier quoted context omitted.

1) Zepto is POS. It offers the illusion of jQuery compatibility while delivering only maybe 80% of it. You simply cannot reverse-engineer something 100% without doing everything the original does, so you might as well use jQuery. 2) In 2014, jQuery feels like it is the wheel reinvented. I'm looking at the jQuery API modules now and here's what I consider jQuery is still useful (as in nontrivial to replicate): - AJAX…

I love the idea of removing Backbone's jQuery dependency. If I could use Backbone without jQuery, I would gladly leave jQuery behind. For my use case, Backbone would also have to lose it's jQuery dependency for RESTful model persistence, but maybe that means I should get to work on it and submit a PR :-)

Check this fork of backbone out:

https://github.com/paulmillr/exoskeleton

Re: You might not need jQuery

#284
post #57

No, please no. If size is an issue for some reason or you want to have no dependencies you can use something like http://zeptojs.com/ and just embed everything in one minified file. If you do things right only the functions you are actually using will get placed in there as well. Do not reinvent the wheel to solve problems that can't be solved in much cleaner and nicer ways. Managing dependencies can be annoying, but…

Its not about reinventing the wheel. Its about being open minded. jQuery is great, and if you are going to use zepto, you might as well use jquery 2.0

But it doesnt hurt to understand how basic stuff works under the hood of jquery and to know native dom operations. The world is not black and white. Good developers know that, they dont get stuck in discussions whatever jQuery should be used everywhere or nowhere.

Re: You might not need jQuery

#286
Apart from size and many functions that translate 1:1, where it really doesn't make sense to use Jquery (time to learn ?) there are two extra factors: 1. the extra http call to load a library, that can be optimized 2. licensing, some company cares about that and avoid the the hassle of having yet another license to understand and manage, there are costs involved

I've seen thousands of js snippets using jquery just because the developer doesn't the pure js syntax, or because he is used to start from adding jquery.

very good page indeed, thanks for spreading the knowledge.

Re: You might not need jQuery

#287
post #259

Earlier quoted context omitted.

It might be the most cached file on the internet. Pulling jQuery is hardly expensive. Especially if you're pulling it from the google cdn.

Caching or CDN does not help in squeezing out JS performance (actual JS execution and not n/w performance)

You think that a page that loads jQuery but doesn't use most of it incurs a performance penalty? I'll grant there are a few initializations and dom checks that jQuery does, but it probably blocks for all of 20ms.

Re: You might not need jQuery

#289
post #183

Earlier quoted context omitted.

Care to substantiate your benchmark where you compare jQ1, jQ2, and the native DOM API?

Here is the mentioned pull request: https://github.com/jashkenas/backbone/pull/2959 Here is his benchmark: http://jsperf.com/backbone-patch-22be8f9/2 It only compares jQuery 1 and the DOM API, no jQuery 2. TestBaseView: DOM API TestPaulView: Reduced jQuery usage TestView: jQuery

Hmm, I'm wary of a test that involves another framework to test the underlying jQ v. Native DOM performance difference. I'd be much more comfortable eliminating Backbone from the equation.

Also, this is just one test - wyuenho's claim was for jQ vs. the DOM in general, which is a much broader claim than an unknown subset of functionality.

I don't doubt that native DOM methods are faster than jQ, but I like claims to be backed up by evidence.

Re: You might not need jQuery

#290
post #57

No, please no. If size is an issue for some reason or you want to have no dependencies you can use something like http://zeptojs.com/ and just embed everything in one minified file. If you do things right only the functions you are actually using will get placed in there as well. Do not reinvent the wheel to solve problems that can't be solved in much cleaner and nicer ways. Managing dependencies can be annoying, but…

This response is quite strange in my eyes, because the website doesn't invent anything new, it actually says to use less bloat, which is always a good thing. Why use a well tested function if you can completely get rid of it?

And yes, less code, less abstraction, and less requirements are damn good reasons not to do something.

Post reply on HN