> 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.