Live data from Hacker News

You might not need jQuery

youmightnotneedjquery.com

291–300 of 360 posts

Re: You might not need jQuery

#291
post #195

>post-IE8, browsers are pretty easy to deal with on their own. False: - CSS browser prefixes are automatically inserted by jQuery - Many jQuery selectors don't exist in the CSS selector specification - Looks really really ugly and that makes it hard to read for you and other coders. var pairs = $(".form").not(".old").serialize(); /* without jQuery */ var pairs = [].slice.call(document.querySelectorAll(".form")); var…

> Looks really really ugly and that makes it hard to read for you and other coders.

This point might have been better made if you hadn't intentionally structured it to be as unreadable as possible, and also shoved in a few lines of comments to pad it out and make it look bigger than it needs to be. Not a very honest example at all, considering native JS can be as readable as you want to make it.

> So be kind with your co-workers, use jQuery. Even my 5 year old android can run jQuery without freezing the built-in browser.

My co-workers can read and write native JS with or without jQuery as it is, why is it being _kind_ to avoid writing in the style of the native language?

Re: You might not need jQuery

#292
post #289

Earlier quoted context omitted.

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…

The evidence is in the form of an experiment repeatable from your browser's dev console. Play with it.

Re: You might not need jQuery

#293

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 :-)

You can just replace Backbone.ajax yourself. There are many $.ajax drop in replacements out there that you can use.

Re: You might not need jQuery

#294
post #242

Earlier quoted context omitted.

jQuery is a library where rails is a framework. but I will agree, a lot of developers are likely to use it as a crutch in lieu of fully understanding cost vs benefit in your app. if this is the case, then you very might well need jquery.

node express is the rails ;)

Node express is Sinatra. There is nothing even close to Rails in the JS world, Meteor is getting closer every day, though.

Re: You might not need jQuery

#295
post #259

Earlier quoted context omitted.

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.

...which is significant.

Re: You might not need jQuery

#296
You might not need [Insert Library Here].

Although this is true, you don't really need any library. The problem comes when you start to need that library. You make a decision to not use it at the start of the project and then the dependency of lower level JS functions grow and it turns out you do need it. What do you do then? Go and get a copy of jQuery and start to rewrite all your functions?

Hindsight is the problem here, I'd rather make the decision to use the (relatively) low sized jQuery library and not have to worry about how the project grows.

As the old saying goes, "It's better to have it and not need it, than need it and not have it".

Re: You might not need jQuery

#297
post #167

Earlier quoted context omitted.

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…

> $("#something") instead of document.getElementById("something") or even just document.querySelectorAll("#something")

You lose some browser compatibility with qSA, whereas gEBId works everywhere. You need IE8+ for qSA, and you need to ensure the page isn't in quirks mode. If you're OK with that then you can also do: var $ = document.querySelectorAll.

Probably best to do this within a closure so that you're not hijacking any jQuery instances that may be on the page.

Re: You might not need jQuery

#298
It's plain stupid. Your code may work for IE8+, but there is no warranty that M$ will not do something stupid in IE16, and your code will be broken. jQuery is unified bridge between all major browsers, so you don't need to support all of them by yourself. "Support for all" is why we shift from compiled to VM languages, even though at the begin they were slower.

Re: You might not need jQuery

#300

I implore all developers to learn native Javascript methods, because I strongly believe jQuery has created a generation of developers who know the library but not the language. You'd be surprised how many developers I've come across think iterating over an object or array requires Javascript and how many people don't know how to write a simple for or while loop in Javascript. jQuery is a fantastic library, but it is…

I like each better than for primarily for readability. However I usually use the each from underscore, and I'm not sure how well that one performs.

The performance of _.each should be very close to that of the native Array#forEach because it delegates to the native method when it's available: https://github.com/jashkenas/underscore/blob/6db5b93eac3eacd...
Post reply on HN