Live data from Hacker News

You might not need jQuery

youmightnotneedjquery.com

191–200 of 360 posts

Re: You might not need jQuery

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

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.

Re: You might not need jQuery

#192
post #53

The Bad: The premise of the examples list seems a bit disingenuous. Very few of these things take into account the full convenience of jQuery. It's much more than saving a couple lines of code or knowing the native way to accomplish the most basic version of a task. jQuery's real benefit is preserving simplicity as your needs grow more complex. Right off the bat I feel like the getJSON[1] example is a bit simplistic.…

That's a great point - this is really awesome as a "learn the essence of what jQuery is doing for you!" and a little annoying as a "you don't need jQuery!".

I took the tone as being directed to people publishing plugins that use jQuery for 1% of its functionality, forcing people not using jQuery to either not use that plugin, rewrite the plugin or include jQuery.

Edit: it actually literally says it's for library developers.

Re: You might not need jQuery

#193
If you only care about IE such as inside corporate intranet, and never had to worry about cross browser compatibility, knock yourself out. On the other hand, the scalablity and performance on the intranet usually are not a high priority. Why not just learn jQuery rather than tight yourself up to vender specific, proprietary technology?

Re: You might not need jQuery

#194

I would like to add a thought about the dispute about the need of using jQuery. Let's say we know a consultant, let's call him Bob, who works on client projects. He needs to implement new features fast, and does not want to worry about low level stuff. Once he's done with a project, he moves on to another. Then, we meet a JS-framework developer, let's call her Alice. She has to weight every line of code she writes be…

Right, and this webpage is explicitly targeting Alice.

Re: You might not need jQuery

#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 data = forms.filter(function(ele){
      return /\bold\b/.test(ele.className);
    }).map(function(ele){ 
      var form = ele.querySelectorAll("select, input, textarea");
      var pairs = [].slice.call(form).map(function(subele){
        // maybe if subele.type === "select"
        // but I got tired of writing this example
        // but that's the point anyway
        return subele.name + ":" + (subele.value || "") + ";";
      });
      return pairs

    }).join("").replace(/;$/, "");
So be kind with your co-workers, use jQuery. Even my 5 year old android can run jQuery without freezing the built-in browser.

Re: You might not need jQuery

#196
post #106

Earlier quoted context omitted.

Right, because why have "var x = 2+2" when you have perfectly maintainable assembly!

I think the point is that "$.contains(el, child)" is not a useful abstraction of "el.contains(child)".

You wont have $.contains, instead $(el).children(child) returns a chainable filtered list of the first level of child nodes, or $(el).find(child) will go down recursively.

jQuery rarely dumbly duplicates some native functionnality, as for the example above, most of the time it will diverge in meaningful ways.

Re: You might not need jQuery

#197

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; }
  forEachSelector('.class', hideElement);
Of course, there is the danger of ending up with homegrown jQuery that is less well tested and less well thought out. Perhaps there is a place for a small JS library that works with native DOM elements, in the same non-invasive way lo-dash and underscore work with data structures.

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.

Re: You might not need jQuery

#198

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

> I love the idea of removing Backbone's jQuery dependency. If I could use Backbone without jQuery

You can the only hard dependency of backbone is underscore.

Re: You might not need jQuery

#199
It isn't that these rebuttals are unsound, it's the sheer volume of them. A tidal wave of irritation and defensiveness always seems to accompany posts that dare question jQuery.

Unless the headline was changed by the mods, there's no hyperbole or sensationalism here. You might not need jQuery. Obviously. But many of these reactions don't belong here, they belong in a post titled You don't need jQuery, which would of course deserve to be downvoted to hell.

Obviously you don't need to pull in jQuery for every little twenty-line gizmo you publish on github. But don't you dare brag about this or you'll offend the sensibilities of those who've invested all their mental energy into learning jQuery and therefore remained ignorant of how browsers actually work.

Post reply on HN