Hacker News Reader

Comment by ceronman | Hacker News Reader

Yes, you can re-implement jQuery in 10 lines of code... if you only support 0.1% of the functionality of jQuery.

jQuery was a game changer for web client side development. Thousands of work hours have been spent on it. It had a specially important role of dealing with all the inconsistencies between browsers. If you don't use all the features, nowadays you can just create a custom build with the stuff you want.

If you don't need jQuery, maybe because you only care about modern browsers, or you use another library or you don't mind a bit of extra boilerplate for DOM manipulation, that's perfectly fine. But these kind of posts seem like mockery on the developers of a library that has provided extreme value for thousands for developers over many years.

View on HN

You are arguing against a strawman - no one is claiming otherwise. All paul_irish wanted to show is that people often use jQuery without realizing that most of what they do is also possible with the current browser APIs. jQuery does a ton more (animation, ajax etc) - the point was not to "rewrite jQuery in 10 lines" (that's Zepto)

Zepto is more of a "provide the jquery interface you're used to" (and that people often find easier, probably by habit) for modern browsers without all the added compatibility in jquery. I don't like the way they present themselves (or at least did in the early days) but I believe they have a place.

I tried "Flot" charts library with zepto as a smaller replacement for JQuery, but it was incompatible with JQuery and uses a weird code style that is incompatible/slow with Firefox (and Zepto devs refuse to fix their code). In the end I replaced the few Jquery dependencies in Flot by hand. It's a shame that Flot still requires Jquery, it's a good charts library.

The primary problem is that the zepto.Z function overrides dom.__proto__, which prevents many JIT optimizations. Overriding an object's __proto__ property is strongly discouraged and will be deprecated in ES6 --Firefox bug 947048

Um, isn't the point of Zepto a modular jQuery that may not support 100% of what jQuery does but it tries to at about the same speed (or better)?

I think modern jQuery is already modular (or semi-modular) and you can download a build of it that contains the features you want.

But honestly, if you load jQuery from a big-time CDN, chances are your users already have it cached and don't need to load anything.

The subtitle of the article is "Because you want the $ of jQuery without the jQuery". With such an ambiguous statement, I think we can afford ceronman the benefit of the doubt.

Furthermore, I don't think he's making up a strawman at all now matter how you look at it. He agreed with the article. You CAN re-implement jQuery in 10 lines of code if all you want is 0.1% the functionality of jQuery. That's what the article said and it is true. It's not an argument against any perceived strawman.

The next paragraph was praise for jQuery and the final paragraph said it's fine to not use jQuery and added an opinion about what "these kinds of posts seem like". Where's the strawman?

> The subtitle of the article is "Because you want the $ of jQuery without the jQuery". With such an ambiguous statement, I think we can afford ceronman the benefit of the doubt.

Headlines are supposed to be ambiguous, in the sense that they are much shorter than the content they accompany (and thus there are fewer possible headlines than there are possible articles). You're expected to read the content.

I would agree with your comment, but the author is not claiming to be reimplementing jQuery in 10 lines of code. He's merely providing a way to benefit from the syntactic sugar ($) to avoid using the verbose vanilla JS API (document.querySelectorAll) and solve the issue of NodeList not supporting the functionality available on Arrays (forEach, map, etc), which doesn't make any sense in the first place.

I wrote this thing because I wanted the classic jQuery API goodness for 1) grabbing elements and 2) binding events. Yes, obviously this gist doesn't cover the feature set of jQuery; and in my brief readme, I hope I didn't convey something different.

We will always need jQuery. We need a well maintained library that addresses browser inconsistencies and provides a better API. (Don't expect my gist to be maintained like jQuery is. :) I wrote a doc a year ago documenting all the bugs jQuery fixes for you (linked elsewhere in this thread). The jQuery team is talented and I respect their dedication and work greatly. I'm also interested in a conversation about what developers want most from their browser JS stdlib. Because whatever a developer's answer is, shouldn't they be able to get a custom build of that?

Hey dude, first of all, thanks for all the stuff over the years. Second, this is really great. This is exactly what I was looking for this afternoon. I need to select some elements and bind an event, nothing more. You rock!

Why did you choose those two functions? There are already small NPM modules like dom-events for attaching and triggering events, and qwery, or sizzle for querying selectors.

> If you don't use all the features, nowadays you can just create a custom build with the stuff you want.

Yes, that's precisely the author's point, except that you might not even need to make custom jQuery builds. You might be able to just use these few lines.

> But these kind of posts seem like mockery on the developers of a library that has provided extreme value for thousands for developers over many years.

There is absolutely no implication of mockery, and anyone who knows anything about Paul Irish knows how laughable that accusation is.

For what it's worth I agree with you; in the end for better or worse jquery is a very good default in that it contains tonnes of debugged code that is tested by literally millions of people in production. It should probably be broken up further but I think they are doing that.

Whenever I've decided I know best and used Zepto or something else it introduces weird bugs and then someone decides we need to support IE8 because their Dad still uses it...

wow, storm in a tea cup much? He clearly mentions implementing '$', and nothing else ...

`$` is the point of entry to almost everything jquery provides, so he's not implementing jquery's `$` since the gist does not come even remotely close to jquery's featureset. He's implementing a completely different function with the same name.

If behaviour is considered irrelevant, here's my one-line implementation of $:

    var $;

But the post isn't claiming to provide everything that Jquery provides just replacing the "$" function. The "$" does two things in jQuery.

1. Its the DOM selection function. This is what he's replacing. This is the real "functionality" of the $ function. The main bit missing is that it won't create a new element if you pass in a string.

Return a collection of matched elements either found in the DOM based on passed argument(s) or created by passing an HTML string.

2. Its a Namespace for all the rest of Jquery. This is NOT what Paul's replacing but is kind of ancillary and really just good housekeeping for a js lib.

3. It also provides a DOMContentLoaded handler.

$(function(){console.log('DOMContentLoaded')})

Reply on news.ycombinator.com