Live data from Hacker News

You might not need jQuery

youmightnotneedjquery.com

151–160 of 360 posts

Re: You might not need jQuery

#151

Earlier quoted context omitted.

Did anyone ever take you up on your hackathon idea? https://news.ycombinator.com/item?id=6645426

Nope, I didn't hear anything further on it. Still seems like an interesting event to me, though finding time might be hard. (FWIW, we do similar things within my employer all the time.)

That's too bad. But as with all things it takes time and organization in addition to some willing victims.

"Similar things" as in hackathons for fun, or hackathons structured to test out different approaches and tech?

Re: You might not need jQuery

#152
post #146

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…

> jQuery was born in 2006, when IE6 still had 70% of market share. jQuery's many layers of smooth-overs come at a very high performance cost, and it doesn't even smooth things over that well. There are still many edge cases in event handling such as triggering a click that bubbles on a detached element on Webkit that jQuery just can't do for you. Shouldn't you aim to provide the best experience for the 50-80% of user…

Nope. jQuery 2 just removed code for IE 6/7/8. Nothing was added. Code sized reduced, but almost the same performance. My benchmark shows only 10-15% improvement. That's nothing compared to using the DOM API straight up.

Re: You might not need jQuery

#153
post #133
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…

Size really is issue when dealing with mobile devices. Even from disk cache each KB increases startuptime by about 1ms (and jquery 2 is ~32kb minified, for Also, last time I checked jquery uses "querySelectorAll" for that fancy $("selector") syntax, which is slow as hell with every possible browser compared to "getElementBy*". This might not be issue with desktop machines, but you will probably lose most of your mobi…

> Also, last time I checked jquery uses "querySelectorAll" for that fancy $("selector") syntax, which is slow as hell with every possible browser compared to "getElementBy".

I seriously doubt you ever "checked". You would know that jQuery's selector engine (Sizzle) is optimized and uses getElementBy* when it can. You would also know that every browser has bugs in querySelectorAll, and jQuery's selector engine detects the bugs and routes around the browser bugs.

https://github.com/jquery/sizzle/blob/master/src/sizzle.js

Re: You might not need jQuery

#154
Well... I don't like this trend. I saw project once where main frontend guy decided to do stuff without jquery and etc. He said that vanilla.js is nice and people just don't get it. After project was done it worked only in firefox properly. Lot of time was spend after that to implement fixes for different browsers. So don't do that. Don't use vanilla js. Size of jquery is issues? Well you are trying to solve problem that does not exist.

Re: You might not need jQuery

#155
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…

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…

>> Shouldn't you aim to provide the best experience for the 50-80% of users out there who are on modern browsers instead of a mediocre experience for 100% of them?

In my experience, this decision is not as cut and dried as you make it seem. But I don't work for a startup, so take that for what it's worth.

Re: You might not need jQuery

#156
post #133
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…

Size really is issue when dealing with mobile devices. Even from disk cache each KB increases startuptime by about 1ms (and jquery 2 is ~32kb minified, for Also, last time I checked jquery uses "querySelectorAll" for that fancy $("selector") syntax, which is slow as hell with every possible browser compared to "getElementBy*". This might not be issue with desktop machines, but you will probably lose most of your mobi…

> Also, last time I checked jquery uses "querySelectorAll" for that fancy $("selector") syntax, which is slow as hell with every possible browser compared to "getElementBy*".

Not true, and has never been true; maybe you confused jQuery with Zepto? "#id" uses getElementById, ".class" uses getElementsByClassName, more complex selectors go through querySelectorAll, and custom selectors through Sizzle.

> And like others said, people mostly use like 1% of the API, which has as easy native browser support.

Hard to argue with that statistic since it's made up!

Re: You might not need jQuery

#157
post #96

Earlier quoted context omitted.

Abstractions are meant to, well, abstract an implementation. You might very well want to abstract a native operation for a bunch of different reasons. You don't need to, but maybe you should. For example, $(el).hide() is quite more readable than el.style.display = 'none' . And I'm not even talking about the other advantages.

Its el.hidden = true; in modern browsers

I'm curious - is this spec'd anywhere? I just tried it in Chrome and it works great, but I couldn't find it in any of the specs for Element or Node.

Re: You might not need jQuery

#158
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…

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

Re: You might not need jQuery

#159
post #126
post #44

Earlier quoted context omitted.

The first example alone is reason enough to use jQuery - why would I want to use four statements instead one? Why would I want to have to remember to call `send`? Why do I have to remember the last boolean parameter of `open`?

Totally valid, but just to say, jQuery's API is just as arbitrary, you just happen to know it better. If you use the native XHR a couple times, you know what open's parameters are.

It is just as arbitrary, but I feel jQuery's API is also easier to grok at a glance. Using either a couple times may instill the parameters in your memory, but what about coming back to it after six months?

Re: You might not need jQuery

#160
post #44
post #21

You had me convinced until I scrolled down to read the code examples and realized why I actually do need jQuery. If its between adding yet another collection of utility functions to approximate the functionality jQuery would give me vs just adding jQuery. I'd rather go with jQuery.

The first example alone is reason enough to use jQuery - why would I want to use four statements instead one? Why would I want to have to remember to call `send`? Why do I have to remember the last boolean parameter of `open`?

If you are writing a library, eliminating a dependency is worth much more then 4 lines of code.

But yeah, if you are just writing code for your own site then knock yourself out.

Post reply on HN