You might not need jQuery • Hacker News Board

Re: You might not need jQuery

#211

Post by rwaldron » Thu, Jan 30, 2014, 11:15 PM UTC

nilsbunger wrote: post #131

efuquen wrote: 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…

It's better if libraries don't just assume jQuery is everywhere, because I suspect those days are ending. Apps built on newer front-end frameworks like Angular and React might not need it, for example. As a library author it's becoming more important to think case-by-case -- use raw JS if you just have some simple selections or XHRs, or use Zepto/etc if that covers you, and only depend on jQuery if you really need it…

If you like spirit, you'll love this: https://gist.github.com/rwaldron/8720084#file-reasons-md

Re: You might not need jQuery

#212

Post by nostrademons » Thu, Jan 30, 2014, 11:19 PM UTC

latj wrote: post #116

__david__ wrote: post #102

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…

I agree with the overall message- you should be thoughtful with all your dependencies. You should only add complexity when it makes sense. However, the author goes beyond just selector vs. getElementById(). Does the way the author uses XMLHttpRequest work in other browsers the way it works in IE? I honestly dont even remember anymore. How about the code for fade? I never even knew the details of this feature. And I'm…

IE has been basically standards-compliant for XHR since IE9, and possibly before:

http://www.w3.org/TR/XMLHttpRequest/#interface-xmlhttpreques...

http://msdn.microsoft.com/en-us/library/ie/ms535874(v=vs.85)...

Re: You might not need jQuery

#213

Post by elclanrs » Thu, Jan 30, 2014, 11:26 PM UTC

"You might not need jQuery" -- But you have to cope with ugly syntax, browser compatibility hacks, and disconnected pieces of code. By the time you re-factor all of this, make it user friendly and lower the cognitive load, you're already re-inventing the wheel by building your own jQuery replacement, with the parts that you need.

The beauty of jQuery is working with the DOM as collections. I don't see how it's better to have all these helpers like `nextSibling`, `matches`, or `filter` thrown in the global scope or having to remember is this a real array? jQuery already built solutions for these common problems and exposes a nice API.

If all I need is querying the DOM and I don't have to support IE8 then I may consider using vanilla JavaScript, or building my own simple jQuery-esque library. But you'd start with some structure, and expose your own API. I re-invented the DOM wheel many times, and from my experience, although the code is smaller, I end up going back to jQuery because it covers some edge case or provides something else I need, like AJAX, or nice events, etc.

But building your own DOM library is a good educational challenge. Querying the DOM is all about collections, and if you don't need IE8 then you can use all the ES5 arrays methods, like map and filter. It all boils down to four functions to work with collections: toArray, unique, flatten and query. And four functions to work with the DOM: compose, join, dot, loop. See here for an example http://jsbin.com/EgIkega/1/edit. The article is more about techniques to build your own jQuery-like library; I wouldn't use "el.nextElementSibling || nextElementSibling(el)" when I can use "$(el).next()". C'mon!

Conclusion, you are probably going to use jQuery anyway.

Re: You might not need jQuery

#214

Post by voltagex_ » Thu, Jan 30, 2014, 11:37 PM UTC

nostrademons wrote: post #212

latj wrote: post #116

Earlier quoted context omitted.

I agree with the overall message- you should be thoughtful with all your dependencies. You should only add complexity when it makes sense. However, the author goes beyond just selector vs. getElementById(). Does the way the author uses XMLHttpRequest work in other browsers the way it works in IE? I honestly dont even remember anymore. How about the code for fade? I never even knew the details of this feature. And I'm…

IE has been basically standards-compliant for XHR since IE9, and possibly before: http://www.w3.org/TR/XMLHttpRequest/#interface-xmlhttpreques... http://msdn.microsoft.com/en-us/library/ie/ms535874(v=vs.85)...

For IE9, don't you need IE-specific code for cross domain requests?

Re: You might not need jQuery

#215

Post by dmethvin » Thu, Jan 30, 2014, 11:38 PM UTC

underwater wrote: post #197

bitwarrior wrote: post #3

