Hacker News Reader

The text of You Might Not Need jQuery says the following:

> If you're developing a library on the other hand, please take a moment to consider if you actually need jQuery as a dependency.

Maybe I am mistaken but it seems to me that this site targets library developers who use jQuery without realizing that they're forcing it on users as a transitive dependency. It does not seem to apply to end-users writing simple tools.

Struggle with vanilla JS is my inspiration for writing this, which was up voted 20 times: https://news.ycombinator.com/item?id=19946032

I don't disagree that you should know core concepts of what you're writing. I write a lot of Go without any heavy abstraction libraries (i.e ORMs) and have done with others like PHP in the past too.

With abstraction there has to be a balance though. Sure, I concede that knowing how it works is actually important, hence why I've spent a lot of time doing things without libraries in the past, especially as I was learning. It actually enrages me when people who've only ever used ORMs make super basic mistakes when writing and executing SQL themselves for the first time, i.e selecting a bunch of relationships in a loop one by one, instead of getting them all in one query. Stuff like that is a good example of how only ever working with abstracted versions of your tech stack results in mistakes down the line that have costs, since the abstracted version doesn't explain these concepts to you.

However, when it comes to actually trying to get things done efficiently, abstraction can help a bunch. Writing a bunch of stuff from scratch every time is not particularly productive either.

> Writing a bunch of stuff from scratch every time is not particularly productive either.

If you were to describe that in offline terms applications would be like books and abstractions would be like parts of the books. In order to make effective use of the book you still have to read, from scratch (whatever that means). When you become well versed in reading and writing it doesn't feel like a chore and you become far more efficient at it than simply guessing at the material from selected paraphrases. Programming is no different.

I'm not really sure what you're saying at all? It seems like we have agreed but I simply cannot comprehend your example.

The point I was making is that we could all spend our time going as deep as possible with as little abstraction as possible and end up writing stuff in assembly because "it's important to know how something works".

There is always a cost/benefit with abstraction when it comes to getting things done.

So what was the struggle with vanilla js?

I'm just curious :)

One of the first things I learned in web development was jquery but right now I never use it. Even if I create a vanilla html/css/js website.

Not really a struggle, but why would you want to type ten lines when two will do?

This is exactly it summarised. It's more frustration at the extra verbosity I had to put in to do something I'd become so accustomed to doing in a line or two.

Isn't that different reduced a lot with ES6+? By adding jQuery load time increase by almost a second or two

> Isn't that different reduced a lot with ES6+?

ES6+ does not replace browser APIs. There's no ES6+ way around this:

    const el = document.createElement(...)
    el.setAttribute(...)
    el.classList.toggle(...)
    
    const parent = document.getElementById(...)
    parent.appendChild(el)

You either do that in one line of jQuery, or end up writing your own wrappers if you need to do this more than once.

I personally prefer what you just outlined over jQuery.

It's more explicit—that will almost always win with me.

That was simplified code to create just one element and add it to the DOM.

Once you write it not once, but twice, or five times, you will either switch to a lib/framework, or to jQuery, or will write your own wrapper not that different from jQuery.

Not for something so simple. It's trivial to abstract small, oft-repeated actions like that to their own function. As I do, regularly. And then I can give it a readable name, like `createElement` or `insertElement` with an interface like:

    insertElement(type: string, text?: string. attributes?: object, parent?: string): void;

I prefer writing something like that with some minor case-handling over pulling in a library every time I meet a repeatable fragment.

If I know I'm going to run into a large host of needs, then it's a different story. But most of the time I find jQuery overkill and somewhat opaque.

I wonder why you found necessary to repeat what I said but in different words? :)

But I expressly wouldn't include a 30-100k library just to wrap a couple of repeated functions.

I happily write them myself. It's a few seconds of work, really.

The reusable functions you need from jQuery likely don't justify jQuery's size. It's better to write or copy/paste wrappers for everything you need.

Browsers are an interesting place since the language we compile to there is generally human readable when compared to assembly lang/machine code but that "more explicit" is something that we've come to reject in general development so I'm curious why it's persisted in the browser world. People[1] don't reject C/C++ because they're putting two much distance between you and the bare metal assembly statements, instead the tradeoff of readability and expressiveness is accepted as correct code is always better than fast code - so why in the browser do we still demand the bare metal option?

[1] Okay, there are some people, they're rare and generally regarded as weird.

Okay, then I need an addendum:

Explicit [within the context of the language]. And by that I did mean human readable.

    const divElement = document.createElement("div");
    divElement.textContent = "Hello world";
    document.appendChild(divElement);

Is more human readable to me than the jQuery abstraction (that pulls in piles of other potentially unused tooling) than:

    $(document).append("div").text("Hello, world");

It's more verbose, sure. But like I said in another comment, if I have to repeat the methods more than twice I'd probably just wrap the couple of lines into a function, like:

    function createTextElement(type: string, text: string): void {
        const element = document.createElement(type);
        element.textContent = text;
        document.appendChild(element);
    }

And anywhere that's called it's quite clear what is being done

    createTextElement("div", "Hello world");

