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.

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.

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.

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.

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.