Hacker News Reader

Comment by lampe3 | Hacker News Reader

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.

View on HN

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.

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.

Reply on news.ycombinator.com