This seems to be preferred when writing C as well, no? Rather than abstracting common methods to more opaque symbols?

Maybe it's just me, but I prefer the English, descriptive version and I prefer working with code formatted the same way. The language (JS) has plenty of quirks as it is.

Comparing C/Assembly I don't think is a 1:1 fair comparison, though. Unless you're including TypeScript—which is how I tend to write JS anyway (whenever possible).

> if I have to repeat the methods more than twice I'd probably just wrap the couple of lines into a function, like:

I wrote in a sibling comment:

Once you write it not once, but twice, or five times, you will either switch to a lib/framework, or to jQuery, or will write your own wrapper not that different from jQuery.

There are a lot of answers to that question, but they all summarize down to: you are the developer not the user.

* Perhaps those 10 lines execute faster

* Perhaps those 10 lines are exactly 10 lines, where jQuery is 2 lines plus a 65k library

* Perhaps those 10 lines work equally in multiple environments (node, deno, electron, browser) where jQuery does not.

* Perhaps those 10 lines sit behind a custom abstraction that actually looks like a single method

* Perhaps those 10 lines do something jQuery does not

* Perhaps those 10 lines scale and extend in ways jQuery does not

* Perhaps those 10 lines have a desired side effect

> * Perhaps those 10 lines work equally in multiple environments (node, deno, electron, browser) where jQuery does not.

Heh, and here we come full circle. I remember back when the whole point of jQuery was to handle the different underlying JS implementations for you.

Yeah, that always passed me off. I had little trouble writing cross browser code, but to be helpful jQuery would add code especially for IE that always got in the way when debugging cross browser compatibility problems.

I'm the user of the language, and JS is a bad user experience.

The fetch API is nowhere as convenient as the jQuery one.

It requires craft to get addEventListener() on par with on().

jQuery comes with many implicits loops that save you time.

fadeIn() is easier to handle than the equivalent css. jQuery supports edge if you target it (things like prepend(), parent() work on it).

Error handling is just better. E.G: jQuery().val() will not raise an error if there is no match while document.getElementById().value will.

And probably a hundred of other little details that won't come out of my head but that will grind my gear if I start working on code.

Chaining is awesome to manipulate DOM. The imperative API is very verbose.

So. Many. Plugins.

I'm more of a VueJS guy now, but if I have only a quick page to setup, the 30ko of jquery are better than anything I can produce to wrap my repetitive code.

Interesting all of these points for me are kind of a non-issue.

The fetch API is more powerful than the Jquery one.

Since forEach is implemented in es6 I just use that.

I see the point that you need it sometimes but still I would prefer some other lighter solutions.

There's a mixed-content warning because the original site doesn't have a valid HTTPS cert but yours forces HTTPS, you might want to fix that.

Fixed that and edited it up a bit.

Getting a

> Error code: SSL_ERROR_BAD_CERT_DOMAIN

trying to access https://youmightneedjquery.com .

The Github certificate takes a while to sign so I've turned off enforcement for the time being :).

You have some pretty unidiomatic JS in there. For example:

Array.prototype.filter.call(document.querySelectorAll(selector), filterFn);

What's more idiomatic is document.querySelectorAll(selector).filter(filterFn)

The same holds for forEach.

I suggest you look into how javascript prototype based OOP works

I didn't make the site, it's a fork of the original website by Hubspot.

.filter() is not a method on the NodeList though, it only has forEach(), and even that is quite recent.

This is why people convert it to an array, and one of many reasons the standard JS API (and the DOM one in particular) are annoying to work with.

There are still more idiomatic methods you can use, ie:

    [...document.querySelectorAll(selector)].filter(filterFn);

That's a significantly newer syntax, so I wouldn't say it's "more idiomatic" than explicitly referencing the original function on the prototype (which is idiomatic to JS) and was the way to do it until the spread proposal, Array.from, and similar additions, what, ~5 years ago?

If anything isn't that code _less_ idiomatic in that it's less specific to JS and more of a generic operation?

In this instance I understood it to be idiomatic as it calls a JS Array constructor and iterates on the passed parameter to create it. It's been more common than the call/apply methods for years—at least as far as I've seen. The use of the array literal is always preferred, AFAIU.

I agree it'll probably become the new idiom in JS, but it probably needs another few years to begin taking over from the idiom that existed for decades before (and still works).

If you've seen that more common than call/apply for years then you probably work almost exclusively on new projects, with people that convert things to bleeding-edge, or with heavy transpilation: The spread operator as used there has only existed in regular released browsers/node for 3-4 years. I don't think it's a stretch to say the vast majority of code out there at this time won't be doing it that way.

Yeah could be. And my client base, as it were, are solely internal to the company I work for at this time and we have some knowledge and some cooperation over what versions of browsers people are using when it comes to web-based software. So support for older systems is largely unnecessary. That and building node backends the ES version doesn’t affect them anyway.

Definitely colours my work, and knowledge base.

your link above is https://youmightneedjquery.com" <--- quote was in the link.

Ah, I've just removed the quotes. Thanks.