I understand the desire for people to make pages like this (this isn't the first), but the examples are not completely honest with themselves, in my opinion. One of the biggest benefits jQuery introduces is the concept of treating single selections and multiple selections identically. While using jQuery, I can emit a $(".class").hide() call, which will apply to all elements with the matching class. Simple and elegant…

In practice a better approach would be to build up a micro-library of functions to just implement the small subset of features you do need. // Using underscore/lo-dash and ES6. _.forEach(document.querySelectorAll('.class'), elem => elem.hidden = true); // Building reusable utility functions function forEachSelector(sel, cb) { _.forEach(document.querySelectorAll(sel), cb); } function hideElement(el) { el.hidden = true…

> The problem with jQuery is that it's an all-or-nothing approach. The way it wraps native DOM nodes means it keeps trying to pull you back to using its inbuilt utility methods.

Not true at all. You can do a custom build and leave out things you don't need. You can even leave out stuff you DO need and replace with your own simpler shim. See the README file.

Re: You might not need jQuery

#216

Post by Sssnake » Thu, Jan 30, 2014, 11:45 PM UTC

smrtinsert wrote: post #191

wyuenho wrote: post #136

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 is really just an abstraction for dom, it is not an api for application building. When I have to use the dom, I definitely turn to it. I'm not sure why people object to having additional helper functions in jquery for a measely 100k or so. You don't have to use plugins you know, its not a law.

Because 100k is not measly, it is huge. And jquery is hundreds of times slower than the perfectly fine native methods.

Re: You might not need jQuery

#217

Post by WickyNilliams » Thu, Jan 30, 2014, 11:48 PM UTC

efuquen wrote: 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…

You do realise zepto works in IE10+ only, and even then you need an additional module for support. I wouldn't say it's worthwhile. It is not a viable alternative.

I'm working on a widget that other people will embed on their page. I cannot make assumptions about jQuery being available and I cannot afford to add jQuery as a dependency. Assuming the widget was valuable to you, would you want to add my widget to your page if it included 94kb (jQuery 1.10.2 minified) of JS before my code was even added on top? If you cared about performance, it's highly unlikely you would.

So for that reason I've been working with plain JS for months now. We have browser support back to IE9 (maybe even 8), and our entire codebase is around 25kb minified (gzipped But you know what? Most of the time it isn't even a problem. And with modern tools [1][2] and a good test suite, it's not difficult testing across multiple browsers to quickly find issues.

Before even working on this project I decided to go on a self-administered "jQuery diet". I haven't used jQuery in any personal projects [3][4] for at least a year and it's great. It took a little adjusting, but not much. If anything it was a little shocking. I thought I was a good JS dev, but it really opened my eyes to how little I knew about the DOM and other native browser APIs and, honestly, I felt a little ashamed.

Conclusion: sometimes going it alone is the right decision. jQuery is absolutely the right choice in some environments, but it doesn't make it the right choice absolutely

[0] http://james.padolsey.com/jquery/

[1] http://karma-runner.github.io

[2] http://vanamco.com/ghostlab/

[3] https://github.com/WickyNilliams/headroom.js

[4] https://github.com/WickyNilliams/enquire.js

Re: You might not need jQuery

#218

Post by cwp » Thu, Jan 30, 2014, 11:49 PM UTC

iSnow wrote: post #163

nilsbunger wrote: post #131

Earlier quoted context omitted.

It's better if libraries don't just assume jQuery is everywhere, because I suspect those days are ending. Apps built on newer front-end frameworks like Angular and React might not need it, for example. As a library author it's becoming more important to think case-by-case -- use raw JS if you just have some simple selections or XHRs, or use Zepto/etc if that covers you, and only depend on jQuery if you really need it…

> Apps built on newer front-end frameworks like Angular and React might not need it, for example. Well, Angular has jQuery (lite) built in.

It has a jQuery-mostly-compatible node wrapper built-in, which is why it doesn't need jQuery.

Re: You might not need jQuery

#219

Post by nostrademons » Thu, Jan 30, 2014, 11:59 PM UTC

voltagex_ wrote: post #214

nostrademons wrote: post #212

Earlier quoted context omitted.

IE has been basically standards-compliant for XHR since IE9, and possibly before: http://www.w3.org/TR/XMLHttpRequest/#interface-xmlhttpreques... http://msdn.microsoft.com/en-us/library/ie/ms535874(v=vs.85)...

For IE9, don't you need IE-specific code for cross domain requests?

Yeah, you need XDomainRequest for CORS requests in IE8 and 9. IE10 is fully standards-compliant.

http://blogs.msdn.com/b/ieinternals/archive/2010/05/13/xdoma...

Re: You might not need jQuery

#220

Post by underwater » Fri, Jan 31, 2014, 12:00 AM UTC

dmethvin wrote: post #215

underwater wrote: post #197

Earlier quoted context omitted.

In practice a better approach would be to build up a micro-library of functions to just implement the small subset of features you do need. // Using underscore/lo-dash and ES6. _.forEach(document.querySelectorAll('.class'), elem => elem.hidden = true); // Building reusable utility functions function forEachSelector(sel, cb) { _.forEach(document.querySelectorAll(sel), cb); } function hideElement(el) { el.hidden = true…

> The problem with jQuery is that it's an all-or-nothing approach. The way it wraps native DOM nodes means it keeps trying to pull you back to using its inbuilt utility methods. Not true at all. You can do a custom build and leave out things you don't need. You can even leave out stuff you DO need and replace with your own simpler shim. See the README file.

Sure, it's technically possible. But not common from the projects I've seen.

The APIs seem to be designed with the assumption that all your code will be using jQuery. For example converting a wrapped node to a native DOM node requires an extra call that, in my opinion, is ugly: $('.something').get(0); and could be considered to be an anti-pattern.

I don't think this is a bad thing. jQuery does a good job at providing a DSL that replaces native DOM access. But if you want a library instead of a framework its strongly opinionated style can be off-putting.